Conway's Law กับ ERP: ทำไมโครงสร้างองค์กรกำหนดรูปร่างระบบที่คุณจะได้

30 มิถุนายน 2569อ่าน 7 นาที
Conway's Law กับ ERP: ทำไมโครงสร้างองค์กรกำหนดรูปร่างระบบที่คุณจะได้

ระบบที่องค์กรสร้าง มักสะท้อนวิธีที่ทีมสื่อสารกัน ถ้าแผนกไม่คุยกัน ERP ก็จะกลายเป็นเกาะข้อมูลที่ต่อกันไม่ติด เข้าใจ Conway's Law ก่อนเริ่มโครงการ ช่วยให้วางระบบไม่ผิดตั้งแต่ต้น

Conway's Law บอกว่า ระบบที่องค์กรออกแบบ จะสะท้อนโครงสร้างการสื่อสารขององค์กรนั้น พูดง่าย ๆ คือ ถ้าฝ่ายขายกับฝ่ายบัญชีไม่เคยคุยกันจริงจัง ERP ที่ได้ก็มักจะมีโมดูลขายกับบัญชีที่เชื่อมกันแบบลวก ๆ และต้องคีย์ซ้ำตรงรอยต่อ นี่คือเหตุผลที่หลายโครงการ ERP ล้มเหลวด้วยเรื่องคน ไม่ใช่เรื่องเทคโนโลยี

รอยต่อของระบบ อยู่ตรงรอยต่อของทีม

เวลา ERP มีปัญหา ข้อมูลไม่ตรง รายงานไม่ครบ มักไม่ได้เกิดกลางโมดูล แต่เกิดตรงที่ข้อมูลต้องส่งข้ามแผนก เช่น ใบสั่งซื้อจากจัดซื้อไปคลัง หรือใบกำกับจากขายไปบัญชี ถ้าสองทีมนี้มีเป้าหมายและนิยามข้อมูลที่ต่างกัน ระบบจะถูกบังคับให้สะท้อนความขัดแย้งนั้น และไม่มีการ customize ใดแก้ได้ถ้าต้นเหตุคือคนไม่ตกลงกัน

ใช้กฎนี้ให้เป็นประโยชน์: ออกแบบทีมก่อนออกแบบระบบ

  • ตั้งเจ้าของกระบวนการข้ามแผนก (process owner) ไม่ใช่แค่เจ้าของโมดูล
  • นิยามข้อมูลกลางร่วมกันก่อน เช่น ลูกค้าหนึ่งราย หมายถึงอะไรในทุกแผนก
  • จัดทีมโครงการให้สะท้อนการไหลของงานจริง ไม่ใช่ตามผังองค์กรเดิม

ก่อนเซ็นสัญญา ERP ลองวาดแผนผังว่าใครต้องส่งข้อมูลให้ใคร แล้วถามว่าทีมเหล่านั้นมีเวทีคุยกันจริงไหม ถ้าไม่มี ให้สร้างมันก่อน เพราะคุณกำลังจะฝังโครงสร้างการสื่อสารวันนี้ลงในระบบที่จะอยู่กับองค์กรไปอีกหลายปี

Conway's LawERPองค์กรIntegration

บริการที่เกี่ยวข้อง

รับวางระบบ ERP

รวมบัญชี สต๊อก การขาย และการผลิตไว้ในระบบเดียวที่เชื่อมกันทั้งธุรกิจ

WhaleScope

ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope

รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล

อ่านต่อ

เมื่อทุกแผนกอยากได้ระบบของตัวเอง

แต่ละแผนกเลือกเครื่องมือที่ดีที่สุดสำหรับตัวเอง แล้ววันหนึ่งบริษัทก็พบว่าตัวเองมีความจริงสิบเวอร์ชัน และไม่มีเวอร์ชันไหนตรงกันเลย

Function Calling: ให้ AI เรียกใช้ระบบและคืนผลเป็นโครงสร้างที่ใช้ต่อได้

AI ที่ตอบเป็นข้อความอิสระ นำไปต่อในระบบยาก Function Calling ให้ AI คืนผลเป็นโครงสร้างชัดเจนและเรียกฟังก์ชันของเราได้ ทำให้ต่อ AI เข้ากับระบบจริงได้อย่างน่าเชื่อถือ

Change Data Capture: ซิงค์ข้อมูลแบบเห็นทุกการเปลี่ยนแปลง

การซิงค์ข้อมูลด้วยการดึงทั้งก้อนซ้ำ ๆ ช้าและหนัก Change Data Capture ส่งเฉพาะสิ่งที่เปลี่ยน ทำให้ข้อมูลระหว่างระบบตรงกันเกือบเรียลไทม์ โดยไม่กวนระบบหลัก เข้าใจว่ามันทำงานอย่างไร

Data Contract: ข้อตกลงที่กันข้อมูลพังเงียบระหว่างทีม

เมื่อทีมหนึ่งเปลี่ยนโครงสร้างข้อมูลโดยไม่บอก รายงานและระบบปลายทางพังเงียบ ๆ Data Contract คือข้อตกลงชัดเจนว่าข้อมูลจะมีหน้าตาอย่างไร เพื่อให้เปลี่ยนแปลงได้โดยไม่ทำของคนอื่นพัง