信息化的典型問題
IT在企業中作用無需多言，即使是規模不大的企業，至少也會有財務系統、進銷存和小型MES系統等等。大企業更是如此，IT系統的發展也是紛繁復雜，不僅覆蓋營銷、生產、研發、供應鏈、服務等核心業務領域，還包括人力資源、資產管理、財務、辦公等管理支持的功能。在這個信息化建設鋪天蓋地的大潮中，業務和IT之間的矛盾是一個持久的話題。
這其中有一些典型的問題，比如這樣的場景_
1.系統上線不易，經過策劃開發實施，費了好大勁結果總還是不滿意；
2.系統上線運行感覺還不錯，可是過了兩年就變得怨聲載道；
3.業務部門常抱怨IT是瓶頸，我們要的功能到他們那里就打折扣，能力不足總找各種借口；
4.IT總是很委屈，業務部門要的功能總是不能一次性說清楚，今天提一個明天提一個，系統不是這樣干出來的;
5.系統建設總是補丁摞補丁的方式，最后發現這些系統都成為孤島而不能相互聯通……
這些都是很具有代表性的現實。不過值得慶幸的是，現在越來越多的企業開始明白了一個基本的道理_IT系統的結果是開始于設計的，IT技術本身從來就不是障礙。盡管如此，如何能夠做好這個設計工作，依然是讓很多企業一籌莫展的問題。下面我們就從IT規劃說起。
IT規劃始于業務架構
企業做IT規劃的時候，總是首先要從業務架構出發_近些年企業越來越多的經驗和教訓充分說明了這一點。調查數據表明，國內企業成功上線ERP的大概比例是46_，這還不包括上線之后存在很多問題的情況。
企業IT規劃的路徑_從業務架構，到功能架構，最后到技術架構。
業務架構
業務架構描述的是一個企業的業務結構和關系。包括企業有哪些業務功能模塊、業務域、業務單元構成？企業的價值鏈結構和業務模式是怎樣的？有哪些業務場景，以及描述這些業務場景的結構和邏輯關系。這個過程不需要到細節的操作流程，操作流程是IT系統設計和實施層面的事情。
業務架構是管理和業務人員來完成的工作，不是技術工作。或者說是業務架構的技術，而不是IT技術。業務架構通常并不如想象中的容易，不只需要基于對業務本身系統性的理解，更需要結構化概念思維和模型化表達，這其中還涉及到業務之間的關系、管理之間的關系，以及業務和管理之間的關系。
業務架構是需要團隊來完成的，需要能夠把握頂層整體架構的架構師，還有業務團隊，是多層面、多維度、多業務系統共同工作的結果。
功能架構
功能架構就是在業務架構基礎上，考慮如何用IT系統來實現其中的哪些功能。包括企業IT建設的整體藍圖、架構的原則和標準，還有這些IT系統之間的關系，以及IT系統與人工之間如何協作。
功能架構是業務架構和技術架構之間的橋梁，既要考慮業務的需要，也要考慮IT系統的功能特征。其中，IT系統功能規劃的邊界是一個典型問題。
有時候企業會面臨這樣的選擇_要實現某一個業務模塊的IT化，是開發一個新的系統，還是在現有IT系統中進行功能的擴展？這樣的問題就是功能架構要回答的。如果在現有IT系統基礎上進行功能的擴展，這樣做的結果是不是能夠滿足未來我們對于這個業務模塊的信息化需求？如果只是實現了其中的一部分功能，而更多的功能是通過這種擴展的方式無法實現的，還是需要再開發一個系統。那么也就意味著未來我們可能要面臨一個窘境_擴展功能受限，而重新開發會擔負更高的成本。
從經濟意義上來說，規劃的價值就在于用盡可能小的成本確保預期目標的實現。
如此，功能架構不是一項單純的業務工作，也不是單純的IT工作。業務人員更理解需求，IT人員考慮技術路線，這個過程是需要對話的，是業務和IT共同完成的工作。
技術架構
技術架構就是在功能架構之后，實現這些功能的技術策略。包括基礎設施和系統設計，選擇什么語言、什么框架、什么數據庫，如何部署、如何通信等等。
技術架構是純技術性質的規劃工作，是由IT架構師來完成的，接續才是IT系統開發和實施的具體的工作。
功能架構和技術架構可以是企業IT規劃的整體藍圖，也可以應用于對單個IT系統的規劃和設計。
現在我們把視角從整體的IT規劃拉近到單個系統的開發。業務和IT之間總有解不開的矛盾，主要原因在于業務人員和IT人員之間沒有一個很好的彼此溝通的語言，都是在自己的語境和邏輯中自說自話。
哪里找這樣的語言？答案是流程。
從軟件需求規格說明書說起
這里我們要提到“軟件需求規格說明書”，這是軟件在開發之前需要確認的需求說明文檔，類似于業務和IT人員為軟件開發約定的一個“合同”。這個“合同”需要描述IT系統功能、性能、數據的需求，也要描述開發的目標、過程和標準。
軟件需求規格說明書一方面是業務人員和IT人員對話的語言，另一方面也是IT人員系統開發、測試以及最后驗收的依據，她對于軟件開發的重要性是不言而喻的。
軟件需求規格說明書有不同的格式，包括ISO也給出了參考目錄，但要說明的內容是大體相同的。
軟件需求規格說明書主要內容_
- 引言:主要包括目的、對象、背景、術語定義和參考資料。
- 任務概述:主要包括目標、運行環境、條件和限制。
- 功能需求:主要包括功能描述、流程圖、崗位角色、數據字典、系統接口。
- 性能需求:主要包括數據精確度、時間特性和適應性。
- 運行需求:主要包括用戶界面、硬件接口和故障處理。
- 其他需求:如可實用性、安全保密、可維護性和可移植性等。
在以上列舉的內容中，業務和IT之間主要討論的就是功能需求，而通常的問題也就出在這里。
很多時候，業務向IT提出的功能需求是不夠完整、不夠詳細的，他們也并不一定清楚這樣的需求應該包括哪些要素，以及用什么方式來表達。可能只是粗略的流程圖，甚至只有功能的列表。
企業IT系統的應用有不同的量級，如果需求不夠詳盡，開發一個簡單的系統可能問題還不大，要是系統相對比較復雜那就是災難了。需求越粗糙，IT發揮的空間就越大，結果的偏差也就越大。
需求規格說明書中的功能需求應該表述哪些內容？我們可以用下面這張圖來表述。
她的內容應該包括_
流程圖_系統要運行哪些流程？這些流程不是簡單的邏輯圖，應該是非常詳細的，比我們通常用來描述業務的流程圖還要精細。比如我們描述業務的時候可能并不需要精確的表達一些審批環節的退回路徑，而面對系統我們就必須精確的告訴她要怎么走。從這一點上來說，IT完全沒有人類的聰明。
權限表_系統中有哪些用戶，這些用戶擁有怎樣的權限？這個比較容易理解，必須賦予使用者某些活動的權限，他們才能操作這些系統的流程。
控制矩陣_系統中應該有組織賦予的崗位和角色關系的，就是誰對誰負責，誰是誰的上級，這樣的矩陣可以建立相應的控制關系。舉個例子來說，一個員工請假，系統需要識別他是哪個級別，屬于哪個部門，他的請假要提交給誰。
表單_表單是系統中流轉的信息，就像我們在現實中流程也總是要用到表單一樣，信息通過她們實現傳遞、轉化和累積，她們是流程路徑的縮影。
數據倉庫_輸入的和流轉的信息都可以在系統中儲存起來，我們需要告訴系統記錄和存儲哪些信息，這樣信息存儲是需要有格式和結構的。結構化的數據能夠被很好的應用，就像我們建一個倉庫總是要清楚的分區、建目錄一樣。
報表_業務都是需要管理的，IT系統必須為管理提供支持和服務，這就需要進行數據的統計和報告。必須告訴系統我們需要什么樣的報表，給她輸入相應的算法和公式，她們才會給我們提供需要的結果。報表的設計常常被忽視，因為她們看起來似乎沒有業務本身那么重要，實際這個部分可以為管理提供直接的支持，很能體現管理的智慧。
以上這些內容是需求的核心要素，如果我們能清楚的表述她們，后面的技術本身通常沒有什么障礙。這些要素的獲取是沿著“業務_功能_技術_數據”這條線來思考的，核心的就是流程，因為流程總是要承載這些要素。如果我們能夠把流程梳理清楚，并且匹配這些要素，一切也就豁然開朗。
企業并不總是要自己開發信息系統，很多時候是對成型信息系統的實施和應用。實施這樣的系統就是要比對現有的業務邏輯和成型系統之間匹配的關系，哪些部分是要配置的，哪些是要應用的。
信息化的實質是業務變革
開發或者應用IT系統，不管這個系統是大的還是小的，都可以視作是一種業務模式的變革，差別只是變革的規模不同而已。
像ERP這樣的大型IT系統對于一個企業來說，是一次非常大的變革。通常有一定規模的企業至少要準備一年以上的時間，否則倉促上線就很難能夠成功。首先總是要從業務模式設計和流程梳理開始，最終實現與系統的匹配和平穩運行。
人們說，信息化能夠讓企業管理和業務運營水平上一個臺階，其實我們應該這樣理解，是你的管理和業務運營水平通過設計和變革上了一個臺階，IT只是最后幫助我們將結果固化下來而已。
還有一些比較小的IT系統，涉及到的業務相對簡單，比如OA系統。她們的應用與人工操作也總會形成差異，對于這樣的系統應用我們也是要經過設計的。有時候就是因為信息系統的簡單而我們忽視了設計，最后不是給我們帶來了效率的提升，而卻是相反的結果。
比如有些企業中涉及到會簽的活動，原本應該是一個小組通過溝通的方式來完成的工作，類似于討論和評審，這樣的活動放在IT系統中就失去了信息充分交流的作用，通過會簽完全達不到我們預想的結果。于是現實操作中人們就選擇首先線下交流，然后在信息系統中再各自去會簽，這樣的設計實在是雞肋，不如從前直接線下完成來得實在而且有效率，這樣的變革還是不做的好。
一個從流程思考的需求示例
這是一個企業的案例，他們準備開發采購IT系統。首先要做的就是構建完整的采購業務框架。
在這樣的業務框架中，我們要考慮哪些功能需要在IT系統中實現，同時與其他系統有什么接口，以及其他管理功能之間的輸入輸出關系。系統需要實現的業務功能包括_采購計劃、采購立項、簽訂合同、采購驗收、發起付款、合同變更。需要考慮和PMC系統、倉儲系統、財務系統的接口，需要預算管理、供應商名錄管理功能提供輸入。這是一個在業務架構基礎上的初步思考。
接下來我們描述每一個業務功能的流程圖，這樣的流程圖是全要素的，包括活動、邏輯關系、輸出輸出的信息、活動的角色、應用的表單等等。
以這樣流程圖為基礎我們可以去設計，哪些流程活動需要在IT系統中運行，將這些活動連接起來，我們也就知道了需要哪些信息以及她們傳遞的路徑，還有哪些崗位和角色會參與其中。如此我們可以按圖索驥，把整個系統需要運行的流程活動以及她們的要素都詳盡的表現出來。
一句話_設計越詳盡，實現越簡單。
當然在這個過程中，我們可以去思考對業務模式和現有流程進行變革，去思考各種管理方法的應用和管理需求的滿足，除非你覺得現實已經足夠完美。
通過這樣的方式進行IT需求的設計，相信你的系統不會有令人頭痛的瓶頸，也許IT團隊會給你一個熱情的擁抱。
（《老包講流程第25講、第26講》文字修訂版，本文最早發表于2021年6月，再稿經過內容增補）
