Toshio Koga | กรรมการบริษัท SimLex Development Co., Ltd.

 

นับตั้งแต่ก่อตั้งบริษัท ผมได้มีส่วนร่วมในการออกแบบ SimLex ERP มาโดยตลอด อย่างไรก็ตาม แนวคิดของ SimLex ERP ไม่ได้เกิดขึ้นมาอย่างกะทันหันในตอนที่ก่อตั้งบริษัท แต่มันเกิดจากการสะสมความคิด ข้อสงสัย และคำถามที่ผมรู้สึกผ่านการทำงานมาโดยตลอดก่อนที่จะตั้งบริษัท เช่น “เราจะทำให้มันเข้าถึงแก่นแท้ และเรียบง่ายกว่านี้ไม่ได้หรือ?”

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

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

ผมหวังว่าการได้รับรู้เส้นทางนี้ จะช่วยให้คุณเข้าใจ SimLex ERP ในปัจจุบัน ไม่ใช่แค่ในฐานะผลิตภัณฑ์ ERP ชนิดหนึ่ง แต่เข้าใจไปถึงแนวคิดที่เป็นภูมิหลังของมันด้วย

บทที่ 1: “ถ้ายกเลิกคลังสินค้านั้น จะเกิดอะไรขึ้น?” …จุดเริ่มต้นจากเเนวคิด Petri Net

หลังจากจบการศึกษาจากมหาวิทยาลัย ฉันได้งานที่บริษัทผู้ผลิตตลับลูกปืนรายใหญ่แห่งหนึ่ง

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

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

ในตอนนั้น ฉันไม่เคยคิดเลยว่าการได้เจอหนังสือเล่มนี้จะเปลี่ยนแปลงชีวิตฉันไปอย่างมากมาย

สิ่งที่เขียนไว้ในนั้นคือทฤษฎีที่เรียกว่าเครือข่ายเพทรี (Petri net)

แนวคิดของโครงข่ายเพทรีนั้นง่ายมาก

สรุปได้ว่า“เราจะจำลองโลกแห่งความเป็นจริงโดยใช้เพียงองค์ประกอบที่จำเป็นที่สุดได้อย่างไร”

ในหนังสือเล่มนั้น มีคำถามหนึ่งที่ดึงดูดความสนใจของฉันเป็นอย่างมาก

“จะเกิดอะไรขึ้นถ้าเรากำจัดโกดังนั้นทิ้งไป?”

การอ่านหนังสือเล่มนี้เป็นประสบการณ์ที่ลึกซึ้งและประทับใจอย่างยิ่ง

อันที่จริง หากเราสามารถกำจัดคลังสินค้าออกไปได้ทั้งหมด การรับและส่งสินค้าทั้งหมดก็จะไม่มีความจำเป็นอีกต่อไป งานบริหารจัดการคลังสินค้า ระบบการจัดการ และแม้แต่ตัวอาคารคลังสินค้าเองก็จะไม่มีความจำเป็นเช่นกัน

แทนที่จะใช้ “คลังสินค้า” ที่มีอยู่แล้วและสมมติว่ามันมีอยู่จริง แล้วจึงวางแผนปรับปรุงโดยอิงจากสมมติฐานนั้น ผมเริ่มตั้งคำถามกับพื้นฐานที่สุดว่า “คลังสินค้าจำเป็นจริงหรือ?” การเปลี่ยนความคิดครั้งนี้เป็นประสบการณ์ที่ทรงพลังสำหรับผมในฐานะคนหนุ่มสาว

และในขณะเดียวกัน ฉันก็ได้ตระหนักถึงความจริงที่สำคัญอีกประการหนึ่ง

“ตัวโกดังเองไม่ได้สร้างมูลค่าเพิ่มใดๆ”

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

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

ทันทีที่ฉันเปลี่ยนมุมมอง ทิวทัศน์โรงงานที่ฉันเคยดูธรรมดาๆ ก็เริ่มดูแตกต่างไปอย่างสิ้นเชิง

คำถามเปลี่ยนจาก “เราจะทำให้คลังสินค้ามีประสิทธิภาพมากขึ้นได้อย่างไร” ไปเป็นคำถามเชิงโครงสร้างมากขึ้นว่า “เป็นไปได้หรือไม่ที่จะกำจัดคลังสินค้าออกไปทั้งหมด”

สำหรับผมแล้ว แนวคิดนี้เป็นมากกว่าแค่วิธีการปรับปรุงระบบโลจิสติกส์

“แทนที่จะทำการเปลี่ยนแปลงเล็กน้อยซ้ำๆ โดยอิงจากสิ่งที่มีอยู่แล้ว เราควรตั้งคำถามถึงการดำรงอยู่ของผลิตภัณฑ์นั้น และวิเคราะห์มันให้เหลือเพียงแก่นแท้”

นี่คือช่วงเวลาที่ปรัชญาหลักซึ่งต่อมาจะกลายเป็นพื้นฐานของการออกแบบระบบที่ผมจะทำงานด้วย และสำหรับ SimLex ERP ได้เริ่มหยั่งรากเป็นครั้งแรก

เพทริเน็ตทำให้ฉันมองเห็นมุมมองที่กว้างขึ้น

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

“แทนที่จะคัดลอกงานที่ซับซ้อนซึ่งมีอยู่จริงมาใส่ในระบบ เราดึงเอาเฉพาะแก่นแท้ของธุรกิจออกมา และกำหนดนิยามใหม่ให้เป็นโครงสร้างที่สวยงาม”

หลายทศวรรษต่อมา แนวทางพื้นฐานนี้ได้พัฒนาจนกลายเป็นผลิตภัณฑ์จริง นั่นก็คือ “SimLex ERP”

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

[คำอธิบาย] ความคล้ายคลึงกันระหว่างโครงข่ายเพทรีและซิมเล็กซ์

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

  • โทเค็น:สินค้าคงคลังหรือปริมาณสินค้า

  • สถานที่: “สถานะหรือตำแหน่ง” ของคลังสินค้า กระบวนการ งานระหว่างดำเนินการ หรือการจัดส่ง

  • การเปลี่ยนสถานะ: “การเปลี่ยนแปลงสถานะ (เหตุการณ์)” เช่น การรับ การจัดส่ง การใส่เข้าสายการผลิต การเสร็จสิ้น และการส่งมอบ

  • การทำงาน:เกิดการเปลี่ยนแปลง และโทเค็นจะเคลื่อนไปยังสถานะถัดไป

สิ่งที่สำคัญอย่างยิ่งในที่นี้ไม่ใช่ผลลัพธ์ในปัจจุบัน แต่เป็น “จำนวนชิ้นส่วนที่เหลืออยู่ในสถานที่นั้นตอนนี้”

สิ่งที่ทรงคุณค่าอย่างแท้จริง คือ ประวัติศาสตร์ของการเปลี่ยนแปลง: “อะไรเคลื่อนไหว เมื่อไหร่ ผ่านช่วงเปลี่ยนผ่าน (เหตุการณ์) ใด และไปที่ไหน “

ตราบใดที่บันทึกการทำธุรกรรมหุ้นยังคงได้รับการดูแลรักษาอย่างครบถ้วนโดยไม่มีการละเว้นใดๆ ในฐานะ “ประวัติการเปลี่ยนแปลง” ก็สามารถคำนวณได้ว่า “ปัจจุบันมีโทเค็นอยู่ที่ใดและจำนวนเท่าใด (เช่น สถานะสินค้าคงคลังล่าสุด)”

แทนที่จะเพียงแค่เก็บรักษา “ตารางสินค้าคงคลัง” ระบบจะบันทึก “การเปลี่ยนแปลง (ข้อเท็จจริง) ที่ก่อให้เกิดสถานะนั้นไว้ในแหล่งข้อมูลเดียว

ความงดงามเชิงโครงสร้างของเครือข่ายเพทรีที่เราได้พบในบทที่ 1 คือตรรกะของ “แหล่งข้อมูลความจริงเพียงหนึ่งเดียว” ซึ่งต่อมาได้แทรกซึมอยู่ในระบบ SimLex ERP

บทที่ 2: ขอบเขตระหว่างฮาร์ดเเวร์เเละซอฟต์เเวร์ที่เลือนรางไปตามระดับพิจารณา

ในช่วงที่ผมทำงานเป็นพนักงานของบริษัทนั้น มีโครงการขนาดใหญ่โครงการหนึ่งชื่อ “การพัฒนาอุปกรณ์รุ่นใหม่” ได้ถูกริเริ่มขึ้นภายในบริษัท

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

เมื่อการประชุมเริ่มต้นขึ้นและการสนทนาดำเนินไป ฉันเริ่มรู้สึกไม่สบายใจ

การสนทนาโดยรอบมักเกี่ยวข้องกับด้านเทคนิคของอุปกรณ์ โดยเฉพาะอย่างยิ่ง “อุปกรณ์ควรมีคุณสมบัติอย่างไร” และ “ควรออกแบบอย่างไร”

“การสนทนานี้ดำเนินไปในลักษณะนี้ มันผิดปกติหรือเปล่า?”

ในความเป็นจริงแล้ว คุณสมบัติเฉพาะของอุปกรณ์ไม่ใช่สิ่งที่ผู้ออกแบบสามารถตัดสินใจได้อย่างอิสระด้วยตนเอง

“อุปกรณ์นั้นใช้ผลิตอะไร?”

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

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

กล่าวอีกนัยหนึ่ง จำเป็นอย่างยิ่งที่จะต้องมองจากมุมมองที่แบ่งย่อยจากข้อกำหนดระดับสูงกว่าและย้อนกลับไป เช่น [ความต้องการของลูกค้า ➔ แผนการผลิต ➔ โรงงาน ➔ สายการผลิต ➔ อุปกรณ์]

ฉันสนับสนุนแนวคิดเชิงโครงสร้างนี้อย่างยิ่งในโครงการนี้

อย่างไรก็ตาม ผลที่ตามมาคือการทะเลาะวิวาทครั้งใหญ่กับหัวหน้าโครงการ

เมื่อมองย้อนกลับไป ตอนนี้มันคงเป็นเรื่องที่หลีกเลี่ยงไม่ได้ เพราะเรามองสิ่งต่างๆ จากมุมมองที่แตกต่างกัน

วิศวกรผู้เชี่ยวชาญในสาขาเฉพาะทางของตนมองสิ่งต่างๆ จากมุมมองระดับจุลภาค โดยเน้นที่ “วิธีการสร้างอุปกรณ์ที่พวกเขารับผิดชอบ” ในทางกลับกัน ผมพยายามมองภาพรวมจากระดับมหภาคที่สูงขึ้น โดยถามตัวเองว่า “อะไรเป็นตัวกำหนดคุณสมบัติของอุปกรณ์นั้นตั้งแต่แรก?”

อย่างไรก็ตาม ในระหว่างการถกเถียงอย่างดุเดือดนั้น ผมได้ตระหนักถึงสิ่งสำคัญอย่างยิ่งประการหนึ่ง

“ขอบเขตระหว่างฮาร์ดแวร์และซอฟต์แวร์นั้นไม่ใช่สิ่งที่ตายตัว มันเปลี่ยนแปลงไปตามมุมมองที่คุณมอง”

ต่อมา ฉันจะจัดระเบียบแนวคิดนี้โดยใช้คำว่า “ข้อจำกัด” และ “สภาวะที่เปลี่ยนแปลงได้”

ในระดับการพิจารณาหนึ่ง ข้อสมมติฐานที่ได้ตัดสินใจไปแล้วและไม่สามารถเปลี่ยนแปลงได้เรียกว่า “ข้อจำกัด” ส่วนประกอบที่สามารถจัดเรียงใหม่หรือปรับให้เหมาะสมที่สุดภายในข้อจำกัดเหล่านั้นเรียกว่า “เงื่อนไขที่ปรับเปลี่ยนได้”

ที่น่าสนใจคือ ความสัมพันธ์นี้จะเปลี่ยนแปลงไปอย่างสิ้นเชิงเมื่อคุณเปลี่ยน “ลำดับชั้น” (มุมมอง) ที่คุณกำลังพิจารณา

  • ระดับของการออกแบบเชิงกล:ชิ้นส่วนที่ซื้อมาถือเป็น “ข้อจำกัด” และวิธีการนำชิ้นส่วนเหล่านั้นมาประกอบกันเพื่อสร้างเครื่องจักรนั้นถือเป็น “เงื่อนไขที่สามารถปรับเปลี่ยนได้”

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

  • ระดับการออกแบบโรงงาน:การกำหนดค่าสายการผลิตแต่ละสายถือเป็น “ข้อจำกัด” ในขณะที่วิธีการรวมข้อจำกัดเหล่านี้เข้าด้วยกันเพื่อสร้างโรงงานโดยรวมนั้นถือเป็น “เงื่อนไขที่สามารถปรับเปลี่ยนได้”

กล่าวอีกนัยหนึ่ง “ฮาร์ดแวร์ (ข้อจำกัด)” ที่ไม่สามารถเลือกได้ในระดับล่าง จะเปลี่ยนไปเป็น “ซอฟต์แวร์ (เงื่อนไขที่เปลี่ยนแปลงได้)” ซึ่งสามารถจัดเรียงใหม่ได้อย่างอิสระเมื่อมองจากระดับที่สูงกว่า

คุณสมบัติของการเป็นฮาร์ดแวร์หรือซอฟต์แวร์นั้นไม่ได้เป็นสิ่งที่ติดตัวมากับตัววัตถุเอง

ขึ้นอยู่กับว่า “คุณกำลังพิจารณาปัญหาจากระดับนามธรรม (ลำดับชั้น) ใด”

การค้นพบนี้—ที่ว่า “ขอบเขตระหว่างข้อจำกัดและเงื่อนไขที่ปรับเปลี่ยนได้จะเปลี่ยนแปลงไปตามระดับของการพิจารณา”—กลายเป็นรากฐานที่มั่นคงเมื่อผมสร้าง “แบบจำลองลำดับชั้น” ที่ซับซ้อนในงานออกแบบระบบในเวลาต่อมา

จากนั้นการเปลี่ยนแปลงครั้งสำคัญอีกครั้งก็เกิดขึ้นในเส้นทางอาชีพวิศวกรของผม

ในการกำหนดคุณสมบัติของอุปกรณ์ เราจำเป็นต้องพิจารณาถึงสายการผลิต

หากต้องการชมสายการผลิต คุณต้องชมโรงงานทั้งหมด

เพื่อให้ได้ภาพรวมที่สมบูรณ์ของโรงงาน คุณจำเป็นต้องรู้ว่า “จะผลิตเมื่อไหร่ ผลิตอะไร และผลิตปริมาณเท่าใด”

และสิ่งที่ตัดสินสิ่งนั้นในท้ายที่สุดก็คือ “ความต้องการของลูกค้า”

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

ในบทที่ 1 ผมได้พบกับคำถามพื้นฐานที่ว่า “จะเกิดอะไรขึ้นถ้าเรากำจัดโกดังนั้นทิ้งไป?”

และในบทที่ 2 นี้ ซึ่งนำไปสู่บทที่ 3 ฉันได้เปลี่ยนมุมมอง โดยถามตัวเองว่า “ข้อจำกัดเหล่านั้นเป็นข้อจำกัดจริงๆ หรือไม่? ฉันกำลังมองจากระดับไหน?”

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

บทที่ 3: การพบกับจารย์ผู้เป็นจุดเริ่มต้น MRP ของผม

หลังจากทำงานให้กับผู้ผลิตตลับลูกปืนรายใหญ่มา 13 ปี ผมก็ตัดสินใจออกมาตั้งบริษัทของตัวเอง

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

บุคคลผู้นี้เคยทำงานให้กับบริษัทแม่มาก่อน และเป็นผู้บุกเบิกในการนำระบบ MRP มาใช้ในทางปฏิบัติในช่วงทศวรรษ 1970 ซึ่งเป็นช่วงเวลาที่คำว่า “MRP” แทบจะไม่เป็นที่รู้จักในญี่ปุ่นเลย นับว่าเป็นบุคคลสำคัญผู้บุกเบิกด้านการจัดการการผลิตของญี่ปุ่นอย่างแท้จริง

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

ก่อนหน้านั้น ในฐานะวิศวกรฝ่ายผลิต ผมมองสถานที่ทำงานจากมุมมองทางกายภาพเท่านั้น โดยเน้นที่ “การไหลเวียนของสิ่งต่างๆ” และ “การจัดวางอุปกรณ์”

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

แนวคิดที่ฉันได้เรียนรู้ที่นั่นนั้นเรียบง่ายอย่างน่าประหลาดใจ

อย่างไรก็ตาม สาระสำคัญของการจัดการการผลิตนั้นบรรจุอยู่ในความเรียบง่ายนั้นเอง

ลำดับเหตุการณ์เป็นดังนี้:

[การจัดการคำสั่งซื้อ ➔ ตารางการผลิตมาตรฐาน ➔ MRP (การวางแผนความต้องการวัสดุ)]

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

ตรรกะเบื้องหลังระบบ MRP นั้นยอดเยี่ยมมาก มันแยกย่อย BOM (Bill of Materials) และกำหนดปริมาณและช่วงเวลาที่ต้องการ สิ่งที่ดูเหมือนจะเป็นงานบริหารจัดการโรงงานที่ซับซ้อนอย่างยิ่ง สามารถแสดงออกมาด้วยตรรกะที่เรียบง่ายและชัดเจนอย่างเหลือเชื่อ ผมประทับใจในความยอดเยี่ยมนี้มาก

สิ่งที่สำคัญยิ่งกว่านั้นคือแนวคิดของแผนภาพ ER (แผนภาพความสัมพันธ์ระหว่างเอนทิตี) ซึ่งเป็นพื้นฐานของการออกแบบฐานข้อมูล

วิธีการนี้จัดระเบียบองค์ประกอบที่จำเป็นสำหรับการจัดการการผลิต เช่น รายการวัสดุ (BOM) ขั้นตอนการผลิต คำสั่งซื้อ และแผนการผลิต ในรูปแบบของ “ความสัมพันธ์” ไม่ใช่แค่เรื่อง “เรามีข้อมูลอะไรบ้าง” แต่เป็นเรื่องของการทำความเข้าใจ “ว่าข้อมูลแต่ละส่วนเชื่อมโยงกันอย่างไรในโครงสร้าง” ในรูปแบบของแบบจำลองข้อมูล ความรู้ที่ได้จากการเรียนรู้นี้กลายเป็นทรัพย์สินที่มีค่าอย่างยิ่งเมื่อผมสร้างฐานข้อมูล SimLex ERP ในภายหลัง

สำหรับฉันซึ่งมาจากพื้นฐานด้านเทคโนโลยีการผลิต โลกแห่งข้อมูลนี้เป็นสิ่งใหม่สำหรับฉันโดยสิ้นเชิง

ก่อนหน้านั้น ฉันใช้ชีวิตอยู่ในโลกของ “สิ่งของ” มีโรงงาน อุปกรณ์ และผลิตภัณฑ์แปรรูปไหลเวียนต่อเนื่องกันไป

อย่างไรก็ตาม การเรียนรู้เกี่ยวกับ MRP ทำให้พบว่าเบื้องหลังทั้งหมดนั้น มี “โลกแห่งข้อมูล” ที่จัดระเบียบอย่างดีอีกโลกหนึ่งซึ่งทำงานแบบเรียลไทม์: [รับคำสั่งซื้อ ➔ การวางแผนการผลิต ➔ การแยกชิ้นส่วน ➔ การคำนวณปริมาณและระยะเวลาที่ต้องการ ➔ การจัดซื้อและการผลิต]

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

ในทศวรรษ 1970 ซึ่งเป็นช่วงเวลาที่คอมพิวเตอร์และเทคโนโลยีฐานข้อมูลขั้นสูงอย่างที่เรามีในปัจจุบันยังไม่มีอยู่จริง บรรพบุรุษของเราได้พิจารณาถึงแก่นแท้ของการผลิตอย่างถี่ถ้วน และสร้างทฤษฎี MRP (Material Requirements Planning) ที่สมบูรณ์แบบขึ้นมา

สิ่งที่คนรุ่นเราควรทำคือ ไม่ควรเพิกเฉยต่อทฤษฎีในอดีตโดยง่าย

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

ด้วยวิธีนี้ ผมจึงได้รับความรู้ที่สำคัญเกี่ยวกับ MRP จากผู้ที่มาก่อนผม

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

ทันใดนั้นคำถามหนึ่งก็ผุดขึ้นมาในหัวผม

“จำเป็นต้องแยก MRP และระบบกำหนดตารางเวลาออกเป็นสองระบบที่แตกต่างกันตั้งแต่แรกเลยหรือ?”

ระบบ MRP คำนวณ “สิ่งที่ต้องผลิต เมื่อใด และในปริมาณเท่าใด”

จากนั้นโปรแกรมวางแผนจะแปลงข้อมูลนี้เป็น “เวลาที่เหมาะสมในการสร้าง โดยคำนึงถึงข้อจำกัดของอุปกรณ์และกระบวนการที่มีอยู่จริง”

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

นี่เป็นก้าวแรกสู่โลกใหม่ที่ ผมจะศึกษาค้นคว้าต่อไปอีกหลายปี นั่นคือ การบูรณาการระบบ MRP และระบบวางแผนการผลิต

เมื่อมองย้อนกลับไป การได้พบกับครูผู้ยิ่งใหญ่ท่านนี้มีความหมายมากกว่าแค่การได้รับความรู้

  • บทที่ 1 (เปตริเนต์):เข้าใจแก่นแท้ของความเป็นจริงผ่านโครงสร้างที่เรียบง่าย

  • บทที่ 2 (ข้อจำกัด):การทำให้ข้อจำกัดเปลี่ยนแปลงได้โดยการเปลี่ยนมุมมอง (ลำดับชั้น)

  • บทที่ 3 (แผนภาพ MRP และ ER):การจำลองกิจกรรมการผลิตเป็นโครงสร้างข้อมูล

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

บทที่ 4: “การทำให้เหมาะสมที่สุดด้วยความเรียบง่าย” และ “ขีดจำกัดของ APS” ที่ขวางหน้า

เพื่อให้สามารถผสานระบบ MRP และระบบวางแผนการผลิตได้อย่างแท้จริง ข้อจำกัดมากมายที่มีอยู่ในสภาพแวดล้อมการผลิตจริงจะต้องได้รับการจำลองอย่างแม่นยำภายในระบบ

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

  • เวลาใช้งานของอุปกรณ์, ความจุของอุปกรณ์, อุปกรณ์สำรอง และลำดับความสำคัญ

  • เวลาการตั้งค่าคงที่ซึ่งเกิดขึ้นโดยไม่ขึ้นอยู่กับผลิตภัณฑ์ก่อนหน้า

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

  • ลำดับความสำคัญในการผลิตที่เกิดขึ้นจากการเปลี่ยนแปลงของสีทา วัสดุ อุณหภูมิ ฯลฯ

  • จำนวนคนงาน ทักษะ และกะการทำงาน

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

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

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

ในบริบทนี้ “การทำให้ง่ายขึ้น” ไม่ได้หมายความเพียงแค่การตัด (ลบ) ข้อมูลออกไปเท่านั้น

[การทำให้ง่ายขึ้น]คือการดึงเอาเฉพาะแก่นแท้ของความเป็นจริงออกมา แล้ว “แยกย่อย” ไปสู่ระดับที่สูงขึ้น

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

ขออนุญาตอธิบายแนวคิดนี้ด้วยตัวอย่างที่เป็นรูปธรรมครับ

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

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

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

  • คุณลักษณะคุณภาพที่ 1 (สีทา):ขาว เทา ดำ

  • คุณลักษณะด้านคุณภาพ 2 (วัสดุ):วัสดุ A, วัสดุ B, วัสดุ C

ข้อมูลหลักของไอเทมจะมีเพียงคุณลักษณะ (คุณสมบัติ) “ไอเทมนี้คือ [สีทา: สีขาว / วัสดุ: A]” เท่านั้น

สิ่งที่เรากำหนดให้เป็นข้อมูลหลักนั้น ไม่ใช่การรวมกันของรายการต่างๆ แต่เป็นลำดับความสำคัญที่มอบให้กับ “การเปลี่ยนแปลง (การเปลี่ยนผ่าน) ระหว่างคุณลักษณะต่างๆ”

  • ขาว ➔ ดำ:ลำดับความสำคัญ 3

  • ขาว ➔ เทา:ลำดับความสำคัญ 2

  • สีที่คล้ายกัน:ลำดับความสำคัญ 1

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

“แทนที่จะสร้างฐานข้อมูลหลักของตัวสินค้าเอง เราจะแยก ‘ลักษณะสำคัญ’ ที่มีอยู่ในสินค้าเหล่านั้นออกมา และสร้างฐานข้อมูลหลักของความสัมพันธ์ระหว่างลักษณะเหล่านั้น”

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

นอกจากนี้ เรายังได้ดำเนินมาตรการต่างๆ เพื่อให้สามารถประมวลผลได้อย่างรวดเร็ว

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

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

ผลที่ตามมาคือปฏิกิริยาลูกโซ่อันน่าทึ่ง: “ตัวมาสเตอร์ง่ายขึ้น ➔ โครงสร้างหน่วยความจำง่ายขึ้น ➔ โปรแกรมง่ายขึ้น ➔ ความเร็วในการประมวลผลเร็วขึ้นอย่างมาก”

ด้วยวิธีนี้ ผมจึงประสบความสำเร็จในการสร้างระบบขั้นสูงที่ผสานรวม MRP และระบบกำหนดตารางเวลาเข้าด้วยกันอย่างสมบูรณ์ ซึ่งก็คือระบบ APS (Advanced Planning and Scheduling) นั่นเอง

ระบบ MRP กำหนด “สิ่งที่จำเป็น เมื่อไหร่ และในปริมาณเท่าใด” และผู้กำหนดตารางการผลิตจะแปลงสิ่งนี้เป็น “เมื่อใดจะผลิตได้จริง ภายใต้ข้อจำกัดของอุปกรณ์ บุคลากร และกระบวนการ” นี่เป็นระบบปฏิวัติวงการอย่างไม่ต้องสงสัย ซึ่งเหนือกว่าการวางแผนการผลิตแบบเดิมอย่างมาก

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

“APS เพียงอย่างเดียวไม่สามารถช่วยโรงงานได้ เพราะ APS มีข้อจำกัด”

โดยพื้นฐานแล้ว APS เป็นระบบที่มีตัวกำหนดตารางเวลา (การวางแผน) เป็นศูนย์กลาง

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

การจัดการการผลิตไม่ได้หมายความถึงแค่การสร้างตารางเวลาที่แม่นยำสำหรับอนาคตเท่านั้น

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

ด้วยเหตุนี้ โครงสร้างที่เชื่อมต่อกันด้วยลำต้นหนาเพียงลำเดียวจึงเป็นสิ่งจำเป็น

[การขาย ➔ การจัดซื้อ ➔ การวางแผนการผลิต ➔ ผลการผลิต ➔ การจัดการสินค้าคงคลัง ➔ การจัดการต้นทุน ➔ (ไปยังแผนถัดไป)]

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

“APS ช่วยเพิ่มประสิทธิภาพในการวางแผนการผลิต อย่างไรก็ตาม นั่นเพียงอย่างเดียวไม่ถือเป็น ‘การจัดการการผลิต’ อย่างแท้จริง”

เมื่อข้อจำกัดนั้นปรากฏชัดเจนขึ้น ผมจึงต้องตัดสินใจครั้งสำคัญ

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

“นับจากนี้เป็นต้นไป คำตอบไม่สามารถหาได้จากการเดินตามเส้นทางเดิมต่อไป”

ฉันได้เริ่มต้นการเดินทางครั้งใหม่ที่ท้าทาย ซึ่งจะทำให้ฉันต้องคิดทบทวนธรรมชาติของระบบทั้งหมดใหม่ตั้งแต่ต้น

บทที่ 5: เหตุใดเราจึงต้องมี Framework ในการพัฒนา… การลดการพึ่งพาบุลคนสู่เเนวทาง Meta-Driven

ขณะที่ผมเผชิญกับข้อจำกัดของ APS และยืนอยู่บนทางแยกสำคัญ โดยสงสัยว่า “ผมควรเลือกเส้นทางไหนดีต่อไป” ความก้าวหน้าทางเทคโนโลยีก็ยังคงพัฒนาไปอย่างรวดเร็ว ทิ้งผมไว้ข้างหลัง

ในเวลานั้น โลกของการพัฒนาซอฟต์แวร์กำลังเผชิญกับการเปลี่ยนแปลงครั้งใหญ่ โดยเฉพาะอย่างยิ่งการเปลี่ยนไปใช้ “.NET”

ในฐานะทั้งเจ้าของธุรกิจและวิศวกร ผมไม่สามารถมองข้ามเรื่องนี้ไปได้ง่ายๆ ว่าเป็นเพียง “การเปลี่ยนไปใช้ภาษาโปรแกรมอื่น” แต่ผมคิดว่านี่เป็นโอกาสทองที่จะได้ทบทวนวิธีการพัฒนาซอฟต์แวร์ที่เราใช้มาจนถึงตอนนั้นเสียใหม่

ในขณะนั้น ระบบจัดตารางงานของเราให้ความสำคัญกับความเร็วในการประมวลผลเป็นหลัก และถูกสร้างขึ้นด้วยภาษา C++

ในทางกลับกัน เราใช้ “MS-Access” ในการประมวลผลข้อมูลหลักและข้อมูลธุรกรรม

อย่างไรก็ตาม การพัฒนาโดยใช้ MS-Access ก่อให้เกิดความท้าทายในการดำเนินงานที่สำคัญสองประการซึ่งไม่ควรมองข้าม

  1. ได้รับผลกระทบโดยตรงจากการอัปเดตเวอร์ชัน (การเปลี่ยนแปลงข้อกำหนด) ของ Microsoft

  2. โปรแกรมมีแนวโน้มที่จะขึ้นอยู่กับทักษะและนิสัยของนักพัฒนาแต่ละคนเป็นอย่างมาก ส่งผลให้กลายเป็น “โปรแกรมที่ปรับแต่งเฉพาะบุคคลอย่างยิ่ง”

โดยเฉพาะอย่างยิ่ง ข้อหลังนี้ถือเป็นความเสี่ยงร้ายแรงสำหรับผมในฐานะผู้จัดการขององค์กร

“ระบบหนึ่งๆ สามารถสร้างเสร็จสมบูรณ์ได้ด้วยโปรแกรมเมอร์ฝีมือเยี่ยมเพียงคนเดียว แต่จะเกิดอะไรขึ้นเมื่อโปรแกรมเมอร์คนนั้นลาออกจากบริษัท? โปรแกรมเมอร์คนอื่นๆ จะสามารถถอดรหัส แก้ไข และพัฒนาระบบที่ซับซ้อนและยุ่งเหยิงนั้นได้หรือไม่?”

ฉันรู้สึกถึงวิกฤตการณ์อย่างรุนแรงเกี่ยวกับความพึ่งพาส่วนบุคคลในกระบวนการพัฒนาครั้งนี้

ดังนั้น เราจึงตัดสินใจเลือกใช้ “C#” ของ .NET เป็นภาษาใหม่ของเรา และในขณะเดียวกัน เราก็เกิดแนวคิดที่จะสร้าง “เฟรมเวิร์กการพัฒนา” ของเราเองขึ้นมาตั้งแต่เริ่มต้น

กล่าวโดยสรุป เป้าหมายของเราคือการสร้างระบบที่ “โปรแกรมเมอร์ทุกคนสามารถบำรุงรักษาโปรแกรมได้อย่างง่ายดาย โดยไม่คำนึงถึงว่าใครเป็นผู้พัฒนาโปรแกรมนั้น”

เพื่อให้บรรลุเป้าหมายนี้ เราจึงได้วางรากฐานแนวคิดที่แน่วแน่มาตั้งแต่เริ่มต้น

  • การรองรับฐานข้อมูลหลายประเภท:รองรับฐานข้อมูลหลักๆ ได้อย่างยืดหยุ่น เช่น Oracle, SQL Server, MySQL, DB2 และ MS-Access

  • ฟังก์ชันการจัดการอัตโนมัติ:ช่วยให้สามารถเริ่มต้นฐานข้อมูลและอัปเดตส่วนต่างได้โดยตรงจากเฟรมเวิร์ก

  • รองรับทั่วโลก:ฟังก์ชันการสลับภาษาหลายภาษาถูกนำมาใช้เป็นคุณสมบัติมาตรฐาน

  • การแปลงข้อมูลการตั้งค่าให้เป็นดิจิทัล:ข้อมูลคุณสมบัติทั้งหมด การตั้งค่าเมนู และการตั้งค่าสิทธิ์จากการออกแบบหน้าจอจะถูกแปลงเป็นฐานข้อมูล

  • การผสานรวมกับ Excel:การกำหนดมาตรฐานการนำเข้า/ส่งออกข้อมูลและการสร้างรายงาน (ไม่จำเป็นต้องสร้างโปรแกรมใหม่)

กล่าวอีกนัยหนึ่ง มันคือการเปลี่ยนแปลงทางความคิด จากเดิมที่โปรแกรมเมอร์เขียนโค้ดตั้งแต่เริ่มต้นสำหรับแต่ละหน้าจอทุกครั้ง ไปเป็นการ “สร้างกลไกทั่วไป (พื้นฐาน) ที่ใช้ในการทำงานของระบบและนำกลับมาใช้ซ้ำๆ” ซึ่งเป็นรากฐานของ “เฟรมเวิร์ก SimLex” ที่จะถูกสร้างขึ้นในภายหลัง

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

ตัวอย่างที่สำคัญที่สุดของเรื่องนี้คือ “การลดทอนการตั้งค่าหน้าจอ”

ฉันจึงเจาะลึกลงไปในคำถามที่ว่า “การกำหนดนิยามเมื่อออกแบบหน้าจอหมายความว่าอย่างไรกันแน่?” และได้ข้อสรุปที่เป็นนามธรรมขั้นสูงสุดเพียงหนึ่งเดียว

“ทุกองค์ประกอบที่ปรากฏบนหน้าจอเป็นเพียงทรัพยากรสำหรับรูปแบบเท่านั้น”

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

ด้วยวิธีนี้ จึงไม่จำเป็นต้องตั้งโปรแกรมหน้าจอแต่ละจอแยกกันอีกต่อไป

ตราบใดที่ทรัพยากรและข้อมูลคุณลักษณะของทรัพยากรเหล่านั้นได้รับการกำหนดไว้ในฐานข้อมูล เฟรมเวิร์กจะอ่านข้อมูลเหล่านั้นโดยอัตโนมัติและแสดงผลบนหน้าจอแบบไดนามิก

ด้วยการสรุปสาระสำคัญของโค้ด ปริมาณโค้ดจึงลดลงอย่างมาก ซึ่งนับเป็นตัวอย่างที่แท้จริงของ “การเพิ่มประสิทธิภาพด้วยการทำให้ง่ายขึ้น”

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

ในปี 2548 ต้นแบบของกรอบการทำงานนี้ได้สร้างเสร็จสมบูรณ์

ความสำเร็จอันยิ่งใหญ่เหล่านั้นสะท้อนให้เห็นอย่างชัดเจนในระบบ ERP ของ SimLex ในปัจจุบัน

ปัจจุบัน SimLex ERP มีหน้าจอประมาณ 1,200 หน้าจอแต่หน้าจอเหล่านี้ไม่ได้ถูกเขียนโปรแกรมแยกกัน โดยการรวมเทมเพลตหน้าจอทั่วไปเพียงแปดแบบบนเฟรมเวิร์ก หน้าจอทั้ง 1,200 หน้าจอจึงสามารถควบคุมและทำงานได้อย่างสมบูรณ์แบบ

แทนที่จะสร้างหน้าจอจำนวนมากทีละหน้าจอ เราได้สร้าง “ระบบ (กลไก) สำหรับสร้างหน้าจอโดยอัตโนมัติ” นี่คือสาระสำคัญของเฟรมเวิร์กที่เราได้พัฒนาขึ้นมา

กรอบการทำงานนี้ซึ่งพัฒนาเสร็จสมบูรณ์ในปี 2548 ได้รับการพัฒนาอย่างต่อเนื่องและยังคงเป็นแกนหลักที่แข็งแกร่งของ SimLex มาจนถึงปัจจุบัน (2569) โดยการเขียนฐานข้อมูลคำจำกัดความใหม่ ก็สามารถปรับเปลี่ยนได้อย่างยืดหยุ่น ไม่เพียงแต่กับซอฟต์แวร์สำหรับอุตสาหกรรมเฉพาะเท่านั้น แต่ยังรวมถึงแอปพลิเคชันทางธุรกิจใดๆ ก็ได้

ต่อมาฉันได้เรียนรู้ว่าในสาขาเทคโนโลยีสารสนเทศสมัยใหม่ที่ล้ำสมัย สถาปัตยกรรมประเภทนี้เรียกว่า “แพลตฟอร์มแอปพลิเคชันที่ขับเคลื่อนด้วยเมตา” (Meta-Driven Application Platform)

อย่างไรก็ตาม ในเวลานั้น ฉันไม่มีทางรู้ถึงศัพท์เฉพาะทางที่ล้ำสมัยเหล่านั้นได้เลย

ในระหว่างการทำงานภาคสนาม เราได้พิจารณาอย่างจริงจังว่า “เราจะสร้างซอฟต์แวร์ที่สวยงามและแข็งแกร่งซึ่งไม่ขึ้นอยู่กับความคิดของโปรแกรมเมอร์คนใดคนหนึ่งได้อย่างไร” และด้วยเหตุนี้จึงได้โครงสร้างนี้ขึ้นมา

เมื่อมองย้อนกลับไป ผมตระหนักว่าปรัชญาระบบของผม ซึ่งต่อเนื่องจากบทที่ 1 นั้น ได้รับการชี้นำโดยหลักการสำคัญเพียงข้อเดียวที่ไม่เปลี่ยนแปลง

  • บทที่ 1 (โครงข่ายเพทรี):การจำลองโลกแห่งความเป็นจริงด้วยองค์ประกอบที่จำเป็นขั้นต่ำ

  • บทที่ 2 (การออกแบบอุปกรณ์):การเปลี่ยนมุมมองของลำดับชั้นและการทำให้ข้อจำกัดสามารถเปลี่ยนแปลงได้

  • บทที่ 3 (แผนภาพ MRP/ER):การจำลองกิจกรรมการผลิตเป็นโครงสร้างข้อมูล

  • บทที่ 4 (ผู้กำหนดตารางเวลา):การแปลงเงื่อนไขการผลิตที่ซับซ้อนให้เป็นคุณลักษณะด้านคุณภาพ

  • บทที่ 5 (กรอบการทำงาน):การสร้างนามธรรมของหน้าจอและฟังก์ชัน และการสร้างระบบโดยอัตโนมัติจากข้อมูลคำจำกัดความ

ทุกอย่างชี้ไปในทิศทางเดียวกัน

“เราไม่ได้นำเสนอความเป็นจริงที่ซับซ้อนในรูปแบบของโค้ดที่ยุ่งเหยิง เราดึงเอาแก่นแท้มาสรุป และแสดงออกมาในโครงสร้างที่เรียบง่ายและสวยงาม”

สำหรับผมแล้ว นี่คือ “การทำให้ง่ายขึ้นอย่างมีประสิทธิภาพสูงสุด” อย่างแท้จริง

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

ข้อจำกัดเชิงโครงสร้างของ APS (Advanced Planning Scheduler) ไม่ได้หายไปโดยปริยาย แม้ว่าจะวางรากฐานที่มั่นคงแล้วก็ตาม

เราได้บูรณาการระบบ MRP และระบบกำหนดตารางเวลาเข้าด้วยกันอย่างสมบูรณ์ เราทำให้การจัดการเงื่อนไขที่ซับซ้อนในสถานที่ทำงานเป็นไปอย่างมีประสิทธิภาพ นอกจากนี้ เรายังได้สร้างกรอบการทำงานที่ช่วยเพิ่มประสิทธิภาพในการพัฒนาและบำรุงรักษาได้อย่างมาก

ถึงกระนั้นก็ตาม มันก็ยังไม่ถึงขั้น “การบริหารจัดการการผลิตอย่างแท้จริง” อย่างที่ผมคาดหวังไว้

“แล้วเราควรทำอย่างไรดี?”

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

บทที่ 6: การตระหนักถึง “มาตรฐานระดับโลก” ชัดเจนยิ่งขึ้นจากประสบการณ์ทำงานในประเทศไทย

เนื่องจากเราพบข้อจำกัดของ APS (Advanced Planning Scheduler) เราจึงได้สร้างแพลตฟอร์มร่วมของเราเองขึ้นมา ซึ่งก็คือ “กรอบการพัฒนา” เพื่อเอาชนะข้อจำกัดเหล่านั้น

ถึงกระนั้น ฉันก็ยังไม่รู้สึกอย่างแน่ชัดในใจว่า “นี่แหละคือสิ่งที่ใช่”

“บางทีเราอาจต้องเริ่มต้นใหม่ทั้งหมดและคิดทบทวนสิ่งต่างๆ ใหม่”

อย่างไรก็ตาม มีข้อกังวลสำคัญอย่างหนึ่งผุดขึ้นมาในใจผม ณ จุดนี้

“ถ้าเรายังคงอยู่ในญี่ปุ่นและพัฒนาระบบต่อไปเรื่อยๆ สุดท้ายแล้วเราจะไม่สร้างสิ่งที่ต่อยอดมาจาก ‘ระบบญี่ปุ่นดั้งเดิม’ ที่มีอยู่ก่อนแล้วหรอกหรือ?”

จากมุมมองของผมในขณะนั้น ระบบการจัดการการผลิตของญี่ปุ่นดูเหมือนจะเอนเอียงไปทางสองสิ่งมากเกินไป คือ “การวางแผนการผลิต” และ “การควบคุมกระบวนการ”

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

[การขาย ➔ การจัดซื้อ ➔ การวางแผนการผลิต ➔ การผลิต ➔ ผลลัพธ์ที่เกิดขึ้นจริง ➔ สินค้าคงคลัง ➔ ต้นทุน]

เมื่อกระบวนการทั้งหมดเหล่านี้เชื่อมต่อกันเป็นโครงสร้างข้อมูลที่แข็งแกร่งเพียงหนึ่งเดียวเท่านั้น จึงจะเรียกได้ว่าเป็น “การจัดการการผลิต” อย่างแท้จริง

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

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

“ลองสร้างระบบการจัดการการผลิตทั้งหมดขึ้นมาใหม่ตั้งแต่ต้นในสถานที่ใหม่ที่ไม่มีข้อจำกัดดูไหม”

เมื่อตัดสินใจเรื่องนั้นแล้ว ฉันก็ตัดสินใจครั้งใหญ่ที่จะย้ายไปอยู่ประเทศไทย มีหลายเหตุผลที่ฉันเลือกประเทศไทย

  • มันเป็นสภาพแวดล้อมการพัฒนาที่เหมาะสมที่สุดสำหรับการสร้างและทดสอบระบบตั้งแต่เริ่มต้น

  • บริษัทผู้ผลิตของญี่ปุ่นหลายแห่งได้เข้าไปตั้งฐานการผลิตที่นั่น และมีความต้องการบริการในพื้นที่เป็นอย่างมาก

  • แตกต่างจากในญี่ปุ่น ที่นี่มีสภาพแวดล้อมที่เปิดกว้าง ซึ่งแม้แต่ธุรกิจเกิดใหม่ก็สามารถท้าทายตลาดได้ด้วยตนเอง

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

  • คุณธรรมและอุปนิสัยของคนไทยสอดคล้องกับค่านิยมของผมเป็นอย่างดี

ดังนั้น ในเดือนสิงหาคม ปี 2012 ฉันจึงย้ายไปประเทศไทยและก่อตั้งบริษัทใหม่ที่นั่น

เราเริ่มต้นจากทีมเล็ก ๆ ที่มีสมาชิกเพียงไม่กี่คน

ทันทีที่ย้ายเข้ามา ผมก็ทุ่มเทเวลาให้กับการพัฒนาซอฟต์แวร์ตั้งแต่เช้าจรดเย็น และเพียงสี่เดือนต่อมา ในเดือนธันวาคม 2012 ผมก็สร้างต้นแบบระบบการจัดการการผลิตใหม่เสร็จสมบูรณ์แล้ว

เมื่อใดก็ตามที่งานพัฒนาโครงการทำให้เหนื่อยล้าทางจิตใจอย่างมาก ผมมักจะไปเล่นบิลเลียดในเมืองเพื่อผ่อนคลายความเครียด

บิลเลียดเป็นกีฬาที่ได้รับความนิยมอย่างมากในประเทศไทย และสถานที่เล่นบิลเลียดก็เต็มไปด้วยผู้คนหลากหลายจากทั่วโลก ไม่เพียงแต่คนไทยเท่านั้น แต่ยังรวมถึงชาวตะวันตก ชาวอินเดีย และอื่นๆ อีกด้วย

แม้ว่าการเล่นบิลเลียดนั้นน่าสนใจ แต่การได้รู้จักเพื่อนจากหลากหลายประเทศที่นั่นกลับเป็นประโยชน์อย่างมากเกินคาด การได้พูดคุยกับพวกเขาทุกวันทำให้ฉันได้เรียนรู้ “ภาษาอังกฤษแท้ๆ” ที่หาไม่ได้ในตำราเรียน รวมถึงวิธีคิดทางวัฒนธรรมที่แตกต่างกันอย่างลึกซึ้ง

ตอนนั้นเองที่ผมได้ตระหนักถึงสิ่งสำคัญอย่างหนึ่ง

“ถึงแม้ผู้คนจะมีสัญชาติ เชื้อชาติ หรือวัฒนธรรมที่แตกต่างกัน แต่ความรู้สึกและกระบวนการคิดพื้นฐานของพวกเขาก็ไม่ได้เปลี่ยนแปลงไปมากนัก”

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

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

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

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

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

ฉันตั้งเป้าหมายไว้ที่ “มาตรฐานระดับโลก”

อย่างไรก็ตาม ณ จุดนี้ คำถามสำคัญข้อหนึ่งก็ผุดขึ้นมาทันที

“มาตรฐานระดับโลก” คืออะไรกันแน่?”

นี่หมายความว่าเราต้องรวมเอาข้อเรียกร้องที่ไม่สมเหตุสมผลทั้งหมดของบริษัทต่างๆ ทั่วโลกเข้ามาไว้ในระบบด้วยใช่หรือไม่?

นี่หมายความว่าเราต้องนำกฎระเบียบท้องถิ่นที่ไม่ชัดเจนและเฉพาะเจาะจงของแต่ละประเทศมาผนวกรวมเข้ากับระบบด้วยหรือไม่?

เป้าหมายคือการเพิ่มฟีเจอร์จำนวนมหาศาลและสร้างระบบขนาดใหญ่ใช่หรือไม่?

ถ้าเราพิจารณาอย่างใจเย็น วลีที่ฟังดูไพเราะอย่าง “มาตรฐานระดับโลก” นั้นไม่ได้ให้ภาพที่เป็นรูปธรรมใดๆ เลย

ในการคลำทางในความมืดของฉัน ฉันได้หวนกลับไปหา “คำสอนของอาจารย์” ที่ฉันได้พบในบทที่ 3 อีกครั้ง ซึ่งก็คือต้นกำเนิดของ MRP นั่นเอง

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

[รับคำสั่งซื้อ ➔ ตารางการผลิตมาตรฐาน ➔ MRP ➔ ใบสั่งซื้อ ➔ คำสั่งการผลิต ➔ การจัดการประสิทธิภาพ ➔ การจัดการสินค้าคงคลัง]

“การสร้างกระบวนการหลักนี้ด้วยความซื่อสัตย์อย่างสมบูรณ์ โดยไม่มีการประนีประนอมใดๆ ในรูปแบบที่สวยงามและแม่นยำ นี่ไม่ใช่แก่นแท้ของ ‘มาตรฐานระดับโลก’ ที่ผมมุ่งมั่นหรอกหรือ?”

ฉันแน่ใจ

มาตรฐานสากลไม่ได้หมายถึงการขยายระบบให้ใหญ่โตโดยการรองรับความต้องการที่หลากหลายจากทั่วโลกทั้งหมด

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

นั่นเป็นคำตอบเดียวที่ผมได้มา

  • บทที่ 1 (โครงข่ายเพทรี):การจำลองแก่นแท้ของความเป็นจริงด้วยองค์ประกอบขั้นต่ำ

  • บทที่ 2 (ข้อจำกัด):การขยายมุมมองและทำให้ข้อจำกัดเปลี่ยนแปลงได้

  • บทที่ 3 (MRP):การยึดมั่นในกระบวนการพื้นฐานที่จำเป็นสำหรับการไหลเวียนของข้อมูล

  • บทที่ 4 (การเพิ่มประสิทธิภาพการลดความซับซ้อน):การสรุปเงื่อนไขที่ซับซ้อนและควบคุมเงื่อนไขเหล่านั้นด้วยตัวแปรหลักที่น้อยที่สุด

  • บทที่ 5 (กรอบงาน):การสร้างระบบแบบไดนามิกจากข้อมูลนิยาม

จากนั้น ในปี 2012 ในดินแดนใหม่ นั่นคือประเทศไทย เราพร้อมที่จะรวบรวมความคิดและเทคโนโลยีทั้งหมดที่เราเคยมีมาเข้าไว้ในโครงสร้างขนาดใหญ่โครงสร้างเดียว

“เพื่อสร้างระบบ ERP ที่ได้มาตรฐานระดับโลกอย่างแท้จริง”

ด้วยความเชื่อมั่นอันแน่วแน่เช่นนี้ การพัฒนา SimLex ERP อย่างเต็มรูปแบบจึงเริ่มต้นขึ้น

บทที่ 7: การพัฒนาระบบบริหารการขาย การวางเเผนเเละบริหารการผลิต เเละระบบบัญชีจาก Zero-base

แม้ว่าเราจะเริ่มต้นพัฒนาจากศูนย์ แต่แนวคิดนั้นก็ชัดเจนอยู่ในใจผมแล้ว สิ่งที่เหลืออยู่ก็คือการแปลงแนวคิดนั้นให้เป็นโค้ด

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

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

ในการเริ่มต้นการพัฒนา เราได้กำหนดนโยบายพื้นฐานที่เราจะยึดมั่นอย่างเคร่งครัด

  • การบูรณาการข้อมูลหลัก : อินเทอร์เฟซ Excel มาตรฐานของเฟรมเวิร์กนี้ช่วยให้สามารถนำเข้าและส่งออกข้อมูลได้อย่างยืดหยุ่น

  • การบูรณาการข้อมูลธุรกรรม : ข้อมูลคำสั่งซื้อและข้อมูลอื่นๆ สามารถนำเข้าและส่งออกได้ในรูปแบบ Excel และ CSV

  • การกำหนดมาตรฐานโครงสร้าง UI : การรวมหน้าจอทางธุรกิจทั้งหมด เช่น การประมวลผลคำสั่งซื้อ การออกใบแจ้งหนี้ และการประมวลผลใบสั่งซื้อ (P/O) ให้เป็น “รูปแบบส่วนหัว-รายละเอียด”

  • การรักษาความถูกต้องของข้อมูล : เมื่อลงทะเบียนแล้ว ข้อมูลธุรกรรมจะไม่สามารถลบได้ และการยกเลิกใดๆ ที่จำเป็นต้องแก้ไขจะต้องบันทึกโดยใช้ “บันทึกสีแดง (กระบวนการยกเลิก)”

  • ระบบ MRP แบบไฮบริดความเร็วสูง : รองรับแนวทางแบบไฮบริดของการจัดการจำนวนการผลิตและการจัดการแบบ MRP โดยประมวลผลการคำนวณความต้องการทั้งหมดในหน่วยความจำด้วยความเร็วสูงมาก

  • รายงานที่ไม่ต้องเขียนโปรแกรม : รายงานเหล่านี้ใช้ Excel ซึ่งเป็นคุณสมบัติมาตรฐานของเฟรมเวิร์ก ทำให้สามารถสร้างและแก้ไขรายงานได้อย่างยืดหยุ่นโดยไม่ต้องเขียนโปรแกรม

จากปรัชญาการออกแบบนี้ เราจึงตั้งเป้าหมายไว้ว่า “จะสร้างต้นแบบให้เสร็จภายในสี่เดือน”

“แหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียว” มีสินค้าพร้อมส่ง

โดยเฉพาะอย่างยิ่ง ในการออกแบบระบบบริหารจัดการสินค้าคงคลัง เราได้ให้ความสำคัญกับแนวคิดในการรวมการเคลื่อนไหวของสินค้าคงคลังทั้งหมดเข้าไว้ในธุรกรรมเดียว ซึ่งเรียกว่า “สมุดบัญชีรับและจ่ายเงิน”

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

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

แทนที่จะกระจายและเก็บรักษาข้อมูลตัวเลข เช่น “สินค้าคงคลัง” ไว้ในหลายสถานที่ แนวคิดการออกแบบที่รวบรวม “บันทึกการรับและจ่ายเงิน” ซึ่งเป็นเหตุการณ์ที่เกิดขึ้นจริง ไว้ในที่เดียว แล้วขยายจากจุดนั้นไปสู่ข้อมูลประเภทอื่นๆ จะกลายเป็นแก่นหลักของระบบ ERP ของ SimLex ทั้งหมด

ความสำเร็จในการนำระบบไปใช้ในระยะเริ่มต้น และความท้าทายที่เราเผชิญในระบบบัญชี

เมื่อต้นแบบเสร็จสมบูรณ์ เราก็เริ่มกิจกรรมการขายทันที เราไปพบกับผู้ผลิตอุปกรณ์อิเล็กทรอนิกส์รายใหญ่และบริษัทที่ปรึกษาต่างๆ อย่างต่อเนื่อง เพื่อนำเสนอระบบการจัดการการผลิตของ SimLex

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

จากนั้น การยื่นข้อเสนอต่อบริษัทที่ปรึกษาได้นำมาซึ่งจุดเปลี่ยนสำคัญครั้งต่อไป

“เราสามารถสร้างระบบบัญชีโดยใช้ SimLex ได้ด้วยหรือไม่?”

เมื่อถูกถามคำถามนั้น ผมตอบโดยไม่ลังเลเลย

“เข้าใจแล้ว ฉันทำได้”

แม้ว่าผมจะตอบรับข้อเสนอนั้นโดยทันที แต่พูดตามตรง แม้ว่าผมจะอ่านงบดุล (B/S) และงบกำไรขาดทุน (P/L) ได้ในฐานะเจ้าของธุรกิจ แต่ผมก็ไม่ได้คุ้นเคยกับตรรกะการบันทึกรายการภายในหรือกลไกการสร้างบัญชีแยกประเภทของระบบบัญชีมากนัก

ถึงอย่างนั้น “เมื่อฉันตัดสินใจทำอะไรแล้ว ฉันจะทำมันให้สำเร็จไม่ว่าจะเกิดอะไรขึ้นก็ตาม” นั่นคือคติประจำใจของฉัน

การพัฒนาท้องถิ่นที่ก้าวข้ามพรมแดนของประเทศ

จากนั้น ผมจึงทุ่มเทให้กับการพัฒนาระบบบัญชี และภายในเดือนพฤษภาคม 2013 ผมก็สร้างต้นแบบเสร็จสมบูรณ์แล้ว อย่างไรก็ตาม การต่อสู้ที่แท้จริงยังมาไม่ถึง

ในขณะนั้น โปรแกรมบัญชีท้องถิ่นได้เข้ามามีบทบาทอย่างแพร่หลายในตลาดไทยแล้ว SimLex ซึ่งเข้ามาในตลาดช้ากว่า จึงเผชิญกับเสียงวิพากษ์วิจารณ์อย่างหนักจากนักบัญชีภาคสนามที่บ่นเกี่ยวกับฟีเจอร์ที่ขาดหายไปและความไม่สามารถสร้างรายงานบางอย่างได้

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

ความท้าทายที่ใหญ่ที่สุดในระหว่างการพัฒนาคือ “การจัดการหมายเลขที่ยืดหยุ่น” และ “การปรับตัวให้เข้ากับมาตรฐานการบัญชีของประเทศต่างๆ ในเอเชียตะวันออกเฉียงใต้”

ในการดำเนินธุรกิจในต่างประเทศ กฎเกณฑ์เกี่ยวกับการกำหนดหมายเลขใบแจ้งหนี้มีความหลากหลายมากกว่าในประเทศญี่ปุ่นมาก

  • IVyyyyMMxxx(หมายเลขลำดับจะถูกรีเซ็ตทุกเดือน)

  • yyyyxxxxxx(รีเซ็ตทุกปี)

  • [顧客コード]＋yyyyMMxxx(ระบบการกำหนดหมายเลขแยกต่างหากสำหรับลูกค้าแต่ละราย)

เพื่อตอบสนองความต้องการเหล่านี้อย่างยืดหยุ่น เราได้สร้างระบบที่กำหนดกฎการกำหนดหมายเลขให้เป็นมาตรฐานหลัก ซึ่งช่วยให้สามารถเลือกและนำไปใช้ได้อย่างอิสระเมื่อออกเอกสารต่างๆ

นอกจากนี้ มาตรฐานการบัญชีของอินโดนีเซียกำหนดให้มีการแยกแยะอย่างชัดเจนระหว่าง “อัตราแลกเปลี่ยนอย่างเป็นทางการสำหรับการยื่นภาษีมูลค่าเพิ่ม” และ “อัตราแลกเปลี่ยนตลาดสำหรับธุรกรรมทางการค้า (ลูกหนี้และเจ้าหนี้)” และยังมีกฎระเบียบท้องถิ่นโดยละเอียดอื่นๆ ที่แตกต่างจากระบบภาษีของไทย เราได้พิจารณาความแตกต่างระหว่างประเทศเหล่านี้ทีละประเด็นอย่างรอบคอบ

การบูรณาการอย่างสมบูรณ์ในฐานะระบบ ERP คืออุปสรรคต่อไป

จากนั้นระบบบัญชีที่พัฒนาเสร็จสมบูรณ์แล้วจึงถูกบูรณาการเข้ากับระบบการจัดการการผลิตอย่างเต็มรูปแบบในระดับแผนภาพ ER

การจัดการการขาย การจัดการการผลิต และการบัญชี ไม่ใช่ระบบที่แยกส่วนกันอีกต่อไป แต่ได้มีการบูรณาการอย่างแน่นหนาในรูปแบบข้อมูลเดียว

สมุดบัญชีรายรับและรายจ่ายจะถูกสร้างขึ้นโดยอัตโนมัติโดยตรงจากธุรกรรมการจัดการการผลิต ซึ่งเป็นแหล่งข้อมูลหลัก แทนที่จะป้อนข้อมูลแยกต่างหากซ้ำสองครั้ง ในส่วนนี้เช่นกัน หลักการของแหล่งข้อมูลเดียวที่ถูกต้อง (Single Source of Truth) ถูกนำมาใช้อย่างสม่ำเสมอ

“แทนที่จะให้ข้อมูลเดียวกันถูกทำซ้ำในหลายระบบ เราจะถือว่าข้อมูลต้นฉบับเป็นความจริงเพียงหนึ่งเดียว และจัดทำรายงานและรายการทางบัญชีที่จำเป็นตามนั้น”

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

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

นั่นคือ “การบริหารต้นทุน”

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

สิ่งนี้จะนำฉันไปสู่ความท้าทายต่อไป: การปรับปรุงระบบการจัดการต้นทุนครั้งใหญ่

บทที่ 8: คำถามต่อ “(Process Charge)” ที่เกิดขึ้นจากการพัฒนาระบบบริหารต้นทุน

ระบบการจัดการต้นทุนที่รวมอยู่ในเวอร์ชันเริ่มต้นของ SimLex ERP นั้น อาจเรียกได้ว่าเป็น “ระบบการจัดการต้นทุนแบบง่าย”

ระบบทำงานโดยการลงทะเบียน “ค่าธรรมเนียมกระบวนการ (อัตราค่าใช้จ่ายในการประมวลผลต่อชั่วโมง)” ล่วงหน้าในข้อมูลหลักของกระบวนการ จากนั้นจึงคำนวณและสะสมราคาต่อหน่วยมาตรฐานสำหรับแต่ละกระบวนการและแต่ละรายการ ซึ่งถือว่าเพียงพอสำหรับความต้องการทั่วไปของระบบ

อย่างไรก็ตาม เมื่อการพัฒนาคืบหน้าไปเรื่อยๆ คำถามสำคัญข้อหนึ่งก็ผุดขึ้นมาในใจผม

เมื่อฉันสอบถามบริษัทผู้ใช้งานว่า “ค่าธรรมเนียมกระบวนการนี้คำนวณเมื่อใดและอย่างไร” คำตอบที่ฉันได้รับนั้นล้วนเหลือเชื่อ

“เราใช้ตัวเลขชุดเดิมที่เรากำหนดไว้ตั้งแต่ตอนก่อตั้งโรงงาน”

“เราเพียงแค่ป้อนจำนวนเงินตามที่สำนักงานใหญ่ของเราในญี่ปุ่นแจ้งมาเท่านั้น”

ฉันไม่ได้บอกว่าเรื่องนี้ใช้ได้กับทุกบริษัท แต่ในหลายๆ ที่ตัวเลขที่ห่างไกลจากต้นทุนการผลิตจริงถูกนำมาใช้โดยไม่ตั้งคำถาม

ในความเป็นจริง ค่าใช้จ่ายตามกระบวนการจะถูกคำนวณและรวบรวมอย่างซับซ้อนโดยใช้โปรแกรม Excel โดยผู้เชี่ยวชาญเฉพาะด้านที่มีความรู้ความสามารถทั้งด้านบัญชีและการผลิต

“ทำไมจึงมีแนวคิดที่คลุมเครือและขึ้นอยู่กับดุลพินิจอย่างมากเช่น ‘ค่าธรรมเนียมกระบวนการ’ อยู่?”

หลังจากพิจารณาอย่างถี่ถ้วนแล้ว ผมก็พบว่าสาเหตุหลักมาจากโครงสร้างเพียงอย่างเดียว

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

หากไม่มีการปรับปรุงค่าธรรมเนียมกระบวนการให้เหมาะสม ต้นทุนก็จะยังคงถูกคำนวณโดยใช้มาตรฐานที่ล้าสมัยต่อไป ในสถานการณ์เช่นนี้ ผู้จัดการย่อมไม่สามารถตัดสินใจได้อย่างถูกต้อง

ที่สำคัญที่สุดคือ ตราบใดที่คุณยังใช้ค่าคงที่ เช่น ค่าใช้จ่ายในการผลิต คุณจะมองข้ามพลวัตต้นทุนขั้นพื้นฐานที่สุดไป เช่น ข้อเท็จจริงที่ว่า “หากปริมาณการผลิตลดลง ต้นทุนคงที่จะไม่กระจายออกไป และต้นทุนต่อหน่วยของผลิตภัณฑ์จะเพิ่มขึ้น”

ในที่นี้ ผมได้กลับมาพิจารณาคำถามพื้นฐานที่ผมพบในบทที่ 1 อีกครั้ง นั่นคือ “เราจะสร้างแบบจำลองโลกแห่งความเป็นจริงโดยใช้เพียงองค์ประกอบที่จำเป็นน้อยที่สุดได้อย่างไร”

องค์ประกอบสำคัญที่ประกอบกันเป็นต้นทุนนั้นมีอะไรบ้างกันแน่?

หลังจากตัดองค์ประกอบที่ไม่จำเป็นออกไปแล้ว จะเหลือเพียงสองส่วนดังต่อไปนี้:

  1. ข้อมูลค่าใช้จ่ายจริงที่แสดงจากระบบบัญชี

  2. ข้อมูล “ปริมาณ เวลาในการผลิต และราคาซื้อ” จะถูกบันทึกไว้ในสมุดบัญชีรายรับและรายจ่าย

ถูกต้องแล้ว ไม่มีสิ่งที่เรียกว่า “ค่าธรรมเนียมกระบวนการ” ในส่วนประกอบสำคัญของต้นทุนตั้งแต่แรกเริ่มเลย

“ถ้าอย่างนั้น การเชื่อมโยงข้อมูลค่าใช้จ่ายทางบัญชีเข้ากับข้อมูลบัญชีรายรับรายจ่ายโดยตรง แล้วคำนวณต้นทุนจากตรงนั้น น่าจะดีกว่าไม่ใช่หรือ?”

จึงได้มาซึ่งตรรกะที่สมเหตุสมผลและเป็นธรรมชาติอย่างยิ่ง

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

ความท้าทายที่ใหญ่ที่สุดในการพัฒนาจริง คือปัญหาที่ ไม่มีความสอดคล้องกันแบบหนึ่งต่อหนึ่งระหว่าง “แผนกบัญชี” กับ “กระบวนการผลิตในโรงงาน “

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

ด้วยการ “เชี่ยวชาญ” กฎการจัดสรรที่เคยซ่อนอยู่ในความคิดของบุคคลเฉพาะกลุ่ม ทำให้ปัจจุบันทุกคนสามารถเข้าใจระบบการจัดการต้นทุนได้อย่างง่ายดาย กล่าวอีกนัยหนึ่ง เราได้ขจัดความจำเป็นในการพึ่งพาความเชี่ยวชาญเฉพาะบุคคลในการกำหนดค่าบริการตามกระบวนการแล้ว

ด้วยเหตุนี้ ระบบการจัดการต้นทุนที่แท้จริงสำหรับ SimLex ERP จึงเสร็จสมบูรณ์

ระบบนี้จัดการต้นทุนมาตรฐาน ต้นทุนจริง และแม้แต่ต้นทุนตามงบประมาณได้อย่างสมบูรณ์แบบ ในโลกของ SimLex ERP นั้น “ค่าธรรมเนียมกระบวนการ” แบบดั้งเดิมจะไม่ใช่สิ่งที่ต้องป้อนตั้งแต่เริ่มต้นอีกต่อไป แต่เป็นเพียง “ผลลัพธ์” ที่ได้มาโดยอัตโนมัติในระหว่างกระบวนการคำนวณ

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

เมื่อเรานำระบบการจัดการต้นทุน SimLex ERP ไปใช้กับผู้ผลิตชิ้นส่วนความแม่นยำสูงรายใหญ่สำหรับ iPhone ข้อมูลต้นทุนที่คำนวณได้ผ่านการตรวจสอบอย่างเข้มงวดจากบริษัทบัญชีชั้นนำของญี่ปุ่น อย่างประสบความสำเร็จ นั่นเป็นช่วงเวลาที่ตรรกะที่เราสร้างขึ้นตั้งแต่เริ่มต้น ซึ่งท้าทายแนวคิดดั้งเดิมของระบบ ERP หลักๆ ได้รับการยอมรับตามมาตรฐานสากล

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

ผู้ตรวจสอบบัญชีในประเทศไทยไม่ค่อยมีความรู้เกี่ยวกับแนวคิดทางการบัญชีบริหารขั้นสูง เช่น “ต้นทุนมาตรฐาน ต้นทุนจริง และการวิเคราะห์ความแปรปรวน” และการปฏิบัติที่ว่า “บริหารงานโดยใช้ต้นทุนจริงเท่านั้น” ยังคงฝังรากลึกอยู่

เนื่องจากภูมิหลังทางประวัติศาสตร์ ญี่ปุ่นและไทยจึงมีแนวทางการจัดการต้นทุนและกระบวนการพัฒนาที่แตกต่างกันอย่างมาก

แม้ว่าตรรกะของระบบจะเสร็จสมบูรณ์แล้ว แต่ก็ทำให้เราเผชิญกับความท้าทายในการดำเนินงานใหม่ นั่นคือ “จะจัดการกับความแตกต่างในปรัชญาการบัญชีระหว่างประเทศได้อย่างไร”

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

บทที่ 9: การวิเคราะห์ต้นเหตุสู่การจัดทำแพ็คเกจบริหารต้นทุนอิสระ… ผลลัพธ์ที่คาดไม่ถึง

ในระหว่างการพัฒนาระบบการจัดการต้นทุน ผมได้ครุ่นคิดว่า “แก่นแท้ของการจัดการต้นทุนคืออะไร?”

ด้วยเหตุนี้ ข้อมูลสำคัญที่จำเป็นสำหรับการบริหารจัดการต้นทุนจึงได้แก่:

  1. ข้อมูลค่าใช้จ่ายจริงที่แสดงจากระบบบัญชี
  2. ข้อมูลต่างๆ เช่น ปริมาณ เวลาในการผลิต และราคาซื้อ จะถูกบันทึกไว้ในสมุดบัญชีรายรับและรายจ่าย

ดังที่ได้กล่าวไว้ในบทที่แล้ว นี่คือข้อสรุปที่เราได้มา

ที่จริงแล้ว ในตอนแรกเราไม่ได้ตั้งใจที่จะสร้างโปรแกรมบริหารจัดการต้นทุนแบบแยกต่างหาก

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

ดังนั้น,

“ในกรณีนั้น หากเรานำเข้าข้อมูลที่จำเป็นจากระบบ ERP และระบบบัญชีของบริษัทอื่น ๆ ก็จะสามารถนำเสนอการจัดการต้นทุนเป็นแพ็กเกจแยกต่างหากได้หรือไม่?”

ฉันก็คิดอย่างนั้นเหมือนกัน

นี่คือจุดเริ่มต้นของแนวคิดเกี่ยวกับซอฟต์แวร์บริหารจัดการต้นทุนแบบอิสระ

สิ่งที่จำเป็นจริงๆ คืออินเทอร์เฟซ Excel สำหรับนำเข้าข้อมูลค่าใช้จ่ายทางบัญชีและข้อมูลใบเสร็จรับเงิน/การจ่ายเงิน อินเทอร์เฟซ Excel สำหรับข้อมูลหลักของสินค้า รายการวัสดุ และราคาสินค้าต่อหน่วยหลักของสินค้าที่ซื้อนั้นมีอยู่แล้ว

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

และตรงนี้เอง เราก็ได้เห็น ปรัชญาการออกแบบของ SimLex อีกครั้ง นั่นคือ “การทำให้ง่ายที่สุด”

ซอฟต์แวร์ที่ออกแบบจากหลักการพื้นฐานไม่จำเป็นต้องลดความซับซ้อนในภายหลังด้วยการตัดคุณสมบัติที่ไม่จำเป็นออกไปเนื่องจากประกอบด้วยเฉพาะสิ่งที่จำเป็นเท่านั้น โปรแกรมจึงมีความเรียบง่ายไปโดยปริยาย

เราไม่ได้ตั้งใจที่จะสร้างแพ็กเกจแบบใช้งานได้โดยสมบูรณ์ตั้งแต่แรก

จากการค้นหาแก่นแท้ของปัญหา จึงได้สร้างแพ็กเกจการจัดการต้นทุนที่เป็นอิสระขึ้นมา

และสำหรับ SimLex นั้น นั่นเป็น “ผลพลอยได้” ที่ไม่คาดคิด นั่นคือการพัฒนา ซอฟต์แวร์บริหารจัดการต้นทุนแบบครบวงจรจนเสร็จสมบูรณ์

ขอขอบคุณที่อ่าน “เรื่องราวการกำเนิดของ SimLex ERP” หากคุณมีข้อคิดเห็นหรือข้อสงสัยใด ๆ โปรดติดต่อเราได้ที่อีเมลด้านล่างนี้

[email protected]