Stakeholder กับ Digital Transformation ซึ่งเป็นคนที่ชี้ชะตาว่า โครงการจะดีหรือไม่ดี จะไปต่อหรือไม่ได้ไปต่อ ทำยังไงให้ปัง และ ทำยังไงจนพัง พร้อมตัวอย่างจากชีวิตจริงเลย

Stakeholder คือใคร 

Stakeholder คือคนที่มีอำนาจในการตัดสินใจที่เกี่ยวข้องกับโครงการนั้นๆ และเป็นเหมือนคนที่ให้ทิศทาง ดูแล กำกับการพัฒนาของโครงการนั้น ในภาพรวม และภาพรายละเอียดบางส่วน แต่ไม่ลึกมาก ตัดสินใจในเรื่องที่มีผลกระทบต่อโครงการ ซึ่งหมายความว่า stakeholder จำเป็นอย่างยิ่งที่จะต้องเข้าใจเป้าหมาย ความต้องการ สถานการณ์ ปัญหา แนวทางแก้ไข ทั้งระยะสั้น และระยะยาวไปพร้อมๆกัน แต่จะไม่ได้เป็นคนลงมือทำเอง เพราะมีทีมงานที่จะเป็นคนลงมือทำ

Stakeholder ต้องมีคุณสมบัติอะไรบ้าง

เข้าใจลูกค้า หรือคนใช้งาน

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

เข้าใจพนักงาน

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

เข้าใจระบบงานที่เกี่ยวข้อง

การจะปรับหรือสร้างระบบอะไรขึ้นมาใหม่ก็ตาม ย่อมมีผลกระทบต่อส่วนการทำงาน 1 ส่วนหรือหลายส่วนไปพร้อมกัน ซึ่งโดยปกติการทำ Digital transformation นั้น มักจะส่งผลกระทบกับการทำงานในหลายๆส่วนที่จะต้องปรับเข้าสู่กระบวนการทำงานแบบใหม่ ดังนั้นจำเป็นอย่างยิ่งที่จะต้องเข้าใจการทำงานที่เชื่อมโยงกันในแต่ละส่วนงาน เพราะหลายบริษัทที่เปิดมานานก็จะมีระบบการทำงานที่ฝังรากหยั่งลึกลงไป ในแบบที่แต่ละส่วนงานก็ไม่ยุ่งเกี่ยวซึ่งกันและกัน (silo) ดังนั้นการสร้างระบบอะไรขึ้นมาที่จะต้องส่งผลกระทบกับหลายๆส่วนงานมาพร้อมกัน จำเป็นที่จะต้องอาศัยความเข้าใจถึงผลกระทบในทุกๆส่วนไปพร้อมๆกัน 

เข้าใจทรัพยากร

เรื่องนี้เป็นเรื่องที่สำคัญ Stakeholder หลายคนไม่สามารถบริหารโครงการได้ เพราะมองทรัพยากรที่บริษัทตัวเองมีไม่ออก โดยทรัพยากรในที่นี้ไม่ได้หมายถึงแค่เรื่องเงินเพียงอย่างเดียว แต่ทรัพยากรหมายถึง องค์ความรู้ที่มี, คนทำงานที่เกี่ยวข้อง, เวลา และ ข้าวของอุปกรณ์ เพราะทั้งหมดนี้จะเป็นตัวกำหนดแนวทางในการดำเนินโครงการได้ค่อนข้างมาก ตัวอย่างหนึ่งที่ผมเคยเจอมา ก็คือการอยากได้ระบบที่มีการพัฒนาต่อเนื่องไปเรื่อยๆ โดยมีเงินพัฒนาโครงการจำกัด แต่เลือกจ้าง Vendor มาทำงานให้ ซึ่งเพียงแค่นี้ก็ขัดกันหมดแล้ว เพราะว่าเงินในการพัฒนาโครงการที่มีจำกัด แต่เลือกใช้งาน Vendor เขาจะไม่สามารถตอบสนองกับความต้องการที่ไม่สิ้นสุดได้ อันเนื่องมาจากโดยปกติ vendor เขาจะรับทำงานใน scope งาน ที่ได้ตกลงกันเอาไว้อย่างชัดเจน ดังนั้นเราจึงจะได้งานตามปริมาณที่เราจ่ายเท่านั้นแล้วก็จบ หรืออีกตัวอย่างที่เคยเจอก็คือมีทีมงานพัฒนาโครงการอยู่ภายในไม่ต้องใช้ Vendor ข้างนอก แล้วก็พัฒนาโครงการไปเรื่อยๆ ไม่สามารถนำมาใช้ได้จริงจนกระทั่งเวลาผ่านไปเป็นเวลา 2 ปี ก็ยังนำมาใช้ไม่ได้จริง (เพราะ stakeholder คิดว่ายังไม่ดีพอ ยังไม่พร้อมมากพอ) ยังมีการพัฒนาต่อยอดไปเรื่อยๆ จนโค้งสุดท้ายที่ถูกบีบให้นำออกมาใช้ก็พบว่าไม่ทันเวลาแล้ว และหลายส่วนที่เคยเจ๋งตั้งแต่ตอนเริ่มคิดโครงการก็ดูเป็นเรื่องธรรมดาไปหมดแล้ว หรืออีกตัวอย่างนึง ที่ตรงกันข้ามเลย ก็คือทำ Proof Of Concept (POC) หลายเรื่อง เยอะมาก ทำไปเรื่อยๆ จบเรื่องนี้ ก็ไปอีกเรื่องนึง จบเรื่องนั้นก็ไปเรื่องใหม่ จนได้ POC ออกมาจำนวนมากมาย แต่สุดท้ายเงินหมดก่อน เพราะยังไม่เคยเอาออกมาใช้งานจริงเลย อันนี้ คือไม่ได้มองหาความ perfect แต่เป็นเพราะยังไม่รู้แนวทางที่แน่ชัด เลยทำได้แค่ POC ไปเรื่อยๆ โดยไม่ได้เก็บ feed back จากการ implement จริงมาปรับปรุงต่อเลยจนทรัพยากรหมดในที่สุด

Stakeholder จะพังงานได้อย่างไร

เรื่องนี้มีได้หลายแนวทาง แต่หลักใหญ่ใจความจะเกิดจากความไม่เข้าใจของ Stakeholder เองเลยโดยตรง ส่งผลต่อการตัดสินใจที่ผิดพลาดออกมา ซึ่งประเด็นที่มักจะเจอกันบ่อยๆเลย ได้แก่

Unlimit requirement

ผมยกให้เรื่องนี้เป็น Common scenario ของ Stakeholder ประมาณ 95% ได้เลย เพราะไม่ว่าบริษัทไหนก็จะเจอแบบนี้เสมอ อธิบายอีกนิด ว่า unlimit requirement คือการให้ requirement ใหม่ เพิ่มเรื่อยๆ ตามเวลาที่เปลี่ยนไป เช่น วันนี้ อยากได้จักรยาน ทีมก็ลงมือสร้างจักรยาน ผ่านไปหนึ่งสัปดาห์ มาบอกว่า อยากต่อยอดเพื่อให้มี มอเตอร์ขับเคลื่อนได้ด้วย ทั้งปั่นเอง ทั้งใช้มอเตอร์ขับเคลื่อน เป็นต้น เวลาขี้เกียจก็หยุดปั่น มันต้องดีกว่าจักรยานธรรมดาแน่นอน

ก่อนอื่นต้องเข้าใจว่าการมี unlimit requirement แล้ว project success ไม่เคยเกิดขึ้นได้จริง ไม่ว่าจะเป็นบริษัทเล็กที่เป็น startup นั่งทำงานกันด้วยความรวดเร็ว ไม่กี่คน จนบริษัทระดับใหญ่ที่มีพนักงานเป็นร้อยหรือเป็นพันคนก็ตาม (ผมเคยไป consult ให้บริษัทนึง แล้วพบว่าบริษัทนั้นจ้าง vendor มาพัฒนา ERP ให้แล้วนาน 5 ปี หมดเงินไปแล้วกว่า 100 ล้านบาท เพราะ requirement ยังคงมีเพิ่มเติมมาเรื่อย ตามเวลาที่ผ่านไป) เดี๋ยวจะอธิบายต่อในหัวข้อถัดไปว่าเพราะอะไร แต่สิ่งที่บริษัทเล็กๆจะเจอจากเรื่องนี้ก็คือ งานที่ทำมานาน แต่ไม่เคยไปถึงจุดที่ใช้งานได้จริงสักที คนทำจะเหนื่อยและล้าไปก่อน บริษัทใหญ่จะเจอเรื่องที่แตกต่างกัน ก็คือความซับซ้อนของระบบที่มีเป็นจำนวนมาก ทำให้การแก้ไขเพิ่มเติมยุ่งยากและยุ่งเหยิง 

Change requirement

นี่จะเป็นเรื่องรอง ที่ไม่น้อยหน้าเรื่องแรกเลย และหลายครั้ง ก็มาพร้อมๆกัน อธิบายเพิ่มอีกนิด คือการปรับรูปแบบการทำงานจากที่มีอยู่เดิมไป เช่น ให้สร้างจักรยาน (คันเดิมเลย) แต่ว่า ผ่านไป ทำเกือบจะเสร็จแล้ว ขอเปลี่ยนระบบขับเคลื่อนจากโซ่ เป็นสายพาน แบบนี้เป็นต้น คือไม่ได้เพิ่มอะไรใหม่ แต่ replace ของที่มีอยู่เดิมเป็นสิ่งใหม่ และไม่ต้องห่วงเลย ทุก change requirement มีเหตุผลที่สุดแสนจะ perfect มาคู่กันเสมอ

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

เพิ่มคนเพื่อเพิ่ม capacity

หลังจากที่ ให้ unlimit requirement บวก change requirement รายชั่วโมงแล้ว (ผมเคยเจอรายชั่วโมงมาแล้วในชีวิตการทำงาน เชื่อผม ว่ามีอยู่จริง คือประชุมเรียบร้อย ได้ข้อสรุปที่ประชุมตรงกันแล้ว ผ่านไปชั่วโมงนึง แจ้งใหม่ว่า ขอเปลี่ยนการตัดสินใจเป็นอีกแบบหนึ่ง ผมนี่ขนหัวลุกเลย) เรื่องที่ตามมาติดๆก็คือมีคนไม่เพียงพอในการที่จะทำระบบนั้น หรือไม่สามารถสร้างระบบนั้นขึ้นมาในระยะเวลาอันสั้นได้ทันต่อความต้องการ สิ่งนี้ก็จะเกิดทันที “งั้นเราก็เพิ่มคนสิ จะได้มีความสามารถในการทำงานได้เร็วขึ้น”

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

Butterfly effect

อันนี้จะเป็นเรื่องที่ Stakeholder ส่วนใหญ่คิดไม่ถึง หรืออาจจะไม่ทันได้ฉุกคิด และสถานการณ์จะแย่ลงไปอีกถ้าทีมงานก็ไม่ได้คิดไปตามกัน (เคยเจอเหตุการณ์นี้เหมือนกัน คือทีมงานรู้เต็มอกว่าการตัดสินใจครั้งนั้นผิดพลาดแน่นอน แต่ก็ไม่มีใครกล้าขัด และในที่สุด ผลที่ได้ออกมาก็ไม่สำเร็จจริง อย่างที่ถูกประเมินเอาไว้ตั้งแต่แรก แต่ stakeholder ต้องการทำอย่างนั้นเพียงเพื่อเกมการเมืองบางอย่าง) อธิบายเพิ่มอีกนิดนึงก็คือ Butterfly effect คือผลกระทบที่เกิดขึ้นอย่างยิ่งใหญ่เป็นวงกว้างจากการกระพือปีกของผีเสื้อเพียงแค่ครั้งเดียว (เป็นงานวิจัย ที่บอกว่า การกระพือปีกของผีเสื้อแม้แตกต่างกันเพียงนิดเดียวก็สร้างผลกระทบความแตกต่างที่มหาศาลได้)

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

• ต้องเริ่มกระบวนการ sourcing ล้อแม็ก ว่ามีเจ้าไหนขายบ้าง
• ต้องเลือกแบบ ว่าแบบไหนจะเหมาะสม มีกี่แบบให้เลือกบ้าง เอามาให้เลือกเยอะที่สุด
• เอาแบบทั้งหมดเข้าที่ประชุม เพื่อถกเถียง หาความเหมาะสม เพื่อให้ได้แม็กที่เหมาะที่สุด กับจักรยานคันที่กำลังสร้าง และรวมทั้ง ราคา น้ำหนัก คุณสมบัติต่างๆ
• เมื่อเลือกได้ ก็สั่งซื้อ ก็อาจจะพบว่าของหมด
• ต้องไปเลือกใหม่อีก 2-3 แบบ เผื่อของหมดอีกครั้ง จะได้เอาแบบสำรองมาใช้งานได้ทันที ก็ใช้เวลามากขึ้นอีก
• มีกระบวนการสั่งซื้อ ตามขั้นตอน การผลิต การส่งมอบ
• นำล้อแม็กที่ได้ เข้าสู่กระบวนการเปลี่ยนจากล้อซี่ลวดเดิม น้ำหนักของรถก็จะเพิ่มขึ้น หรือ ศูนย์ถ่วงต่างๆของรถก็จะเปลี่ยนไปจากเดิม
• ต้นทุนเพิ่มขึ้น ส่งผลกระทบต่อราคาขาย การทำ promotion ตอนเปิดตัวของทีม marketing และการตัดสินใจของผู้ซื้อ
• ส่งผลกระทบต่อสู้กับคู่แข่ง เพราะเดิมตั้งใจว่าจะออกมาสู้ในรุ่นล่าง ที่ราคาประหยัด แต่การเปลี่ยนเป็นการขับเคลื่อนสายพาน และ ล้อแม็ก ก็เป็นการยกระดับ product ไปอยู่ในจุดสูง ราคาแพง ที่ยังไม่เคยมีตลาดตรงนี้มาก่อน และ ยังไม่มีใครคิดซื้อด้วย เพราะจักรยานหนักเกินไปกว่าจะปั่นได้ในชีวิตประจำวัน แม้ว่ามันจะเป็นสุดยอดจักรยานแล้วก็ตาม

เห็นไหมครับแค่เปลี่ยนจากระบบโซ่เป็นสายพาน และเปลี่ยนจากล้อซี่ลวดเป็นล้อแม็กของจักรยานเท่านั้น การเปลี่ยนทั้ง 2 ส่วนนั้นไม่ได้มีความซับซ้อนอะไรเลย แต่สร้างผลกระทบยิ่งใหญ่มหาศาล เรียกได้ว่าอาจจะล้มบริษัทผลิตจักรยานบริษัทนี้เลยก็ได้ 

Stakeholder ที่ดีควรเป็นอย่างไร

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

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

พอพูดแบบนี้แล้วถ้าคนที่เข้าใจ Agile mindset ก็จะพอนึกออกว่านี่คือแนวทางการทำงานของ Stakeholder ที่ควรจะเป็น ที่เชื่อมโยงกับการทำงานแบบ Agile mindset นั่นเอง เพราะ Agile mindset ที่ได้ผล ต้องได้รับการยอมรับและใช้งาน ตั้งแต่ระดับบนลงล่างเลย

ผมไม่ได้บอกว่าแนวความคิดนี้เป็นแนวความคิดที่ดีที่สุดในโลกและมันจะสามารถแก้ปัญหาได้ทุกเรื่อง แต่ต้องบอกว่าปัญหาโดยส่วนใหญ่ที่เราเจอกันอยู่ นี่ไม่ใช่ครั้งแรกที่เจออยู่ในโลกใบนี้ แต่มันเป็นปัญหาที่มีมานานแล้ว หรือที่เค้าเรียกว่า classic problem เขาจึงได้คิดค้นแนวทางที่พอจะช่วยแก้ปัญหาได้ออกมาเป็น Agile นั่นแหล่ะ 

บทความนี้ไม่ว่าคุณจะเป็นคนทำงาน หรือคุณจะเป็น Stakeholder หรือคนที่เกี่ยวข้องในการพัฒนาโครงการ ผมเชื่อเหลือเกินว่าคุณจะต้องเข้าใจเรื่องทั้งหมดนี้ได้อย่างแน่นอน แต่สิ่งที่ผมอยากให้เกิดขึ้นจริงๆก็คือการที่ Stakeholder ได้เข้ามาอ่าน และรับรู้ความสัมพันธ์ระหว่าง stakeholder กับ digital transformation รวมทั้งทำความเข้าใจอย่างถ่องแท้ของการตัดสินใจใดๆ ที่จะต้องผ่านกระบวนการคิดมาแล้วอย่างดีและรอบคอบ และตอบสนองต่อการเปลี่ยนแปลงได้อย่างทันท่วงที เพราะ Stakeholder คือคนที่มีอำนาจมากที่สุดแล้วในการชี้เป็นชี้ตายของโครงการ ในการจะทำให้โครงการเกิดหรือดับได้ 

อมรเดช คีรีพัฒนานนท์

เชี่ยวชาญเรื่อง eCommerce และ Digital Transformation เพราะมีประสบการณ์กว่า 10 ปี และยังเป็น Full Stack Developer รวมถึงประสบการณ์ด้าน Big Data Ecosystem , Blockchain Ecosystem ถามได้ปรึกษาได้ เป็นกันเอง และ จริงใจ 🙂