BPM Migration
สิ่งที่ย้ายได้ และสิ่งที่ต้องสร้างใหม่ เมื่อย้ายจาก Camunda, IBM BPM, Oracle BPM Suite และ Appian มาสู่ beflex Enterprise BPM
องค์กรที่ยังรัน IBM BPM หรือ Oracle BPM Suite อยู่ทุกวันนี้ ส่วนใหญ่ไม่ได้อยู่ตรงนั้นเพราะเพิ่งประเมินทางเลือกแล้วเลือกเหมือนเดิม แต่เพราะระบบยังทำงานอยู่ และการย้ายดูเป็นงานใหญ่ที่ยังไม่ถึงเวลา — จนกระทั่งวันที่ถึงเวลาจริง
เมื่อถึงวันนั้น ขั้นตอนแรกดูตรงไปตรงมา — export process ออกมาเป็น BPMN 2.0 XML แล้ว import เข้าระบบใหม่ ในเมื่อทั้งสองฝั่งรองรับมาตรฐานเดียวกัน
ผลลัพธ์ที่ได้จริงมักเป็น diagram ที่ทุก element กองทับกันอยู่มุมซ้ายบนของ canvas หรือแย่กว่านั้นคือ error ตั้งแต่ตอน import ยังไม่ทันได้เห็นภาพ
นี่ไม่ใช่ bug และไม่ใช่ความผิดของเครื่องมือฝั่งใดฝั่งหนึ่ง มันคือช่องว่างระหว่าง สิ่งที่มาตรฐาน BPMN 2.0 กำหนดไว้ กับ สิ่งที่ระบบ BPM หนึ่งระบบต้องมีเพื่อทำงานได้จริง ซึ่งกว้างกว่าที่ทีมส่วนใหญ่ประเมินไว้ตอนตั้งงบประมาณ
บทความนี้อธิบายว่าช่องว่างนั้นอยู่ตรงไหน แต่ละระบบต้นทางมีปมเฉพาะอะไร และควรวางแผน migration อย่างไรให้ประมาณการงานได้ใกล้เคียงความจริงตั้งแต่วันแรก
BPMN มี 4 ชั้น และมีเพียงชั้นเดียวที่ portable จริง
เวลาเราพูดว่า “process นี้เป็น BPMN 2.0” เรากำลังพูดถึงของ 4 อย่างที่ซ้อนกันอยู่ และมีคุณสมบัติในการย้ายข้ามระบบต่างกันสิ้นเชิง
ชั้นที่ 1 — Model คือโครงสร้างของกระบวนการ: Task, Gateway, Event, Sequence Flow, Sub-process และ Boundary Event ชั้นนี้คือสิ่งที่มาตรฐาน BPMN 2.0 กำหนดไว้จริง ๆ และย้ายข้ามระบบได้ตามที่โฆษณาไว้
ชั้นที่ 2 — Diagram Interchange (DI) คือพิกัดของทุกกล่องและทุกเส้นบน canvas มาตรฐานกำหนดรูปแบบไว้ แต่ ไม่ได้บังคับว่าระบบต้อง export ออกมา ระบบที่ไม่ได้เก็บ layout ในรูปแบบ BPMN มาตั้งแต่แรกจึง export ออกมาโดยไม่มีชั้นนี้ติดมาด้วย ผลคือ diagram ที่ถูกต้องทางตรรกะ 100% แต่มองไม่รู้เรื่องเลย
ชั้นที่ 3 — Vendor Extension คือ attribute เฉพาะของแต่ละเจ้าที่บอกว่า Service Task นี้เรียกอะไร User Task นี้มอบหมายให้ใคร Timer นับอย่างไร ทั้งหมดอยู่ใน namespace เฉพาะของผู้ผลิตแต่ละราย และ ระบบปลายทางจะไม่เข้าใจและตัดทิ้งทั้งหมด โครงสร้างจะย้ายมาครบ แต่ทุกอย่างที่ทำให้มัน “รันได้” หายไป
ชั้นที่ 4 — Runtime Assets คือฟอร์ม กฎธุรกิจ integration connector โครงสร้าง user/group และข้อมูลประวัติ ของทั้งหมดนี้ ไม่ได้อยู่ในไฟล์ BPMN ตั้งแต่แรก มันอยู่ในฐานข้อมูลหรือ repository แยกของระบบเดิม
ไฟล์
.bpmnคือส่วนที่เล็กที่สุดของงาน migration ทีมที่ประเมินงานจากจำนวน process diagram อย่างเดียวจะพลาดงานจริงไปเกือบทั้งหมด เพราะน้ำหนักงานอยู่ที่ชั้นที่ 3 และ 4 ซึ่งไม่ปรากฏบน diagram เลยสักเส้น
แต่ละระบบต้นทางยากไม่เท่ากัน
Camunda 7 → beflex BPM
เคสที่ตรงไปตรงมาที่สุด เพราะ export ออกมาครบทั้งชั้น Model และ DI เปิดดูได้ทันทีในเครื่องมือใด ๆ ที่รองรับ BPMN 2.0 งานจริงอยู่ที่ชั้นที่ 3: extension เฉพาะของ Camunda ทุกตัวต้อง map ใหม่ — Java Delegate ที่ผูกกับ Spring context เดิม, Camunda Forms, Execution Listener และการตั้งค่าฝั่ง Job Executor
Camunda 8 → beflex BPM
โครงสร้างย้ายได้เท่ากับ Camunda 7 แต่ job worker ที่เขียนไว้ต้องเขียนใหม่ ข้อดีคือ pattern ยังเหมือนเดิม ทีมที่คุ้นกับการแยกงานหนักออกไปรันนอก engine อยู่แล้วจะไม่ต้องเปลี่ยนวิธีคิด เปลี่ยนแค่ชั้นสื่อสาร
IBM BPM / Business Automation Workflow → beflex BPM
ยากขึ้นชัดเจน BPMN ที่ export ออกมาไม่มีชั้น DI ติดมาด้วย ต้องสร้าง layout ขึ้นใหม่ทั้งหมด ส่วนไฟล์ .twx มีข้อมูล diagram อยู่จริงแต่อยู่ในรูปแบบเฉพาะที่ไม่ใช่ BPMN ปมที่หนักกว่านั้นคือ Coach — UI layer ของ IBM ที่ไม่มีคู่เทียบในมาตรฐาน BPMN เลย เพราะฉะนั้นทุกหน้าจอต้องสร้างใหม่ เช่นเดียวกับ Integration Service และ General System Service
Oracle BPM Suite → beflex BPM
อยู่ระหว่าง IBM กับ Appian ในแง่ความยาก Oracle BPM export เป็น BPMN 2.0 XML ได้ และโครงสร้าง process ย้ายมาได้ค่อนข้างครบ แต่แทบทุกอย่างที่ทำให้มันรันได้เป็น Oracle-specific: Human Task ที่ผูกกับ UI แบบ ADF, Oracle Business Rules (OBR), ชุด Adapter สำหรับเชื่อมระบบภายนอก และ dashboard ฝั่ง BAM ทั้งหมดนี้อยู่นอกไฟล์ BPMN และต้องสร้างใหม่ ในทางปฏิบัติสัดส่วนงาน re-implement ขึ้นกับว่าทีมเดิมใช้ Oracle-specific component หนักแค่ไหน — process ที่เขียนแบบยึดมาตรฐานไว้มาก ย้ายง่ายกว่า process ที่ใช้ของ Oracle เต็มที่อย่างมีนัยสำคัญ
Appian → beflex BPM
ยากที่สุดในกลุ่มนี้ เพราะ Appian ไม่ได้เก็บ process model ในรูปแบบ BPMN ตั้งแต่ต้น สิ่งที่ export ได้เป็น package เฉพาะของ Appian ไม่ใช่ BPMN ที่ระบบอื่นอ่านได้ การย้ายจึงเป็นการ re-model จากเอกสารและ process report ไม่ใช่การแปลงไฟล์ SAIL Interface, CDT และ Smart Service ทั้งหมดต้องออกแบบใหม่บนแนวคิดของ BPMN
แล้วระบบอื่นที่ไม่ได้กล่าวถึง?
ในทางปฏิบัติทุกระบบจัดกลุ่มได้เป็นสามแบบตามคุณสมบัติในการ export
| กลุ่ม | ลักษณะ | ตัวอย่าง | ความยาก |
|---|---|---|---|
| A | BPMN-native — export ครบทั้ง Model และ DI | Camunda, jBPM / Red Hat PAM, Bonita | ต่ำ |
| B | export เป็น BPMN แต่ขาดชั้น DI หรือเป็นเพียง BPMN-like | IBM BPM / BAW, Oracle BPM Suite | กลาง |
| C | proprietary model — ไม่มี BPMN export ที่ใช้งานได้จริง | Appian, Pega, Nintex / K2, ProcessMaker | สูง — ต้อง re-model |
ระบบที่ไม่อยู่ในรายการนี้ประเมินได้ด้วยคำถามเดียว — export BPMN 2.0 ออกมาแล้วมีชั้น DI ติดมาด้วยหรือไม่ คำตอบนั้นบอกว่าคุณอยู่กลุ่มไหน และบอกด้วยว่าควรตั้งงบสำหรับงาน re-implement ไว้เท่าไร
องค์ประกอบเดิม ย้ายมาอยู่ที่ไหนใน beflex BPM
| องค์ประกอบในระบบเดิม | ปลายทางใน beflex BPM |
|---|---|
| Human Task / Coach / SAIL Interface | Form Designer แบบ drag & drop หรือ Custom Form (HTML/JS/CSS) สำหรับหน้าจอที่ซับซ้อน |
| Business Rule / Decision Table | Decision Tables แบบ no-code รองรับ Hit Policy ครบ และเปิดเป็น Decision as a Service เรียกผ่าน REST จากระบบอื่นได้ |
| Java Delegate / Smart Service | Custom Java Delegates (วาง JAR ใน custom-libs/) หรือ Expression Language (UEL) |
| External Task / Job Worker | External Task Worker — worker ภายนอกต่างภาษาต่างเครื่อง poll งานผ่าน REST พร้อม Retry และ Deadletter Queue |
| Connector / Adapter | REST Service Task, Webhooks สองทิศทางพร้อม HMAC-SHA256 และ Kafka Event Registry |
| LDAP Group / Role | LDAP / Active Directory Sync (JIT, Bulk, Scheduled) พร้อม Candidate Group และ RBAC |
| Timer / SLA / Business Calendar | BPMN Date Expression และ SLA Monitoring พร้อมแจ้งเตือนอัตโนมัติระดับ WARNING / OVERDUE |
จุดที่ลดงาน re-implement ได้จริง
งานหนักที่สุดของ migration ไม่ใช่การแปลงไฟล์ แต่คือการสร้างสิ่งที่แปลงไม่ได้ขึ้นมาใหม่ beflex BPM มีสามอย่างที่ตรงเข้าไปที่จุดนี้
AI Process Generation — สำหรับ process ที่ export ออกมาใช้ไม่ได้ (Appian ทั้งหมด และ IBM บางส่วน) ทีมสามารถป้อนคำอธิบายกระบวนการหรือเอกสาร spec เดิม แล้วให้ AI ร่างโครงสร้าง BPMN ตั้งต้นให้ — Task, Gateway, ลำดับงาน — จากนั้น Designer ตรวจและปรับก่อน deploy แทนที่จะต้องวาดใหม่ทุกเส้นจากศูนย์ เช่นเดียวกับ AI Form Generation ที่ช่วยร่างฟอร์มจากคำอธิบาย ซึ่งเป็นงานที่กินเวลามากที่สุดเมื่อย้ายจากระบบที่มี UI layer เป็นของตัวเอง
Process Simulation — ทดลองรัน process ที่แปลงมาแล้วแบบ dry-run พร้อม rollback ตรวจว่า flow เดินถูกทางก่อนขึ้น production โดยไม่แตะข้อมูลจริง
beflex CLI — promote configuration ทั้ง Process, Form และ App ข้าม Dev → Staging → Prod ผ่าน transfer bundle ใช้เป็น gate ใน CI pipeline ได้ระหว่างช่วง migration ที่ต้องย้ายของเป็นระลอก
ทุกการเรียก AI ถูกบันทึกใน AI Audit Log ครบทั้ง prompt, response, token และ latency — องค์กรที่มีข้อกำหนดด้าน governance ตรวจสอบย้อนหลังได้ว่า AI ถูกใช้ทำอะไรบ้างในกระบวนการ migration
สองคำถามที่ควรตอบก่อนวางแผนงบประมาณ
แนวทางที่เราใช้แบ่งงานเป็นสามระยะ — Assessment, Pilot หนึ่ง process ให้จบตั้งแต่ต้นจนถึง UAT แล้วจึงขยายผลตาม playbook ที่ได้จากระยะ Pilot รายละเอียดทั้งหมดอยู่ใน Migration Checklist ท้ายบทความ แต่มีสองคำถามที่เปลี่ยนขนาดโครงการอย่างมีนัยสำคัญและทีมมักข้ามไป
1. Instance ที่กำลังรันอยู่จะเอาอย่างไร — ย้ายข้ามระบบ หรือปล่อยให้ระบบเดิมรันจนจบแล้วเปิดรับงานใหม่บนระบบใหม่เท่านั้น (drain) ทางหลังถูกกว่าและเสี่ยงน้อยกว่ามาก แต่ต้องยอมรันสองระบบขนานกันชั่วคราว
2. ข้อมูลประวัติต้องย้ายหรือไม่ — หรือเก็บระบบเดิมไว้เป็น read-only archive คำตอบขึ้นกับข้อกำหนด compliance ไม่ใช่ความสะดวกของทีม IT
ต้นทุนของการรอ
ต้นทุนของการไม่ทำอะไรมักถูกประเมินต่ำเกินจริง ค่า license รายปีของระบบที่ไม่ได้รับ feature ใหม่แล้วยังคงเดินต่อไปทุกปี บุคลากรที่มีทักษะกับแพลตฟอร์มรุ่นเก่าหายากขึ้นและแพงขึ้นเรื่อย ๆ และเมื่อระบบเข้าสู่ปลายวงจรการสนับสนุน ทางเลือกจะเหลือน้อยลงพร้อมกับที่แรงกดดันด้านเวลาสูงขึ้น — migration เป็นค่าใช้จ่ายครั้งเดียวที่วางแผนได้ ส่วนการรอเป็นค่าใช้จ่ายที่เดินต่อเนื่องและควบคุมจังหวะไม่ได้
ควบคุมต้นทุนระยะยาว ด้วย Perpetual License
ประเด็นที่ควรพิจารณาพร้อมกันคือ โครงสร้างของค่าใช้จ่าย ไม่ใช่เพียงยอดรวม beflex BPM เป็น license แบบ perpetual — ค่า license เป็นการลงทุนครั้งเดียว โดยมีค่า Maintenance Agreement รายปีแยกสำหรับการอัปเดตเวอร์ชันและการสนับสนุน ความต่างที่สำคัญอยู่ที่วันที่องค์กรตัดสินใจหยุดต่อสัญญา: รูปแบบ subscription หมายถึงหมดสิทธิ์ใช้งาน ระบบต้องหยุด ส่วนรูปแบบ perpetual ระบบยังทำงานต่อได้ เพียงไม่ได้รับเวอร์ชันใหม่และการสนับสนุน — องค์กรจึงยังถือ อำนาจตัดสินใจ ไว้กับตัวเอง ไม่ใช่ผูกไว้กับรอบบิลของผู้ขาย
ประเมินความพร้อมก่อนตัดสินใจ
ส่ง BPMN export หรือรายการ process ของระบบเดิมมาให้เรา ทีมงานจะวิเคราะห์และส่งรายงานจำแนกให้ว่า process ใดย้ายได้ตรง ใดต้องปรับ และใดต้องสร้างใหม่ พร้อมประมาณการ man-day เบื้องต้น — ไม่มีค่าใช้จ่าย
B Circle Co., Ltd.
อีเมล [email protected] · โทร +66 (0) 2007-2140 · beflexbpm.com
