奧卡姆剃刀原則在ERP項目的應用

一貫崇信「奧卡姆剃刀原則」，如非必要，毫不新增。

在我所實施的項目中，自定義字段、自定義報表很是少。很極端的一個例子是，曾經有一家工廠，生產打印機的部件，產品百分之百外銷。

在項目實施完成，成功上線後，我發現整個系統中的自定義的查詢報表不超過5張，自定義字段不超過10個，格式化搜索不超過5個……

 

但實施的項目，又能夠說是很是複雜。還以上面那家工廠爲例，雖然打開他們的系統，你會爲它的簡單而大吃一驚，但若是真的

按照業務藍圖所規定的流程實際操做一次，你又會很頭痛它的複雜。

只要一個不當心，一個輸入錯誤，或者想偷偷懶繞過某張基礎單據、繞過某個須要預先定義的設置項，系統都不會容許你保存。

要走通個人流程，估計得花很長的時間吃透我業務藍圖上規定的流程邏輯、單據的流轉邏輯，你纔可能很順利地一次性操做成功。

固然，這對真正的用戶來講不存在問題，他只要徹底按平常的業務去操做，沒有犯錯，那系統會很樂意接受他的數據。

因此，其實並非方案簡單，而是習慣把複雜的邏輯藏在背後，用戶看到的東西越簡單明瞭越好，但系統中的邏輯必定要很是精細、嚴謹，經得起錯誤操做和新手操做的考驗。

把一些複雜的事情，花一點時間封裝起來，讓用戶也好，顧問也好，都能簡單地應用，這就是在這篇文檔裏所描述的「方案」的概念。

不斷積累可移植移強、通用性強的方案，這就是我追求的目標和我一向的作事方法。也是爲何幾年前要花50我的天去作的項目，如今也許只須要30我的天的緣由。

作任何事情，都須要有本身的積累。這就比如走路同樣，不喜歡走同一條路，一樣我也不樂意換一個項目就得從新去作一個方案，或從新去寫一段SQL代碼，或者從新去開發一個報表、加一個字段……

若是有一個很特殊的需求，咱們只須要從以前的通用方案中隨手拈取一個，花幾秒鐘的時間簡單改一改配置，就能放到新的數據庫中，那會有更多的精力去關注如何達成項目的目標，而不會爲軟件的功能限制了你的拳腳而苦惱。因此，須要思考的是：設計任何方案，都不該只知足於當前的客戶和他當前的需求，而是要考慮這個方案是否能夠擴展它的健壯性，讓它能儘可能通用，儘可能提升可移植性，儘可能能作一個簡單的勾選和配置，就能知足下一個客戶的不一樣需求？只有這樣不斷積累本身的方案，才能越作越輕鬆，越玩越能感受到ERP的無窮樂趣。

 

一個項目實施如何才能算完美，什麼纔算是實施能達到最好的目標？我常常思考這個問題，其實並不認爲一個方案有多麼出乎意料，或者有多麼讓人讚揚的巧妙思路，或者是否能徹底涵蓋客戶的全部需求，甚至有多麼高的技術含量這些東西是一個完美項目的判斷標準。一個項目成功的關鍵只有簡單的兩點：

• 達到管理提高的目標。那麼如何纔算是管理提高了呢？從中小企業定位來看，它能給企業帶來的最大提高，就是將先進的管理理念經過顧問設計的管理流程固化和推廣，讓成長型的中小企業擺脫做坊式管理的桎棝，得到高速成長的助力。固然這是理論化的說法，若是咱們把這個概念說得通俗一點，就是經過上ERP系統，老闆能夠制定一個遊戲規則，而後用ERP這個工具控制住關鍵點，不按這個規則走就走不通。而後老闆能夠帶着小祕出去晃悠半年回來，發現他的企業仍是規規矩矩按着這個遊戲規則在運做，不須要他去盯着，ERP這個工具就幫他達成他想要怎麼管理企業的思路了，這就是ERP能給企業帶來的管理提高！
• 項目實施完成後，客戶能自行維護。這也是評價一個項目實施成功的關鍵點。若是項目實施完成，顧問離場幾年後，客戶還不斷爲添加過帳期間、爲某個新業務要改變某個設置，或者爲不理解某個單據、某個報表的數字而頭痛，那麼顧問也煩，客戶也對這個系統內心也沒底。因此在項目實施過程當中，必需注意培養客戶成長起來，永遠不要懼怕客戶知道得比你多，相反，他知道和了解得越多，對這個系統也就會更有信心，同時對你的難點也會體諒得越多，不會再無休止地給你出難題。

因此，在項目實施中，不會太多關注操做人員的利益，會更多關注流程是否會被操做人員繞過去，會關注是否某個流程的關鍵點會失去監控，會爲那些依賴於操做人員的「自覺性」或者過於依賴操做人員的素質才能幹好的事情而難受，在設計的流程中，每每更多會體現部門間的互相牽制，而不會去在乎操做的快捷和便利。所設計的外協加工流程，須要橫跨採購、計劃、倉庫、財務部門共同協做才能完成，會禁止用戶直接用MRP的結果生成採購和生產訂單，甚至我還會禁止銷售訂單直接生成採購訂單。若是隻能選擇其一，那會選擇讓系統去檢查必填項，而不會期望一個自動刷新的格式化搜索去減輕輸入工做量。我相信站在老闆的角度，他也會更關注控制而非便捷。畢竟請個文員的成本，遠不如流程失控帶來的隱性損失大。

所以你們在下面的方案中，其實能夠看到，大多數的方案都是偏向於邏輯的控制，而非減輕操做人員的負擔。目標始終在於把ERP作成老闆的工具，而不是操做人員的OA工具！

在每一個項目中，爲了保證個人流程有效，控制點都有將近上百個。或許有人會懷疑這會影響系統的運行效率。我不想在這裏闡述這個擔憂是多餘的，只想說明一點，只要目標是正確的，那咱們付出多大的代價均可以接受，而且「影響效率」的事還能夠經過科學的代碼編寫來很好地規避。因此當項目實施上線後，不用擔憂脫離個人指導，系統會由於錯誤操做而帶來致命和不可挽回的影響。我會很是放心地放手讓客戶的系統管理員去接手項目，我寧肯不賺客戶的維護工單，寧肯遠程指導，也逼着系統管理員迅速成長起來，可以自行維護他的（而不是個人）系統。

基於這種風格，在項目實施中和系統上線後，不少時候的表現能夠稱得上是「殘酷」和「無情」。不會讓操做用戶直接找我，有事情必定要彙報給系統管理員，只會回答系統管理員提出的問題。而在一個項目實施結束後，驚訝地發現，我幾乎都叫不出某些操做人員的名字，只知道這張臉孔是哪一個部門的！而系統管理員在一年之後，成長爲一個合格的顧問，本身的職業生涯也拓寬後，在他內心，他不會後悔曾經承受的壓力和付出的汗水，他對你也會有那麼一點點的感激之情！

要作到這點，其實不難，只要在上線後，你足夠放心地放手就行！

而你放手的資本，就是你在你的方案中，已經儘量地把全部的意外狀況考慮進去，杜絕了全部難以回滾的災難性操做錯誤，你的方案容錯性已經最大程度獲得擴展。這就是你最大的資本！

 

因此，你們在這裏閱讀這些方案時，稍有一點可供分享的，不是ADDON，不是技術，也不是多麼巧妙的SQL語句，而是設計和思考這些方案的思路，以及指望這些方案能達到的目標，這纔是但願與你們一塊兒共勉的！