• 引子

　　這個故事講的是一家擁有百年曆史的製造業大廠的資訊化轉型過程中的波折。這家企業擁有超過三萬名員工，它是某行業的領先品牌，但是在資訊化程度上卻非常古老。 

　　有許多人說，國企的專案都是坑，相當一部分專案都是為了騙經費而忽悠人的，換一撥管理層，基本上就得換一撥專案，油水全被領導撈走了。我很遺憾，沒能經歷這些事情。這個專案實打實都是做出來給基層用的專案，也確實獲得了各方較高的滿意度。 

　　以中臺為政治正確的網際網路開發者們會說，這個專案從商業層面和技術上來說似乎毫無價值，首先它不是網際網路產品，其次它沒什麼技術含量，什麼大資料，雲端計算，容器，微服務，無服務，它都不需要，這甚至有點像我們身邊許多人十年前就做過的專案，技術上平淡無奇，看起來毫無挑戰。 

　　顯然並非如此，每個專案存在都有價值。作為過程中的親歷者，我希望通過總結這個專案過程中存在的不足，引起思考和引發討論。尤其是隨著時代的進步，像這樣資訊化轉型的傳統制造業企業，或許越來越罕見，這樣的專案看起來非常獨特，但也是軟體專案中的一個典型，對於未來從事行業網際網路開發的軟體從業人員來說，也許能帶來一些思考。 

• 背景

　　2015年開始，製造業企業開始流行起一種新的趨勢：工業4.0，在這個大背景下，國內則提出了中國製造2025的計劃，旨在通過幾年努力，實現中國製造業的智慧化水平在上一個臺階。 

　　該大型國企作為該某領域的領先品牌，其生產的產品遠銷國內外，也是軍民融合的典型代表，但是在過去的發展過程中，由於產品本身比較特殊，許多關鍵步驟仍然是採用手工完成，無法完全實現自動化替代，包括檢驗管理體系也同樣建立在一大堆紙質表單的基礎上完成。集團管理層看到了中國製造2025帶來的巨大機遇，也想奮鬥一波，但要做的事情實在是太多了。 

　　康威定律說，一個組織的軟體架構設計，實際上是組織管理形式的體現。在9012年的今天，為了維持這樣一套以紙質表單為核心的檢驗管理體系，需要維持龐大的管理體系，帶來了巨大的管理成本，對於組織來說本身成為了一種巨大的負擔。更何況這種管理形式，問題實在是太多了。 

　　1，需要花費大量的時間和精力來維持現有組織，哪怕是非關鍵崗位的離職，都可能影響一些流程的開展。（紙質資料的交接，其實跟口口相傳沒什麼區別）。 

　　2，過程資料儲存困難，為了儲存資料，更是需要專門安排檔案室和檔案保管員，一旦出現產品質量問題，需要進行問題追溯時，要從檔案中檢索問題要花許多時間。 

　　3，一旦發生災害或事故，例如火災洪災，就意味著過程資料將成為廢紙，產品的關鍵過程資訊將無法尋覓。 

　　在網際網路技術飛速發展、實體經濟受到巨大沖擊的今天，原有管理模式，過於臃腫，已經無法適應組織發展的需要。行業越來越不景氣，企業的管理成本居高不下，負擔越來越重，每年裁員裁了許多人，卻沒能從管理效能上帶來多大的提高，因此提升企業的資訊化管理水平其實勢在必行。 

　　但是如果要實現一步到位，直接構建基於工業4.0的智慧製造新體系，在這個行業都不太現實，畢竟許多產品都是屬於定製生產、小批次製造，部署全套自動化製造生產線成本非常高，事實上新生產線也在建設，但是一直沒有投產，老的生產線也得維持好，這樣才能持續創造價值。做好眼前能做的，實現檢驗管理的資訊化（無紙化），然後再逐步實現製造業的智慧化，只有實現了這一小步，才有未來的無限可能。 

• 立項

　　之前提到中國製造2025的大背景，還有一個小背景。企業內部企業的中高層普遍都是八十年代末畢業擁有更高學歷的管理層，不乏清北的高才生。他們那些大學同學正是這一波大時代的受益者之一，有許多同學都藉助於企業的騰飛實現了個人價值，但是留在這家國企的高管們，卻看著企業越來越差，也想有所作為，卻感覺一個拳頭打在了棉花上，他們的壓力很大。 

　　然而，大家都清楚，傳統國企的體質僵化，很多時候看起來兩個字所謂“變革”，實際上卻有點像個美夢而已，就拿“資訊化”系統建設來說吧，資訊化對於國企來說並非第一次提起，許多國企的老員工，乃至管理層其實已經經歷了過去十年資訊化失敗之苦，許多資訊化系統在領導們的支援下，看似搞得轟轟烈烈，熱熱鬧鬧，但是最終都難逃被拋棄的下場，而每個資訊化專案的失敗，都會讓好幾位負責對應資訊管理工作的牽頭人背鍋，並最終從公司離開。 

　　在IT從業人員看來或許很簡單的資訊化建設，從來沒那麼順順利利，極有可能會由於基層的抗拒最終失敗，並給資訊化建設的參與者帶來職業生涯上的汙點。 

　　於是在國企把資訊化提上議程之後，獲得了兩種不同的聲音。很戲劇性的，不懂資訊化的業務部門是資訊化的支持者，他們說這個事情一定要搞，砸鍋賣鐵都要上，再難也要上。另外一種負責資訊化工作的資訊中心的負責人對資訊化的態度很明顯，要我支援，沒問題，我可以把網路做好，但是要我參與軟體的研發過程，恕我無能為力。 

　　因此最終牽頭組織這個過程資料資訊化的，是平時對這一塊需求最大的檢驗管理部門。在他們的推動下，專案正式提上了議程。 

　　這是個涉及面非常廣泛的專案集，包括了三個專案，分別是面向民用領域單一事業部的A專案，面向融合領域的B專案，以及面向整個集團全方向的C專案。事實上集團曾經購買過現成的產品，但是都沒能用起來，所以這個專案集最終是以定製開發的形式承包出來。

• A專案

　　A專案作為最先立項的專案，萬事開頭難，承受了巨大的壓力，許多人在等著看一出好戲。
　　A專案的負責人W部長今年三十八歲，在此之前他一直是從事檢驗管理出身，對產品檢驗有自己明確的要求，他奠定了整個專案的基調。沒有設定特別巨集大的目標，不是做一個通用的大系統，就做一個簡單實用的系統，能夠給基層帶來方便，為管理層帶來便利就夠了。 

　　專案的早期，承建單位曾經試圖引入新技術和更加友好的使用者體驗，但是w部長卻不這麼認為，他說在這樣的老國企，沒必要用新技術，一切以滿足可用性為目標，操作越簡單越好。於是最終承建方設計了一個基於cs的資料採集系統和基於bs的管理系統。不僅功能　　儘可能的簡單，而且連流程都能省就省，儘量讓參與者減少學習成本。 

　　這個設計簡單實用的系統，恰好滿足了敏捷專案所要達到的構建簡單專案、實現快速迭代小步快走的管理目標。駐場開發期間，及時發現問題和解決問題，讓軟體得到了非常充分應用，獲得了甲方的高度評價。 

　　而且如果說早期專案的應用的推進需要靠組織的強勢推動，到了後期就令人欣慰了，由於這個系統無需特別複雜的操作流程就能完成資料的錄入，提交和彙總，基層崗位的工作人員只要會用計算機、簡單培訓就能迅速上手，無形中為專案的快速鋪開奠定了良好的基礎。而且承建方與甲方的基層人員之間溝通融洽，有問題及時反饋，及時處理，為專案推進帶來了非常不錯的效果。 

　　在專案運轉正常一年之後，主導專案工作的部長調任了，新接手的負責人是曾經不太看好這個系統的車間主任，他也被基層工作人員帶動，成為了這個專案的擁躉。 

• B專案

　　藉著A專案成功的東風，馬上啟動了B專案。 

　　前面提到了，B專案是面向融合產業的，因此對這個專案的要求也相對而言更高。 

　　當這個專案完成立項後，B專案建設方的組織架構也發生了比較大的變更，首先是之前推動A專案的集團公司大領導由於工齡屆滿，已經退休，而集團的整個管理層都相繼發生了變化，包括推動專案立項的一位高階工程師也從公司離職，意味著專案早期干係人已經完全換了。 

　　組織架構調整其實是為了給年輕人機會。調整後，B專案負責整個專案的，都是87後的年輕人。  

　　這群年輕人們，相對於A專案的負責人來說，對資訊化有了更加深入的認識。事實上而言，A專案建設，其實不過是一個類似於協同辦公的一個模組，他們認為這個專案沒什麼技術含量，甚至有點low。他們經常出去考察學習，對使用者體驗和功能應用都有很多想法，他們渴望真正打造一個能夠真正打造一個符合企業未來發展目標的資訊化一體化平臺。 

　　這些想法再跟現有政策、以及組織架構混合在一起發酵，最終變成了一個無比巨大的專案，用專業術語來說，就是一個“大泥球”系統。 

　　在專案立項之初，合同上原始需求其實只有19個條目，而且為了讓這些內容容易落地，前期的推動者甚至儘可能的減少流程的複雜度，但是等合同簽訂後、組織結構調整完，新的干係人們在原合同的基礎上，對範圍進行了大幅修改。最終等需求調研落地，變成的是一個基本上涵蓋了公司大部分審批事項、涉及幾十個流程，涉及全公司數百人、超過十幾個小系統的大專案。 

　　為了完成這個專案，雙方投入了最少20個人，超過十人的研發團隊駐場開發了超過半年時間，也沒折騰出幾個讓甲方滿意的東西。建設單位現場條件惡劣、涉及流程複雜、涉及特殊的管理機制，要開發的功能點特別多，不斷的完善，不斷的修改，整個專案研發前前後後折騰了至少一年時間之後，才通過直接負責人的認可，但是給領導彙報時，卻根本不可用，得推翻重做。 

　　專案到今年專案依然沒有上線，這離合同交付日期已經超過兩年了，顯然可以稱之為“失敗專案”了。 

　　承建方雖然早期意識到了專案風險，但是建設方過於強勢，無法拒絕；建設方貪多求快，忽略了組織本身的複雜性、低估了軟體研發的工作量以及軟體實施的難度，最終雙方都竹籃打水一場空。 

• C專案

　　C專案是在B專案完成了到一半時啟動的新專案，其目標是將A專案成功的經驗，推廣到全集團。（不包括B專案的事業部）。 

　　C專案的實施異常順利，合同期一年，實際上只花了8個月就把專案做完了。 

• 總結

　　當我年輕時曾經向其他擁有豐富經驗的專案經理請教什麼樣的專案才是成功專案時，他們說： 

“剛剛好”：剛剛好滿足客戶的需求，就是一個不錯的專案。

　　一個充滿智慧的回答。不過“剛剛好”其實很難把握這個度，我覺得一定是功能簡單、實用即可。 

　　在這個故事中，那個最簡單實用，幾乎沒有什麼技術含量的專案在組織中獲得了很大的成功，而一開始就打算做成全流程資訊化的系統，最終卻一敗塗地。 

　　這恰好就像我們經常見到的專案，簡單純粹的產品才能最先站穩腳跟、獲得不錯的使用者反響，那些一味畫餅的PPT專案，都是忽悠人，幾乎沒幾個成功了。 

　　除此之外，每一個軟體行業從業者，越愛鑽研技術，越容易陷入技術的迷思，總以為靠技術能改變世界，彷彿一個專案沒用上什麼新技術就容易就無法體現出自己的價值來。然而一個組織的技術體系，必須依託組織的實際組織架構而存在。再優秀超前的技術，脫離了土壤都是空中樓閣，永遠沒有最優秀的技術，能真正為組織帶來價值的技術，才是最合適的技術。