สถาปัตยกรรมองค์กร ตอนที่ 1: แผนที่ที่ทำให้ระบบในโรงงานไม่ต่างคนต่างทำ

โรงงานส่วนใหญ่ไม่ได้ขาดระบบ แต่มีระบบมากเกินไปจนไม่มีใครเห็นภาพรวม ฝ่ายผลิตมีโปรแกรมของตัวเอง คลังมีอีกตัว งานซ่อมบำรุงใช้ Excel และรายงานผู้บริหารต้องมีคนรวบรวมตัวเลขด้วยมือทุกสิ้นเดือน สถาปัตยกรรมองค์กร (Enterprise Architecture หรือ EA) คือวิธีวาดแผนที่ของทั้งหมดนี้ แล้วใช้แผนที่นั้นตัดสินใจว่าจะสร้าง ซื้อ เชื่อม หรือเลิกใช้ระบบไหน

บทความชุดนี้มี 5 ตอน สรุปจากวิชาการจัดการเทคโนโลยีดิจิทัลเชิงกลยุทธ์ที่ผมเรียนในระดับปริญญาโท และเล่าว่าผมนำแต่ละส่วนไปใช้กับโรงงานอย่างไร ตอนนี้เป็นภาพรวม

ปัญหาที่สถาปัตยกรรมองค์กรแก้

ในตำราเรียกปัญหานี้ว่า IT silo คือระบบที่ต่างคนต่างทำ อาการที่ผมเห็นในโรงงานตรงกับที่ตำราบรรยายแทบทุกข้อ

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

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

สี่ชั้นที่ต้องมองให้ครบ

สถาปัตยกรรมองค์กรแบ่งเป็นสองฝั่ง ฝั่งธุรกิจเป็นตัวนำ ฝั่งไอทีเป็นตัวตาม

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

ทั้งสี่ชั้นครอบด้วยการจัดการการเปลี่ยนแปลงและธรรมาภิบาล ซึ่งเป็นส่วนที่ทำให้พิมพ์เขียวไม่ถูกวาดครั้งเดียวแล้วทิ้งไว้ในลิ้นชัก ผมจะเล่าส่วนนี้ในตอนที่ 4

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

สี่ขั้นของการทำ

1. ศึกษาวิสัยทัศน์ พันธกิจ ค่านิยม และโครงสร้างองค์กร เพื่อเห็นภาพรวมก่อน ยังไม่ต้องลงรายละเอียดทุกเรื่อง
2. สำรวจสภาพปัจจุบัน (as-is) ว่ามีงานอะไร ใครรับผิดชอบ ใช้แอปอะไร ข้อมูลอยู่ที่ไหน และมีปัญหาอะไร
3. ออกแบบสภาพที่ต้องการ (to-be) ได้รายการทางแก้ทั้งหมด และพิมพ์เขียวที่เห็นภารกิจหลัก ภารกิจรอง โครงสร้างพื้นฐาน และแอปทั้งหมดในหน้าเดียว
4. สรุป นำเสนอ และพัฒนาต่อเนื่อง เป็นเอกสารโครงการที่มีขอบเขต ระยะเวลา ผลที่คาดว่าจะได้ และมาตรฐานเทคโนโลยีที่เกี่ยวข้อง

ตารางสำรวจสภาพปัจจุบัน: เครื่องมือที่ผมใช้บ่อยที่สุด

ขั้นที่ 2 ใช้ตารางจัดวางธุรกิจกับไอที (business and IT alignment worksheet) หนึ่งแถวต่องานหนึ่งงาน ผมปรับคอลัมน์ให้เข้ากับโรงงานแบบนี้

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

ตารางแค่สามแถวนี้บอกงานถัดไปได้แล้ว แถวแรกคือฟอร์มที่ควรย้ายขึ้นมือถือก่อน แถวที่สองกับสามบอกว่าต้องมีทะเบียนเครื่องจักรกลางที่ทุกระบบใช้ร่วมกัน ผมเล่าเรื่องนี้ต่อในตอนที่ 3

ตำราประมาณว่าองค์กรหนึ่งมีแผ่นออกแบบลักษณะนี้ราว 25–35 แผ่น แต่ละแผ่นจะกลายเป็นกล่องหนึ่งกล่องในพิมพ์เขียว

สิ่งที่ผมเรียนรู้จากการใช้จริง

• เริ่มจากธุรกิจเสมอ ทุกครั้งที่ผมข้ามไปคุยเรื่องระบบก่อน งานจะวนกลับมาที่คำถามว่า "แล้วโรงงานต้องการอะไร" อยู่ดี
• ตารางสำรวจต้องกรอกที่หน้างาน คำตอบในห้องประชุมกับสิ่งที่คนทำจริงที่หน้าเครื่องมักไม่ตรงกัน
• พิมพ์เขียวหน้าเดียวคุยกับผู้บริหารได้ดีกว่าเอกสาร 50 หน้า ผู้บริหารต้องการเห็นว่าจะลงทุนอะไรก่อน และลงทุนแล้วได้อะไร
• ไม่ต้องทำครบทั้งองค์กรในรอบแรก เลือกหนึ่งสายการผลิตหรือหนึ่งกระบวนการ ทำให้เห็นผล แล้วขยาย

ตอนต่อไปจะลงรายละเอียดชั้นธุรกิจและแอปพลิเคชัน ว่าเลือกแอปให้เหมาะกับหน้างานอย่างไร เช่น ทำไมงานที่หน้าเครื่องควรเป็นแอปมือถือที่ทำงานได้แม้สัญญาณไม่ดี

อ้างอิง

ดนัยรัฐ ธนบดีธรรมจารี และ วรัญญา ปุณณวัฒน์. (2565). การออกแบบสถาปัตยกรรมองค์กร. ใน ประมวลสาระชุดวิชาการจัดการเทคโนโลยีดิจิทัลเชิงกลยุทธ์. สำนักพิมพ์มหาวิทยาลัยสุโขทัยธรรมาธิราช. ISBN 978-616-16-2818-5

The Open Group. The TOGAF Standard. https://www.opengroup.org/togaf

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