1. Business Blueprint คืออะไร?

Business Blueprint คือการออกแบบว่าBusiness Process จะทำงานอย่างไรในระบบใหม่

ไม่ใช่เพียง Requirement List และไม่ใช่เพียงการวาด Flowchart ให้ดูสวย

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

รวมถึงต้องเห็นว่า Accounting Entry เกิดเมื่อใด Master Data ใดถูกใช้ ถ้ามี Exception ต้องไปทางไหน ข้อมูลเชื่อมกับระบบอื่นอย่างไร และสุดท้ายต้องได้ Report อะไร

ดังนั้น Business Blueprint จึงไม่ใช่เอกสารของฝ่าย IT เพียงฝ่ายเดียว

แต่เป็นจุดที่Business, Accounting และ System Teamต้องตกลงกันว่า To-Be Process จะเป็นอย่างไร

2. ทำไมเลือก Software แล้ว ยังต้องออกแบบ Process ใหม่?

ก่อน Software Selection บริษัทควรมี Business Requirement ในระดับที่สามารถใช้เปรียบเทียบระบบได้

เช่น ต้องมี Purchase Approval ต้องติดตาม Project Cost ต้องมี Inventory ต้องเชื่อม Bank หรือต้องแยก P&L ตาม Department

Requirement ระดับนี้ช่วยตอบคำถามว่า

Software ใดมีโอกาสรองรับสิ่งที่บริษัทต้องการ?

แต่หลังเลือก Software แล้ว คำถามจะละเอียดขึ้นมาก

ตัวอย่างเช่น Purchase Approval จะเกิดที่ Document ไหน Approval Route กำหนดจาก Amount, Department หรือ User Role และเมื่อ Approve แล้ว Accounting Posting จะเกิดเมื่อใด

ถ้า Supplier Invoice ไม่ตรงกับ PO ต้องทำอย่างไร ใครเป็นผู้ตรวจสอบ และใครมีสิทธิ์ Override

นี่คือระดับของBusiness Blueprint / Detailed To-Be Design

เพราะหลัง Software Selection เราจึงรู้จริงว่า ระบบมี Capability อะไร Configure อย่างไร ใช้ Data Structure แบบไหน และมีข้อจำกัดตรงไหน

3. Flowchart คือหัวใจสำคัญของ Business Blueprint

การอธิบาย Process ด้วยข้อความอย่างเดียว มักทำให้คนแต่ละฝ่ายตีความไม่เหมือนกัน

Flowchart ที่ดี ช่วยเปลี่ยนคำอธิบายจำนวนมาก ให้ทุกฝ่ายเห็น Process เดียวกัน

Purchase Request → Manager Approval → Purchase Order → Receive Goods / Service → Supplier Invoice → Invoice Verification → Payment Approval → Payment → GL / AP / Bank

แต่ Flowchart สำหรับ Business Blueprint ต้องลึกกว่าการแสดงลำดับงาน

ต้องเห็นด้วยว่าใครทำ? System หรือ Manual? Decision Point อยู่ตรงไหน? Control อยู่ตรงไหน? และถ้าไม่ผ่านต้องย้อนกลับไปไหน?

ตัวอย่างเช่น “Invoice ตรงกับ PO และ Receipt หรือไม่?”

ถ้า Yes จึงเข้าสู่ Payment Process แต่ถ้า No ต้องส่งกลับให้ผู้รับผิดชอบตรวจสอบ

เมื่อมี Decision และ Exception Flowchart จึงเริ่มสะท้อน Business Rule และ Internal Control ไม่ใช่แค่ลำดับขั้นตอน

4. Blueprint ที่ดีต้องเห็นทั้ง Process, Data และ Control

ถ้ามองเฉพาะ Process Flow ก็ยังไม่เพียงพอสำหรับ Implementation

Process

ใครทำอะไร Transaction เริ่มตรงไหน ผ่านขั้นตอนอะไร และจบเมื่อใด

Data

ระบบต้องใช้หรือสร้างข้อมูลอะไร เช่น Customer, Supplier, Item, Account, Department, Cost Center, Project, Tax Code และ Payment Term

Control

ต้องกำหนดว่า ใคร Create, Edit, Approve, Post, Reverse หรือ Override ได้

รวมถึง Approval Limit, Segregation of Duties และ Audit Trail ตามความเหมาะสม

เมื่อ Process, Data และ Control ไม่เชื่อมกัน Blueprint อาจดูสมบูรณ์บนกระดาษ แต่ยังนำไป Configuration จริงไม่ได้

บริษัทที่กำลังเตรียม Blueprint สามารถดูขอบเขตบริการออกแบบระบบบัญชีและกระบวนการทำงาน เพื่อพิจารณางานด้าน Process โครงสร้างข้อมูล และจุดควบคุมที่ต้องเตรียมร่วมกัน

5. หลังเลือก Software ต้องทำ Fit / Gap อีกครั้ง

หลังเลือกระบบ Requirement แต่ละข้อ ต้องถูกพิจารณาว่าจะ Implement อย่างไร

จุดสำคัญคือGap ไม่ได้แปลว่าต้อง Custom ทุกครั้ง

บางครั้ง Standard Process หรือ Configuration อาจตอบโจทย์ได้ดีกว่า และลดความซับซ้อนในระยะยาว

แต่ก็ไม่ควรกลับกันจนกลายเป็นว่า ทุก Process ต้องเปลี่ยน เพียงเพราะ Software ทำไม่ได้

การตัดสินใจควรกลับไปพิจารณา Business Value, Control, Cost และความซับซ้อนร่วมกัน

6. Blueprint ต้องออกแบบ Exception ไม่ใช่เฉพาะ Happy Path

Process ที่ทุกอย่างถูกต้อง มักออกแบบได้ง่าย

แต่โลกจริงมี Exception เช่น ลูกค้าจ่ายเงินไม่ครบ Supplier Invoice ไม่ตรงกับ PO สินค้าที่รับมาไม่ครบ Payment ถูก Reject หรือ Approver ไม่อยู่

รวมถึง Transaction ที่ต้อง Cancel User เลือก Account ผิด Credit Limit เกิน หรือ Interface ส่งข้อมูลไม่สำเร็จ

Blueprint ที่ดีจึงต้องตอบว่า

ถ้าสิ่งที่ควรเกิด ไม่เกิดตามปกติ System และคนจะทำอย่างไรต่อ?

หลายครั้งปัญหาตอน Implementation ไม่ได้เกิดจาก Standard Transaction แต่เกิดจาก Exception ที่ไม่มีใครออกแบบไว้

7. Accounting Posting ต้องอยู่ใน Blueprint ด้วย

สำหรับ Accounting System Process ไม่ควรจบเพียงว่า “User กด Submit แล้วเสร็จ”

ต้องเข้าใจด้วยว่า Transaction ทำให้เกิด Accounting Impact เมื่อใด

เช่น Dr. อะไร Cr. อะไร Posting Date มาจากไหน Tax เกิดเมื่อใด และ Sub-ledger เชื่อมกับ GL อย่างไร

รวมถึง Cost Center หรือ Project ถูกดึงมาจากไหน ใครมีสิทธิ์แก้ Accounting Dimension และ Correction Process ทำอย่างไร

ถ้า Business Process และ Accounting Logic ถูกออกแบบแยกจากกัน ปัญหามักไปโผล่ตอน Reconciliation หรือ Month-end Closing

8. Reporting ต้องย้อนกลับมาอยู่ใน Blueprint

Blueprint ไม่ควรออกแบบ Transaction ให้เสร็จ แล้วค่อยถามภายหลังว่า Management ต้องการ Report อะไร

ถ้าต้องการP&L by DepartmentTransaction ต้องมี Department

ถ้าต้องการProject ProfitabilityRevenue และ Cost ต้องเชื่อมกับ Project

ถ้าต้องการCustomer Marginต้องสามารถเชื่อม Revenue และ Cost กลับไปยัง Customer ได้

ดังนั้น Blueprint ควรเชื่อมInput → Process → Accounting → Outputเข้าด้วยกัน

9. ถ้า Blueprint ไม่ชัด จะเกิดอะไรตอน Implementation?

ปัญหาที่พบได้บ่อย คือ Project เริ่ม Configuration ทั้งที่ Process ยังไม่ได้ตกลงกันจริง

จากนั้น Requirement เริ่มเปลี่ยนระหว่าง Build Business กับ Implementer เข้าใจไม่ตรงกัน และ Configuration ต้องแก้ไปมา

ผลที่ตามมาอาจเป็น

Business Blueprint จึงไม่ใช่ Paperwork ที่ทำเพียงเพื่อให้ Project มีเอกสารครบ

แต่เป็นวิธีลดความคลุมเครือก่อนเริ่ม Build

10. Blueprint ที่ดีควรจบด้วยอะไร?

ก่อนเข้าสู่ Implementation Process หลักควรมีความชัดเจนอย่างน้อยว่า

และที่สำคัญที่สุดคือ

Business และ Implementation Team ต้องเห็น Process เดียวกัน

Business Blueprint กับ UAT เชื่อมกันอย่างไร?

Blueprint ที่ชัด จะกลายเป็นพื้นฐานสำคัญของ UAT

UAT ไม่ควรถามเพียงว่า “กดแล้วระบบ Error หรือไม่?”

แต่ต้องพิสูจน์ว่า

To-Be Process ที่ตกลงไว้ สามารถทำงานจริงได้หรือไม่

Scenario สำหรับ UAT จึงควรย้อนกลับไปหา Blueprint เช่น Normal Transaction, Approval, Exception, Accounting Result, Integration Result และ Reporting Result

ถ้า Blueprint ยังคลุมเครือ UAT อาจกลายเป็นช่วงที่ Business เพิ่งเริ่ม Design ระบบจริง ซึ่งสายเกินไปแล้ว

ลำดับของโครงการหลัง Software Selection

Software Selection → Business Blueprint / To-Be Process → Fit / Gap & Design Decision → Configuration / Development → Testing → UAT → Training / Cutover → Go-live

ระหว่างทางอาจมีการย้อนกลับ เพื่อปรับ Blueprint เมื่อพบข้อจำกัดหรือข้อมูลใหม่

สิ่งนี้เป็นเรื่องปกติ แต่ไม่ควรปล่อยให้ Project อยู่ในสภาพที่Design เปลี่ยนตลอดเวลาโดยไม่มี Baseline

สรุป

Software Selection ตอบว่า“เราจะใช้ Platform อะไร?”

Business Blueprint ต้องตอบต่อว่า“Platform นั้นจะทำงานกับ Business Process ของเราอย่างไร?”

Flowchart ที่ดี ช่วยให้ Business, Accounting และ System Team เห็น Process เดียวกัน

ตั้งแต่ Transaction เริ่มต้น ไปจนถึง Decision, Control, System, Accounting, Exception และ Reporting

Green Light ที่ควรจำคือRequirement ชัด → Blueprint ชัด → Implementation เดินตรง