上篇談到自己程式設計師成長之經歷，也大致談到了EOM來龍去脈，那什麼是EOM呢？

我們發現企業所有活動都可以歸結於企業經營，EOM就是從企業經營這個源頭著手，對經濟生活中的大量企業經營行為進行抽象，並用模型的方式來定義企業經營。（EOM並不僅僅針對企業資訊化，它還在經濟學、企業管理學等領域有其重要的應用，這裡就不再涉及了）

EOM是將指企業或企業經營定義為：企業員工利用企業資源設計出產品（服務），通過業務流程將產品（服務）生產出來，並銷售給企業客戶，收回銷售款項，並向客戶提供售後服務，以及企業管理者對此進行全過程管理的活動。其中企業資源、企業客戶、企業員工、企業產品或服務、企業業務、企業財務 、企業管理等七大要素是EOM的核心。

EOM示意圖：

很多程式設計師一定會說：我只管編我的程式，我管企業經營幹什麼呀！企業經營和我有什麼關係呀？哥們兒搞的是技術，不是業務，不是管理。

的確，企業經營和哥們沒有直接的關係，但是哥們所編的程式卻是和企業資訊化產物。而企業資訊化是企業經營的一個部分，如果沒有企業經營，沒有企業資訊化，程式設計師可能就會失去工作。從這個道理上來說，程式設計師和企業經營還是有關係的。

程式設計師-〉程式-〉企業資訊化-〉企業經營。

這是一個從下往上的一種關係。

有了EOM，我們可以從企業經營的源頭對企業資訊化進行科學的規劃，可以對現有的企業資訊化進行評判，進而對系統、軟體、程式、程式設計師進行規劃和評判。我們依據EOM理論提出了EOMS的構架：

上面說的可能太理論了，還是舉一個例子來說明現行做法和EOM之間的差異。

假設企業A開展資訊化需要一個報表系統,這個系統上線之後，可以產生統計報表，減輕員工的手工勞動，實現報表生成、管理、瀏覽的自動化，供管理者使用，提高企業管理水平和效率。

現行做法：企業A提出報表系統的需求，由軟體公司組織程式設計師進行需求分析和開發，開發完成後，系統投產執行，軟體公司獲得開發費用50萬，專案結束。

EOM做法：企業A首先應該按EOM建立企業資訊化總體構架，然後針對報表的需求，去尋找EOMS構架中的MIS中的通用系統或專用系統（假定市場已經可提供出EOMS下的各中通用系統和專用系統），併購買，然後通過引數化配置實現系統的客戶化。實現了企業A關於報表系統的需求。

兩者相同之處：都實現了報表系統功能。

不同之處：

1、 需求

1） 現行的報表系統開發是需求驅動，需求由企業A自身提出，需求水平高低，取決於需求提出者的業務水平和需求提出者所站的層次，而需求提出者很難是行業中最佳的，所佔的層次往往限於所在部門的層次，很難站在整個企業層次，更不用說站在行業層次了，所以需求存在天然的缺憾。這種缺憾會導致需求不明、需求調整頻繁、需求不斷升級的情況出現。

2） EOM是站在企業經營的高度來審視企業資訊化的，而且它通過模型的方式抽象出企業經營概念，因此EOM能概括企業各種經營活動。而依據EOM建立的EOMS必然能夠滿足企業資訊化的要求。其中的構架、平臺、通用系統、專用系統的設定都能夠滿足企業經營資訊化的要求。所以，企業A提出的報表系統的需求，一定能在EOMS找到相應的解決方案。大家要注意的是EOMS中的報表系統的需求，並不是來源於企業A，而是來源於EOM理論，以及現有企業資訊化的成功經驗。因此，需求具有理論的依據，更具有科學性和先進性。

2、 資訊化整體構架

1） 現行做法：就係統而系統，沒有構架之說。企業系統開發由需求驅動，容易造成重複建設和交叉建設。

2） EOM做法：將所有系統都放在企業資訊化統一的構架之中。系統開發處於一個有序的管理之下。系統無重複開發，功能和資訊能夠實現共享。

3、 系統來源

1） 現行的報表系統來自於定製開發。

2） EOM的報表系統來自於EOMS的通用系統和專用系統。

4、 效果

1） 需求滿足度

（1）現行方式需求滿足度相對比較緊密，體現了需求當前的滿足度。時間一長，需求將發生變化，系統滿足度將會降低。

（2）EOM不但能滿足現有的需求，企業A沒有考慮到的需求都被一併滿足，因此EOM還對未來需求，以及同行業的需求都進行了考慮，滿足度更加廣泛。

2） 軟體質量

（1）由於定製開發軟體質量取決於該軟體公司的技術實力和程式設計師的技術水平，而由於需求質量不高，開發時間短，軟體公司技術一般只能處於平均水平，程式設計師只管編成了事，因此軟體質量基本上處於一個功能實現，執行不出錯這種水平，其內在的軟體構架、相容性、可擴充套件性、效率、容錯、可維護性等都很少涉及。

（2）EOM方式中，由於其需求有EOM理論的支援，需求從抽象到具體反覆完善，採用的通用系統和專用系統開發方式。軟體不但能實現功能，而且軟體質量各個方面都可以得到最大的提高，它對技術要求更高，和定製軟體不可同日而語。

3） 程式設計師

（1）定製軟體的開發人員要求相對要低，只要按需求編出來就行了，程式設計師什麼都能編，不關注系統的業務。

（2）EOM軟體的對開發人員要求相對要高，其程式設計的水平要求比較高，程式設計師不但在某個技術領域有專長，而且要專業於特定的業務。

4） 價值

（1）開發費用50萬。定製軟體的價值，一般等於一個軟體的開發費用。

好一點的軟體公司通過複用系統來增加系統的市場價值。例如，一個報表系統複用個數為10，單個系統價格為30萬（一般複用價格要低於開發價格），則系統的市場價值為300萬。

要指出的是，由於系統需求天然的缺憾和系統技術限制，系統的複用個數往往很少，大都在1位數到2位數之間。

（2）EOM通用系統或專用系統從理論上來說開發費用相對定製軟體要高，主要是由於程式設計師價格高，開發週期長。例如，定製軟體開發費用為50萬，EOM開發費用要200萬。假定系統價格為10萬，由於是通用軟體其可銷售的使用者數可能達到3位數甚至4位數，所以市場價值巨大。

現行思路：需求提出-〉開發-〉應用系統-〉企業資訊化-〉企業經營

 EOM思路：企業經營-〉EOM-〉EOM的企業資訊化-〉企業資訊化總體構架-〉通用系統-〉需求滿足。

也許這些還是太理論和太抽象了，可能會把程式設計師給搞糊塗了。我還是用通俗的話說EOM意義吧：

1、 EOM就是想建立各個企業資訊化統一的構架和規劃。（注意不是一個企業，而是全部企業）

2、 EOM是建立這個構架和規劃下各系統的理論基礎,解決了企業資訊化應該做哪些系統的問題，也就說解決了程式設計師應該開發哪些系統的問題（現在程式設計師只知道需求是什麼就做什麼）。

3、 EOM下的各個系統基本上是通用系統和專用系統，不同企業的差異通過引數和介面技術來解決。

4、 程式設計師編制通用系統和專用系統，可以降低企業資訊化成本，可以大大提高系統市場價值，可以提高自身的市場價值，避免“IT農民工”的尷尬，可以實現程式設計師的夢想。

也許有人說EOM想法很好，但是懷疑EOM現實的可能性。EOM真的能解決企業資訊化中的各種問題嗎？EOM真的能給程式設計師帶來新的機遇嗎？如果能帶來，程式設計師如何抓住這個機遇？

這些問題我會將在以後給與展開說明。

如果想進一步瞭解EOM情況可以看看我的部落格《關於EOM（Enterprise Operating Model）企業經營模型》1-13。（這些內容雖然是3年前所寫，但是其核心思想沒有改變。要指出的是看完這些文章是需要毅力的，有機會我會寫出更簡練EOM簡介來）