เป็นไปได้ไหมที่จะใช้แนวทางแบบคล่องตัวเพื่อโครงการที่ต้องใช้การประมาณเวลาและเวลาที่บันทึกไว้?

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

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

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

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

มีวิธีใดบ้างที่จะเข้าใกล้ภารกิจนี้ในลักษณะที่ยืดหยุ่นซึ่งทำให้ฉันสามารถรักษาประโยชน์ของ Agile ไว้ได้อย่างน้อยที่สุด?

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

หนึ่งในวิธีการที่ฉันชอบเกี่ยวกับ Agile คือขอบเขตของโครงการไม่ได้รับการแก้ไข สามารถขยายขนาดเริ่มแรกได้ที่ระดับคุณลักษณะและมหากาพย์จากนั้นธุรกิจสามารถกำหนด ROI ตามคุณสมบัติที่สำคัญที่สุด บางที UI ที่น่าสนใจด้วยระฆังและนกหวีดนั้นมีมูลค่าทางธุรกิจต่ำ แต่เครื่องมือเวิร์กโฟลว์สำหรับจัดการการเรียกร้องมี ROI สูง

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

นี่คือวิธีที่ฉันทำสิ่งนี้:

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

สิ่งนี้ช่วยให้คุณสามารถจัดประเภทโครงการของคุณเป็นโครงการย่อยขนาดเล็กที่มีมูลค่าทางธุรกิจแตกต่างกัน แต่ละข้อควรมีความโดดเด่นในแง่ของมูลค่าทางธุรกิจ

เสื้อยืดขนาดความพยายามในคุณสมบัติ

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

ทำลายคุณสมบัติเป็นเรื่องราว

ผ่านการฝึกซ้อมเพื่อค้นหาฟีเจอร์เล็ก ๆ ที่เข้าใจได้ดีและแบ่งย่อยเป็นเรื่องราวเริ่มแรก ประเมินเรื่องราวเหล่านี้ตามคะแนน ตอนนี้คุณมีพื้นฐานที่

ขนาดเล็ก -> 40 คะแนน

นี่จะเป็นพื้นฐานของการเปรียบเทียบกับคุณสมบัติอื่น ๆ

เชื่อมโยงความพยายามชี้เรื่องราวของฟีเจอร์ทั้งหมด

เปรียบเทียบคุณสมบัติขนาดเล็กของคุณกับคุณสมบัติอื่น ๆ ตัวอย่างเช่น,

Medium Feature Y รู้สึกว่ามันมีขนาดใหญ่เป็นสองเท่าและความพยายามของ Small Feature X จาก 40 แต้ม

ฟีเจอร์ Medium Y น่าจะเป็นเรื่องราว 80 จุด ทำสิ่งนี้ต่อไปจนกว่าคุณจะได้คะแนนเรื่องราวในระดับสูงสำหรับฟีเจอร์ทั้งหมด

ประเมินความเร็วทีมของคุณ

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

จากจำนวนงานที่ทีมคิดว่าสามารถส่งมอบได้ภายใน 2 สัปดาห์ให้ใช้จำนวนจุดเรื่องราวนั้นเป็นความเร็วเฉลี่ยที่อาจเกิดขึ้นในทีมของคุณ!

ค้นหาวันที่เสร็จสมบูรณ์ที่คาดการณ์ของคุณ

หากทีมของคุณในการวางแผนการวิ่งล้อเลียนรู้สึกสะดวกสบายที่ส่งมอบคะแนน 25 เรื่องในการวิ่งและงานในมือของคุณดูเหมือน 300 เรื่องสำหรับโครงการ Cadillac รุ่นทองของคุณดูเหมือนว่าทีมของคุณจะใช้เวลา 12 วิ่งหรือ 24 สัปดาห์ ทำทุกอย่างให้เสร็จ

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

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

ถ้าเช่นนั้นทำไม Agile

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

ประเด็นสำคัญบางประการในการประมาณเวลา:

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

ปรับปรุง:

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

นี่เป็นส่วนที่ยากที่สุดในการแนะนำ Agile

"ฝ่ายบริหารยังคงต้องการเวลาโดยประมาณ"

แนวทางของฉันคือ

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

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

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

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

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

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

ฉันคิดว่าคุณกำลังตั้งสมมติฐานที่ผิดพลาดเกี่ยวกับการพัฒนาแบบ Agile มีความยืดหยุ่นและการเปลี่ยนแปลงความต้องการจะอบตัวอักษรลงในเปรียว

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

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

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

ความเรียบง่าย - ศิลปะของการเพิ่มปริมาณงานที่ไม่ได้ทำเป็นสิ่งจำเป็น

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

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

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

สิ่งนี้เข้ากันได้กับปรัชญาการพัฒนาแบบ Agile (หรืออื่น ๆ ) และฝ่ายบริหารของคุณควรซื้อในสิ่งนี้

ใช่ความคล่องตัวมีข้อดีบางอย่าง

• ช่วยให้นักธุรกิจเปลี่ยนใจกลางเที่ยวบิน
• มันจัดเรียงของการปกป้องธุรกิจจากการประมาณการที่ไม่ดีตลอดกาลของวิศวกร
• มันมอบคุณค่าตั้งแต่เนิ่นๆและบ่อยครั้งก่อนที่จะบรรลุวิสัยทัศน์สุดท้าย
• มันอะไหล่คุณบางส่วนของค่าใช้จ่ายการวางแผนขึ้นด้านหน้าซึ่งมักจะสามารถผลิตแผนไม่ดีอยู่แล้ว
• มันยอดเยี่ยมมาก ขวา?

แต่คุณยังต้องให้การประมาณการล่วงหน้าอย่างแม่นยำอย่างสมเหตุสมผล

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

และฉันสามารถได้ยินมันตอนนี้

ฉันเคยได้ยินมาก่อน ฉันค่อนข้างแน่ใจว่าฉันเคยพูดไว้ก่อนหน้านี้:

โอ้ - แต่ Haow! HAOW เป็นมนุษย์ที่มีความเป็นมนุษย์เช่นตัวฉันจ้องมองดวงตาของฉันไปสู่ชะตากรรมของสิ่งต่าง ๆ ! สิ่งต่าง ๆ ที่พระเจ้าเท่านั้นที่สามารถสวรรค์และควบคุม สิ่งที่มนุษย์ซึ่งเป็นมนุษย์สามารถฝันได้ในความง่วงเหงาและลืมโดยการตื่นขึ้นของวัน! โอ้ประเภทการกดขี่ข่มเหง HAOW สามารถตอบสนองความต้องการดังกล่าวได้หรือไม่?

ใช้ผลการดำเนินงานที่ผ่านมาของคุณเป็นคู่มือและจะซื่อสัตย์

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

ในที่สุดนำเสนอกรวยความไม่แน่นอนของคุณต่อผู้มีส่วนได้ส่วนเสียระบุข้อสันนิษฐานและข้อกังวลของคุณ

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

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

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

ฉันจะลองซื้อแบบบาย - อินเกี่ยวกับการวัดความเร็วโดยอิงตามจุดเรื่องราวที่เป็นนามธรรมและถ้าคุณทำอย่างนั้นไม่ได้

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

กรณีที่คุณระบุไม่ใช่ปัญหาที่คล่องตัว:

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

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