Kindergarten for Pre-Enterprise

ช่วงปลายปีที่ผ่านมามีเหตุการณ์แปลกเกี่ยวกับโปรแกรมหลายอย่างเกิดขึ้น บริษัทแห่งหนึ่งเลิกใช้โปรแกรมของเราเพื่อเปลี่ยนไปใช้ระบบ ERP ระดับโลก ในเวลาไล่เลี่ยกันก็มีบริษัทอีกแห่งหนึ่งต้องการเลิกใช้โปรแกรมระดับโลก เปลี่ยนมาเลือกใช้โปรแกรมเรา

จนล่วงเลยผ่านปีใหม่มา หลังจากรู้ว่า "การเปลี่ยนผ่านทั้งสองเรียบร้อยดี" ผมเพิ่งมีโอกาสได้รับฟังเรื่องราวจาก PM ของเรา นำเสนอข้อสังเกตว่าองค์กรทั้งหลายต้องการ "ระยะเวลา" สำหรับการเปลี่ยนผ่าน

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

"ทำไมได้แค่เปลี่ยนผ่าน โปรแกรมเราใช้ต่อไปเรื่อยๆ ไม่ได้หรือ?" 

เราอภิปรายกันหลายแง่มุม จนผมเริ่มจะยอมรับแนวคิดโปรแกรม(แบบเจียมตัว) ที่ไม่เคยมีมาก่อนในแวดวงของ ERP โปรแกรมที่เป็นพื้นที่ปลอดภัย เตรียมความพร้อมให้องค์กร 

การเตรียมความพร้อมองค์กรก่อนที่เปลี่ยนผ่านไปสู่ ERP ระดับโลก ประกอบด้วยเรื่องสำคัญ 2 เรื่อง ได้แก่ คนและข้อมูล

"แล้วอีกบริษัท ที่ถอยลงมาใช้โปรแกรมเรา มองว่าชั่วคราวเหมือนกันไหม?"

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

"เมื่อสบายเนื้อสบายตัว?"

"ใช่ เหมือนย้ายบ้าน สบายเนื้อสบายตัว รู้สึกว่า 'เอาอยู่' กับงานที่รับผิดชอบ แล้วเขาจะเริ่มฟัง มีเวลาที่จะสำรวจเรื่องใหม่"

Kindergarten

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

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

โอเค งั้นผมน่าตั้งชื่อโปรแกรมให้ใหม่ "รุ่นกุ๊กไก่" ดีไหม ขำๆ นะครับ

ยังไงผมก็ไม่ค่อยเชื่อ(ยอมรับกับเชื่อเป็นคนละเรื่องกัน) ว่าจะมีใครเข้าใจข้อเสนอ (ของเขา) ที่ว่าควรมี stage ก่อนที่จะตัดสินใจใช้โปรแกรมระดับโลก โดยเตรียมความพร้อมผ่านโปรแกรมกุ๊กไก่ ERP ของเราก่อน

Data

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

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

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

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

"ลูกวัว ไม่กลัวเสือ" ผมนึกในใจ เท่าที่รู้มา ทีมข้อมูลของเราเชี่ยวชาญสเปรดชีต (จึงเขียนสูตรตัดต่อข้อมูลเก่ง)​ ไม่ได้มีพื้นฐานดาต้าเบสมากมายนัก จึงไม่กลัว ไม่รู้ว่าการโอนข้อมูลอย่าว่าแต่รื้อทำหลายครั้งเลย แค่ครั้งเดียวสำหรับระบบอื่นก็ไม่ใช่เรื่องง่ายแล้ว ยิ่งถ้าเป็น SQL ต้องเข้าใจมิติของ table ตาม relation ที่ซับซ้อน

นี่อาจจะเป็นผลพลอยได้จากคุณสมบัติของดาต้าเบสที่ไม่เหมือนใคร 

Safe Zone

พื้นที่ปลอดภัยไม่ใช่สถานที่ แต่เป็นบรรยากาศ ความรู้สึก เป็นคำที่ใครคนหนึ่งบอกคุณว่า "It's OK!" ในวันที่ไม่เป็นตามคาดหวัง

หลายครั้งที่ผมรับฟังเรื่องงานวางระบบที่ไม่อาจคืบหน้าตามแผน แล้วต้องอ้อมเปลี่ยนจาก Plan A ไป Plan B หรือแม้กระทั่ง C, D นั่นอาจเป็นวิธีวางระบบ ERP ที่ไม่เหมือนใครจนหล่อหลอมโปรแกรมกลายเป็นเช่นนี้

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

หลายครั้งที่ความไม่เต็มพร้อมนั้นมักถูกคาดหวังว่าเติมเต็มได้ เริ่มต้นออกแบบขั้นตอนที่ชัดเจน แต่จนกระทั่งกระบวนการพัฒนาดำเนินไปแล้ว จึงพบว่าไม่เป็นอย่างนั้น คงมี PM ไม่กี่คนที่บอกว่าไม่เป็นไร "It's OK!" ที่จะกลับมาทบทวนหลังจากเจอทางตัน

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

ผมนึกถึงคำของ มาเรีย มอนเตสซอรี

เมื่อใดเด็กๆ บ่มเพาะการเรียนรู้จนได้ที่  พวกเขาก็จะระเบิดมันออกมา 

Exception Case

อีกเรื่องเล่าของ PM ที่ผมฟังแล้วติดอยู่ในหัว (เพราะคิดหาคำตอบไม่ได้) นอกจากวางระบบแล้วยังคอนซัลท์ด้วยเหรอ

"ไม่หรอก ผมได้รับฟังมาจากเจ้าของบริษัทแห่งหนึ่ง"  

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

บางทีคุณอาจจะนึกถึงความยากลำบาก ตอนที่ไม่มียอดขาย 

บางทีคุณอาจจะนึกว่าใกล้สิ้นปีแล้ว จะทำอย่างไรกับผลงานที่ไม่ค่อยดีนักของคุณ

บางทีคุณอาจจะรู้สึกฮึกเหิม การดูแลเอาใจใส่ลูกค้าจำนวนมาก ต้องคำนึงถึงระบบผลกระทบต่อคนส่วนใหญ่

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

สำหรับผู้ที่ให้คุณค่าระบบ มองว่าเงื่อนไขพิเศษที่เป็นข้อยกเว้นเหล่านี้ หากไม่จำเป็นก็ควรหลีกเลี่ยง หากยอมให้มีรายที่หนึ่ง ต่อไปก็จะมีสอง สาม มากขึ้น ทำให้ระบบหรือกฏเกณฑ์ใดๆ เริ่มมีความซับซ้อน จนไม่สามารถรักษาข้อดีของความเป็นระบบที่เรียบง่าย ไม่ต้องพึ่งพิงความสามารถพิเศษเฉพาะบุคคล

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

เอาเถอะ แต่คำถามของผมคือ 

"แล้วโปรแกรมล่ะ ควรจะรองรับหรือสนับสนุนค่านิยมแบบไหน" 

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

"ก็แล้วแต่" 

สั้นๆ ง่ายๆ (สำหรับเขา) รู้หรือไม่ว่าการออกแบบโปรแกรมให้รองรับ Exception Case ได้เหมือนกับลุกไปชงกาแฟ ต้องผ่านอะไรบ้าง ต้องใช้จินตนาการหรือ assumption ขนาดไหน แต่เป็นคำท้าทายที่น่าสนใจนะ ที่จะออกแบบโปรแกรมไม่เหมือนใคร แล้วโยนความปวดหัวกลับไปให้ทีมวางระบบ

เหมือนกำลังคิดหลักสูตร เตรียมขึ้นระบบ ERP ระดับโลก ด้วย "กุ๊กไก่" (เห็นว่ามีชื่อจริงแล้ว ผมไม่แน่ใจ)

ลูกชายผมเรียนหลักสูตรเตรียมวิศวะฯ ทางโรงเรียนเพิ่งจัดให้ผู้ปกครองพบครู 

มีคำพูดของอาจารย์ท่านหนึ่ง ที่น่าจะใช้อธิบายคำว่าเตรียมความพร้อมได้ดี

"ผมสอนเนื้อหาเหมือนกับนักศึกษาป.ตรีของผม แต่ตอนสอบวัดผลไม่ยากเท่า"