Document Flow Fundamentals

หลายครั้งที่คนทำโปรแกรมกับคนวางระบบมักมีความเห็นไม่ตรงกัน เรื่องที่ว่าทำไมงานบางขั้นตอนจึงไม่ใช้ตามมาตรฐานที่มีอยู่แล้ว ทำไมเลือกที่จะปรับแต่งแก้ไขกลายเป็นเคสเฉพาะให้องค์กรนั้นๆ
 
เหตุผลของคนทำโปรแกรมมองว่า หากปล่อยให้มีการปรับแต่ง (customize) ทุกครั้ง ในระยะยาวจะกลายเป็นต้นทุนการดูแลโค้ดส่วนที่แตกต่างกันนี้ ไม่มีใครได้ประโยชน์ทั้งฝั่งผู้ใช้และผู้พัฒนาโปรแกรม
 
ปัญหาโลกแตก เมื่อเจอระบบงานที่คล้ายกับเหมือนกันแต่ก็จะมีรายละเอียดบางอย่างไม่เหมือน จึงมักเกิดการต่อรองเสมอว่าจะปรับเปลี่ยนที่โปรแกรมหรือผู้ใช้ 
 
เมื่อเจอบ่อยๆ จนทำให้ต้องทบทวนต้นตอความกังวลที่แท้จริง มีวิธีไหนบ้างที่งานปรับแต่งทั้งหลายไม่ต้องวนกลับมาเป็นภาระสะสม
 
ทางเลือกเท่าที่คิดออกมีอยู่ไม่กี่ทาง 
 
ตัวอย่างที่เห็นจากโปรแกรมระดับโลก อาศัยว่ายืนระยะได้ยาวนานพอ สามารถเก็บเคสหลากหลายครอบคลุมแทบทุกกระบวนท่า
 
แนวทางนี้ไม่เหมาะกับทรัพยากรที่มีอยู่ ผมลองคิดหาทางอื่น ออกแบบอย่างไรที่ทำได้ด้วยคนที่มีจำกัดและภายในเวลาจำกัด พบว่าหากทำโปรแกรมให้เหลือแต่ "แก่น" มีแค่ concept เหมือนชิ้นส่วน LEGO ที่ยังส่งมอบให้คนทั่วไปใช้ทันทีไม่ได้ แล้วโยนไปให้ทีมวางระบบประกอบให้กลายเป็นชิ้นงานก่อน เคล็ดลับอยู่ที่คิดให้ออกว่าเจ้าชิ้นส่วน LEGO นั้นควรมีหน้าตาอย่างไร 
 
ผมคิดถึงแผนการสร้างโปรแกรมที่ไม่ได้ทำออกมาให้ผู้ใช้ตรงๆ แต่ทำให้ผู้วางระบบไปประกอบสร้าง (craft) ให้กลายเป็นชิ้นงานที่แตกต่างกัน ทักษะของบุคคลที่ประกอบสร้างได้อยู่ตรงกลางระหว่าง Low Code กับ ABAP ไม่ถึงกับง่ายจนใครก็ทำได้ แต่ไม่ยากจนแทบไม่เหลือใครทำได้ ในใจประมาณคนกลางๆ ที่มีพื้นฐานเขียนสูตร Excel ได้ อาจไม่ต้องถึงกับเขียน VBA

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

Measurement
 
วัตถุประสงค์ของ Measurement เพื่อใช้บอกว่าเรายังอยู่ในแผน มุ่งหน้าทิศทางที่ถูกต้องหรือไม่ เปรียบเสมือนเข็มทิศ หรือ GPS ที่บอกตำแหน่งใน Google Map
 
เดิมเมื่อออกแบบแล้ว ขั้นตอนพัฒนามีการตั้งค่ากระจัดกระจายไปทั่ว ไม่มีวิธีง่ายๆ ที่จะรวบรวมให้ดูง่ายๆ นอกจากเป็นผู้ที่คลุกคลีใกล้ชิด ที่ผ่านมาทีมวางระบบใช้วิธีกำหนดตัวผู้รับผิดชอบเบ็ดเสร็จสำหรับแต่ละโปรเจคท์ เป็นเสมือนศูนย์ข้อมูลการสอบถามความคืบหน้าต้องอาศัยรายงานสรุปจากผู้รับผิดชอบนี้
 
เมื่อทีมวางระบบสามารถแชร์ vision ให้ผู้สนใจภายนอกทีมรับรู้ได้สะดวกกว่าเดิมแล้ว ทำให้ต้องคิดถึงคู่หู measurement ที่เป็นเครื่องมือใช้ติดตามความคืบหน้า
 
ผมคิดหาวิธีอธิบายระบบงาน (workflow) ผ่านข้อมูลการตั้งค่าระบบเอกสารหรือหมวดบิล ที่อยู่ในโปรแกรมนั่นเอง
 
ข้อมูลหมวดบิล ประกอบด้วยรหัสและชื่อเอกสาร รหัสเปรียบเสมือนชื่อย่อที่ใช้เรียกกันเองภายใน (ที่คนภายนอกไม่เข้าใจ) เช่น QT, IV, PR, PO ส่วนคนนอกที่ไม่คุ้นเคยก็อาศัยดูจากชื่อเอกสาร การดูแลระบบให้หลายๆ ที่ซึ่งอาจใช้รหัสเอกสารไม่เหมือนกัน เป็นความท้าทายอย่างหนึ่งของทีมวางระบบ 
 
ข้อมูลหมวดบิล ประกอบด้วยการตั้งค่าภายในหมวด เพื่อกำหนดคุณสมบัติของเอกสารที่แตกต่างกัน ซึ่งควรได้ออกมาตามที่ออกแบบไว้ สามารถกลับไปเทียบกับแผนภูมิจาก vision ได้
 
ความสัมพันธ์ระหว่างหมวดบิล การตั้งค่าส่วนนี้ ช่วยแสดงเส้นทางไหลของเอกสาร ซึ่งควรเป็นตามที่ออกแบบ และสามารถกลับไปเทียบ vision ได้
 
เนื่องจากทีมวางระบบมีการตั้งค่า label หรือ tag ด้วยชื่อระบบเอาไว้ด้วย ทำให้สามารถแสดงการตั้งค่าของหมวดเอกสารที่เกี่ยวข้องกับระบบนั้นๆ มาเทียบกันได้สะดวก
 
ตัวอย่าง คำอธิบายจากแผนภูมิ Procurement to Pay ที่นำเสนอในสไลด์
 
1.Purchase Requisition (ทุกแผนก)
 
2.Purchase Order (จัดซื้อ)
 
3.Receipt (คลัง)
 
4.Vendor Bill (การเงิน)
 
5.Bill Acceptance (การเงิน)
 
6.Vendor Payment (การเงินและบัญชี)
 
และ เมื่อดูข้อมูลจริง รายการหมวดบิลที่ตั้งค่าไว้
 
1.PRA ใบขอซื้อ
 
2.POA ใบสั่งซื้อ
 
3.GRA ใบรับสินค้า
 
4.APA ใบตั้งหนี้
 
5.PVA ใบจ่าย
 
ครั้งแรกดูเร็วๆ จะเห็นว่าจำนวนขั้นตอนไม่เท่ากัน แต่เมื่อทำความเข้าใจละเอียดจึงพบว่า ส่วนของ Vendor Bill Bill Acceptance เป็นงานต่อเนื่องของแผนกเดียวกัน คือ การเงิน เมื่อตั้งค่าจริงจึงยุบรวมเป็นเอกสารหมวดเดียว (APA)

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


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


 
กลไกสำคัญ ที่ถูกใช้แทนที่วิธีการดัดแปลงหรือผนวกในระดับซอร์สโค้ด คือ ทำให้ "ตั้งค่าได้" (configurability) ตั้งแต่พื้นฐาน เช่น ตั้งค่าอัตราภาษีง่ายๆ ไปจนถึงตั้งค่าที่ซับซ้อน เช่น การลงบัญชี เป็นการเปลี่ยนวิถีของการพัฒนาระบบโดยไม่พยายามแตะต้องโค้ด ให้สำคัญกับทีมวางระบบ ซึ่งสามารถรวมการออกแบบและพัฒนาระบบเบ็ดเสร็จในจุดเดียว (one stop implementation) 
 


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


 
1. หมวดบิล
 
หมวดบิล เป็นคำที่ผมใช้เรียกตั้งแต่ยุคแรก ตอนนั้นโลกของเรายังแบ่งเป็นโมดูลเช่น ซื้อ-จ่าย, ขาย-รับ เหมือนทั่วไป ข้อดีของโครงสร้างแบบนี้คือ สามารถแยกงานออกเป็นระบบให้คนทั่วไปเข้าใจง่าย สามารถกระจายการพัฒนาเป็นส่วนๆ โดยไม่ต้องกังวลเรื่องเงื่อนไขหรือลอจิกที่ขัดแย้งกัน
 


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


 
เมื่อพิจารณาโดยละเอียด ข้อมูลเอกสารทั้งหมดมีโครงสร้างหลักแทบจะเรียกว่าเหมือนกัน 
 


 
เลขที่เอกสาร ต้องไม่ซ้ำกันทำหน้าที่เสมือน ID ของเอกสารที่มนุษย์ใช้สื่อสาร เช่นเดียวกับ ID ของข้อมูลที่โปรแกรมใช้สื่อสารกับดาต้าเบส
 


 
วันที่ ในเอกสารใดๆ ก็ตามอย่างน้อยต้องระบุวันที่ เพราะทำหน้าที่บันทึกเหตุการณ์ บอกให้รู้ว่าสารสนเทศหรือรายละเอียดอื่นที่ประกอบอยู่ในเอกสารมีผลตั้งแต่วันนั้น
 


 
ใคร หรือผู้เกี่ยวข้อง ส่วนใหญ่แล้วเอกสาร 99% มักใช้บันทึกเหตุการณ์ที่สัมพันธ์กับบุคคล (และนิติบุคคล)​ ซึ่งอาจเป็นบุคคลภายนอก ลูกค้า, ผู้ขาย, ลูกหนี้, เจ้าหนี้, บุคคล, กลุ่มบุคคลหรือแม้แต่แผนกในองค์กร ที่มีนัยยะแทนตัวตนหนึ่งเดียว น่าสังเกตว่าความสัมพันธ์ในเอกสารมักเป็นหนึ่งเดียว กล่าวคือ เอกสารใดๆ จะบ่งบอกเรื่องราวที่เกี่ยวข้องกับบุคคลเดียวเท่านั้น หากมากกว่านั้นมักแยกเป็นเอกสารต่างหาก
 


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


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


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


 
2. การเชื่อมโยง
 
เวิร์คโฟลว์ขององค์กรใดๆ ไม่จำเป็นต้องเหมือนกัน แม้กระทั่งทำธุรกิจเหมือนกันก็อาจมีขั้นตอนงานแตกต่างกันได้ 
 


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


 
จากยืนยันขายสินค้า มาเป็นใบส่งสินค้า รายการสินค้ามักจะล้อตามกันไป 
 


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


 
3. Compiler
 
หน้าที่ของเอกสารคือ เก็บบันทึกเหตุการณ์ในรูปแบบที่สามารถสื่อสารกับมนุษย์ที่เป็นผู้ใช้งานได้ ขณะเดียวกันก็จะเป็นเป็นต้นกำเนิด (source) ที่สามารถแปลไปเป็นข้อมูลในรูปแบบที่คอมพิวเตอร์เข้าใจง่าย
 
เปรียบเสมือนโปรแกรมเมอร์เขียนโปรแกรมโดยใช้ภาษา Python เพราะอ่านเข้าใจ แต่เพื่อให้คอมพิวเตอร์ทำงานตามคำสั่งนั้นได้จำเป็นมีกลไกแปลเป็นชุดคำสั่งที่ CPU เข้าใจได้อีกทีหนึ่ง
 


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


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


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


 
หรือกรณีล่าสุด เปิดใบกำกับภาษีเป็นสกุลเงิน USD แต่ต้องแปลเป็นรายการเพื่อสรุปภาษีขายเป็นเงินบาท ก็เป็นหน้าที่ของ compiler ที่แปลเป็นข้อมูลภาษีที่ถูกต้อง โดยส่วนประมวลผลภาษีมูลค่าเพิ่มสามารถนำไปใช้งานโดยไม่ต้องปรับแก้ใดๆ
 
ความลับ
 
เฮนรี ฟอร์ด กล่าวว่า 
 
"คุณจะเลือกรถยนต์สีไหนก็ได้ตราบเท่าที่มันเป็นสีดำ"
 
หัวหน้าทีมวางระบบเคยบอกว่า 
 
"คุณจะตั้งรหัสหมวดบิลอะไรก็ได้ตราบใดที่ใบกำกับภาษีต้องขึ้นต้นด้วย IV" 
 
หรืออีกนัยหนึ่งเรื่องที่เล่ามาตั้งแต่ต้น ไม่ควรเล่าให้ผู้ใช้รู้ ตราบใดที่ใบกำกับภาษีของผู้ใช้ทุกรายเป็น IV คนที่ต้องดูแลผู้ใช้ทั้งหลายจะไม่สับสน ไม่ต้องรับมือกับความหลากหลายของรหัสเรียกเอกสาร
 
แนวคิดที่เปิดให้ตั้งค่าอิสระนั้นอาจดีสำหรับผู้วางระบบ ให้สามารถเสกอะไรหลายอย่างขึ้นมาได้เองโดยไม่ต้องรอโปรแกรมเมอร์ แต่ก็สร้างปัญหาให้กับผู้ที่ยังไม่เข้าใจแนวคิดนี้ กลายเป็นความยากลำบากที่จะเริ่มต้น
 
เพราะฉะนั้นจึงเลือกที่จะซ่อนมันไว้ภายใต้ชื่อที่อ้างอิงตามชื่อระบบงานที่คุ้นเคย เช่น Order to Cash, Procurement to Pay สื่อสารกับผู้ใช้ให้เข้าใจก่อน 
 
จนกว่าพวกเขาจะเชี่ยวชาญและต้องการค้นคว้าหาความลับของมันจริงๆ