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