ปัจจัยที่มีผลต่อโครงการ

  • ปัจจัยที่มีผลต่อโครงการ คือ องค์ประกอบต่างๆ ที่เกี่ยวของกับบริบทของโครงการ และมีผลต่อการดำเนินโครงการให้บรรลุเป้าหมาย ซึ่งต้องรีบระบุให้เร็วที่สุดเมื่อเริ่มโครงการ หรือก่อนเริ่มโครงการ
  • ตัวอย่าง เช่น
    • Business artifacts: business service (product/service), business function, business process, business data, business unit, business rule, business strategy, business plan
    • IT artifacts: application, system, hardware, network
    • Other artifacts: project อื่นๆ

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

ขั้นตอนหลักๆ ที่สามารถนำไปใช้กับโครงการไอทีทั่วไปได้ มีดังต่อไปนี้

ระบุ Business Driver

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

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

หากจำเป็นต้องเก็บ เราเริ่มต้นได้ง่ายๆ ด้วยการถามว่า “โครงการนี้ส่งผลต่อผลิตภัณฑ์หรือบริการใดขององค์กรคุณบ้าง?” คือให้เริ่มระบุแบบ outside-in คือเริ่มจากผลิตภัณฑ์หรือบริการ แล้วค่อยเจาะเข้ามาข้างในเรื่อยๆ สำหรับองค์กรแบบ non-profit ก็สามารถใช้ได้ อย่าลืมว่าองค์กรทุกแห่งมี business service ทั้งนั้น! จากนั้นก็ค่อยถามเจาะเข้าไป เช่น หากจะให้ผลิตภัณฑ์หรือบริการเหล่านั้นบรรลุเป้าหมายที่กำหนดไว้ จะต้องอาศัยปัจจัยสำคัญอะไรบ้าง คราวนี้เราก็ไล่ระบุไปเลย ให้พิจารณาและระบุจากระดับธุรกิจไล่ไปหาไอที เช่น ระบุจากมุมมองธุรกิจ (ผลิตภัณฑ์/บริการ กระบวนการทางธุรกิจ บุคลากร หน่วยงาน ฯ) ไล่ไปยังแอพพลิเคชั่น ระบบไอที อุปกรณ์ฮาร์ดแวร์ และเน็ตเวิร์ก เป็นต้น

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

จากนั้นเมื่อระบุ business driver ที่จะอยู่ภายในขอบเขตโครงการเรียบร้อย ก็มาประเมินศักยภาพของ business driver เหล่านั้นกันแบบทีละตัวกันไปเลย ตรงนี้อาจเรียกว่าเป็นการทำ ‘การประเมินความพร้อมขององค์กร’ หรือ ‘Organizational Readiness Assessment’ เพื่อดูว่า business driver ตัวไหนมีศักยภาพไม่ดีบ้าง เช่น กระบวนการทางธุรกิจบางตัวเกี่ยวข้องกับหน่วยงานจำนวนมาก อาจส่งผลต่อการสื่อสาร, การให้ความร่วมมือของบุคลากรมีน้อย อาจส่งผลต่อการสื่อสาร, มีกลยุทธ์ธุรกิจแต่ไม่มีแผนชัดเจน อาจส่งผลต่อทิศทางการดำเนินงาน, ระบบไอทีที่เกี่ยวข้องบางระบบไม่มีเอกสารที่อัพเดตทัสมัยและผู้ดูแลระบบก็ไม่มีความชำนาญ อาจส่งผลต่อการเชื่อมต่อระบบ เป็นต้น ดังนั้นเมื่อทราบศักยภาพของ business driver ต่างๆ แล้วจะได้มาวางแผนรับมือนั่นเอง เพื่อช่วยบริหารความเสี่ยงไปด้วยในตัว

ระบุโครงการอื่นที่เกี่ยวข้อง

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

สมัยนี้ในองค์กรใหญ่ๆ มักมีหน่วยงานด้าน PMO (Program Management Office) เป็นหน่วยงานหรือคณะทำงานที่รับผิดชอบด้านการบริหารโครงการต่างๆ ในองค์กรในลักษณะภาพรวม เพราะหากโครงการของเราไปเกี่ยวข้องกับโครงการอื่นๆ เยอะ เราก็กลับมาทบทวนกับทีมงานว่าเรามีขอบเขตและอำนาจ (วาสนา) แค่ไหน ที่จะก้าวข้ามขอบเขตของโครงการเราไปเก็บข้อมูลในโครงการอื่น เพื่อระบุประเด็นที่เกี่ยวข้องและผลกระทบระหว่างกัน มิฉะนั้นแล้วหากแต่ละโครงการเก็บความต้องการและบริหารกันแบบตัวใครตัวมัน เราก็จะมีโอกาสพบปัญหาความขัดแย้ง ความซ้ำซ้อน ความไม่เข้ากัน (เช่น ตอนหลังระบบของแต่ละโครงการเชื่อมต่อกันลำบาก) ดังนั้นหากประสบสถานการณ์ที่โครงการเราไปเกี่ยวข้องกับโครงการอื่นหลายโครงการ เราก็ควรแจ้งลูกค้าและผู้บริหารฝ่ายเราเองด้วย ว่าควรจัดตั้งคณะทำงานเพื่อบริหารโครงการภาพรวมขึ้น กรณีนี้ควรมีทีมงานเพื่อเก็บความต้องการเชิงภาพรวม ที่ไม่เฉพาะเจาะจงโครงการใดโครงการหนึ่งเป็นหลัก ประเด็นนี้อาจเรียกว่าเป็น ‘Interoperability Requirements’ระหว่างโครงการต่างๆ ก็ได้ในทางไอทีก็คือเรื่องอินเตอร์เฟสนั่นเอง นั่นหมายถึงการเก็บความต้องการของอินเตอร์เฟสระหว่างโครงการต่างๆ ทั้งประเภทเดียวกันและคนละประเภทกัน

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

ระบุแผน, นโยบาย และกลยุทธ์ที่เกี่ยวข้อง

การดำเนินโครงการใดๆ ควรมีทิศทางที่ชัดเจน (แม้จะมีหมอกปกคลุมบ้างในบางช่วง แต่ไม่ใช่มืดหม่น แบบตาบอดคลำช้าง) ดังนั้นจึงควรทราบว่าโครงการนี้เกี่ยวข้องหรืออยู่ภายใต้กรอบของแผนธุรกิจ, Master Plan, Roadmap, นโยบาย อะไรบ้าง ด้านไหนบ้าง (เช่น การเงิน การตลาด ไอที) และเกี่ยวข้องกับยุทธศาสตร์ และ/หรือกลยุทธ์ใดบ้าง นั่นคือเราต้องทราบที่มาที่ไปว่าโครงการนี้มันเกิดขึ้นได้อย่างไร ส่งผลต่อความอยู่รอดและความเติบโตขององค์กรลูกค้าอย่างไร ไม่ใช่ว่าเขามาจ้างให้พัฒนาระบบอะไรก็รับทำไป โดยไม่รู้เลยว่าเขาจะเอาไปทำอะไร มันจะสร้างประโยชน์อะไรได้บ้าง เพราะบางครั้งเราก็มักพบว่าผู้จ้างเองก็ยังหาคำตอบแบบชัดๆ ให้เราไม่ได้ด้วย! ประเภทฉันอยากได้ระบบ ฉันก็เลยจ้างคุณ… เอ้อ คิดแค่นี้เอง จริงๆ นะในสังคมเรามีคนแบบนี้เยอะนะ ไม่ใช่น้อย หรือบางประเภทก็รู้ก็ตอบได้ แต่ไม่ชัดเจน ประมาณว่าข้อมูลมันเบลอมาก สิ่งเหล่านี้ก็จะทำให้เราไม่เคลียร์ เราจะไม่มีทางเห็นหรือกำหนดขอบเขตโครงการที่ชัดเจนและขับเคลื่อนไปอย่างถูกทิศถูกทางได้เลย!

หลายครั้งพอถามลูกค้า ก็มักโดนสวนกลับมาว่ามันเกี่ยวอะไรกับคุณ มันนอกเหนือโครงการนี้ มันนอกเรื่อง เหตุผลหนึ่งเพราะเขาคิดอย่างนั้นจริงๆ อีกเหตุผลหนึ่งคือเขาก็ไม่รู้ (ประเภทได้รับมอบหมายให้มาให้ข้อมูลหรือมาประสานกับเรา..แค่นี้) เพราะหากไม่ทราบตรงนี้อย่าว่าแต่ขอบเขตโครงการที่ไม่ชัดเลย ผลลัพธ์/ผลผลิตหลักของเรานั่นคือความต้องการ ก็จะไม่ชัดเจน ไม่ครอบคลุมแท้จริง เหมือนเขามาซื้อรถจากเรา แค่บอกว่าจะเอาไปขับ แต่ไม่ได้บอกว่าจะเอาไปขับใช้งานแบบไหน บรรทุกอะไร วิ่งบนถนนแบบไหน เราก็ไม่มีทางระบุความต้องการที่ถูกต้องได้ร้อยเปอร์เซ็นต์ และนั่นย่อมนำมาซึ่ง change…change…change แล้วก็ change ตลอดโครงการ และอาจจบไม่สวยด้วยระบบที่พัฒนาเสร็จแต่ไม่ครอบคลุมความต้องการ ต้องตามแก้ ตามปรับ เหมือนคนป่วยที่รักษาไม่หายขาดสักที นอกจากนี้หากไม่สามารถระบุแผน นโยบาย และกลยุทธ์ได้ถูกต้องและชัดเจนแล้ว ก็จะส่งผลต่อการระบุ business artifact และการวิเคราะห์ธุรกิจที่เกี่ยวข้องกับโครงการต่อไปอีกด้วย

สำหรับการระบุแผน นโยบาย และกลยุทธ์ อาจแบ่งเป็น 2 ระดับง่ายๆ คือ ระดับองค์กร (ภาพกว้าง) และระดับหน่วยงาน (ที่เกี่ยวข้องกับโครงการ) ในช่วงแรกที่ทำต้องระบุระดับองค์กรให้ได้ จากนั้นระดับหน่วยงานอาจทำไปพร้อมๆ กับการวิเคราะห์ธุรกิจ พูดง่ายๆ คือ การบริหารองค์กรที่ดี องค์กรควรมีแผน นโยบาย และกลยุทธ์ระดับองค์กร จากนั้นในระดับหน่วยงานต่างๆ ก็ควรมีเป็นของตนและไล่เรียงไปตามลำดับชั้นในสายงานต่างๆ จนสุดท้ายไปสู่แผนระดับบุคคล ดังหลักการ ‘ถ่ายถ่ายทอดกลยุทธ์สู่การปฏิบัติ’ หรือ ‘Transform strategies to operations’ หลายองค์กรสมัยมีการใช้พวก Balanced Scorecard และ Strategy Map ก็ง่ายหน่อย ช่วยงานเราตรงนี้ได้เยอะ แต่คราวนี้ปัญหาที่มักพบคือ ระดับองค์กร…มี ระดับหน่วยงานก็…มี แต่… มันไม่เชื่อมกัน อารมณ์เหมือนระบบมีระบบย่อยมากมาย แต่ไม่มีอินเตอร์เฟสเชื่อมต่อกัน ถามใครฝั่งลูกค้าก็บอกมีๆๆๆๆๆ แต่หาเอกสารบันทึกไม่ได้ เพราะข้อมูลเหล่านี้มักอยู่ใน…หัวคน! ก็ยุ่งยากอีกที่ต้องไปขุดออกมาให้ได้ แล้วเราก็อาจเจอปัญหาการเมือง กระทบกระทั่ง ขัดแย้ง ฯลฯ ตามมา ในโครงการเล็กๆ คงไม่ซีเรียส แต่โครงการใหญ่ๆ ที่มีผลต่อองค์กรลูกค้ามากๆ เราต้อง…ทำให้ได้!

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

คุณสามารถนำไปปรับแต่งให้เข้ากับโครงการไอทีได้ จะตัดต่อจะเพิ่มเติมอย่างไรก็ได้ เพราะที่นำมาแนะนำเป็นเพียงแนวปฏิบัติกว้างๆ เท่านั้น อาจน้อยไปหรือมากไปก็ได้ อย่างในโครงการด้าน Enterprise Architecture แค่ที่แนะนำอาจไม่พอก็ได้ อาจน้อยได้ไปก็ได้ เพราะในงาน Enterprise Architecture ขนาดใหญ่จำเป็นต้องทำอะไรเยอะแยะมากมายกว่านี้มากในกิจกรรมที่เกี่ยวกับ requirement ดังนั้นแนะนำให้นำไปปรับก่อนใช้นะครับ

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s