一般ERP公司在做系統分析粗略分為兩種方式
專案訪談型－透過訪談資料去蒐集客戶的需求，然後產生報告
套裝系統型－事先有自己的一套作法，再讓客戶依需求作部分修改
就系統分析的角度這兩種方式各有他的缺點
專案訪談型
訪談型的缺點就是，你沒辦法訪談出好的架構，為什麼？
今天訪談的人對自己的職務很難有一個完整的結構，
比如我們去訪談一個會計從業人員，他會講出一套會計制度嗎？講不出來
多數僅能片面的講出他的作業。
我們如果嘗試把自己平常作的事情講一遍，經常都是掛一漏萬
都是講大部分簡單的作業，一些重要的例外狀況都沒講
如果你拿講出來的東西來去作分析，得到的結果往往是錯的
又因為你不熟悉他的作業，你也不知道你錯了
你訪談的單位本身也不是專家，他沒辦法用數理的角度去判斷你的分析是有漏洞的
最後的結果，就是作出不理想的設計
套裝系統型
套裝我可以理解到他已經有一個既有的流程，然後在這流程之上看你需要修改什麼。
這樣的方式一樣有很多不足取的地方
他用他的觀點來詮釋別人的事情，但每一家企業都有他的特殊變化
大部分看起來都是對的，就以為全部都對了
到真正導入的時候才發現有些重要的流程是不對的
[plsc_divider color=”black” style=”dotted”]
我們一個企業的運作是很多面向的，有品質、會計、財務、內控、預防…等基本要素在企業的底層流動
這些東西都沒有彰顯在表面，是訪談不出來的
所以當你依靠訪談出來的東西，不會知道什麼是品質，究竟品質在這中間怎麼達成的你看不出來
erp系統最重要的就是要去確保效率、預防錯誤、異常管理、設計內控，同樣也無法透過訪談得知
花了那麼大的工夫卻得不到這些重要的事情，只得到一些不需訪談的瑣碎常規，
偏偏這卻是業界普遍採用的方式
Project Base的ERP系統開發在訪談時都必須把結果寫清楚，要叫客戶作確認以免以後客戶不認帳，才接著作系統分析
但這就牽涉到一個天生的問題
今天你做系統的人過來問我的作業我跟你講，你寫好了叫我簽字，但是你寫的東西我看不懂阿？
沒錯你寫的東西都是我的名詞，但我要怎麼知道你寫的是完整的？
我自己也不見得講得清楚你就要我在上面簽字，我不敢簽阿…
另一種情況是你叫我來進行訪談，因為怕漏掉，我就把需求講得更多更大，原本只有十個報表我就告訴你有100個報表
Project Base的架構通常是先由PM決定大的目標，然後才做系統分析
但偏偏一種程序去看他的細節可以看到很細很細，一個命令出去要不要合併、什麼時候可以修改、誰可以修改、什麼情況下要送到什麼部門才能修改…我為了要讓你簽字這些通通都要寫進去，不然會覺得不完整而不敢簽
這就是專案型合約先天的困境，雙方勞費大功夫卻設計出不對的系統
MicroStep 如何做ERP系統分析？
我們沒有一個大的模子，
我們只有最簡單的－人跟人是怎麼講話的
人跟人一定是這樣講話的，不可能不是這樣講話
我交代你一件事情，你去做，做完了就回報我你做完了
我叫你做十件，你做了三件還有七件沒做在這裡
我看你七件沒做，就知道這七件可以改掉或取消
人跟人之間的溝通行為是有一定的規則的
但這種的規則和變化卻是最複雜的
所以我們透過文法的分析先把人跟人之間的交辦、回報，什麼叫異常等等的溝通模型都先定了
到了系統分析就不是要問你這個單據會不會改，還用問，一定會改
這個命令下了能不能修改？理所當然是還沒執行你就能改，已經不用問了
你已經有一套會計制度了，還需要去問你這是怎麼過帳的嗎？
你只要問他你怎麼開傳票，後面你都知道了
當你已經有一個底層的溝通模型，很多東西都已經是自然的了，而且更豐富
真正到訪談的時候只需要訪談內容，所有複雜的、瑣碎的部份都不需要花時間
