如何解決一個具體的企業信息化問題呢？怎麼樣給自己的公司或者客戶設計一個企業應用，服務目標用戶呢？本篇文章提供了四種解決
企業IT問題的基本途徑，爲你做出解答。
解決企業信息化問題有幾個完全不同的途徑，並非每個途徑都需要從頭開始
設計企業應用，使用一些現成的、實用的方案會讓你事半功倍，減少無謂的設計和開發工作，提升交付的質量；有一些場景則可能需要從零開始，獨立建立架構，進行
企業設計開發;還有一些需求場景可以混合使用多種方案，搭建合適的橋樑，從而滿足需求。
我們可以把滿足
企業IT需求的基本途徑概括爲如下幾種:
按需原生開發；
使用和對接 SaaS 產品；
混合和實用模式。
1. 按需原生開發
按需原生開發是指企業不得不根據應用要解決的問題，進行完整的產品架構設計和應用設計，利用某一種集成開發環境和編程語言完成所有的業務前後端開發。
當然，在這種情況下，企業也需要獨立
管理軟件運行所需要的IT基礎設施。
這種途徑代價很高，需要依賴擁有多種技能的設計開發人員，交付週期長，而且需要建立專門的團隊來跟進應用的長期迭代。雖然應用在開發完成後會逐步完善和穩定下來，但這個過程通常需要幾個月甚至幾年的時間。
在實踐中，如果沒有穩定的設計研發團隊長期跟進某套IT系統，它的可用性便會隨着時間的推移而降低，因爲在實際環境中，很少有業務是一成不變的。
另外，隨着應用設計水平的提升，客戶的要求也會在無形中提升，因此這也對應用的迭代升級提出了要求。就像我們現在使用五年前設計開發的產品，總是覺得不夠好用，哪怕這套系統在當時已經達到了很高的水平。
企業在決定是否需要進行原生開發時，可以根據以下條件判斷：
1. 應用本身解決了企業核心業務流程的高價值問題，而不是周邊性質的小問題，否則帶來的產出很可能抵不過投入。比如一個金融服務企業可能需要原生開發客戶賬務處理和風險控制應用，但對於一般的招聘和人事管理業務可能更適合選擇既有的產品方案或者基於平臺開發產品方案。
2. 應用要解決的問題和所採用的問題解決模式有明顯的獨特性，而不是那種很多企業已經解決了的問題，爲後者進行原生開發很可能是在重複造輪子。
3. 除了以上兩個明顯特徵，對於特定的問題來說，還可以檢驗市場上是否有主流的
軟件產品已經可以很好地解決之。
通常，使用已有的產品方案必然會犧牲一定的靈活性和個性，這時就需要權衡利弊，做出合理的決策。
如果利弊相當，則一般應該優先從已有的產品方案開始，通過實際的使用進行評估。即便將來依然需要自建應用，使用已有產品的過程也可以幫我們降低試錯成本。
按需原生開發的最小化人員組合：
要開發出高質量的企業應用，每個環節都很重要。儘管也有極少數的全能型人才，但我們依然青睞專業化的分工，因爲專注聚焦能夠提高工作的質量和效率。
一個完善的企業應用設計團隊應該儘量包含以下專業成員和角色：
業務分析師：負責從產品設計的角度搜集、分析和歸納業務需求，將其撰寫爲業務需求文檔（BRD），並保證其始終反映了需求的變更。業務需求文檔不需要過於技術化，也必不涉及實現細節，但它要將 IT 應用待解決的業務問題、背景、價值和風險描述得非常清晰。它是業務需求方和應用開發方之間的橋樑。
產品經理：負責將業務需求文檔轉換爲產品需求文檔（PRD），將需求按照某種邏輯進行橫向的模塊拆分，並按照實現步驟進行縱向拆分(通過多個迭代版本依次實現)。PRD有更加規範的組成部分和格式要求，在本書後面的章節中會提供更多的PRD局部範例。
架構師：如果涉及非常複雜的數據結構，應當由專門的
軟件架構師來負責數據結構和業務邏輯的設計。他要負責設計應用所對應的數據實體關係圖（Entity Relationship Diagram）和流程圖。因爲數據結構涉及更多的
軟件技術背景，所以在實際分工中，也可能是開發團隊成員來承擔架構師的工作。
前端(交互)設計師：根據定義好的PRD（產品需求文檔）繪製產品前端界面設計稿，並在其中填充範例數據。根據實際需要，設計稿可能是框線圖，也可能是高保真的靜態稿，甚至有時需要用專門的
軟件製作可以交互的演示稿。企業應用通常比較複雜，交互環節衆多，所以在很多情況下，產品團隊會選擇投入產出比較高的框線圖模式。如果設計團隊擁有完備的交互範式庫，那麼這個設計環節將會順利很多。
因爲本文聚焦於企業應用的設計過程，所以不便對開發、測試和運維流程展開介紹。但是我們應該對自建一個完整企業應用的複雜度有所預估。
即使完成了獨立的產品設計，後面還要有後端工程師、前端工程師、測試工程師、運維工程師等多個專業崗位來保證它的高質量交付。
一個完全自建、按需原生開發的企業應用是非常昂貴的，因此在選擇這個途徑之前需要慎重衡量投入成本和產出。
2. 使用和對接 SaaS 產品
解決企業IT問題的第二個途徑是使用現有元的
軟件產品，尤其是按需使用的SaaS模式軟件。
對於年營收在五億元人民幣以內，人數在1000人以下的中小型企業，選擇現有
軟件產品是主流方案。
爲了找到滿意的SaaS產品，企業首先需要明確自己的問題所對應的門類。
如果你需要滿足一個具體的企業信息化需求，不妨先看看是否有完美匹配的市場化的成熟產品。
比如，某企業希望解決採購過程中供應商管理的分級流程問題、貨物驗收和付款流程的有序性問題、報價蒐集規範化問題以及招標過程自動化問題，與第1章的內容對照，會發現這些問題幾乎都對應了現代
企業管理軟件的某個門類，屬於運營和財務管理領域的交集。
現成的SaaS
軟件產品有顯而易見的好處，那就是開箱即用。客戶無須進行煩冗的定製開發和IT部署，也不需要詳細撰寫自己的需求說明書，直接開通雲端賬號就能夠開始使用(對於複雜的企業應用，用戶培訓可能是必不可少的)。但是它也有顯而易見的缺點——作爲
通用軟件，它無法迎合每個客戶的需求。
這時就需要用戶企業做出權衡，SaaS軟件產品無法滿足的那些需求是不是必不可少的?如果無法迴避，是否可以通過API來進行局部的擴展開發，而不是完全重新設計？
一般而言，SaaS
軟件產品都可以提供完善的 API，而且SaaS
軟件自身的特性組合也會根據客戶的實際需求進行增加。所以，理論上來說，用戶企業的共同需求很快會得到廠商的重視，並被加入升級版本的開發計劃中。
3. 基於開源軟件和平臺開發
基於某個比較成熟的
軟件產品開源軟件進行
軟件定製開發（行業俗稱“二次開發”）是一種比較折中的方式，它在保持靈活度的同時控制了開發成本。
除了傳統意義上的
開源軟件，中間件和雲計算時代出現的PaaS模式也都能起到類似的作用。它們旨在幫助企業應用開發者降低開發成本，提高交付速度。
在企業應用領域，比較知名的開源產品如下表所示：
企業應用領域的開源商業模式和其他領域的開源經典模式略有不同，並非所有的開源廠商都會免費提供產品，也就是說，開源不等於免費，商業用戶在獲得可修改的源代碼的同時依然有義務支付授權費用。
雖然
開源軟件能夠節省設計和開發的時間，但選擇任何一個開源平臺都需要設計與開發人員對這個平臺充分熟悉。而且，任何一個開發平臺都不可能提供完全自由的設計空間，應用的實現受制於開源軟件的框架和特性基礎。
這也是爲什麼大部分開源產品構築的應用都具有雷同的界面和功能。對於部分追求效率和可靠性的企業應用開發者來說，這未嘗不是好事。
在某些企業應用領域，比如BPM（業務流程管理）和BI（商業智能），基於某個平臺進行開發恐怕是不可避免的，因爲很少有企業願意從頭構築這些應用的基礎數據結構和邏輯，它們實在是過於複雜了。而且，隨着商業自動化、智能化的要求越來越高，幾乎所有的複雜企業應用門類都有專業化分工的需求。
在
商業軟件世界裏，雖然廠商不提供源代碼，也不能通過修改源代碼進行二次開發，但客戶依然可以通過自定義數據、自定義流程和自定義規則等用戶數據來搭建滿足自己需求的具體應用。所以，在選擇企業應用產品的時候，到底是選擇一個應用，還是選擇一個應用開發平臺，有時候界限是模糊的。
4. 混合和實用模式
除了以上介紹的這三種途徑，企業也可以綜合使用這三種方式來滿足自己的IT需求，這是一種非常務實的做法。
即便像阿里巴巴這樣的巨型企業，也不可能完全獨立開發所有的應用，當然更不可能通過購買現有的
軟件產品來滿足自己的全部需求。
在使用混合模式時，企業集成門戶（EA）和單點登錄（SSO）是最常使用的 IT 框架，因爲用戶當然不願意在使用混合解決方案的過程中出現混亂，員工也不可能通過多個孤立的賬號來使用多個系統。而且，企業希望這些組合起來的應用最終能夠被準確地分發、授權和收回。當然，在選擇這些起到整合IT應用作用的系統時，也要決定是進行獨立開發還是使用現有平臺。
