gipi的學習筆記-經營管理、數據思考、終身學習

不管是ERP、CRM、BPM或是KM系統，這些應用軟體一開始會被發展出來大多是因為有特定的使用者需求，以ERP來說，其實一開始可能只是由一些財務管理、生產管理、庫存管理、訂單管理等等功能的需求，如下圖，本來這些需求可能都是由不同的系統來負責的：


但是當我們的應用愈來愈成熟，我們在應用上開始發現各個系統間彼此是有一定關聯的，我們就會開始構思是否要將這些系統做一個整併：


經過好一些時間運作，ERP就被提出了，他將過去企業營運相關的系統加以彙整後，擷取相關連的部分放在一套系統中，買了這套系統，你可以不用像過去一樣建置一大堆不同的系統，在現在，你只要買一套ERP就可以滿足了，而這樣的模式就稱為套裝(Package)，而財務、生管、維修、訂單等系統，在ERP中就從過去的系統變成了模組，這代表的意義是該功能不再是獨立的，而是因應使用者的需求，被適度的融合在一起。

做套裝軟體並不簡單，模組與模組間的切分更是困難，有些模組彼此的相關性極高(或稱功能耦合)，通常買了A模組就會連B模組一起買了，但有些模組彼此間的相關性較低，我買了A模組不見得要買B模組，為了滿足不同的用戶、產業別、國家別的需求，這些模組的功能應該是要可被置換的，但你卻不能因為我不買某個模組而讓我的系統無法使用，如下圖，我想買你們ERP中的訂單、生管及維修模組，但財務跟客服的系統我要沿用我們公司既有的系統，你能做得到嗎？這個問題我相信大多數的廠商都被問過，有些夠靈活的系統在模組設計時就是以子系統的觀念去設計模組與模組間的接口(鬆耦合)，所以可以做到，但有更多的廠商是透過客製化的方式來解決這個問題。


不過本篇不是要論設計架構，而是想從使用者觀點來談產品這件事情，我想以上的狀況是我們在設計產品之初就該考量的，很多IT專案的失敗原因就在這邊了，一廂情願的希望客戶換掉既有系統來使用全新的系統，但卻提不出用新系統取代既有系統的利基點，所以單子接不下來，又或者接下來後為了客製化而花費了許多成本，一個無法將範疇、時間、成本控制在一定範圍內的專案，只能以失敗告終。

使用者需求觀點，這一項我們很常談，但卻很容易陷入到系統的思維中，我們面對的使用者需求往往不會很清楚的告訴你『我就是想要一套CRM系統』、『我就是想要ERP的生管模組』，大部分都是類似『我們工廠的管理很亂，常常會有庫存不足或者太多囤貨的問題』、『我們現在記帳都靠紙本，月底的時候用計算機一筆一筆算，在自己做成會計帳』、『我們上游的廠商老是或延遲交貨，給的材料品質也不穩定』，其實有一定經驗的顧問或者產品人員，很快的就可以從客戶的需求中探索出要依靠什麼系統來滿足客戶的需求，靠ERP、SCM、CRM三套系統應該就可以滿足了。

但只要能滿足客戶需求，客戶不會管你是靠什麼系統，他想要的是一個解決方案，你可以說將CRM(兩個模組)+ERP(三個模組)+SCM(兩個模組)等包裝成解決方案一起販售，對客戶談的是滿足他的需求，而不是分開來談說CRM可以幫你解決什麼問題、ERP可以幫你解決什麼問題、SCM又可以解決什麼問題，這些對使用者來說意義是較低的，但即使我們談解決方案，我們還是不得不承認這確實是三個系統，因為你要用不同的功能還是要登入到不同系統中，而為了解決這個問題，單一個入口(Portal)與單一帳號登入(SSO)就顯得特別重要了，有了這個最重要的元素，我們的解決方案就可以包裝的更加漂亮，三個問題一次解決，而且不會增加額外的困擾。

在大陸地區有人談到一體化解決方案是將所有的系統包在一個很大的套裝軟體中，這也是一種作法，但能綁在一起賣，不見得可以一個一個拆開賣，未來我們面臨的使用者需求會愈來愈複雜，整合的問題也會愈來愈多，過去是模組整合、系統整合，未來可能是私有雲與公有雲整合，但對使用者來說，我管你是什麼整合，你給我解決方案就對了，而要提供這些解決方案，就考驗著軟體公司的能耐了。

系統、模組切分：系統架構師
系統、模組interface設計：技術架構師
系統、模組功能設計：系統分析師、系統設計師
系統、模組功能實作：軟體工程師

其實愈抽象層級的角色愈重要，系統架構師有如畫建案藍圖般重要，要蓋幾棟大樓，樓與樓之間要有多少通路相連；而技術架構師則將通路定義出來，是要10米還是20米，要不要透過電扶梯、天橋相連；分析師與設計師則分別去規劃出每棟樓的細部藍圖，接著進入實作，環環相扣，只要一開始想錯了，一體化的解決方案可能會達不到本來的目的，本來透過天橋可以直接相連的，現在還要走平面道路才能跨到另一棟樓，多少喪失了一體化設計的原意，要擔任畫建案藍圖的角色，本身必須要熟知每個系統的特性及應用範圍，才有可能制定一套完善的制度，這樣的人非常的稀少，在講求整合能力的未來會愈來愈重要。