erp老實說2

ERP老實說(二)ERP系統分析難以呈現企業真實面貌

一般ERP公司在做系統分析粗略分為兩種方式

專案訪談型-透過訪談資料去蒐集客戶的需求,然後產生報告
套裝系統型-事先有自己的一套作法,再讓客戶依需求作部分修改

就系統分析的角度這兩種方式各有他的缺點

專案訪談型

訪談型的缺點就是,你沒辦法訪談出好的架構,為什麼?
今天訪談的人對自己的職務很難有一個完整的結構,
比如我們去訪談一個會計從業人員,他會講出一套會計制度嗎?講不出來
多數僅能片面的講出他的作業。

我們如果嘗試把自己平常作的事情講一遍,經常都是掛一漏萬
都是講大部分簡單的作業,一些重要的例外狀況都沒講

如果你拿講出來的東西來去作分析,得到的結果往往是錯的
又因為你不熟悉他的作業,你也不知道你錯了
你訪談的單位本身也不是專家,他沒辦法用數理的角度去判斷你的分析是有漏洞的
最後的結果,就是作出不理想的設計

套裝系統型

套裝我可以理解到他已經有一個既有的流程,然後在這流程之上看你需要修改什麼。
這樣的方式一樣有很多不足取的地方
他用他的觀點來詮釋別人的事情,但每一家企業都有他的特殊變化
大部分看起來都是對的,就以為全部都對了
到真正導入的時候才發現有些重要的流程是不對的
[plsc_divider color=”black” style=”dotted”]
我們一個企業的運作是很多面向的,有品質、會計、財務、內控、預防…等基本要素在企業的底層流動
這些東西都沒有彰顯在表面,是訪談不出來的
所以當你依靠訪談出來的東西,不會知道什麼是品質,究竟品質在這中間怎麼達成的你看不出來
erp系統最重要的就是要去確保效率、預防錯誤、異常管理、設計內控,同樣也無法透過訪談得知
花了那麼大的工夫卻得不到這些重要的事情,只得到一些不需訪談的瑣碎常規,
偏偏這卻是業界普遍採用的方式

Project Base的ERP系統開發在訪談時都必須把結果寫清楚,要叫客戶作確認以免以後客戶不認帳,才接著作系統分析

但這就牽涉到一個天生的問題
今天你做系統的人過來問我的作業我跟你講,你寫好了叫我簽字,但是你寫的東西我看不懂阿?
沒錯你寫的東西都是我的名詞,但我要怎麼知道你寫的是完整的?
我自己也不見得講得清楚你就要我在上面簽字,我不敢簽阿…
另一種情況是你叫我來進行訪談,因為怕漏掉,我就把需求講得更多更大,原本只有十個報表我就告訴你有100個報表

Project Base的架構通常是先由PM決定大的目標,然後才做系統分析
但偏偏一種程序去看他的細節可以看到很細很細,一個命令出去要不要合併、什麼時候可以修改、誰可以修改、什麼情況下要送到什麼部門才能修改…我為了要讓你簽字這些通通都要寫進去,不然會覺得不完整而不敢簽

這就是專案型合約先天的困境,雙方勞費大功夫卻設計出不對的系統

MicroStep 如何做ERP系統分析?

我們沒有一個大的模子,
我們只有最簡單的-人跟人是怎麼講話的
人跟人一定是這樣講話的,不可能不是這樣講話

我交代你一件事情,你去做,做完了就回報我你做完了
我叫你做十件,你做了三件還有七件沒做在這裡
我看你七件沒做,就知道這七件可以改掉或取消

人跟人之間的溝通行為是有一定的規則的
但這種的規則和變化卻是最複雜的

所以我們透過文法的分析先把人跟人之間的交辦、回報,什麼叫異常等等的溝通模型都先定了
到了系統分析就不是要問你這個單據會不會改,還用問,一定會改
這個命令下了能不能修改?理所當然是還沒執行你就能改,已經不用問了

你已經有一套會計制度了,還需要去問你這是怎麼過帳的嗎?
你只要問他你怎麼開傳票,後面你都知道了

當你已經有一個底層的溝通模型,很多東西都已經是自然的了,而且更豐富
真正到訪談的時候只需要訪談內容,所有複雜的、瑣碎的部份都不需要花時間