ไทย
English
ทีม IT ส่วนใหญ่รู้แล้วว่า Low-Code ดียังไง แต่คำถามที่ได้ยินบ่อยที่สุดจากลูกค้าของเราคือ “เราจะเริ่มต้นยังไง?”
คู่มือพัฒนาแอป Low-Code ฉบับนี้ ไม่ได้อธิบายว่า Low-Code คืออะไร เพราะ เรามีบทความนั้นอยู่แล้ว แต่จะอธิบายว่าถ้าวันนี้องค์กรของคุณตัดสินใจจะ ระบบพัฒนาแอปด้วย Mendix ต้องทำอะไร เรียงลำดับยังไง และระวังอะไรบ้าง
ก่อนเริ่มใช้คู่มือพัฒนาแอป Low-Code: ตอบ 3 คำถามนี้ให้ได้ก่อน
หลายโปรเจค Low-Code ไปต่อไม่ได้ไม่ใช่เพราะตัวระบบแต่เพราะไม่ได้เตรียมตัวให้พร้อมก่อนเริ่ม ดังนั้นก่อนจะเปิดโปรแกรมพัฒนาขึ้นมา ให้ตอบ 3 คำถามนี้ให้ได้ก่อน
1. งานนี้เหมาะกับ Low-Code จริงไหม?
Low-Code เหมาะกับงานที่มีขั้นตอนชัดเจน ต้องการเชื่อมต่อกับระบบเดิมและต้องการปรับเปลี่ยนบ่อย
ตัวอย่างที่เหมาะ:
– ระบบขออนุมัติ
– พอร์ทัลสำหรับลูกค้า
– ระบบต้อนรับพนักงานใหม่
– แดชบอร์ดรายงาน
– ระบบสินเชื่อ
ตัวอย่างที่อาจไม่เหมาะ:
– ระบบที่ต้องการสูตรคำนวณซับซ้อนมาก
– ระบบที่ต้องประมวลผลข้อมูลปริมาณมากแบบเรียลไทม์
– ระบบที่มีกฎทางธุรกิจเฉพาะทางสูงมาก
2. ใครรับผิดชอบโปรเจคนี้?
Low-Code ทำงานได้ดีที่สุดเมื่อมีทั้งเจ้าของฝั่งธุรกิจและหัวหน้าทีม IT เข้าร่วมตั้งแต่ต้น ถ้ามีแค่ฝ่ายใดฝ่ายหนึ่ง ผลลัพธ์มักออกมาไม่ตรงความต้องการจริง
3. ระบบเดิมที่ต้องเชื่อมต่อมีอะไรบ้าง?
ก่อนเริ่มสร้างต้องรู้ว่าระบบหลัก เช่น ERP, Core Banking หรือระบบ HR มีช่องทางเชื่อมต่อพร้อมไหม เพราะส่วนนี้คือขั้นตอนที่ใช้เวลามากที่สุดในทุกโปรเจคระดับองค์กร ถ้าไม่มีเอกสารพร้อม
ต้องเผื่อเวลาหาข้อมูลเพิ่มอีก 1–2 สัปดาห์
ขั้นตอนที่ 1: สำรวจและกำหนดขอบเขต
นี่คือขั้นตอนที่สำคัญที่สุดและมักถูกข้ามเพราะรู้สึกว่าเสียเวลาแต่จริงๆ แล้วเป็นขั้นตอนที่ประหยัดเวลามากที่สุด สิ่งที่ต้องทำในขั้นตอนนี้:
- วาดขั้นตอนการทำงานปัจจุบันออกมาก่อน ว่าตอนนี้ทำอะไรบ้าง ใครทำ ใช้เวลานานแค่ไหน และปัญหาหลักคืออะไร อย่าข้ามขั้นตอนนี้เด็ดขาดเพราะถ้าไม่รู้ว่ากระบวนการเดิมเป็นยังไง จะออกแบบกระบวนการใหม่ไม่ได้
- เขียนความต้องการของผู้ใช้ในรูปแบบ “ในฐานะ [ใคร] ฉันอยากทำ [อะไร] เพื่อให้ได้ [อะไร]” ตัวอย่าง: “ในฐานะเจ้าหน้าที่สินเชื่อ ฉันอยากดูข้อมูลลูกค้าทั้งหมดในหน้าเดียว เพื่อให้ตัดสินใจอนุมัติได้เร็วขึ้น”
- ทำรายการระบบที่ต้องเชื่อมต่อ (API) พร้อมระบุว่ามีช่องทางเชื่อมต่อไหมและใครดูแลระบบนั้น
เมื่อทำครบแล้ว ให้สรุปขอบเขตงาน ที่ระบุชัดเจนว่าในรุ่นแรกจะทำอะไรและไม่ทำอะไร
ขั้นตอนที่ 2: ออกแบบระบบเวอร์ชันแรก
หลักการคือทำให้เล็กที่สุดเท่าที่ยังแก้ปัญหาหลักได้ใน Mendix ขั้นตอนนี้ประกอบด้วย:
สร้างโครงสร้างข้อมูล
แสดงว่ามีข้อมูลอะไรบ้าง
และแต่ละส่วนเชื่อมกันยังไง
นี่คือสิ่งแรกที่ต้องทำเพราะเป็นรากฐานของทั้งระบบออกแบบเส้นทางการใช้งาน วางว่าผู้ใช้แต่ละประเภทจะทำอะไรได้บ้างตั้งแต่เข้าระบบไปจนถึงทำงานเสร็จ ในขั้นตอนนี้ยังไม่ต้องสวย แต่ต้องครอบคลุมเส้นทางหลักให้ครบ
วางกฎทางธุรกิจ เช่น ถ้ายอดสินเชื่อเกิน X บาท ต้องผ่านการอนุมัติกี่ชั้นและมีข้อยกเว้นอะไรบ้าง นอกจากนี้ Mendix ที่ผสาน AI เข้ามาช่วยยังช่วยออกแบบกฎที่ซับซ้อนได้เร็วขึ้นด้วย
ขั้นตอนที่ 3: สร้างระบบเป็นรอบๆ
แนะนำให้ทำงานเป็นรอบละ 2 สัปดาห์โดยแต่ละรอบมีเป้าหมายชัดเจน แต่ละรอบทำแบบนี้:
วัน 1–2: วางแผนว่ารอบนี้จะทำอะไร
วัน 3–8: สร้างระบบ โดยมีนักวิเคราะห์ธุรกิจ
ติดตามและให้ความเห็นระหว่างทำ
ไม่ใช่รอให้เสร็จแล้วค่อยดู
วัน 9–10: สาธิตให้เจ้าของโปรเจคดู
และจดทุกความเห็นที่ได้รับ
สิ่งที่ต้องทำในแต่ละรอบ:
ทดสอบทุกกฎทางธุรกิจทีละอัน อย่ารอทดสอบรวมตอนสุดท้ายเพราะถ้าพบปัญหาตอนนั้นจะแก้ยากมาก
ทดสอบการเชื่อมต่อกับระบบหลัก ทุกสถานการณ์ รวมถึงกรณีที่ระบบขัดข้อง
ให้ผู้ใช้จริงทดสอบด้วยตัวเอง ไม่ใช่ให้ทีม IT ทดสอบแทน เพราะผู้ใช้จริงจะเจอสถานการณ์ที่ทีม IT ไม่ได้นึกถึงเสมอ
ขั้นตอนที่ 4: เชื่อมต่อระบบเดิม
นี่คือขั้นตอนที่ใช้เวลานานที่สุดในโปรเจคขององค์กรไทย เพราะระบบเดิมหลายตัวไม่มีเอกสารครบถ้วน
สิ่งที่ต้องเตรียม:
ขอเอกสารช่องทางเชื่อมต่อจากทุกระบบที่ต้องเชื่อมต่อ ถ้าไม่มีต้องเผื่อเวลาหาข้อมูลเพิ่มมีสภาพแวดล้อมทดสอบแยกออกจากระบบจริง การทดสอบบนระบบจริงโดยตรง คือความผิดพลาดที่แพงมาก วางแผนล่วงหน้าว่าถ้าการเชื่อมต่อมีปัญหา จะทำอะไร เพราะในระบบจริงต้องตัดสินใจได้เร็ว
ขั้นตอนที่ 5: เปิดใช้งานจริง
ใน Mendix มี 3 สภาพแวดล้อมที่ควรใช้เสมอ: พัฒนา → ทดสอบ → ใช้งานจริง
ขั้นตอนที่แนะนำ:
เปิดให้ใช้กลุ่มเล็กๆ ก่อน เช่น 10–20 คน เพื่อเก็บความเห็นจริงก่อนเปิดใช้ทั้งองค์ก ติดตามข้อผิดพลาดและประสิทธิภาพ อย่างใกล้ชิดใน 48 ชั่วโมงแรก เพราะปัญหาส่วนใหญ่จะโผล่ในช่วงนี้กำหนด 2 สัปดาห์แรกหลังเปิดใช้งานเป็นช่วงดูแลพิเศษ โดยมีทีมนักพัฒนาพร้อมแก้ไขทันทีถ้ามีปัญหาเกิดขึ้น
ขั้นตอนที่ 6: ดูแลและขยายแอปที่พัฒนาด้วย Low-Code
หลายทีมคิดว่าเปิดใช้งานแล้วคือจบ แต่จริงๆแล้วคือจุดเริ่มต้นของการดูแลระบบที่แท้จริง สิ่งที่ต้องทำหลังเปิดใช้งาน:
ตั้งระบบติดตามที่แสดงสถานะและอัตราข้อผิดพลาดแบบเรียลไทม์ สร้างช่องทางให้ผู้ใช้แจ้งปัญหาและขอฟีเจอร์ใหม่ได้โดยตรงกำหนดช่วงเวลาบำรุงรักษา เช่น ทุกคืนวันอาทิตย์เวลา 2–4 AM
ติดตามการใช้งานเพื่อวางแผนล่วงหน้าว่าเมื่อไหร่จะต้องขยายระบบ
นอกจากนี้การนำ AI มาผสานกับระบบหลังเปิดใช้งานเป็นขั้นตอนต่อไปที่ทำให้ระบบมีคุณค่ามากขึ้น
ระยะเวลาโดยรวมตามคู่มือพัฒนาแอป Low-Code
งานขนาดกลาง เช่น ระบบขออนุมัติหรือพอร์ทัลลูกค้า:
สำรวจและกำหนดขอบเขต 1–2 สัปดาห์
ออกแบบระบบเวอร์ชันแรก 1–2 สัปดาห์
สร้างระบบรอบที่ 1 | 2 สัปดาห์
สร้างระบบรอบที่ 2 | 2 สัปดาห์
เชื่อมต่อระบบเดิม 2–3 สัปดาห์
ทดสอบและแก้ไข 1 สัปดาห์
เปิดใช้งานจริง 1 สัปดาห์
รวมทั้งหมด 10–13 สัปดาห์
ตัวเลขนี้สั้นกว่าการพัฒนาแบบดั้งเดิม ที่งานขนาดเดียวกัน อาจใช้เวลา 6–12 เดือน อย่างไรก็ตาม ตัวเลขขึ้นอยู่กับ ความพร้อมของช่องทางเชื่อมต่อ และความชัดเจนของความต้องการตั้งแต่ต้น
ข้อผิดพลาดที่พบบ่อย
คู่มือพัฒนาแอป Low-Code ฉบับนี้ รวบรวมข้อผิดพลาดที่เจอซ้ำๆ จากประสบการณ์จริงของ TBN ที่ช่วยองค์กรไทยมานาน
งานบวมกลางรอบ อยากใส่ทุกอย่างตั้งแต่แรก แก้ได้โดยล็อคขอบเขตก่อนเริ่มรอบ และเก็บทุกความต้องการใหม่ไว้รอรอบถัดไป ไม่ใช่เพิ่มเข้ารอบปัจจุบัน
ไม่มีนักวิเคราะห์ธุรกิจ นักพัฒนาสร้างตามที่คิดเอง ส่งผลให้ระบบออกมาไม่ตรง กับสิ่งที่ธุรกิจต้องการจริงๆ
ทดสอบช้าเกินไป รอให้สร้างเสร็จทั้งหมดแล้วค่อยทดสอบ เป็นแนวทางที่แพงมาก ดังนั้นต้องทดสอบทุกรอบเสมอ
ไม่บันทึกกฎทางธุรกิจไว้ พอคนที่สร้างออกไป คนใหม่เข้ามาไม่รู้ว่าระบบทำงานยังไง ควรบันทึกคำอธิบายไว้ใน Mendix ทุกครั้งที่มีกฎซับซ้อน
คำถามที่พบบ่อย
Q: ต้องมีนักพัฒนากี่คนถึงจะเริ่มได้?
A: สำหรับงานขนาดกลาง
เริ่มต้นด้วย 2–3 คนได้ครับ
ประกอบด้วยนักพัฒนา Mendix 1 คน
นักวิเคราะห์ธุรกิจ 1 คน
และเจ้าของโปรเจค 1 คน
นอกจากนี้ควรมีผู้เชี่ยวชาญด้านการเชื่อมต่อระบบ
อีก 1 คน สำหรับขั้นตอนเชื่อมต่อระบบเดิม
Q: นักพัฒนาเดิมต้องเรียนรู้อะไรบ้าง?
A: นักพัฒนาที่มีพื้นฐานเขียนโปรแกรมแบบ Object-Oriented เช่น Java หรือ C# จะเรียนรู้ Mendix ได้เร็วมากTBN Academy มีหลักสูตร Mendix สำหรับนักพัฒนาองค์กรโดยเฉพาะ
Q: ถ้าทีมไม่มีประสบการณ์ Low-Code เลย ควรเริ่มยังไง?
A: เริ่มจากงานเล็กๆ ที่ความเสี่ยงต่ำ เช่น ระบบขออนุมัติภายใน
และฝึกทีมไปพร้อมกัน อย่าเริ่มจากระบบที่สำคัญมากในโปรเจคแรก
Q: เมื่อไหร่ควรใช้ผู้เชี่ยวชาญภายนอกแทนที่จะสร้างเอง?
A: ถ้างานแรกต้องเชื่อมต่อกับระบบหลัก เช่น Core Banking
แนะนำให้ทำกับผู้เชี่ยวชาญที่มีประสบการณ์ด้านนี้โดยตรง
ติดต่อ TBN เพื่อประเมินโปรเจคขององค์กร
อยากรู้ว่า Mendix เหมาะกับองค์กรของคุณไหม?
TBN Corporation เป็น Mendix partner ที่ได้รับการรับรองในไทยตั้งแต่ปี 2008พร้อมทีมผู้เชี่ยวชาญที่ประจำอยู่ในกรุงเทพฯ และมีประสบการณ์มากกว่าใครในตลาด
ปรึกษาผู้เชี่ยวชาญ →
