這個故事講的是一家擁有百年曆史的製造業大廠的信息化轉型過程當中的波折。這家企業擁有超過三萬名員工,它是某行業的領先品牌,可是在信息化程度上卻很是古老。 網絡
有許多人說,國企的項目都是坑,至關一部分項目都是爲了騙經費而忽悠人的,換一撥管理層,基本上就得換一撥項目,油水全被領導撈走了。我很遺憾,沒能經歷這些事情。這個項目實打實都是作出來給基層用的項目,也確實得到了各方較高的滿意度。 架構
以中臺爲政治正確的互聯網開發者們會說,這個項目從商業層面和技術上來講彷佛毫無價值,首先它不是互聯網產品,其次它沒什麼技術含量,什麼大數據,雲計算,容器,微服務,無服務,它都不須要,這甚至有點像咱們身邊許多人十年前就作過的項目,技術上平淡無奇,看起來毫無挑戰。 微服務
顯然並不是如此,每一個項目存在都有價值。做爲過程當中的親歷者,我但願經過總結這個項目過程當中存在的不足,引發思考和引起討論。尤爲是隨着時代的進步,像這樣信息化轉型的傳統制造業企業,或許愈來愈罕見,這樣的項目看起來很是獨特,但也是軟件項目中的一個典型,對於將來從事行業互聯網開發的軟件從業人員來講,也許能帶來一些思考。 學習
2015年開始,製造業企業開始流行起一種新的趨勢:工業4.0,在這個大背景下,國內則提出了中國製造2025的計劃,旨在經過幾年努力,實現中國製造業的智能化水平在上一個臺階。 大數據
該大型國企做爲該某領域的領先品牌,其生產的產品遠銷國內外,也是軍民融合的典型表明,可是在過去的發展過程當中,因爲產品自己比較特殊,許多關鍵步驟仍然是採用手工完成,沒法徹底實現自動化替代,包括檢驗管理體系也一樣創建在一大堆紙質表單的基礎上完成。集團管理層看到了中國製造2025帶來的巨大機遇,也想奮鬥一波,但要作的事情實在是太多了。 雲計算
康威定律說,一個組織的軟件架構設計,其實是組織管理形式的體現。在9012年的今天,爲了維持這樣一套以紙質表單爲核心的檢驗管理體系,須要維持龐大的管理體系,帶來了巨大的管理成本,對於組織來講自己成爲了一種巨大的負擔。更況且這種管理形式,問題實在是太多了。 spa
1,須要花費大量的時間和精力來維持現有組織,哪怕是非關鍵崗位的離職,均可能影響一些流程的開展。(紙質資料的交接,其實跟口口相傳沒什麼區別)。 架構設計
2,過程資料存儲困難,爲了存儲資料,更是須要專門安排檔案室和檔案保管員,一旦出現產品質量問題,須要進行問題追溯時,要從檔案中檢索問題要花許多時間。 設計
3,一旦發生災害或事故,例如火災洪災,就意味着過程資料將成爲廢紙,產品的關鍵過程信息將沒法尋覓。 開發
在互聯網技術飛速發展、實體經濟受到巨大沖擊的今天,原有管理模式,過於臃腫,已經沒法適應組織發展的須要。行業愈來愈不景氣,企業的管理成本居高不下,負擔愈來愈重,每一年裁人裁了許多人,卻沒能從管理效能上帶來多大的提升,所以提高企業的信息化管理水平其實勢在必行。
可是若是要實現一步到位,直接構建基於工業4.0的智能製造新體系,在這個行業都不太現實,畢竟許多產品都是屬於定製生產、小批次製造,部署全套自動化製造生產線成本很是高,事實上新生產線也在建設,可是一直沒有投產,老的生產線也得維持好,這樣才能持續創造價值。作好眼前能作的,實現檢驗管理的信息化(無紙化),而後再逐步實現製造業的智能化,只有實現了這一小步,纔有將來的無限可能。
以前提到中國製造2025的大背景,還有一個小背景。企業內部企業的中高層廣泛都是八十年代末畢業擁有更高學歷的管理層,不乏清北的高才生。他們那些大學同窗正是這一波大時代的受益者之一,有許多同窗都藉助於企業的騰飛實現了我的價值,可是留在這家國企的高管們,卻看着企業愈來愈差,也想有所做爲,卻感受一個拳頭打在了棉花上,他們的壓力很大。
然而,你們都清楚,傳統國企的體質僵化,不少時候看起來兩個字所謂「變革」,實際上卻有點像個好夢而已,就拿「信息化」系統建設來講吧,信息化對於國企來講並不是第一次提起,許多國企的老員工,乃至管理層其實已經經歷了過去十年信息化失敗之苦,許多信息化系統在領導們的支持下,看似搞得轟轟烈烈,熱熱鬧鬧,可是最終都難逃被拋棄的下場,而每一個信息化項目的失敗,都會讓好幾位負責對應信息管理工做的牽頭人背鍋,並最終從公司離開。
在IT從業人員看來或許很簡單的信息化建設,歷來沒那麼順順利利,極有可能會因爲基層的抗拒最終失敗,並給信息化建設的參與者帶來職業生涯上的污點。
因而在國企把信息化提上議程以後,得到了兩種不一樣的聲音。很戲劇性的,不懂信息化的業務部門是信息化的支持者,他們說這個事情必定要搞,砸鍋賣鐵都要上,再難也要上。另一種負責信息化工做的信息中心的負責人對信息化的態度很明顯,要我支持,沒問題,我能夠把網絡作好,可是要我參與軟件的研發過程,恕我無能爲力。
所以最終牽頭組織這個過程資料信息化的,是平時對這一塊需求最大的檢驗管理部門。在他們的推進下,項目正式提上了議程。
這是個涉及面很是普遍的項目集,包括了三個項目,分別是面向民用領域單一事業部的A項目,面向融合領域的B項目,以及面向整個集團全方向的C項目。事實上集團曾經購買過現成的產品,可是都沒能用起來,因此這個項目集最終是以定製開發的形式承包出來。
A項目做爲最早立項的項目,萬事開頭難,承受了巨大的壓力,許多人在等着看一出好戲。
A項目的負責人W部長今年三十八歲,在此以前他一直是從事檢驗管理出身,對產品檢驗有本身明確的要求,他奠基了整個項目的基調。沒有設定特別宏大的目標,不是作一個通用的大系統,就作一個簡單實用的系統,可以給基層帶來方便,爲管理層帶來便利就夠了。
項目的早期,承建單位曾經試圖引入新技術和更加友好的用戶體驗,可是w部長卻不這麼認爲,他說在這樣的老國企,不必用新技術,一切以知足可用性爲目標,操做越簡單越好。因而最終承建方設計了一個基於cs的數據採集系統和基於bs的管理系統。不只功能 儘量的簡單,並且連流程都能省就省,儘可能讓參與者減小學習成本。
這個設計簡單實用的系統,剛好知足了敏捷項目所要達到的構建簡單項目、實現快速迭代小步快走的管理目標。駐場開發期間,及時發現問題和解決問題,讓軟件獲得了很是充分應用,得到了甲方的高度評價。
並且若是說早期項目的應用的推動須要靠組織的強勢推進,到了後期就使人欣慰了,因爲這個系統無需特別複雜的操做流程就能完成資料的錄入,提交和彙總,基層崗位的工做人員只要會用計算機、簡單培訓就能迅速上手,無形中爲項目的快速鋪開奠基了良好的基礎。並且承建方與甲方的基層人員之間溝通融洽,有問題及時反饋,及時處理,爲項目推動帶來了很是不錯的效果。
在項目運轉正常一年以後,主導項目工做的部長調任了,新接手的負責人是曾經不太看好這個系統的車間主任,他也被基層工做人員帶動,成爲了這個項目的擁躉。
藉着A項目成功的東風,立刻啓動了B項目。
前面提到了,B項目是面向融合產業的,所以對這個項目的要求也相對而言更高。
當這個項目完成立項後,B項目建設方的組織架構也發生了比較大的變動,首先是以前推進A項目的集團公司大領導因爲工齡屆滿,已經退休,而集團的整個管理層都相繼發生了變化,包括推進項目立項的一位高級工程師也從公司離職,意味着項目早期干係人已經徹底換了。
組織架構調整實際上是爲了給年輕人機會。調整後,B項目負責整個項目的,都是87後的年輕人。
這羣年輕人們,相對於A項目的負責人來講,對信息化有了更加深刻的認識。事實上而言,A項目建設,其實不過是一個相似於協同辦公的一個模塊,他們認爲這個項目沒什麼技術含量,甚至有點low。他們常常出去考察學習,對用戶體驗和功能應用都有不少想法,他們渴望真正打造一個可以真正打造一個符合企業將來發展目標的信息化一體化平臺。
這些想法再跟現有政策、以及組織架構混合在一塊兒發酵,最終變成了一個無比巨大的項目,用專業術語來講,就是一個「大泥球」系統。
在項目立項之初,合同上原始需求其實只有19個條目,並且爲了讓這些內容容易落地,前期的推進者甚至儘量的減小流程的複雜度,可是等合同簽定後、組織結構調整完,新的干係人們在原合同的基礎上,對範圍進行了大幅修改。最終等需求調研落地,變成的是一個基本上涵蓋了公司大部分審批事項、涉及幾十個流程,涉及全公司數百人、超過十幾個小系統的大項目。
爲了完成這個項目,雙方投入了最少20我的,超過十人的研發團隊駐場開發了超過半年時間,也沒折騰出幾個讓甲方滿意的東西。建設單位現場條件惡劣、涉及流程複雜、涉及特殊的管理機制,要開發的功能點特別多,不斷的完善,不斷的修改,整個項目研發前先後後折騰了至少一年時間以後,才經過直接負責人的承認,可是給領導彙報時,卻根本不可用,得推翻重作。
項目到今年項目依然沒有上線,這離合同交付日期已經超過兩年了,顯然能夠稱之爲「失敗項目」了。
承建方雖然早期意識到了項目風險,可是建設方過於強勢,沒法拒絕;建設方貪多求快,忽略了組織自己的複雜性、低估了軟件研發的工做量以及軟件實施的難度,最終雙方都竹籃打水一場空。
C項目是在B項目完成了到一半時啓動的新項目,其目標是將A項目成功的經驗,推廣到全集團。(不包括B項目的事業部)。
C項目的實施異常順利,合同期一年,實際上只花了8個月就把項目作完了。
當我年輕時曾經向其餘擁有豐富經驗的項目經理請教什麼樣的項目纔是成功項目時,他們說:
「剛恰好」:剛恰好知足客戶的需求,就是一個不錯的項目。
一個充滿智慧的回答。不過「剛恰好」其實很難把握這個度,我以爲必定是功能簡單、實用便可。
在這個故事中,那個最簡單實用,幾乎沒有什麼技術含量的項目在組織中得到了很大的成功,而一開始就打算作成全流程信息化的系統,最終卻一敗塗地。
這剛好就像咱們常常見到的項目,簡單純粹的產品才能最早站穩腳跟、得到不錯的用戶反響,那些一味畫餅的PPT項目,都是忽悠人,幾乎沒幾個成功了。
除此以外,每個軟件行業從業者,越愛鑽研技術,越容易陷入技術的迷思,總覺得靠技術能改變世界,彷彿一個項目沒用上什麼新技術就容易就沒法體現出本身的價值來。然而一個組織的技術體系,必須依託組織的實際組織架構而存在。再優秀超前的技術,脫離了土壤都是空中樓閣,永遠沒有最優秀的技術,能真正爲組織帶來價值的技術,纔是最合適的技術。