第92章 流程改造
IT女經理的職場迴憶錄 作者：八月的獅子座 投票推薦 加入書簽 留言反饋
“鷹總，你知道ipd？”有天快十二點了，突然收到院長的微信消息。
我都準備睡覺了，看到這個消息有點左右為難。雖然微信沒有已讀功能，但我這種急性子的人，看到消息不迴複不搞清楚狀況很難睡著了。
“集成產品開發嗎？integrated product development, 簡稱ipd那個？”我在腦袋裏過了一遍我知道的所有ipd，似乎隻有這個最有可能。
“對對，你了解嗎？”
“聽說過，國外ibm用，國內華為也用。但我沒有實踐過。”
“那你以前公司用什麽流程？”
“以前做項目的那幾家公司都是pmp那套加cmmi。上家公司做產品，沒感覺有什麽特殊的，就是基本的產品研發路子。”
“啊，甲骨文沒有整什麽特殊的流程嗎？google（穀歌）都有呀！你們他們公司出了不少這方麵的書。”
“真沒有，我在那裏待了十一年，真沒有發現什麽特殊的。所以你看外界從來沒有相關的新聞和書籍。”這種類似的問題裁員後每個麵試人基本都會問（打探）一輪。
“這樣呀，s總說為了配合轉型，我們的流程也要改造。”
“以前我們不做產品，現在做產品，確實要好好設計下業務流程。不過我們哪有什麽流程呀？就x總（同事i）才整不久的新研發管理流程。”
“是呀，以前公司做項目就很隨意。s總意思是：簡單改造現在的流程不如引入一個外界廣泛被人接受認可的。華為的ipd就很適合。”
“確實是這樣。不過我們公司剛開始做產品，就上華為這麽大公司用的流程，會不會不太適合呀？”
“我也問過類似的問題，s總說沒問題，ipd流程不單單華為在用，很多做產品的公司都在用，不少和我們差不多規模的公司也在用。當初他把ipd引入他上家公司時，大家一樣有質疑。不過堅持下去，效果很好。”自從s總入職後，院長對他的思想幾乎是全盤接受。
“好吧。希望s總能帶領公司做出好產品來。”
“項目流程也要改。s總說產品和項目的流程要一起看，相輔相成，為公司戰略服務。”
“項目流程怎麽改呢？”
“項目流程不會大改，等產品流程定下後微調吧。不過目前的項目考核機製不行，這個要改革。他說華為的項目管理和考核機製不錯，可以借鑒。”
“好吧。我抓緊學習下ipd。”
我的瞌睡蟲早已被趕走了，心裏想著：這一下聽到一堆華為的巴拉巴拉，看來要好好研究下華為了。上上家公司的經理，那位知心大姐聽說去了華為，好像專門做流程監督和改進的，明天來問問她。
第二天找到大姐，講了講我公司的情況和找她的緣由。她很痛快地通過電話傳授我一番，最後還推薦了幾本相關的書籍給我。那些書幫助我快速了解了流行的一些產品研發流程和華為的產品研發曆程，受益匪淺。不過在看這些書的過程中，我總會想起公司的現狀，心裏想著“這些東西真能在我們公司實現嗎？”。
那段時間大佬們真忙呀！口頭或書麵的各種匯報，討論（吵架），寫ppt，改流程。不過我沒有院長、副院長那樣的行政職務，隻是個管理研發組織的技術中層，和他們討論的產品和項目都沾不上，除了有時作為他們的替補參加下一些不重要的會議，其餘的都很少參加。因此他們聊天時提到這些事情時，我也很難感受到當時的緊張氣氛。
那時我感受最深刻的卻是每天大家提及“華為”的次數。院長每天都會轉發些關於華為管理的各種文章，開會時，因為產品研發流程用的華為的ipd，項目流程和管理基本上也是照搬華為的項目管理體係。新來的項目總監也是從華為出來的，之前在華為幹了十幾年。解決方案、經營部、采購部，甚至人力資源部也有不少華為出來的新同事。
有天中午吃飯剛好碰到同事i，聊了聊近況，我吐槽道：“現在天天都是說華為怎麽樣，怎麽樣，我們要學習，要改進。怎搞不懂怎麽整真能解決公司的那些問題嗎？”
“也許他們也想不到更好的辦法了唄！”
“華為都發展幾十年的大公司了，摸爬滾打那麽多年，而且各方麵都很成熟。我們公司改製後才剛幾年？就想一骨碌學會了？”
“你以為他們不知道呀！但是嚐試了總比什麽都不做好。而且公司還要上市，你想下對外宣傳時說我們采用的是華為的產品研發流程和項目管理體係，別人，尤其是投資人聽了不是很有信心？”他笑笑對我說。
“好吧，這樣說來肯定還是比什麽都不幹好太多。”我明白了。
就這樣前前後後折騰了快一個月，被公司基於厚望的產品線體係終於定下來了，從此各個部門隻能做約定好的那些產品和相關的項目，不能跨界。而結合ipd和scrum敏捷開發的產品研發流程也隨之出爐了。加上更新的項目管理體係，大家剛開始看到這兩個長長的文檔說明都是發蒙的。不過仔細翻翻，大部分人發現和自己有關的內容不多而且也沒有太大的變化，活還是照幹。因此不少人又是對新的流程一頓嘲笑。隻有項目經理和產品經理吐槽多了不少文檔要輸出，不少會議要組織和參與。
以前在工廠做erp實施時，在推廣erp之前，大部分企業都需要做“流程再造”，否則很難成功實施erp，很難達到預期的目標。大部分企業都會盡可能地將組織和流程改造，往正規和優秀的模式上靠。隻有非常有國家、地方、行業或自身特點的東西，才用采用二次開發。軟件行業發展前期，也大量采納了工業管理的很多優秀管理理念和模式。後來才逐步發展和不斷改進，形成適合軟件行業的管理模式和業務流程。
隻要一提到“流程重組”或是“改造”，好多人都覺得很高大上。其實以我自己從業二十多的經驗來看，做流程並不難。很多時候都是將一件複雜的事情拆分成幾個步驟，然後每個步驟由設立專門的部門或是人員去負責。同時每個步驟設置準入準出條件，明確其中的運作程序和涉及到的角色，確定需要什麽樣的輸出，針對輸出的檢查，審核和評審。總之就是明確責任分工，標準化工作，並設置關卡檢查，及早發現問題和風險，盡快糾正及解決。
我覺得最難的不是怎麽設計，而是設計出來後如何執行，發現問題怎麽改進。很多公司花高價請諮詢公司，或是引入某個體係，覺得就完事了。結果後麵卻無人負責，無人監管，無人督導，最後好好的流程束之高閣，無人遵循。我們公司也是負麵案例之一，最後也徒留個花架子，人來人往吹一吹。
我都準備睡覺了，看到這個消息有點左右為難。雖然微信沒有已讀功能，但我這種急性子的人，看到消息不迴複不搞清楚狀況很難睡著了。
“集成產品開發嗎？integrated product development, 簡稱ipd那個？”我在腦袋裏過了一遍我知道的所有ipd，似乎隻有這個最有可能。
“對對，你了解嗎？”
“聽說過，國外ibm用，國內華為也用。但我沒有實踐過。”
“那你以前公司用什麽流程？”
“以前做項目的那幾家公司都是pmp那套加cmmi。上家公司做產品，沒感覺有什麽特殊的，就是基本的產品研發路子。”
“啊，甲骨文沒有整什麽特殊的流程嗎？google（穀歌）都有呀！你們他們公司出了不少這方麵的書。”
“真沒有，我在那裏待了十一年，真沒有發現什麽特殊的。所以你看外界從來沒有相關的新聞和書籍。”這種類似的問題裁員後每個麵試人基本都會問（打探）一輪。
“這樣呀，s總說為了配合轉型，我們的流程也要改造。”
“以前我們不做產品，現在做產品，確實要好好設計下業務流程。不過我們哪有什麽流程呀？就x總（同事i）才整不久的新研發管理流程。”
“是呀，以前公司做項目就很隨意。s總意思是：簡單改造現在的流程不如引入一個外界廣泛被人接受認可的。華為的ipd就很適合。”
“確實是這樣。不過我們公司剛開始做產品，就上華為這麽大公司用的流程，會不會不太適合呀？”
“我也問過類似的問題，s總說沒問題，ipd流程不單單華為在用，很多做產品的公司都在用，不少和我們差不多規模的公司也在用。當初他把ipd引入他上家公司時，大家一樣有質疑。不過堅持下去，效果很好。”自從s總入職後，院長對他的思想幾乎是全盤接受。
“好吧。希望s總能帶領公司做出好產品來。”
“項目流程也要改。s總說產品和項目的流程要一起看，相輔相成，為公司戰略服務。”
“項目流程怎麽改呢？”
“項目流程不會大改，等產品流程定下後微調吧。不過目前的項目考核機製不行，這個要改革。他說華為的項目管理和考核機製不錯，可以借鑒。”
“好吧。我抓緊學習下ipd。”
我的瞌睡蟲早已被趕走了，心裏想著：這一下聽到一堆華為的巴拉巴拉，看來要好好研究下華為了。上上家公司的經理，那位知心大姐聽說去了華為，好像專門做流程監督和改進的，明天來問問她。
第二天找到大姐，講了講我公司的情況和找她的緣由。她很痛快地通過電話傳授我一番，最後還推薦了幾本相關的書籍給我。那些書幫助我快速了解了流行的一些產品研發流程和華為的產品研發曆程，受益匪淺。不過在看這些書的過程中，我總會想起公司的現狀，心裏想著“這些東西真能在我們公司實現嗎？”。
那段時間大佬們真忙呀！口頭或書麵的各種匯報，討論（吵架），寫ppt，改流程。不過我沒有院長、副院長那樣的行政職務，隻是個管理研發組織的技術中層，和他們討論的產品和項目都沾不上，除了有時作為他們的替補參加下一些不重要的會議，其餘的都很少參加。因此他們聊天時提到這些事情時，我也很難感受到當時的緊張氣氛。
那時我感受最深刻的卻是每天大家提及“華為”的次數。院長每天都會轉發些關於華為管理的各種文章，開會時，因為產品研發流程用的華為的ipd，項目流程和管理基本上也是照搬華為的項目管理體係。新來的項目總監也是從華為出來的，之前在華為幹了十幾年。解決方案、經營部、采購部，甚至人力資源部也有不少華為出來的新同事。
有天中午吃飯剛好碰到同事i，聊了聊近況，我吐槽道：“現在天天都是說華為怎麽樣，怎麽樣，我們要學習，要改進。怎搞不懂怎麽整真能解決公司的那些問題嗎？”
“也許他們也想不到更好的辦法了唄！”
“華為都發展幾十年的大公司了，摸爬滾打那麽多年，而且各方麵都很成熟。我們公司改製後才剛幾年？就想一骨碌學會了？”
“你以為他們不知道呀！但是嚐試了總比什麽都不做好。而且公司還要上市，你想下對外宣傳時說我們采用的是華為的產品研發流程和項目管理體係，別人，尤其是投資人聽了不是很有信心？”他笑笑對我說。
“好吧，這樣說來肯定還是比什麽都不幹好太多。”我明白了。
就這樣前前後後折騰了快一個月，被公司基於厚望的產品線體係終於定下來了，從此各個部門隻能做約定好的那些產品和相關的項目，不能跨界。而結合ipd和scrum敏捷開發的產品研發流程也隨之出爐了。加上更新的項目管理體係，大家剛開始看到這兩個長長的文檔說明都是發蒙的。不過仔細翻翻，大部分人發現和自己有關的內容不多而且也沒有太大的變化，活還是照幹。因此不少人又是對新的流程一頓嘲笑。隻有項目經理和產品經理吐槽多了不少文檔要輸出，不少會議要組織和參與。
以前在工廠做erp實施時，在推廣erp之前，大部分企業都需要做“流程再造”，否則很難成功實施erp，很難達到預期的目標。大部分企業都會盡可能地將組織和流程改造，往正規和優秀的模式上靠。隻有非常有國家、地方、行業或自身特點的東西，才用采用二次開發。軟件行業發展前期，也大量采納了工業管理的很多優秀管理理念和模式。後來才逐步發展和不斷改進，形成適合軟件行業的管理模式和業務流程。
隻要一提到“流程重組”或是“改造”，好多人都覺得很高大上。其實以我自己從業二十多的經驗來看，做流程並不難。很多時候都是將一件複雜的事情拆分成幾個步驟，然後每個步驟由設立專門的部門或是人員去負責。同時每個步驟設置準入準出條件，明確其中的運作程序和涉及到的角色，確定需要什麽樣的輸出，針對輸出的檢查，審核和評審。總之就是明確責任分工，標準化工作，並設置關卡檢查，及早發現問題和風險，盡快糾正及解決。
我覺得最難的不是怎麽設計，而是設計出來後如何執行，發現問題怎麽改進。很多公司花高價請諮詢公司，或是引入某個體係，覺得就完事了。結果後麵卻無人負責，無人監管，無人督導，最後好好的流程束之高閣，無人遵循。我們公司也是負麵案例之一，最後也徒留個花架子，人來人往吹一吹。