什麼是企業軟件

第1章     企業軟件

1.1     什麼是企業軟件

社會組織的主要形式有以下幾種:web

  1. 政府單位
  2. 企業
  3. 個體戶
  4. 非盈利組織

企業明顯的區別於其餘組織方式,企業通常有銷售、採購、庫存、市場、人力、行政、研發生產等部門,這些部門爲了完成公司的目標有不一樣的職責和業務流程。當企業使用軟件工具來輔助運營公司時,軟件商提供的軟件產品則可稱之爲企業軟件。企業經過軟件來進行公司管理的過程叫企業的信息化。數據庫

維基百科中「企業軟件」有以下定義:json

企業級軟件,也稱企業軟件(Enterprise software)或者企業級應用軟件,指的是支持企業、事業單位或者政府等機構各項業務運做的軟件系統。除了支持機構內部的協同工做以外,企業軟件也支持企業與其供應商、業務夥伴和用戶的協做與協調[1]。微信

企業級軟件能夠按功能劃分爲財務會計、ERP(企業資源規劃)、CRM(客戶關係管理)、SCM(供應鏈管理)、HRM(人力資源管理)、BI(商務智能)、CMS(內容管理系統)和企業通訊工具等。也能夠按行業劃分爲製造業、零售業、醫藥業等解決方案。架構

馬汀·弗勒(Martin Fowler)在其《企業應用架構模式》一書中這樣定義:企業級應用主要負責顯示、操做和存儲大量複雜數據,並對這些數據進行支持和自動化併發

維基百科中有兩點的觀點與本文不一樣:框架

  1. 企業軟件不只僅指企業,也包括政府等機構,本文並無考慮政府等機構,本人認爲維基的觀點也能夠接受。
  2. Martin Flower從技術上進行定義,強調了「大量複雜數據」、「支持和自動化」等關鍵詞,本人的理解這個定義沒有什麼價值,由於其強調的這些關鍵詞模糊不清,不能造成有效的知識。可是須要說明的是,不少技術人員通常會把企業級軟件理解爲功能強大的、穩定的、健壯的面向一個領域的技術組件,本文不認同這種觀點,由於這是從技術角度來定義的。

企業管理者通常對企業管理軟件的指望是歸納來講有以下幾個:socket

編號分佈式

企業指望工具

說明

經常使用軟件或者模塊

1

營銷

藉助互聯網進行品牌的宣傳和推廣,最終達成銷售

CMS、企業門戶網站、商城系統、微博、微信。典型的是企業經過網站或者而購買關鍵詞把流量引入本身網站(商城),推廣本身。

CRM管理系統,用來進行客戶行爲分析指導企業決策,CRM還能夠進行客戶二次營銷。

 

特別說明的是,相對於以下幾點,營銷類軟件是市場是需求最強的,緣由有以下幾點:

  1. 不少企業營銷是最重要的部分,營銷能夠給企業帶來收入。只要有錢其餘的問題重要性就不這麼重要,即便企業管理混亂也可短時間無視。而企業沒有足夠的收入則直接面臨倒閉,管理混亂則不會馬上倒閉。
  2. 通常來講國內企業可以生存下去必須具有着三個條件之一:核心技術、強大的營銷、過硬的資源。從技術上來講,由於技術的積累須要很大的成本,因此國內的企業有核心技術很少;資源也只掌握在部分人手中;若是不具有技術和資源,那麼只能依靠營銷。
  3. 基於第二點,國內市場產能開始過剩,企業沒有能力進行技術上的積累,短時間則更加抓住營銷的救命稻草。
  4. 新技術的變化,致使營銷方式一直在改變。

 

從技術上來講,營銷類產品簡單、通用性強;變化快,美工要求多;以網頁形式展示。

 

2

提升效率

使用軟件工具提升工做效率

使用專業工具通常有比較強的行業特性,好比廣告公司用Photoshop,製造行業使用AutoCAD,建築行業使用計價算量工具。計算機發展到如今,沒有此類的軟件工具,有些行業就無法工做。

本文強調的是與企業管理軟件總體結合的工具,而不是純粹的專業工具,好比電商ERP自己具備的批量打印快遞單功能。

企業使用這些工具的目的本質是爲了提升效率,不是爲了管理。

在中國,這類軟件無償使用居多,用戶沒有付費習慣。

3

管理

使用軟件工具輔助本身企業內部管理

因爲歷史的緣由,管理系統國內通常從兩個角度來作,這一點的區分比較有趣並且很是重要:

1.  基於工做協同的思路,如OA系統、工做流系統、IM、項目管理系統等等,強調工做流程,這種角度與真實的業務更適應,更容易操做。

2.  基於數據的管理的思路,如財務會計、ERP、CRM、SCM、HR等等。

 

基於工做協同和基於數據管理是基於其傾向性而言的,不是說基於工做協同的就不基於數據管理,或者基於數據的就不基於工做協同。總的來講他們未來應該是不進行區分,目前市場上也有兩種結合到一塊兒的產品。

4

BI

使用信息系統的數據做爲企業決策的依據

有時也稱之爲商業智能,基於大數據作的企業決策分析。容易理解,再也不贅述.

 

1.2     當前信息化面臨的核心問題

1.2.1  客戶化

    對於一我的而言,慾望無限而其能力有限,這種主客體上的差距是其痛苦的根源;經濟學的本質則是如何分配資源給有無限慾望的人類。一樣,研發產能有限而客戶軟件需求無限則是管理軟件的主要矛盾,這裏有限產能指的是沒法承擔的成本或者沒法完成的進度要求等。

 

雖然經過高級語言、面向對象、技術組件及平臺、MRP、ERP等的發展,問題獲得必定程度的解決,可是問題仍然存在。目前,一方面軟件從業者經過技術方面的框架或者平臺積累,另外一方面也在管理理論方面有所積累(如MRP和ERP),解決了一些通用的問題,這叫管理軟件的標準化。可是每一個行業和每一個客戶都有本身個性化的要求,解決仍然困難,這種現象本文稱之爲客戶化。因此,如何解決標準化和差別化是企業管理軟件的核心問題。

 

本文嘗試從企業的角度和技術的角度來對差別化進行考察。企業的角度是不一樣的企業主要在所處行業、企業規模、企業文化及企業制度三個方面有所不一樣,詳細狀況參見下表:

 

編號

內容

說明

其餘說明

1

所處行業

金融、傳媒、電信、石油、醫療、建築施工等不一樣的企業所關注業務徹底不一樣,這致使對軟件的要求差異很是大

不一樣的行業體如今不一樣的流程,以及不一樣的行業概念上,行業的概念對應的是不一樣的業務字段和業務規則。

2

企業規模

一個跨國公司和一個30人的小公司,企業管理也是不同,對軟件的要求也有天壤之別。

不一樣的企業規模主要體如今組織機構以及業務流程上。

3

企業文化及企業制度

相同的企業,不一樣的管理者對企業不一樣的管理對軟件的要求也不盡相同。

若是企業信息化程度比較低,則適合軟件簡單一些,較少的改變現有員工工做方式,經過漸進的方式實現信息化,若是企業領導是一個完美主義者,則信息化失敗的概率大大增長。

另外一方面,非軟件從業人員確定會錯誤的評估軟件的複雜度和實施的難度,這是也致使軟件不能成功的重要緣由。

 

    那麼從技術角度來講,客戶化的角度不少,下表按照由大到小的幾回順序介紹了常見的幾種級別的客戶化。

 

 

差別化

內容

常看法決方式

1

物理形態級別

是否基於互聯網

是否支持跨國應用

等等

 

2

技術選型級別

通常要指定的操做系統、指定的開發語言、指定的數據庫等

 

3

業務流程級別

任意新增流程或者改變現有流程

  1. 工做流能夠解決業務不復雜的流程
  2. 複雜的業務流程解決起來有時成本很高,設計好能夠經過業務插入的方式完成

4

系統選項級別

通常在工具選項中來停用啓用某些功能

此種方式比較常見,處理起來容易理解。可是其同其餘級別的擴展很難經過插件的方式體現出來。

5

單據級別

新增長一張單據類型

  1. 簡單的單據能夠經過平臺完成,不須要開發
  2. 複雜的單據

6

字段級別

在現有業務對象上添加字段

在現有的字段上添加一些邏輯

  1. 經過實體模型和界面模型通常能夠解決
  2. 複雜邏輯經過實施和二次開發解決

7

界面級別

改變界面的佈局和樣式

 

 

1.2.2  複用和擴展

上文已經得出結論客戶化是企業軟件的核心問題,這是從產品功能的角度來講的。若是從技術角度來講,客戶化其實就是軟件的複用和擴展,因此也能夠說複用和擴展是企業軟件的核心問題。下面是本關於複用和擴展的幾個觀點:

  1. 複用和擴展是統一的,有了複用纔有可能擴展,由於擴展才能複用
  2. 基於可預見的需求的擴展是有意義的擴展,不然是過分設計
  3. 在敏捷裏下面的幾個原則是擴展相關的,開閉原則、里氏代換原則、依賴倒轉原則、接口隔離原則、組合/聚合複用原則、迪米特法則
  4. 如今的系統技術上通常經過接口、IOC容器 、插件系統來進行擴展。插件是比較系統的一種方式,這種方式愈來愈被普及和承認。

複用和擴展也能夠當作是企業軟件客戶化的解決方法,可是由於這種方式理解起來比較簡單,因此能夠認爲他是一種現象。如何進行復用和擴展的具體技術手段則是解決方法中須要重點關注的。

複用和擴展的文章和著做較多,本文再也不展開贅述。

1.3     企業信息化解決之道

1.3.1  分析設計與技術架構

本人認爲從事企業軟件的技術從業者須要兩個能力,分別是分析設計與技術架構,這兩點應該囊括一個企業軟件開發者的全部能力;不少軟件公司研發通常分紅兩個部分產品研發部(或者項目開發部)和平臺部也是這種分類的方法。分析設計和技術架構的能力對於一個技術人員來講這兩種能力是一體的。

 

分析設計是針對客戶指定的需求,經過分析建模大腦的思惟,最終以技術化的語言表達出來,成果就是其設計文檔或者代碼/僞代碼,設計成果的標準有三個:無歧義、不重複、無遺漏;這三個標準是針對於設計成果的讀者的,由於讀者不一樣,因此設計的成果可能會不一樣的,有一種說法叫設計是基於一種認同,與此意思是相近的。

 

分析設計通常針對於特定的問題,這些問題通常都是繁瑣且複雜的,因此這些問題只有當事人關心,在軟件技術社區中其餘人員對其問題並不關心,因此通常分析設計的交流都是分析設計方法論的交流,好比UML就是一種分析設計的方法論,你們會一塊兒討論UML怎麼用。本人把分析設計的過程總結爲以下的一段話:

企業軟件的分析與設計是針對需求定義的問題域進行樹狀結構的合理分解(本文稱之爲分而治之的方法),分而治之的目的(也是分析設計的目的)是找到最小粒度的代碼單位,容易理解的代碼就是最小粒度代碼單位。

 

依據上面內容下能夠得出且須要強調的以下幾種觀點:

1, 設計的思惟方式或者設計結果(代碼組織或者設計文檔組織)和需求是一致的。也就是說在理解需求的狀況下,若是有技術經驗是很容易理解代碼的,或者基於代碼就能夠容易的瞭解需求。若是設計組織和需求文檔的思惟方式的不一致,極有多是需求的不合理或者設計的不合理。

2, 離開具體的需求就不存在設計,換言之離開具體的需求談設計的好與壞是無心義的。

3, 不瞭解需求的評審是無心義的。

4, 設計分析過程是概括的過程,體現的結果是層層展開的邏輯分樹。只能是先具體後抽象的過程,這要求設計必須找到代碼的最小邏輯單位,走遍全部的邏輯路徑。

5, 代碼的多與少不是設計好與壞的關鍵因素,基於需求是否進行合理的分解,是否找到了最小粒度的代碼單位纔是設計好與壞的最主要因素。

6, 設計是須有很強的代碼經驗。軟件設計就是用程序語言描述問題域的過程,這和用進行文字創做有殊途同歸之妙,他們都是人的思惟經過語言的對別人的表達。

7, 分而治之邏輯樹上每一個節點都對應一個完整的概念,每一個概念的命名是第一性和相當重要的(且和儘可能和需求的叫法一致),他是設計和開發溝通的基礎。設計的思惟比需求的思惟要細密,因此概念也會比需求多。概念的建立不要多也不要少。

8, 設計已經找到了最小粒度的代碼單位,其走遍了全部問題域的邏輯路徑,複用、擴展、重構等是水到渠成的,體現代碼之美。

9, 基於可預見需求的擴展才是有意義的擴展,不然是過分設計。

10, 分而治之方法的設計是概括的過程,是一個迭代(否認之否認)的螺旋式的過程(重構)。

 

分析設計是一種實用的方法論,也是一種形而上的美的藝術,由於其藝術性因此仁者見仁,智者見智,觀點很難統一。本人會單開「分析設計」系列詳細論述上文觀點,此文再也不贅述。

 

技術架構和分析設計的區別主要體如今下文的企業軟件研發成熟度分析中(企業軟件研發七階段),技術架構主要作第四階段即技術平臺的工做,業務分析主要作業務平臺的工做。這種區別是就其傾向性而言的,若是說這兩種能力就是同一種能力也是能說得通的。

 

本文的全部系列則都是說都是技術架構,技術架構和分析設計相比,技術架構通常都涉及通用的技術點,因此有具體的可視化的成果,更容易被理解和認同。技術架構關心的問題有持久層、MVC、分佈式、事務、序列化等等。從另一個角度來講,技術架構是技術人員立足於若干需求場景所作的抽象工做的分析設計,因此技術架構也算是一種分析設計。

1.3.2  企業軟件研發成熟度分析

企業軟件研發成熟度分析本人於2010年總結的國內企業軟件七種軟件研發的模式,這其中模式是由低到高的不一樣階段,因此也能夠稱之爲企業軟件研發七階段。

 

編碼

階段

特徵

達到的條件

1

硬編碼

直接使用IDE提供的工具進行代碼的編寫,不多考慮使用第三方的組件,或者本身封裝正規的組件。一切代碼只要能實現客戶需求便可,不肯意或不懂得多作一些從技術上有益於產品的工做。

 

2

部分組件

1,開始需找第三方的組件,包括界面控件、持久層、配置組件

2,本身寫一些經常使用的組件

3,可能使用一些第三方工具,如PD等進行快速的代碼生成

4,有初步的分層思想

 

3

系統框架

本身寫或者使用第三方的組件,特色是框架的全面性,在每一個主要的技術點都有系統框架的支撐

1,團隊技術負責人對技術熱愛,但願寫出高質量的代碼

1,會對比分析各類部署方式下的開發模式包括,會分析前段的各類展示方式(Silverlight/WinForm/WPF/HTML4/HTM5),會分析分佈式的各類組件(webservice/json/remoting/wcf/socket),分析各類持久層框架,等等

 

2,熟悉常見的業務展示形式,從技術角度進行整理,包括單據、列表、報表、選項、工做流、等等

 

4

技術平臺

(業務基礎軟件平臺)

1,技術平臺自己即爲產品

2,在系統框架基礎之上,提供友好穩定的工具維護框架下的元數據,並提供二次開發接口和工具。

 

3,提供基礎業務功能,包括權限管理、組織機構管理、單據編碼管理、枚舉管理、選項管理、工做臺界面等等

1,被動使用平臺:業務自己複雜,不使用技術平臺,致使研發成本過高

2,主動使用平臺:技術負責人願意在系統框架之上提供優良的開發工具讓業務開發人員進行元數據的維護。

   技術負責人願意對實施人員,或者有二次開發能力的客戶提供接口和平臺開發工具

3,產品經理有明確的文檔要求客戶要自定義產品行爲的

5

業務平臺

1,在技術平臺之上,業務按照領域對象爲粒度,每一個領域對象能夠單獨存在,能夠和其餘領域對象組合成新的的業務,能夠擴展功能,能夠二次開發覆蓋原有的功能

2,在第一點的基礎之上,能夠基於流程調整領域對象的流程關係

1,領域的整體設計師指望作出結構優良的產品

2,產品經理對業務的分析抽象比較合理

6

軟件生命週期管理

1,技術平臺和業務平臺是進行產品的研發,本階段是爲這兩個階段提供項目管理工具,此工具能夠是本身研發的,也能夠是繼承第三方產品到本身的產品中。

2,功能包括源代碼管理、需求管理、BUG管理、升級和補丁管理等

1,研發負責人願意使用科學的管理手段進行項目管理

2,研發負責人願意在本身的管理軟件平臺上擴展出項目管理的功能

7

軟件生態環境

1,前六個階段是在產品廠商的角度來看的,此節點是站在整個社會的角度來看的。

2,生態環境容許第三方開發人員和廠商在現有的業務平臺上擴展業務功能。也容許在技術平臺上構建本身的特殊的業務。典型的例子有Eclipse和淘寶電商平臺。

3,產品廠商和第三方互惠互利,合做雙贏共同達成一種生態圈。

1,技術團隊、業務團隊、銷售團隊三者目標都有志向,目標遠大

2,產品真的能爲客戶帶來價值,物美價廉

3,平臺能爲第三方的開發人員、銷售人員帶來利益

4,團隊有卓越的業務能力和推廣能力

 

1.3.3  企業業務基礎平臺

企業業務基礎軟件平臺,是這幾年逐漸被承認的一種叫法,不少人叫技術平臺或者平臺,都不太準確。業務基礎平臺是上文「企業軟件研發成熟度分析」第四個階段,他是在一個語言(如.NET或者JAVA)平臺基礎之上作的一個能夠快速最終產品的平臺。下圖介紹其同應用軟件、軟件開發平臺、操做系統在概念上的區別:

 

    企業業務基礎平臺自己對客戶不產生直接價值,他對軟件廠商有價值,能夠幫助研發人員最低成本的構建面向最終客戶的軟件產品。

   

國外並無業務基礎軟件平臺的概念,這也算是中國特點,緣由是中國客戶化的要求太多了,致使軟件商想辦法提升軟件自身的複用能力和實施能力。還有一個緣由是國內的環境下,沒有資源作更深的技術,因此大部分的精力都在作管理軟件,天然的也就都在作業務基礎平臺。

 

本文認爲企業基礎業務平臺是解決客戶化的一個重要的方式,首先,平臺自己提供了通用的基礎功能如組織、權限、工做流等等,這些功能研發成本是很高的;其次,平臺做爲開發人員和實施人員的工具,從技術手段上能夠在很大程度上不修改代碼的狀況下完成客戶的一些個性需求;最後,平臺自己也是一個框架,他完成了一些大量的基礎性的技術工做,如分佈式調用、持久化、併發、引用檢查等功能,這些基礎的技術工做,對技術的要求比較高。

 

有了企業基礎業務平臺,並不能解決全部客戶化的需求,由於客戶的需求是無限的,能解決客戶化需求是有其範圍的,這個範圍是由平臺設計人員的能力決定的,也就是說,平臺設計人員的能力決定了解決客戶化能力。

 

企業軟件七階段的第五階段是企業業務平臺,相對於業務平臺來講,基礎業務平臺稱之爲技術平臺是有必定道理的。業務平臺是提供面向最終客戶的解決管理業務的產品。一個有意思的話題是,從研發成本上考慮,技術平臺和業務平臺的研發投入比重都各佔多少呢?答案是由技術平臺的功能以及業務的客戶化程度決定的,通常來講,客戶化程度越低的產品,技術平臺比例越高,最大的場景是,不須要業務開發代碼,技術平臺可直接配置知足客戶需求的產品。本人所在的公司所研發的很正規的ERP產品和技術平臺產品的代碼量基本是對半。對於國內某些平臺所聲稱的不需編寫代碼即開發產品是幼稚好笑的。

 

繼續考察技術平臺和業務平臺的關係還能夠得出結論,首先技術平臺爲業務平臺提供框架和基礎技術工做,這些工做不只僅是減小了業務開發的工做量,更大的價值是,技術平臺的框架和基礎類庫自己就是一個研發的規範,這比制定研發規範要實際和有效的多;另外一方面,技術平臺提供了工具,提升工做效率,進行工做糾錯,讓業務開發人員從乏味的基礎工做中解脫出來,如業務人員作一張銷售訂單的表單界面,有平臺工具的支持,通常須要20分鐘,可是若是硬編碼,可能須要1-3天。

 

本文特別感謝東莞許勝平的建議和校對工做。

相關文章
相關標籤/搜索