一、泥足深陷
M項目自實施以來已經過去了1個半月，目前該項目還在;試用-修改-再試用-再修改”的泥沼中苦苦掙扎，4名開發人員已經人困馬乏，疲于應付，但系統的問題清單仍然越來越長，似乎沒有盡頭 。
……
這個項目是為生產部門開發的生產線的管理系統。去年，由于生產工藝和流程變化，已經使用了幾年的管理系統無法繼續使用了，因此生產部門購買了一套外國公司的生產管理軟件，花費不菲，試運行的時候卻發現系統響應速度非常慢，幾乎造成5條生產線全部停工，無奈之下只好提前結束合同，當然，首付款也打了水漂。目前，生產線完全依靠人工管理，生產效率低下，生產部門迫切希望于信息部門能夠盡快開發出新系統，以緩解生產制造的混亂局面。
系統的上線時間，生產部門的要求近乎苛刻，信息部在接到任務后，只好將項目計劃緊縮、再緊縮。開發部的工程師非常努力，只用了3個月就完成了需求調研和代碼開發，并于1個半月前開始試運行。但是問題很快出現了，本來預計只要2周的系統實施階段一拖再拖，問題不斷，眼看三個2周都過去了，距正式上線仍遙遙無期，對此各方面都非常著急，卻搞不清楚為何如此。
二、原因何在？
實施受阻，原因何在？
信息部為了按時交付系統，不得不一再的壓縮開發和測試的時間，軟件質量因此大打折扣。在開發過程中，系統集成測試基本屬于奢望，開發人員甚至沒有時間對自己的代碼做充分的單元測試，就匆忙發布了，這種做法大大降低了軟件的質量，也正是不斷降低的質量標準導致了試運行 時鋪天蓋地的錯誤和缺陷。更麻煩的是，由于不斷的對軟件功能進行修改，只好不斷的對修改的代碼進行測試，不斷的對修改過的功能進行用戶培訓，造成實施時間一延再延。
“實施階段”指的是指軟件拿到用戶的實際工作場所進行部屬和使用的階段。一般來說，系統實施要經過“軟件交付——〉發布——〉用戶培訓——〉用戶試用——〉發現問題——〉軟件修改——〉軟件測試——〉重新發布”這樣一個螺旋式前進的過程，這個過程將不斷的重復，直到系統沒有問題或者存在的問題用戶可以接受為止。不要懷疑這個過程的復雜和繁瑣，因為這才是事實，像那種理想化的、一帆風順的實施過程通常只會在教科書上出現，我們必須充分認識到系統實施階段存在的風險。
在這樣一個循序漸進的過程中，每個環節都可能引發混亂，造成延誤，并在各步驟間傳遞和放大這些延誤，導致實施階段的延期。比如：開發過程的延誤，造成交付的推遲；用戶培訓的拖后，造成試用的推遲；問題發現的緩慢，造成軟件修改的推遲；軟件修改的頻繁，造成測試的推遲；軟件測試的延誤，造成再次發布的推遲。
三、沖出泥沼
讓我們用TOC的觀點和方法來分析這混亂的狀況，并找出解決方法。
沖突。
[TOC觀點]：發現沖突是解決問題的第一步。TOC認為，如果一個問題未能以兩個必備條件之間的沖突來表達，那么這個問題就沒有清晰的定義。
從成本世界出發，各步驟所用的時間越短越好，所進行的循環次數越少越好；
從有效產出世界出發，各步驟所做的準備工作越充分越好，所進行的循環次數越多，則有效產出的質量和效果越好。
錯誤的假設。
[TOC觀點]：TOC認為，沖突實際上是不存在的，當我們遇到一個沖突，那其實是一個清晰的信號，顯示有人做了一個錯誤的假設，而這個錯誤的假設是可以糾正的，一旦糾正了，沖突就不存在了。
在實施階段存在的錯誤假設是，越早將軟件交到用戶手上，實施階段就可以越早結束。這個假設忽視了由于沒有經過充分測試的軟件缺陷所造成的混亂和延誤。
制約因素。
[TOC觀點]：對企業來說，改造最弱的環節才會提升整體的能力，任何時候最弱的一環都只有一個，這就是制約因素。
對于整個實施階段來說，制約因素是軟件在交付時應該達到的質量標準。如果標準過高，可能會造成交付日期的延誤；如果標準過低，則會造成修改缺陷和重新發布過程的多次重復，造成整個實施階段的延誤。
解決方法。
[TOC觀點]：任何問題都可以用聚焦五步驟來解決：找出、挖盡、遷就、松綁、回頭。
我們就用聚焦五步驟來解決實施階段所面臨的麻煩：
第一步，找出。從實際情況來看，軟件的質量標準是我們最應該關注的，是整個實施過程的制約因素。不斷出現的錯誤、頻繁的修改、無休止的測試和培訓，都是由此產生的。
第二步，挖盡。挖盡質量標準的潛力，也就是找出一個最符合項目具體情況的標準，既不會因質量要求過高影響軟件按時交付，也不會因質量標準過低導致上線后問題頻發。
第三步，遷就。質量標準制定出來以后，其它各方面都要配合這個標準，這樣才能使制約因素不再是瓶頸。比如，軟件需要進行充分的測試以保證滿足質量標準的要求，軟件交付必須在測試通過之后，并且在重新發布之前也要進行測試。
第四步，松綁。做到前面三步之后，軟件只有達到一定的質量標準后才會發布，對軟件的修改也必須經過測試后才能發布新版本，因此不會再出現BUG滿天飛的情況，用戶培訓也可以有條不紊的進行，系統試運行不再是怨聲載道，瓶頸也不再是瓶頸了。
第五步，回頭。原有的瓶頸消失了，必然會有新的步驟成為最弱的一環，接下來就是我們去發現并解決它的時候了。
TOC背景
TOC（Theory Of Constraints）是高德拉特(Eliyahu M．Tolerate)創立的“制約法”，是一套獨特的管理方法論，將之應用到軟件項目管理中也一樣適用。TOC致力于找出管理鏈條中的薄弱環節，然后通過各種手段加強它，當它不再是最弱的一環時，再去尋找新的薄弱環節，如此往復，整個管理鏈條都得以加強了。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.hanmeixuan.com/
本文標題：從TOC看項目實施階段現存問題
本文網址：http://www.hanmeixuan.com/html/consultation/1082014061.html
相關文章
