任何ERP系統都不可能不修改的，因為企業本身就是在追求永續改善，經理人最大功能就是要讓企業更好，流程更順暢、錯誤率更小、預防錯誤的發生、幫助每個人累積知識、運用知識…這些都是沒有止盡的，需要一點一滴去構思、設計、累積
因為企業是永續改善，所以我們的ERP系統也永遠需要去修改、增訂，這是必然的。
但這種無止盡的增訂修改，就跟一般的專案開發剛好是相違背的
ERP專案開發商的想像中企業是存在一個固定的流程，便去好好的分析他，然後花一大段時間去把它開發完成，以後有修改再提出修改需求，但這個修改在他們眼中是一個很小的事情。
我們換個方式來比喻，就如同今天你蓋一個辦公室，你的需求是要彈性的隔間，他卻用水泥去施作，然後告訴你之後要改，把水泥牆打掉再做新的就可以了。
以專案開發者的角度，他的任務就是要去完成你訂定的規格，不會去考慮你以後方不方便修改，因為方不方便修改跟這個專案規格無關，交付條件沒有好不好修改這件事。
套裝ERP軟體也是一樣，套裝軟體自然就希望我的軟體流程，能依照我所設定的客層的最大需求是去設計，所以他也不希望每個客戶都去做很細膩的修改，也不會在讓軟體好修改這件事下功夫。
[plsc_divider color=”black” style=”dotted”]
如果在設計系統的當下沒有考慮到往後能大量修改，修改這件事就會變得很困難，修改的時間長、成本高、容易出錯，甚至不想去修改。
換個從合約的角度想，修改也不是他們會想要去賺的錢，完成專案對系統商而言才是真正大的收入，維護修改則是一種能免則免的負擔。
然而一般的企業客戶因為不了解系統的本質，也覺得系統不改沒關係，將就著用，但這將就著用就讓你的企業沒辦法前進。
當然你可以在商品的開發上、製程的設計上有很大的改善，但是你在公司的內部管理上、服務的流程上、物流管理上，便沒辦法很細膩的作改變。
MicroStep跟其他ERP廠商不一樣的地方，就在於我們一開始就認定必須要去修改軟體，我們設計的系統就是以的一個一個小組件去作前後的銜接，隨時能夠拆卸、重組，而且是每個小地方都可以。
用這樣的精神來設計時，你要改一個畫面就是改一個畫面的工，要改一個報表就是一個報表的工，所以他的時間、成本、錯誤率都能很輕鬆的控制。
就好比一棟房子裡面所有的隔間、牆面、地板、天花板、燈具都設計可移動的、可更換的。我今天可以隨意的移動隔間，不用考慮其他的結構。
反觀一般的設計如果要改一面牆，不僅要打掉一面牆，還會動到地基、動到天花板、動到裝潢、動到油漆壁紙，最後就不敢打這面牆。
不同的出發點、不同的想法，整件事情是天翻地覆的。
MicroStep著重在長期的服務，根據我們的經驗，一個企業在ERP系統運作的前二～三年，每年大約要改掉整個系統的60~70%，接下來每年大約會改掉30%
這樣的修改量代表著經理人是持續的在構思改善，或是有在跟進外面的環境變化、客戶的要求。要因應這樣的需求我們必須要有一種工程模式去滿足客戶的大量修改。
有人認為改得快和改得慢不都是一樣改好了嗎？這其實在本質上有很大的差異：
今天我們鼓勵員工要全員品質、永續改善，要每個人員提案要怎麼改怎麼改…
結果提案了系統卻跟不上，這樣的改善怎麼成立？
如果每個改善都要當一件大事情來看，要審慎的考量、計畫、決策，結果考慮再三還不太敢動，因為改善的成本太大了。
某某人員對流程有個改善想法，或是對單據格式有些建議，現在提出來可能過幾天就出來了，這個建議對了馬上就能享受成果，錯了就趕快改回來，幾乎沒有負擔，這樣才有可能形成一種改善循環，大家更願意改善。
所以一個出發點的不同是有決定性的影響的。
今天是因為客戶有需求的產生而要去做修改，這個需求也有可能是一個問題或困難要解決
我今天有一件事情發生錯誤了，電腦如何讓我不會錯誤、或是如何預防我的錯誤，有不同的解法，這在系統設計上就有明顯的高下了。
如果要設計成系統預防你的錯誤，這是最高境界；如果只是出錯的時候通知你，就比較差一點，但哪一種作法對現在的狀況是最適當的還是要依靠有經驗的顧問，來做好這件事情。
客戶一個很重大的缺點，很可能透過顧問的拆解後，就只要改一點點。
當然還是有可能要改很大，但是顧問可以確保這件事的正確。
如果是專案或套裝的ERP廠商，心態上是你要修改必須要告訴我你要改哪裡，通常是這樣。因為他不會花時間或請顧問去幫你看你的原始需求，對照你提出的修改看看是不是合適的，或是產出一個完整的方案。畢竟對廠商來講，幫客戶解決問題不是他想要做的，最好是都不要有問題。長期下來系統就越來越不適用。
