ปัญหา
ทีม delivery ของ Acme Shop อยากให้ลูกค้าส่งของคืนผ่าน courier เจ้าที่สองได้ด้วย เป็น change เล็ก ๆ ที่ใช้เวลา development ราวหนึ่งวัน แต่ change DLV-214 กลับไปถึงลูกค้า 22.5 วันทำงานหลังจากมี request เข้ามา ทุกทีมระหว่างทางยุ่งกันหมด และรายงานว่าขั้นของตัวเองเร็ว: product manager triage request ใน 1 ชั่วโมง, code review ใช้ 2 ชั่วโมง, review ของทีม security 2 ชั่วโมง, ทีม platform ตั้ง test environment ใน 1 ชั่วโมง, QA test ใน 4 ชั่วโมง และ change board รายสัปดาห์ใช้เวลากับมัน 1 ชั่วโมง ตัวเลขพวกนี้รวมได้ 20 ชั่วโมง คือ 2.5 วันทำงาน ส่วนอีก 20 วันหมดไปกับคิวระหว่างทีม: backlog, การรอ reviewer, คิว ticket ของทีม security, คิว environment ของทีม platform และการรอประชุม board ครั้งถัดไป (ตัวเลขของ Acme เป็นตัวเลขของตัวอย่างนี้เอง ไม่ใช่ผลวิจัย ส่วนหนึ่งวันในหน้านี้คือวันทำงาน 8 ชั่วโมง)
ไม่มีใครวัดการรอพวกนี้ เพราะไม่มีใครเป็นเจ้าของมัน แต่ละทีมปรับปรุงส่วนที่ตัวเองมองเห็น ทีม security เลยภูมิใจกับ review 2 ชั่วโมง ขณะที่ ticket รออยู่หน้าทีม 5 วัน และพอ support ถามว่า feature จะ ship เมื่อไหร่ ทุกทีมก็ตอบได้แค่ขั้นของตัวเอง ไม่มีใครบอกวันที่ได้ ถ้าไม่มีภาพของ flow ทั้งเส้น การคุยกันว่าจะปรับปรุงตรงไหนก็เดินด้วยความเห็น และแรงมักไปลงที่ขั้นที่เจ้าของบ่นดังที่สุด หรือไปลงกับเครื่องมือใหม่ของทีมเดียว ขณะที่คิวก็ยังอยู่ที่เดิม
ทำงานยังไง
Value stream คือทุกขั้นที่ request หนึ่งผ่านระหว่างทางไปหาลูกค้า ไม่ว่าขั้นนั้นจะเพิ่มคุณค่าหรือไม่ Value stream mapping วาด stream นั้นลงในหน้าเดียว พร้อมตัวเลขไม่กี่ตัวของแต่ละขั้น เพื่อให้คนที่เป็นเจ้าของแต่ละขั้นเห็นภาพเดียวกัน: งานถูกทำตรงไหน รอตรงไหน และถูกส่งกลับมา rework ตรงไหน
มาจากไหน
Toyota วาด material and information flow diagrams เป็นส่วนหนึ่งของ Toyota Production System และ Lean Enterprise Institute (LEI) ก็อธิบาย value stream mapping ว่าเป็นเครื่องมือที่ Toyota พัฒนาขึ้นภายใต้ชื่อนั้น workbook Learning to See (LEI) ของ Mike Rother กับ John Shook ที่ได้รางวัล Shingo Research Prize ในปี 1999 พามันไปสู่คนวงกว้างในโลกการผลิต: map current state ของ flow ของ product family หนึ่งตั้งแต่ order จนส่งมอบ, ออกแบบ future state และวางแผนว่าจะไปถึงยังไง Value Stream Mapping ของ Karen Martin กับ Mike Osterling (McGraw-Hill, 2013) ปรับวิธีนี้ให้ใช้กับงานออฟฟิศ งานบริการ และ knowledge work ที่ชิ้นงานคือ request, document หรือ code change และที่ผู้เชี่ยวชาญที่ใช้ร่วมกันให้บริการหลาย value stream พร้อมกัน ทั้งสองคนมอง mapping เป็น management practice: คนที่ทำ map ควรมีผู้นำที่มีอำนาจเปลี่ยนวิธีจัดงานรวมอยู่ด้วย และ map ควรจบด้วยแผนที่ถูกลงมือทำจริง
อะไรอยู่บน map
map ควรหยาบ ๆ ไว้ คู่มือ capability นี้ของ DORA แนะนำให้แบ่ง value stream เป็น process block 5 ถึง 15 block และจดไว้ในแต่ละ block ว่าเป็น activity อะไรและทีมไหนทำ สำหรับ software ตัว stream มักเริ่มจาก request หรือไอเดีย ไปจนถึง change ที่รันอยู่ใน production ให้ลูกค้าใช้ แต่ละ block ได้ตัวเลขสามตัว (นิยามจากคู่มือของ DORA และ glossary ของ TKMG บริษัทของ Karen Martin):
| Metric | วัดอะไร | DLV-214 |
|---|---|---|
| Process time (PT) | เวลาที่ลงมือทำงานจริงที่ชิ้นงานหนึ่งต้องใช้ ถ้ามีคนทำได้โดยไม่ถูกขัดจังหวะ และมีทุกอย่างพร้อมอยู่ในมือ เรียกอีกชื่อว่า touch time | 1 h ถึง 8 h ต่อขั้น รวม 20 h |
| Lead time (LT) | สำหรับขั้นหนึ่ง คือเวลาตั้งแต่งานพร้อมให้ขั้นนั้นหยิบ จนถึงตอนที่ส่งต่อ เลยรวมการรอทั้งก่อน ระหว่าง และหลังการทำงาน ส่วน lead time ของทั้ง stream คือผลรวมของทุกขั้น | 22.5 d ตั้งแต่ต้นจนจบ |
| Percent complete and accurate (%C/A) | สัดส่วนของงานที่ขั้นหนึ่งได้รับแล้วใช้ต่อได้ทันที โดยไม่ต้องแก้ ไม่ต้องเติมข้อมูลที่ขาด และไม่ต้องถามเพื่อให้ชัดเจน ให้ถามคนในขั้นที่รับงาน คู่มือของ DORA ก็บันทึกตัวเลขนี้ไว้ที่ block ของขั้นที่รับงาน เหมือนที่ diagram ทำ ส่วน Martin กับ Osterling เขียนเป็น %C&A | development 80%, QA 60%, ขั้นอื่น 100% |
จากตัวเลขพวกนี้ได้ตัวเลขสรุปอีกสองตัว:
- Activity ratio = process time ทั้งหมด ÷ lead time ทั้งหมด × 100 ตัวนี้ Martin กับ Osterling ใช้เป็นตัววัดสรุปว่างานไหลดีแค่ไหน สำหรับ DLV-214: 2.5 ÷ 22.5 = 11% แปลว่าเกือบเก้าในสิบส่วนของเวลา change นี้นั่งรออยู่
- Rolled first-pass yield = ผลคูณของ %C/A ของทุกขั้น: สัดส่วนของชิ้นงานที่ผ่านทุกขั้นได้โดยไม่ต้อง rework สำหรับ DLV-214: 80% × 60% = 48%
ใช้หน่วยเดียวกันกับเวลาทั้งสองแบบ ตัวอย่างนี้นับเป็นวันทำงาน 8 ชั่วโมงตลอด ถ้านับเป็นวันตามปฏิทิน lead time เดียวกันจะเป็นราวสี่สัปดาห์ครึ่ง และ activity ratio จะต่ำลงไปอีก การวาด timeline ไม่มีมาตรฐานเดียว ตามที่ Karen Martin บอกไว้ในโพสต์ปี 2014: square wave แบบดั้งเดิมวาง lead time ไว้บนยอดคลื่น และวาง process time ไว้ในร่องใต้กล่อง ต่อมาเธอกับ Osterling ก็เปลี่ยนไปใช้เส้นเดียว ส่วน diagram แยก lead time ของแต่ละขั้นเป็นเวลารอที่วาดขึ้นด้านบนเป็นสีแดง กับ process time ที่วาดลงด้านล่างเป็นสีน้ำเงิน
Current state, future state, แผน
- Current state ให้ map สิ่งที่เกิดขึ้นจริง ด้วยตัวเลขจริงของวันนั้น ไม่ใช่ตัวเลขที่คนอยากให้เป็น (คู่มือของ DORA) ถ้าเป็นไปได้ให้ตามงานจริงไปตรงที่ทำงานนั้น คือ gemba ในงานออฟฟิศและ knowledge work ทาง Martin แนะนำให้ตามชิ้นงานชิ้นเดียวไปตลอด stream
- Future state ออกแบบว่า stream ควรไหลยังไง ณ วันที่กำหนด: glossary ของ TKMG บอกว่า future-state map มักมองไปข้างหน้า 3 ถึง 12 เดือน ส่วนคู่มือของ DORA ยกตัวอย่าง 6 เดือนถึง 2 ปี ให้ติด kaizen burst ไว้ที่ทุกการเปลี่ยนแปลงที่ต้องทำ ตัว kaizen burst คือ icon หยัก ๆ ในชุดสัญลักษณ์ mapping ของ LEI แล้วประเมินตัวเลขใหม่
- วางแผน แล้ว map ใหม่ เปลี่ยน burst แต่ละอันเป็นงานที่มีเจ้าของและกำหนดเสร็จ (Martin กับ Osterling เรียกว่า transformation plan) ลงมือทำ แล้วเดินตาม stream อีกรอบเพื่อดูว่าอะไรเปลี่ยนไปจริง ๆ DORA แนะนำให้ทำ exercise นี้ซ้ำตามรอบ เช่นทุก 6 เดือน และเก็บ map ไว้ในที่ที่ทุกคนเห็นได้
ลงมือทำจริงยังไง
- เลือก value stream เดียวและงานแบบเดียว Acme ทำ map ของ change เล็ก ๆ ที่เข้าไปใน service ของทีม delivery ไม่ใช่ของ "IT" ทั้งหมด เขียน charter สั้น ๆ ก่อน: stream เริ่มและจบตรงไหน, ปัญหาคืออะไร (ลูกค้ารอ change เล็ก ๆ เป็นสัปดาห์), เป้าหมาย, ใครเข้าร่วมและเมื่อไหร่ ส่วน tips ของ LEI ก็เน้นให้ตกลง scope ให้เรียบร้อยก่อน workshop
- ชวนคนให้ถูก คนจากทุกขั้น รวมถึงขั้นที่อยู่นอก engineering (product, security, change board, support) และผู้นำที่มีอำนาจเปลี่ยน policy ที่ทำให้เกิดคิว ตัว Martin เรียก mapping ว่าเป็นกีฬาประเภททีม และเตือนไม่ให้มี map ที่ improvement specialist วาดคนเดียว หรือที่กลุ่มที่ไม่มีอำนาจลงมือทำตามมันเป็นคนวาด ส่วน DORA ก็นับการขาดอำนาจเป็นหนึ่งในอุปสรรคที่เจอบ่อย
- เดินตามงานจริง เลือก change ล่าสุดแบบที่เลือกไว้มาหนึ่งหรือสองตัว แล้วตามมันผ่านประวัติใน ticket, pull request, thread ใน chat และ deploy log โดยถามคนในแต่ละขั้นว่าเกิดอะไรขึ้น เอาเวลามาจาก timestamp ไม่ใช่จากความจำ แล้วเช็กกับตัวเลขเดียวกันของ change หลายสิบตัวล่าสุดในระบบ ticket เพื่อไม่ให้ change ที่ผิดปกติตัวเดียวพาแผนไปผิดทาง
- วาด current state กระดาษ, whiteboard หรือ online board ที่แชร์กันก็พอ coach ของ LEI อย่าง Dave LaHote แนะนำดินสอกับกระดาษ ณ ที่ที่งานเกิดขึ้น มากกว่า diagram ที่ขัดเกลามาสวย ๆ เติมคิว, timeline และกล่องสรุป และตอนนี้ยังไม่ต้องใส่รายละเอียด
- อ่าน map ด้วยกัน มองหาการรอที่นานที่สุด, ขั้นที่ %C/A ต่ำและส่งงานกลับ, handoff ที่ไม่เพิ่มอะไร, approval ที่ใช้ check แทนได้, ขั้นที่ทำต่อกันทีละขั้นแต่ทำคู่ขนานกันได้ และการรวม batch อย่าง board รายสัปดาห์หรือ planning ทุกสองสัปดาห์
- ออกแบบ future state และแผน เลือกการเปลี่ยนแปลงไม่กี่อย่างที่ตัดการรอได้มากที่สุด ประเมินตัวเลขใหม่ และให้ kaizen burst ทุกอันมีเจ้าของ กำหนดเสร็จ และตัววัด ลองแต่ละการเปลี่ยนแปลงเป็น experiment ก่อนขยายไปใช้กว้าง ๆ ตามที่ tips ของ LEI แนะนำ ที่ Acme ตัว burst กลายเป็นงานสี่อย่าง: policy check ใน CI (ทีม security กับทีม platform), test environment แบบ self-service จาก Launchpad (ทีม platform), กติกา standard change ที่ให้ peer review approve change ความเสี่ยงต่ำแบบที่รู้จักกันดี (change board) และ triage รายวันพร้อม WIP limit (ทีม delivery)
- Map อีกรอบและทำให้ flow มองเห็นได้ตลอด เดินตาม change ใหม่หลังแผนลงมือเสร็จ แล้วหลังจากนั้นก็ map ตามรอบ ระหว่าง map แต่ละครั้ง team board ที่มี WIP limit และ lead time ที่อ่านจากระบบ ticket จะทำให้ยังเห็นการรออยู่ ส่วน Flow Framework ที่ Mik Kersten เปิดตัวใน Project to Product (2018) ก็เป็นวิธีหนึ่งในการวัด software delivery เป็น flow ตามเวลา และ Flow Engineering (Steve Pereira กับ Andrew Davis, 2024) ใช้ map ห้าแบบใน session ที่ทำร่วมกัน เพื่อเปลี่ยนสิ่งที่ map เผยให้เห็นเป็น roadmap ที่คนทำงานเป็นเจ้าของเอง
อยู่ตรงไหนใน solution
- The Three Ways: value stream map แสดง flow ทั้งเส้นที่ First Way ปรับปรุง ในคำอธิบายของ Gene Kim ตัว First Way ดู performance ของทั้งระบบ ไม่ใช่ของแผนกเดียว ใน The DevOps Handbook ฉบับ first edition (2016) การเลือก value stream และทำให้งานในนั้นมองเห็นได้อยู่ใน Part II "Where to Start" ก่อน technical practice ของ flow
- DORA Metrics: change lead time ของ DORA นับจาก commit ถึง production เป็นแค่ปลายฝั่งขวาของ map นี้ ส่วน map ครอบคลุมการเดินทางทั้งหมดจาก request ถึงลูกค้า และบอกว่าส่วนไหนช้า DORA นับ visibility of work in the value stream เป็นหนึ่งใน lean product management capability ของตัวเอง ที่งานวิจัยของ DORA พบว่าทำนาย software delivery performance และ organisational performance ที่ดีขึ้นได้
- การแก้ใน future state ของ Acme มีหน้าของตัวเองทั้งหมด: Policy as Code มาแทน ticket ของ security สำหรับ check ประจำ, Golden Paths กับ Platform as a Product เปลี่ยน ticket ขอ environment ให้เป็น self-service และ Continuous Delivery ทำให้ release เป็นแค่การรัน pipeline หนึ่งรอบ ส่วน guidance ของ DORA เรื่อง streamlining change approval สนับสนุน peer review มากกว่า board ภายนอก และ Trunk-Based Development ทำให้ batch เล็กอยู่เสมอ
- Team Topologies: handoff ทุกจุดบน map คือเส้นแบ่งระหว่างทีม stream-aligned team ที่เป็นเจ้าของ flow มากขึ้น และ platform team ที่ให้บริการแทนการรับ ticket จะกำจัดคิวทิ้ง แทนที่จะแค่ทำให้มันสั้นลง You Build It, You Run It ให้ release และ pager อยู่กับทีมที่ build service เอง เลยไม่มี release team แยกมาเพิ่มคิวอีก
- Testing Pyramid: %C/A 60% ของ QA ที่กลายเป็นเป้าหลัง map ครั้งที่สองของ Acme เป็น rework แบบที่ automated test ที่เร็วขึ้นและอยู่ต้น pipeline ช่วยลดได้
- CALMS ตั้ง Lean เป็นหนึ่งในห้า dimension ของมัน และ value stream map ก็เป็นวิธีที่ใช้กันบ่อยในการดู dimension นี้ ส่วน SPACE & DevEx วัดความติดขัดจากฝั่งของ developer ความติดขัดเดียวกับที่ map แสดงจากฝั่งของชิ้นงาน ITIL 4 ครอบคลุม service management process อย่าง change approval ที่มักโผล่บน map แบบนี้เป็นคิว: map แสดงว่า control หนึ่งตัวกิน lead time ไปเท่าไหร่ future state เลยเก็บ control นั้นไว้ได้ แต่เปลี่ยนวิธีทำ
ใช้ตอนไหนดี
Value stream mapping คุ้มค่าในที่ที่งานข้ามหลายทีม และไม่มีใครบอกได้ว่าเวลาหายไปไหน: lead time ยาวสำหรับ change เล็ก ๆ, handoff, approval และ ticket จำนวนมาก หรือมีแผนจะซื้อเครื่องมือ ปรับโครงสร้างทีม หรือสร้าง platform ถ้าวาด map ก่อนลงทุนแบบนี้ ก็จะเห็นว่ามันจะช่วยตรงไหน ส่วน map หลังลงทุนก็บอกว่ามันช่วยได้จริงไหม วิธีนี้เข้ากับสภาพแวดล้อมที่มีกฎระเบียบคุมได้ดี เพราะมันแสดงว่า control แต่ละตัวกิน lead time ไปเท่าไหร่ และพาไปสู่การทำ control แบบอื่นแทนการทิ้งมันไป
มันลงทุนมากกว่าที่ได้คืนในบางที่:
- ทีมเล็กทีมเดียวที่มี handoff น้อย board ที่มี WIP limit กับ lead time จากระบบ ticket ก็แสดง flow อยู่แล้ว ส่วน workshop เต็มรูปแบบเพิ่มอะไรได้น้อย
- งานที่แต่ละชิ้นไม่เหมือนกันเลย เช่นงานวิจัย หรือ migration ที่ทำครั้งเดียว ให้ map ชิ้นงานแบบทั่วไปในระดับหยาบ ๆ หรือตามหลายชิ้นแล้วหาคิวที่มีร่วมกัน
- ไม่มีใครจะลงมือทำ ถ้าไม่มีผู้นำที่เปลี่ยน policy ข้ามขั้นต่าง ๆ ได้ map ก็แค่บันทึกปัญหาไว้ แค่นั้นเอง
- Flow ที่เปลี่ยนเร็ว map เป็นภาพถ่ายของช่วงเวลาหนึ่ง ถ้า stream เปลี่ยนทุกไม่กี่สัปดาห์ flow metric ที่เครื่องมือเก็บให้อย่างต่อเนื่องจะใช้ได้ดีกว่า map ที่ละเอียด
ปรับใช้ตามที่จำเป็น: ในสภาพแวดล้อมที่มีกฎระเบียบคุม ให้ดึงทีม compliance กับ audit เข้ามาตั้งแต่เนิ่น ๆ เพื่อตกลงกันว่า control ใน future state (record ของ peer review, automated check, log ของ pipeline) ใช้เป็นหลักฐานได้, กับ legacy system ให้ map ทางไป production ก่อน แล้วกำจัดการรอแบบ manual ที่ใหญ่ที่สุด และกับทีม remote ให้เดินตามงานแบบ virtual ผ่านประวัติใน ticket และ handoff ที่มีบันทึกไว้
กับดักที่เจอบ่อย
- Map ว่างานควรไหลยังไง map ที่วาดจาก process wiki หรือจากความจำ จะแสดง process ทางการ (ที่ Acme คือ 5 ขั้นกับ 3 วัน) แทนสิ่งที่เกิดขึ้นจริง (8 ขั้น, 22.5 วัน) ให้เดินตามงานจริง พร้อมกับคนที่ทำมัน และเอาเวลามาจาก record
- Map ครั้งเดียวแล้วเก็บเข้าแฟ้ม Martin นับ map ที่วาดไว้สวยงามแต่ไม่มีการลงมือทำตามเป็นหนึ่งในความล้มเหลวที่เจอบ่อย ให้เปลี่ยน future state เป็นแผนที่มีเจ้าของและกำหนดเสร็จ และ map ใหม่ตามรอบและหลังทุกการเปลี่ยนแปลง
- ปรับปรุงขั้นที่ไม่ใช่คอขวด การลดเวลา test 4 ชั่วโมงของ QA ลงครึ่งหนึ่ง ลด lead time จาก 22.5 เหลือ 22.25 วัน ราว 1% ให้กำจัดการรอที่ใหญ่ที่สุดและต้นเหตุ rework ที่ใหญ่ที่สุดก่อน คู่มือของ DORA ก็เตือนว่า efficiency ที่ได้จากจุดที่ไม่ใช่คอขวดแทบไม่ขยับ lead time เลย
- เพิ่มเครื่องมือโดยไม่กำจัด handoff ต่อให้ portal สำหรับ ticket ขอ test environment ดีขึ้น ก็ยังต้องรอ 3 วันอยู่ดี ให้กำจัดตัว handoff เอง (self-service, automated check, change type ที่ approve ไว้ล่วงหน้า) และเพิ่มเครื่องมือเฉพาะตรงที่มันช่วยเรื่องนั้น
- ละเอียดเกินไปตั้งแต่แรก หกสิบกล่องที่ละเอียดถึงระดับคลิกและช่องในฟอร์มทำให้ map กลายเป็น process map และ workshop ก็จบก่อนที่การรอใหญ่ ๆ จะโผล่ Martin ขีดเส้นไว้ตรงนี้: value stream map คือมุมมองเชิงกลยุทธ์ตั้งแต่ต้นจนจบ ส่วน process map คือมุมมองเชิงปฏิบัติที่ละเอียด ให้เริ่มจาก 5 ถึง 15 block และซูมเข้าไปเฉพาะตรงที่ map ชี้
- คนในห้องไม่ใช่คนที่ใช่ map ที่ improvement specialist วาดคนเดียวจะพลาดสิ่งที่คนในแต่ละขั้นรู้ และ map ที่วาดโดยคนที่ไม่มีอำนาจเหนือขั้นเหล่านั้นก็เปลี่ยนมันไม่ได้ ให้ดึงทั้งคนที่ทำงานและคนที่เปลี่ยนกติกาได้เข้ามา
- เชื่อ change ตัวเดียว change ตัวเดียวที่เดินตามอาจผิดปกติก็ได้ ให้เช็กตัวเลขของมันกับประวัติใน ticket ของงานแบบเดียวกันก่อนเลือกว่าจะแก้อะไร
- ใช้ map เพื่อหาคนผิด คิวเป็นของระบบ ไม่ใช่ของทีมที่คิวไปก่อตัวอยู่ตรงหน้า map ที่ถูกเอาไปจัดอันดับทีมจะสอนให้ทีมซ่อนการรอในครั้งหน้า