一向崇信“奧卡姆剃刀原則”，如非必要，絕不新增。
在我所實施的專案中，自定義欄位、自定義報表非常少。很極端的一個例子是，曾經有一家工廠，生產印表機的部件，產品百分之百外銷。
在專案實施完成，成功上線後，我發現整個系統中的自定義的查詢報表不超過5張，自定義欄位不超過10個，格式化搜尋不超過5個……
但實施的專案，又可以說是非常複雜。還以上面那家工廠為例，雖然開啟他們的系統，你會為它的簡單而大吃一驚，但如果真的
按照業務藍圖所規定的流程實際操作一次，你又會很頭痛它的複雜。
只要一個不小心，一個輸入錯誤，或者想偷偷懶繞過某張基礎單據、繞過某個需要預先定義的設定項，系統都不會允許你儲存。
要走通我的流程，估計得花很長的時間吃透我業務藍圖上規定的流程邏輯、單據的流轉邏輯，你才可能很順利地一次性操作成功。
當然，這對真正的使用者來說不存在問題，他只要完全按日常的業務去操作，沒有犯錯，那系統會很樂意接受他的資料。
所以，其實並不是方案簡單，而是習慣把複雜的邏輯藏在背後，使用者看到的東西越簡單明瞭越好，但系統中的邏輯一定要非常精細、嚴謹，經得起錯誤操作和新手操作的考驗。
把一些複雜的事情，花一點時間封裝起來，讓使用者也好，顧問也好，都能簡單地應用，這就是在這篇文件裡所描述的“方案”的概念。
不斷積累可移植移強、通用性強的方案，這就是我追求的目標和我一貫的做事方法。也是為什麼幾年前要花50個人天去做的專案，現在也許只需要30個人天的原因。
做任何事情，都需要有自己的積累。這就好比走路一樣，不喜歡走同一條路，同樣我也不樂意換一個專案就得重新去做一個方案，或重新去寫一段SQL程式碼，或者重新去開發一個報表、加一個欄位……
如果有一個很特殊的需求，我們只需要從之前的通用方案中隨手拈取一個，花幾秒鐘的時間簡單改一改配置，就能放到新的資料庫中，那會有更多的精力去關注如何達成專案的目標，而不會為軟體的功能限制了你的拳腳而苦惱。所以，需要思考的是：設計任何方案，都不應只滿足於當前的客戶和他當前的需求，而是要考慮這個方案是否可以擴充套件它的健壯性，讓它能儘量通用，儘量提高可移植性，儘量能做一個簡單的勾選和配置，就能滿足下一個客戶的不同需求？只有這樣不斷積累自己的方案，才能越做越輕鬆，越玩越能感覺到ERP的無窮樂趣。
一個專案實施如何才能算完美，什麼才算是實施能達到最好的目標？我經常思考這個問題，其實並不認為一個方案有多麼出乎意料，或者有多麼讓人讚賞的巧妙思路，或者是否能完全涵蓋客戶的所有需求，甚至有多麼高的技術含量這些東西是一個完美專案的判斷標準。一個專案成功的關鍵只有簡單的兩點：
- 達到管理提升的目標。那麼如何才算是管理提升了呢？從中小企業定位來看，它能給企業帶來的最大提升，就是將先進的管理理念通過顧問設計的管理流程固化和推廣，讓成長型的中小企業擺脫作坊式管理的桎棝，獲得高速成長的助力。當然這是理論化的說法，如果我們把這個概念說得通俗一點，就是通過上ERP系統，老闆可以制定一個遊戲規則，然後用ERP這個工具控制住關鍵點，不按這個規則走就走不通。然後老闆可以帶著小祕出去晃悠半年回來，發現他的企業還是規規矩矩按著這個遊戲規則在運作，不需要他去盯著，ERP這個工具就幫他達成他想要怎麼管理企業的思路了，這就是ERP能給企業帶來的管理提升！
- 專案實施完成後，客戶能自行維護。這也是評價一個專案實施成功的關鍵點。如果專案實施完成，顧問離場幾年後，客戶還不斷為新增過賬期間、為某個新業務要改變某個設定，或者為不理解某個單據、某個報表的數字而頭痛，那麼顧問也煩，客戶也對這個系統心裡也沒底。所以在專案實施過程中，必需注意培養客戶成長起來，永遠不要害怕客戶知道得比你多，相反，他知道和了解得越多，對這個系統也就會更有信心，同時對你的難點也會體諒得越多，不會再無休止地給你出難題。
所以，在專案實施中，不會太多關注操作人員的利益，會更多關注流程是否會被操作人員繞過去，會關注是否某個流程的關鍵點會失去監控，會為那些依賴於操作人員的“自覺性”或者過於依賴操作人員的素質才能幹好的事情而難受，在設計的流程中，往往更多會體現部門間的互相牽制，而不會去在意操作的快捷和便利。所設計的外協加工流程，需要橫跨採購、計劃、倉庫、財務部門共同協作才能完成，會禁止使用者直接用MRP的結果生成採購和生產訂單，甚至我還會禁止銷售訂單直接生成採購訂單。如果只能選擇其一，那會選擇讓系統去檢查必填項，而不會指望一個自動重新整理的格式化搜尋去減輕輸入工作量。我相信站在老闆的角度，他也會更關注控制而非便捷。畢竟請個文員的成本，遠不如流程失控帶來的隱性損失大。
因此大家在下面的方案中，其實可以看到，大多數的方案都是偏向於邏輯的控制，而非減輕操作人員的負擔。目標始終在於把ERP做成老闆的工具，而不是操作人員的OA工具！
在每個專案中，為了保證我的流程有效，控制點都有將近上百個。或許有人會懷疑這會影響系統的執行效率。我不想在這裡闡述這個擔心是多餘的，只想說明一點，只要目標是正確的，那我們付出多大的代價都可以接受，並且“影響效率”的事還可以通過科學的程式碼編寫來很好地規避。所以當專案實施上線後，不用擔心脫離我的指導，系統會因為錯誤操作而帶來致命和不可挽回的影響。我會非常放心地放手讓客戶的系統管理員去接手專案，我寧可不賺客戶的維護工單，寧可遠端指導，也逼著系統管理員迅速成長起來，能夠自行維護他的（而不是我的）系統。
基於這種風格，在專案實施中和系統上線後，很多時候的表現可以稱得上是“殘酷”和“無情”。不會讓操作使用者直接找我，有事情一定要彙報給系統管理員，只會回答系統管理員提出的問題。而在一個專案實施結束後，驚訝地發現，我幾乎都叫不出某些操作人員的名字，只知道這張臉孔是哪個部門的！而系統管理員在一年以後，成長為一個合格的顧問，自己的職業生涯也拓寬後，在他心裡，他不會後悔曾經承受的壓力和付出的汗水，他對你也會有那麼一點點的感激之情！
要做到這點，其實不難，只要在上線後，你足夠放心地放手就行！
而你放手的資本，就是你在你的方案中，已經儘可能地把所有的意外情況考慮進去，杜絕了所有難以回滾的災難性操作錯誤，你的方案容錯性已經最大程度得到擴充套件。這就是你最大的資本！
所以，大家在這裡閱讀這些方案時，稍有一點可供分享的，不是ADDON，不是技術，也不是多麼巧妙的SQL語句，而是設計和思考這些方案的思路，以及期望這些方案能達到的目標，這才是希望與大家一起共勉的！