โครงการและการส่งมอบ

ตั้งแต่ต้นจนจบ

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

ขอบเขตงาน

• ERP และระบบงานธุรกิจ: การคัดเลือก การติดตั้งใช้งาน การย้ายข้อมูล การทำให้ผู้ใช้ยอมรับ
• คลาวด์และโครงสร้างพื้นฐาน: ออกแบบ สร้าง ย้ายจากเซิร์ฟเวอร์ในองค์กร
• การเชื่อมต่อระหว่างเครื่องมือที่ไม่ได้ออกแบบมาให้ทำงานร่วมกัน
• เว็บไซต์และระบบงานธุรกิจ
• การพัฒนาซอฟต์แวร์และ product ownership
• การย้ายข้อมูลออกจากระบบที่ไม่มีใครทำเอกสารไว้
• การสรรหาบุคลากรในพื้นที่และสร้างทีม ทั้งสำหรับโครงการและระยะยาว
• การบริหารโปรแกรมข้ามผู้ขายหลายราย

โครงการดำเนินไปอย่างไร

1. 01

   การกำหนดขอบเขต

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

2. 02

   การออกแบบและการเลือกผู้ขาย

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

3. 03

   การสร้าง

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

4. 04

   การทดสอบเพื่อตรวจรับ

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

5. 05

   การขึ้นใช้งานและการส่งมอบ

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

คุณได้รับอะไร

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

การบริหารโครงการฝั่งเจ้าของงาน

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

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

รับช่วงโครงการที่กำลังมีปัญหาได้ไหม

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

เราต้องการอะไรจากฝั่งคุณ

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

บริบทของภูมิภาคเปลี่ยนอะไร

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

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