ESG Data Bridge: ทำไมต้นทุนการปฏิบัติตาม CSRD ส่วนใหญ่ไปกระจุกอยู่ที่ Layer ที่ไม่มีใครพูดถึง

ใบเสนอราคา 200 ล้านบาท กับบรรทัดที่ไม่มีใครอธิบาย

รูปแบบที่เราเห็นซ้ำๆ ในช่วงนี้ บริษัทในกลุ่มไทยขนาดใหญ่ — กลุ่ม SCG, Indorama, Thai Union, CP, ThaiBev, Banpu, PTT, Minor, Thai Beverage — ได้รับ memo ภายในยืนยันว่าบริษัทลูกในยุโรปแห่งหนึ่งเข้าข่าย CSRD (Corporate Sustainability Reporting Directive) ของสหภาพยุโรปแล้ว ยอดขายสุทธิเกิน €50M, พนักงานมากกว่า 250 คน, จดทะเบียนในตลาดหลักทรัพย์หรือมีขนาดใหญ่พอที่ Omnibus simplification ที่ผ่านในเดือนธันวาคม 2025 ก็ไม่ได้ปลดล็อกออก รายงานความยั่งยืนฉบับแรกเริ่มมีกำหนดส่ง สำนักงานสอบบัญชีนัดประชุม และกระบวนการจัดซื้อ "ซอฟต์แวร์ CSRD compliance" เริ่มเดินเครื่อง

รายชื่อ vendor มาถึง Workiva, Sphera, Greenly, Sweep, Watershed, Persefoni, Pulsora, IBM Envizi ราคาตั้งแต่ €40K ต่อปี (ประมาณ 1.5 ล้านบาท) สำหรับธุรกิจขนาดกลาง ไปจนถึง €200K ต่อปี (ประมาณ 7.5 ล้านบาท) ขึ้นไปสำหรับบริษัทใหญ่ที่จดทะเบียน บวกค่า implementation ทีม sustainability advisory ของ Big 4 ยื่นใบเสนอราคาสำหรับ "CSRD readiness" มาที่ €2–5M (ประมาณ 75–185 ล้านบาท) ครึ่งหนึ่งเป็นค่า advisory อีกครึ่งเขียนแบบกำกวมว่า "data integration และงานระบบ"

CFO ถามคำถามที่ทุกคนควรถาม ทำไม line item ของ data integration ถึงใหญ่ขนาดนี้ Reporting tool ก็มี connector มาให้แล้ว ผู้สอบบัญชีก็ยืนยันว่า platform รองรับ ESRS module แบบ native งาน integration มูลค่า 35–90 ล้านบาท หายไปไหน

นี่คือความจริงที่พูดกันน้อยที่สุดของการทำ CSRD: reporting platform เป็น 20% ที่มองเห็นของปัญหา อีก 80% คือ data bridge layer ระหว่างระบบต้นทาง (operational source systems) กับเครื่องมือรายงาน สำหรับกลุ่มบริษัทไทยที่มี operations กระจายอยู่ทั้งในไทย, จีน, เวียดนาม, อินโดนีเซีย, ญี่ปุ่น, และยุโรป — bridge นี้คือจุดที่ project พัง และเป็นที่ที่เงินจริงๆ หายไป

บทความนี้จะพูดถึงสิ่งที่ bridge นี้ทำจริงๆ ทำไม operations ในเอเชียถึงเป็น case ที่ยากที่สุด และสิ่งที่เราเรียนรู้จากการสร้าง integration middleware สำหรับ production environment ที่ audit trail ไม่ใช่ option

Reporting tool ทำอะไรจริงๆ (และไม่ทำอะไรบ้าง)

CSRD reporting platform สมัยใหม่ทำสิ่งที่มันถูกออกแบบให้ทำได้ค่อนข้างดี รองรับ data point กว่า 1,144 รายการที่กระจายใน ESRS 12 module, generate iXBRL output ที่พร้อมตรวจสอบ, จัดการ double materiality assessment, และผลิตเอกสารเปิดเผยตามรูปแบบที่ EU ต้องการ มี connector ที่สร้างไว้แล้วสำหรับระบบ enterprise ขนาดใหญ่ที่สุด — โดยทั่วไปคือ SAP S/4HANA, Oracle Fusion, Microsoft Dynamics, และ HR/CRM platform ดังๆ อีกไม่กี่ตัว

สิ่งที่มันไม่ทำ คือการแก้ปัญหาจริงที่กลุ่มบริษัทเอเชียส่วนใหญ่เจอ ซึ่งก็คือ data ที่ connector คาดหวัง ไม่มีอยู่ในระบบเหล่านั้นในรูปแบบที่ connector ต้องการ

ตัวอย่างที่เป็นรูปธรรม ESRS E1-6 ต้องการการเปิดเผย gross Scope 1 และ Scope 2 GHG emissions แยกตามทำเล แยกตามกิจกรรม พร้อมเอกสารยืนยัน emission factor และ methodology ที่ใช้ SAP connector ของ reporting tool อ่านบัญชีค่าใช้จ่ายพลังงานจาก finance ledger ของคุณ แต่ในบัญชีนั้นมีแต่ ยอดเงินตามใบกำกับภาษี เป็นบาทแยกตาม vendor ไม่ใช่แยกตาม facility ไม่ใช่แยกตามชนิดพลังงาน ไม่ใช่ kWh และที่แน่นอนคือไม่มี emission factor ติดมาด้วย Data จริงที่ต้องใช้สำหรับ Scope 2 อยู่ที่อื่น คือใน facility energy management system ของแต่ละโรงงาน, building management system ที่แต่ละ plant, หรือใน PDF ของบิลค่าไฟรายเดือนจากการไฟฟ้าฯ ที่ฝ่ายธุรการ scan แล้วโยนใส่ SharePoint folder

นี่ไม่ใช่ bug ของ software มันคือช่องว่างระหว่างความเป็นจริงของ operations กับสิ่งที่ regulator ต้องการ Reporting tool อ่าน BMS ของโรงงานที่ระยองไม่ได้ ที่ปรึกษา Big 4 ที่บินมาจาก Frankfurt ก็อ่านไม่ได้ ต้องมีใครสักคนที่ไหนสักแห่งสร้างสะพานเชื่อม

ในช่องว่างนั้นมีอะไรอยู่

จากประสบการณ์ของเราในการ implement integration ให้ผู้ผลิตและกลุ่มบริษัทในเอเชีย ระบบต้นทางที่ป้อนข้อมูล sustainability ของกลุ่มบริษัทขนาดกลางที่มี operations ทั่วโลก หน้าตาประมาณนี้:

flowchart TD
    A["ระบบต้นทางในเอเชีย"] --> B["ESG Data Bridge"]
    B --> C["CSRD Reporting Tool"]

    A1["SAP ECC / S4 HANA<br/>(TH/JP/CN regional)"] --> A
    A2["mcframe / OBIC7<br/>(โรงงาน JV ญี่ปุ่นในไทย)"] --> A
    A3["MES / SCADA<br/>(Modbus, OPC-UA)"] --> A
    A4["BMS<br/>(Building Management)"] --> A
    A5["Fleet / Logistics<br/>tracking systems"] --> A
    A6["HR / Payroll<br/>(SAP HR, ระบบในประเทศ)"] --> A
    A7["Supply chain<br/>(supplier portal, EDI)"] --> A
    A8["บัญชีในประเทศ<br/>(Express, AutoFlight, FormulaSoft)"] --> A
    A9["Spreadsheet, PDF,<br/>shared drive"] --> A

    B1["Connector layer"] --> B
    B2["ESRS data point<br/>mapping"] --> B
    B3["Emission factor<br/>library"] --> B
    B4["Validation & quality"] --> B
    B5["Multi-language<br/>normalization"] --> B
    B6["Audit log<br/>(immutable lineage)"] --> B

    C --> D["Workiva / Sphera /<br/>Greenly / in-house BI"]

ระบบทางซ้ายเป็นเรื่องจริงที่อยู่ที่หน้างานลูกค้าทั้งนั้น โรงงาน JV ญี่ปุ่นในไทย — กลุ่ม Toyota, Honda, Denso, Mitsubishi Electric, AGC, NSK, Bridgestone และพันธมิตรใน supply chain — มักจะใช้ mcframe หรือ OBIC7 ซึ่งที่ปรึกษาในยุโรปแทบไม่เคยเห็น โรงงานในเครือกลุ่มไทยรุ่นเก่า ระบบบัญชีบางครั้งยังเป็น Express, AutoFlight, หรือ FormulaSoft ซึ่งไม่มี export module ที่รับรู้ ESRS PLC ที่ shop floor ในโรงงานเก่าๆ ทั่วเอเชียยังคุยด้วย Modbus RTU หรือ proprietary fieldbus ที่ไม่มีใครแตะมา 15 ปีแล้ว

"SAP connector" ของ reporting tool ช่วยอ่านสิ่งเหล่านี้ไม่ได้สักอย่าง ที่ปรึกษายุโรปก็เช่นกัน

Bridge นี้ทำอะไรจริงๆ

Data bridge layer เชิงกลไกแล้วคือ integration platform ที่สร้างขึ้นเฉพาะสำหรับปัญหา "การแปล" ระหว่าง operations กับ regulation ส่วนประกอบที่สำคัญ:

Source-system connector ที่พูดภาษาของระบบ operational ในเอเชีย — SAP IDoc/BAPI สำหรับ SAP ระดับภูมิภาค, REST API สำหรับระบบใหม่, ODBC/SQL สำหรับระบบ legacy, file-based ingestion สำหรับ spreadsheet และ PDF ที่ไม่หายไปไหน สำหรับ data จากโรงงานต้องมี OPC-UA และ Modbus translation layer ที่ดึง energy และ production telemetry จาก shop floor

ESRS data point mapping ที่แปลง raw operational data เป็นรูปแบบที่ reporting tool ต้องการ ไม่ใช่ config ครั้งเดียวจบ — ESRS data point มีการพัฒนาเมื่อ EFRAG ออก implementation guidance ใหม่ และ mapping ต้องมี version control การเปลี่ยนวิธีคำนวณ E1-6 location-based emission ในปี 2027 ไม่ควรต้องสร้าง source-system connector ใหม่ทั้งหมด

Emission factor management พร้อม provenance การคำนวณ Scope 2 ต้องใช้ grid emission factor เฉพาะภูมิภาค และการเลือกแหล่งที่มา (IEA, ค่ามาตรฐานของ TGO กรณีในประเทศไทย, ค่าเฉพาะของ supplier) ต้องตรวจสอบได้ Scope 3 category ต้องการ factor library ตาม spend category, transport mode, และ supplier Bridge เก็บไว้ว่าใช้ factor ไหนสำหรับการคำนวณไหน เมื่อใด และทำไม

Quality validation ที่จับปัญหาก่อนที่ data จะถึง reporting platform Data ค่าไฟที่ขาดหายไปบางเดือน, outlier reading จากมิเตอร์ที่เสีย, error การแปลงสกุลเงิน, การนับซ้ำของบริษัทลูกที่ใช้ facility ร่วมกัน — ทุกเรื่องต้อง flag และแก้ตั้งแต่ upstream ของ reporting tool เพราะผู้สอบบัญชีไม่สนหรอกว่า reporting tool คำนวณถูก ถ้า input มันผิดมาตั้งแต่แรก

Multi-language และ multi-entity normalization Operational data ที่เป็นภาษาไทย, จีน, ญี่ปุ่น, เกาหลี ต้องถูก normalize เป็นหน่วยและภาษาที่ reporting framework ต้องการ ปีงบประมาณของบริษัทลูกที่ไม่ตรงกับ parent ต้องถูก reconcile การรายงานสกุลเงินท้องถิ่นต้องการการจัดการ FX ด้วย consolidation methodology ที่ถูก

Audit trail ที่แก้ไขไม่ได้ ส่วนที่ทีมส่วนใหญ่ประเมินต่ำที่สุด Limited assurance ภายใต้ CSRD กำหนดให้ผู้สอบบัญชีต้อง trace ตัวเลขที่รายงานกลับไปถึงแหล่งที่มาได้ พอ assurance เปลี่ยนจาก limited เป็น reasonable ในอีกไม่กี่ปี ข้อกำหนดนี้จะเข้มขึ้น Audit trail ต้อง query ได้, ตรวจการแก้ไขได้, และตอบคำถาม "ตัวเลขนี้มาจากไหน" ได้แม้ผ่านไปหลายเดือนหรือหลายปีหลังส่งรายงาน

Output adapter สำหรับ push data ที่ normalize แล้วเข้า reporting platform ที่ลูกค้าเลือก Bridge เป็น platform-agnostic ถ้าจัดซื้อ Workiva มาแล้ว, bridge ป้อน Workiva ถ้าปีที่ 3 เปลี่ยนจาก Greenly เป็น Sphera เพราะเหตุผลเรื่องราคา, bridge ก็ทำงานต่อโดยไม่ต้องสร้าง source connector ใหม่

จุดสุดท้ายคือจุดที่เป็นกลยุทธ์ Bridge คือ asset ระยะยาว Reporting tool คือสิ่งที่เปลี่ยนได้

ทำไม operations ในเอเชียถึงเป็น case ที่ยาก

ความท้าทายเฉพาะตัวที่ที่ปรึกษายุโรปประเมินต่ำเป็นประจำ

ความหลากหลายของระบบต้นทางสูงกว่าใน operations ของยุโรปอย่างมาก บริษัทลูกของกลุ่มไทยขนาดใหญ่เติบโตจากการ acquisition มาหลายทศวรรษ โดยแต่ละหน่วยธุรกิจตัดสินใจเรื่อง IT เอง บริษัทแม่รัน S/4HANA Thailand, ฝ่าย chemicals รัน Oracle EBS, JV ญี่ปุ่นด้านชิ้นส่วนยานยนต์รัน mcframe, โรงงานในเวียดนามรัน SAP B1, plant ในอินโดนีเซียใช้ระบบเฉพาะที่ build เอง, supply chain ในประเทศเป็น Express ขอบเขต CSRD ถูกกำหนดที่ระดับ parent แต่ data กระจายอยู่ในทุกระบบเหล่านั้น

Document-based data มีอยู่เยอะอย่างผิดปกติ ความเป็นจริงของ operations ในโรงงานไทย, จีน, ญี่ปุ่น คือใบแจ้งค่าไฟรายเดือนเป็น PDF จากการไฟฟ้าฯ ในแต่ละพื้นที่ บางครั้ง scan มา บางครั้งมีลายมือเขียนหมายเหตุ สัญญาจัดซื้อพลังงานและ PPA เป็น PDF ภาษากฎหมายภาษาไทย จีน หรือญี่ปุ่น Transport log จากพันธมิตร logistics ในภูมิภาคมาเป็น Excel attachment การปฏิบัติต่อสิ่งเหล่านี้ในฐานะ "edge case" ไม่ work ใน operations เอเชียจำนวนมาก สิ่งเหล่านี้ คือ แหล่งข้อมูลหลัก ระบบ multilingual document AI แบบ simpliDoc สำหรับการ ingest สิ่งเหล่านี้ไม่ใช่ option

Scope 3 supply chain data เป็นไปไม่ได้จริงๆ ถ้าไม่มี supplier engagement infrastructure ESRS E1-6 เรียก Scope 3 emission ใน 15 category ซึ่งหลาย category ต้องใช้ data เฉพาะจาก supplier กลุ่มบริษัทเอเชียมักมี supplier tier-2 และ tier-3 หลายพันราย ส่วนใหญ่ไม่เคยวัด emission ของตัวเองเลย Bridge ต้องการ supplier portal — ที่ที่ supplier ส่ง data ของตัวเองได้ในรูปแบบที่ structured และผ่านการ validate — ไม่อย่างนั้นต้อง fall back ไปใช้ spend-based estimation ซึ่งผู้สอบบัญชีตั้งคำถามมากขึ้นเรื่อยๆ

ข้อจำกัดเรื่อง data residency และ access Operational data ของจีนออกนอกประเทศจีนอย่างเสรีไม่ได้ภายใต้ PIPL Banking และ HR data ของญี่ปุ่นมีข้อจำกัดเรื่องการส่งข้ามพรมแดนอย่างเข้มงวด สำหรับไทยเอง PDPA และ พ.ร.บ. การรักษาความมั่นคงปลอดภัยไซเบอร์ มีข้อกำหนดเฉพาะเกี่ยวกับ data ในกลุ่ม sensitive Architecture ของ bridge ต้องจัดการเรื่องนี้ได้ — local processing, local storage, federated aggregation — ไม่ใช่แค่จาก compliance perspective แต่เพราะ audit committee ของลูกค้าจะ block architecture ที่ละเมิดข้อจำกัดเหล่านี้ ไม่ว่า EU regulator ต้องการอะไรก็ตาม

ปฏิทินและหน่วยที่ไม่ตรงกัน ปีงบประมาณของบริษัทไทยส่วนใหญ่เป็น ม.ค.–ธ.ค. แต่บริษัทในเครือที่ไปทำธุรกิจกับญี่ปุ่นมักใช้ปีงบประมาณ เม.ย.–มี.ค. การรายงานตามปฏิทินจีนได้รับผลกระทบจากเทศกาลตรุษจีนซึ่งมีผลต่อ production data หน่วยพลังงานบางระบบเป็น kWh บางระบบเป็น MJ น้ำหนักบางที่เป็นเมตริกตัน ในบันทึกของ supplier จีนแบบไม่เป็นทางการเป็น 斤 ทุกอย่างไม่ยากเป็นรายตัว แต่ผลสะสมของการทำให้ทุกอย่างถูกต้องอย่างสม่ำเสมอใน 40 source system และ 12 ESRS module เป็นงาน engineering ที่ใหญ่จริง

ในประสบการณ์ของเรา ที่ปรึกษายุโรปไม่รู้เรื่องปัญหาเหล่านี้ หรือไม่ก็ใส่ในใบเสนอราคาเป็น "to be assessed during implementation" — ซึ่งเป็นวิธีที่ project budget บานปลายในเดือนที่ 4

ส่วนยากที่ทีมส่วนใหญ่ประเมินต่ำ

ของที่เราเรียนรู้แบบเจ็บตัวจากการสร้าง integration สำหรับ production environment ที่ data ตรวจสอบไม่ได้ไม่ใช่ option

ความสมบูรณ์ของ audit trail ยากกว่าที่คิด การ log ทุก input และทุก calculation อย่างเดียวไม่พอ Audit trail ต้องอยู่รอดผ่านการเปลี่ยน source system (บริษัทลูก migrate จาก mcframe เป็น S/4HANA ในปีที่ 2 และ historical data ต้องยังถูก query ได้ในรูปแบบเดิม), การเปลี่ยน prompt หรือ methodology (IEA update emission factor ตอนกลางปี และคุณต้องรู้ว่า calculation ไหนใช้ factor เก่า ไหนใช้ factor ใหม่), และการเปลี่ยน platform (เปลี่ยน reporting tool และ audit trail ต้องตามไปด้วย)

Data lineage เป็นสัญญา ไม่ใช่ feature ผู้สอบบัญชีจะถาม "แสดงให้ดูว่าตัวเลข Scope 2 สำหรับ Q3 2027 นี้คำนวณยังไง รวมถึง kWh reading จาก facility ไหน, ใช้ emission factor จากแหล่งไหน, และ data แต่ละชิ้นถูกแก้ไขครั้งสุดท้ายเมื่อไหร่" คำตอบต้องเป็นคลิกไม่กี่ครั้ง ไม่ใช่งาน forensic นี่คือปัญหา engineering ที่ไม่ trivial ถ้า bridge ไม่ได้ออกแบบมาเพื่อสิ่งนี้ตั้งแต่วันแรก

Double materiality drift การประเมิน double materiality ที่ใช้ justify ว่า ESRS topic ไหน "material" สำหรับธุรกิจของคุณ ตามหลักแล้วต้องมีการ review เป็นระยะ ในความเป็นจริง data ที่ป้อนการประเมินนั้นเปลี่ยนทุกเดือนเมื่อมี operations ใหม่เริ่มหรือถูกขาย Bridge ต้อง support ไม่ใช่แค่ flow ของ data แต่รวมถึง metadata เกี่ยวกับ อะไรอยู่ใน scope ในงวดนี้และทำไม

Methodology versioning การคำนวณ Scope 3 Category 11 ที่ทำในปี 2027 ด้วย methodology หนึ่ง และทำอีกครั้งในปี 2028 ด้วย methodology ที่ update แล้ว จะออกตัวเลขต่างกัน Year-over-year comparability ต้องการให้คุณเก็บไม่ใช่แค่ data แต่รวมถึง methodology version และต้องสามารถคำนวณ historical period ใหม่ on-demand ได้ถ้า audit หรือบอร์ดถาม

Failure mode "ใช้ Excel ไปก่อน" มันยั่วใจจริงๆ โดยเฉพาะใน reporting cycle แรก ที่จะ bridge data ด้วย Excel กับมือ ทำได้แค่ครั้งเดียว เป๊ะๆ พอถึง cycle ที่ 2 หรือ 3 ปริมาณ data, ข้อกำหนด audit, และ timeline การรายงานทำให้การ bridge ด้วยมือเป็นไปไม่ได้ ทีมที่เริ่มด้วย Excel ในปีที่ 1 คือทีมที่จ่ายค่าที่ปรึกษาฉุกเฉิน 100 ล้านบาทในปีที่ 3 เพื่อแก้

ต้นทุนจริงและสิ่งที่ประหยัดได้

กรอบ budget ที่สมจริงสำหรับกลุ่มบริษัทไทยขนาดกลางที่มี 8–15 entity อยู่ใน CSRD scope:

ใบเสนอราคา Big 4 สำหรับ implementation แบบ custom ทั้งหมด รวมงาน data integration อยู่ในนั้น จะอยู่ที่ €1.5–4M (ประมาณ 55–150 ล้านบาท) สำหรับปีแรก พร้อม €400–900K (15–34 ล้านบาท) สำหรับ ongoing maintenance ส่วนใหญ่เป็นค่า labor ของ advisory partner และ manager ที่อัตรา €350–600/ชั่วโมง (13,000–22,000 บาท/ชั่วโมง)

Data bridge layer ที่สร้างเฉพาะกิจ scope ตาม source-system surface และ ESRS reporting requirement เดียวกัน จะอยู่ที่ประมาณ 30–50% ของต้นทุนนั้นในปีแรก และน้อยลงอย่างมีนัยสำคัญในปีต่อๆ มา — เพราะ bridge เป็น asset ที่ reuse ได้ ไม่ใช่ billable engagement ที่เริ่มใหม่ทุก reporting cycle งานที่เคยเป็น variable cost กลายเป็น fixed asset

ประโยชน์ที่ไม่ใช่ต้นทุนคือ reporting timeline รายงาน CSRD ในประเทศสมาชิก EU ส่วนใหญ่ต้องส่งภายใน 4 เดือนหลังสิ้นปีงบประมาณ Bridge ที่ delivery clean, audit-ready data feed ภายใน 48 ชั่วโมงหลัง period close ให้ทีม sustainability และ finance ของคุณมีเวลาทำงานจริงก่อน auditor มาถึง process แบบ manual หรือ Excel-based ให้ panic week และ deferred audit qualification risk

ใครคือคนที่มีปัญหานี้จริงๆ

ถ้าคุณกำลังอ่านอันนี้อยู่ และมีอย่างใดอย่างหนึ่งดังต่อไปนี้เป็นจริง ปัญหาที่อธิบายในบทความนี้ไม่ใช่เรื่องนามธรรมสำหรับคุณ กลุ่มบริษัทของคุณคือ parent company ในไทย, จีน, ญี่ปุ่น, เกาหลี, หรือไต้หวัน ที่มีบริษัทลูกในยุโรปหนึ่งหรือมากกว่าที่ข้าม CSRD threshold Sustainability data ของคุณกระจายอยู่ในระบบต้นทาง 15 ระบบขึ้นไป โดยมีอย่างน้อยหนึ่งใน mcframe, OBIC7, regional SAP installation, factory MES, ระบบบัญชีในประเทศแบบ Express หรือ AutoFlight, หรือใบแจ้งค่าไฟแบบ PDF ใบเสนอราคา Big 4 ใบแรกสำหรับ "CSRD readiness" ทำให้คุณรู้สึกไม่สบายใจ และความไม่สบายใจส่วนใหญ่มาจาก line item ของ data integration Vendor ของ reporting platform ที่คุณใช้ ไม่มีระบบที่ data จริงของคุณอยู่ในรายการ connector

ข่าวดีคือ นี่คืองาน engineering ไม่ใช่ปาฏิหาริย์ ข่าวร้ายคือ บริษัทที่ปรึกษายุโรปทำงาน engineering นี้ไม่ได้ เพราะ source system อยู่ในเอเชีย, ความจริงของ operations อยู่ในโรงงานในเอเชีย, และ integration pattern ต้องการคนที่อ่าน error message ภาษาญี่ปุ่นได้, เดิน shop floor โรงงานจีนได้, คุยกับหัวหน้าโรงงานคนไทยรู้เรื่อง คนที่จะสร้าง bridge นี้ต้องอยู่ใกล้ data ทั้งทางกายภาพและทางภาษา

นอกจาก CSRD แล้ว แรงกดดันการเปิดเผย ESG ยังขยายเข้ามาในไทยเองด้วย — One Report ของ ก.ล.ต., มาตรฐาน TCFD ที่ตลาดหลักทรัพย์ฯ ผลักดัน, แนวทางการประเมิน carbon footprint ของ TGO, และร่าง พ.ร.บ. การเปลี่ยนแปลงสภาพภูมิอากาศที่กำลังจะเข้าสภา การสร้าง data infrastructure ที่ถูกต้องตั้งแต่ตอนนี้ ไม่ได้ตอบโจทย์แค่ CSRD ของบริษัทลูกในยุโรป แต่ตอบโจทย์ความต้องการเปิดเผยที่จะเข้ามาเรื่อยๆ ในไทยด้วย

ถ้าคุณกำลัง scope การ implement CSRD อยู่ และ line item ของ data integration ทำให้ CFO รู้สึกไม่สบายใจ — นั่นคือบทสนทนาที่เราคุยกันที่ Simplico เราสร้าง integration middleware สำหรับระบบ operational ในเอเชียมานานกว่า 10 ปี — นานพอที่จะรู้ว่า mcframe พูด protocol ไหนจริงๆ, ทำไม export module ของ OBIC7 ถึงช่วยไม่ได้, และต้องทำอะไรบ้างเพื่อให้ energy data จาก PLC ของโรงงานสามารถ defend ใน audit ได้ CSRD เพิ่งเปลี่ยนงานนี้จาก nice-to-have เป็นโครงสร้างที่รับน้ำหนักของการเข้าตลาดยุโรป