今天準備談下IT規劃咨詢的核心方法論和思考邏輯。在這篇文章我不會詳細的去談目前主流的企業架構方法論理論架構和内容。而是根據多年IT咨詢實踐，将一些關鍵邏輯點和你分析。
為什麼要談核心IT規劃和咨詢邏輯？
可以毫不客氣的講，大部分的做IT規劃咨詢的人是不具備進行全局架構規劃咨詢能力的，這個一方面是需要你有大量業務和技術雙領域的實踐經驗積累，一方面是需要你真正做過大型的咨詢規劃項目并在這個過程中将實踐内容，各個架構之間輸出關系想清楚。
系統學習下類似TOGAF課程當然有用，但是這不代表你具備了咨詢規劃能力。
理論可以指導實踐，但是沒有通過自我實踐證悟的理論沒有價值。
很多IT顧問完全叫PPT顧問都不為過，完全拿着已有的咨詢規劃模闆到處套内容。如果你本身做同一垂直行業，比如拿着某家電制造行業的規劃輸出去給另外一家做咨詢。這種場景下基本還能夠像模像樣的的輸出一個規劃報告。
但是生搬硬套最大問題就在于，你即使有了輸出結果，你也無法自己詳細論證清楚這個結果如何分析得來的，即無法實作自我論證。
類似的場景，我們可以看下講課和教育訓練，很多人能力強但是怕講課，即雖然這類人可以快速的輸出結果，但是具體是如何分析和解決問題的過程，這個确出來沒有考慮過系統化。是以這類人本身能力也很難做到很好的知識分享和轉移。
比如我們常說的架構規劃裡面這個業務架構圖如何一步步形成的？這些接口你是通過什麼方法一步步的分析識别出來的。這些問題大部分人無法清晰回答。即使對于TOGAF，我們也很少從官方材料裡面看到類似業務架構，資料架構，應用架構和技術架構之間的内在邏輯關聯在哪裡。
IT規劃涉及到咨詢方法論、流程管理和分析、資訊架構、應用系統分析和設計、技術架構、項目管理和實施等衆多方面的内容。從企業戰略到業務目标，從業務目标到IT目标，從IT目标到應用藍圖，從應用藍圖到分階段實施落地，任何一個步驟的脫節将導緻規劃内容無法落地。
再完美的規劃和架構，如果脫離企業業務目标，都不能帶來企業業務價值的提升。此外，IT規劃之難，不在于IT本身，而在于流程；不在于技術本身，而在于業務。
業務驅動IT是核心
對于IT規劃，遵循的思路主要是：從業務到技術，從流程到IT，圍繞價值鍊分析和優化的核心模型往前驅動。核心過程包括現狀分析、差距分析、目标提出、藍圖規劃、實施規劃等幾個關鍵步驟。
現狀分析包括業務現狀和IT現狀，根據企業戰略提出業務目标和發展規劃，分析現狀和目标之間的差距提出和整理問題集（定義IT建設目标），根據差距和問題給出規劃藍圖，根據目标和問題分解到的子目标和子問題以及藍圖規劃内容，多元度評估和确定後續的實施規劃，定義IT系統建設實施的優先級。
IT規劃始終圍繞業務和IT兩條線展開和協同
從以上的描述可以看出，整個IT規劃始終圍繞業務和IT兩條主線，業務包括了業務流程，業務資料，崗位組織和角色，業務管控體系；而IT包括了資料架構，應用架構體，技術架構和平台，基礎設施建設。業務驅動IT，端到端業務流程最終落地到應用系統的功能上，業務資料最終映射到資料模型并沉澱到資料庫中。
各類架構标準規範體系和最佳實踐是關鍵輸入
随着各種思路的不斷融合，IT規劃核心指導思想應該轉化為企業架構層面。
企業架構的提出，主要是為了解決業務和IT“兩層皮”的問題，企業架構整個方法應該融入到整個IT規劃思想中。此外，核心業務模型和業績标準作為核心指導思想，雖然有裁剪，但是必須參考，如供應鍊SCOR模型，産品研發IPD方法論，項目管理PMBOK體系，戰略和人力資源的平衡記分卡，CRM的4P和4C，财務域的核心模型等。
針對不同行業可能又有不同行業的業務标準和模型，如電信行業的eTom業務模型等。
與此同時，在前面基礎上再融入雲計算和SOA的核心思想，它将很好的解決我們多年前IT規劃經驗裡的多個豎井式IT系統的集中化和協同化的問題。若現在規劃仍走以前老路是不妥當的。那麼，今天規劃重點在開始之初就應該考慮集中化和協同的問題，将SOA思想融入到IT規劃當中。當今的資訊化規劃，要務必避免出現IT重複建設和資訊孤島，流程斷點和業務無法協同的局面。
中台和微服務發展趨勢下，原有規劃方法是否調整？
可以很明确的講在新的中台和微服務發展下，原來的企業架構相關方法和内容必然做出調整。比如在我最近中台規劃思考裡面提出了業務架構和應用架構合并，基于SOA思想增加中台+服務+前台的分層邏輯規劃，單獨增加服務架構規劃，在資料架構規劃中增加資料庫拆分規劃等。
以上内容後續我會專門寫文章來進一步詳細說明。
現狀分析的核心思路是把戰略目标、業務目标調研清楚，如果客戶不清楚我們可以給出參考目标；其次是把實際的現狀了解清楚，如客戶現狀流程、IT支撐現狀；最後是将潛在問題識别清楚：一是在目前目标和目前現狀被識别後客戶意識到的問題，二是在我們提出參考目标和業界實踐下，客戶意識到潛在存在的問題。
對于整個調研仍然要展現業務驅動IT，從業務流程和IT系統兩個方面入手，但是最終兩個部分内容不能散，在調研階段還需要完成目前的IT系統是如何支撐現有業務的分析。
一個完整的調研階段流程邏輯如下：
業務流程和現狀分析
業務現狀分析重點在于業務流程和業務資料上，建議采取自頂向下逐層分解的方法，找到關鍵的幾個端到端流程為主線進行逐層分解，分解時抛開業務部門的隔離，IT系統的限制，進行跨業務域的流程分析和梳理。
在流程分析和梳理的過程中進一步分析子流程和活動，業務元件和資料，跨業務域的協同和互動等一系列問題。業務分解的方法可以參考價值鍊分析方法，業務模型可以參考針對各個業務域的一些标準業務參考架構和模型，如供應鍊的SCOR模型，電信的etom模型，研發領域的IPD和PACE方法，CMMI成熟度模型，項目管理知識體系，營銷和客戶關系管理模型，财務域标準模型等。
IT現狀調研
IT現狀包括現有的IT應用系統現狀和功能架構，IT基礎設施架構現狀，IT系統對業務現狀的支撐情況分析等。重點的是理清業務和IT的關系，IT對業務的支撐度。現狀分析的目的是為提出後續業務目标和IT系統規劃建設目标打基礎，明确了建設目标才能夠真正為業務服務，展現業務價值。
調研完成後的輸出内容覆寫四個方面
在調研完成後的輸出如上圖包括了業務流程，業務資料，系統功能，接口內建和部署四大方面的内容。而這四個方面的内容剛好是我們做後續四大架構規劃的基礎。
有了以上現狀分析和調研，才談得上差距分析。
差距分析包括了目前目标和目前現狀間的問題和差距分析；業界參考目标/最佳實踐和目前現狀下的差距分析；IT現狀對目前目标支撐的差距分析；IT現狀對參考目标和業績标準的差距分析。
差距分析清楚後得到雙方認可的最終業務戰略目标和業務子目标，由業務目标傳遞到對應的IT規劃和建設目标，而後續的IT規劃即解決兩個問題。
IT建設解決目前業務和IT間的差距（無新業務戰略下你如何更好支撐）
IT建設解決後續戰略目标和IT間的差距的問題（新戰略下你如何擴充支撐）
對于目标提出而言，有兩個途徑。
其一直接提出業務目标和IT建設目标；
其二是通過差距進一步細化目标和有針對性的目标，特别是IT建設目标的提出，必須進行差距分析，因為IT建設重點就是支援業務目标，那麼所有現存的IT建設和應用架構中無法支撐的部分都是差距，IT規劃建設就是要解決這些差距。
改進也同樣的道理，有些是不需要業務改進直接進行IT建設和改進，有些則是業務優化和改進先進行，IT配合業務優化改進措施的落地。從這個思路基本也就清楚BPR的考慮和定位，并不是所有場景都一定要讓使用者進行BPR。
通過差距分析得出的目标是多個子目标，是一個目标群，正如我們面臨的問題是一個問題集一樣，多個子目标的分階段，分步驟實作最終才可能完成一個大的業務目标。
目标分解，問題分解，目标和問題映射最終形成一個完整的解決方案。這也是為何我們說，在大的IT規劃中一定會涉及到組合管理，項目群管理方面的内容，目标分解到子目标，子目标最終落實到具體的項目，通過項目規劃和建設的方式推動實作。
這個本身我和前面文章談到的咨詢類方案成為的思路完全一緻。
第一階段：問題分解和基礎素材對應
在這個階段重點就是将目标分解為子問題，然後将論據映射到對應的子問題上。
在這個過程中你已有知識庫積累可能不足夠，這個不要緊，那麼需要你進一步學習，進一步上網搜尋資料，對資料進行分析，同時将沒有的素材論據全部要清理掉。
最後留下的就是能夠完全支撐目标的有用論據材料。
第二階段：粗粒度對應，進一步排序和整合
到了第二階段做什麼？簡單來說就是要做抽象和歸納的事情了，即進一步對你的材料進行整合和歸納，形成大塊的解決子產品，然後将解決子產品對應到子問題域。
在解決子產品形成過程中，我們還需要對素材論據進行優先級排序，确定材料的重要性，哪些在最終呈現的時候應該放在前面，哪些應該放在後面等。
第三階段：進一步歸納并從歸納到演繹反轉
前面三個論據形成了，但是仍然比較散。是以我們需要進一步進行歸納，将其形成一個完整的整體，不論是靜态的金字塔結構，還是動态的流程結構都需要看到，你最終的解決方案中各子產品必須首先是一個整體，不能散。
經常看企業架構輸出的可能會注意到，對于完整的業務架構輸出而言可能并看不到具體的流程圖。這是因為實際上業務架構中的每一個小方框都可以是一個完整業務流程。
比如你在一個完整的業務架構圖裡面會看到有合同簽訂，采購需求的小方框。而這些本來就是獨立的業務流程，你完全還可以自己畫Level3到Level4級的流程圖進行描述。
類似上面的業務架構圖如何構圖出來？
大部分人實際上缺的正是如何形成上面的業務架構完整構圖。在整個業務架構和資料架構規劃裡面我們看到，核心仍然是從最頂層核心價值鍊開始驅動，逐層分解的端到端流程分析，跨業務域流程分析。
價值鍊模型為何具備普适性？
可以看到，雖然不同類型的企業核心業務流程都存在差異，比如類似電信營運商，電網公司和實際的傳統制造型企業，那麼核心業務上肯定有差異。但是核心價值鍊思想無差異。
核心價值鍊思想一句話描述就是：
接收市場和使用者的需求，将最終的需求轉變産品或服務并傳遞給客戶的過程。
你可以是重資産企業也可以是輕資産企業，可以是服務類也可以是制造類企業，可以是傳統企業也可以是目前的網際網路營運企業，但是最終價值核心思想不變。
那麼我們可以看一個我多年前畫的一個電網類企業的價值鍊模型圖：
這種價值鍊模型就可以了解為企業的核心頂層流程視圖。通過該視圖你再去分析企業核心的端到端業務流程，去分析跨業務域的一些流程。比如：
工程項目建設的端到端流程（最長的一個流程）
供應鍊跨域流程
财務的概預核決流程
客戶全生命周期服務流程
為什麼要去梳理這些端到端和跨域流程？
我前面已經談到一個重要觀點，即對于你熟知的行業領域你可以直接拿出結果，類似上面的業務架構圖，但是對于你未知領域，你必須通過詳細流程分析得出結果。
流程分析後，你會發現裡面有流程圖裡面有業務活動，而這些業務活動就是最終會展現到業務架構圖裡面的業務功能單元。流程分析中可以識别出關鍵的業務對象和資料對象，而這些就是展現到你後續資料架構裡面的關鍵内容。
這也是我經常強調的一個點。
從頂向下的流程分析是找到關鍵業務單元和資料單元的過程，而業務架構規劃和資料架構規劃是對單元進行歸類，彙總，朝上進行聚合和抽象的過程。
隻有這樣才才能夠真正解釋清楚你的業務架構是如何得來的。
比如我們基于價值鍊已經看到供應鍊跨越流程，那麼我們可以對供應鍊流程進行梳理。
梳理完後你會發現，輸出的職能帶流程圖中的大階段剛好就是你業務架構裡面的業務域或業務單元。或者流程圖中的業務活動剛好就是你業務架構分解到最底層的業務功能子產品。
即當我們流程分析到最底層後，我們就可以抽象輸出一個最底層的業務架構圖。比如對應供應鍊和采購管理，我們可以輸出到最底層的業務架構圖或業務元件圖。
流程梳理和分析究竟應該到多細的粒度？
流程梳理從整體的端到端流程分析入手，細化到各業務域的端到端，經過不斷的流程分解到3-4級流程，最終細化到最底層流程（如EPC流程，它是流程，本身也是業務功能）。另外的一個方式是直接從業務活動資訊收集入手，如根據組織架構和崗位職責直接收集業務功能點。
第一種方式既看到面又看到點，從上到下層層推進；而第二種方法則是容易隻看到點，但無法貫徹整個企業端到端流程。當然，流程分析并不一定能夠涵蓋所有的業務功能點，因為有些業務功能本身便是最底層的EPC流程，往往并不是從高端的端到端流程分解而來，如用章管理是一個業務功能和EPC流程，但并不一定能夠挂接到高端流程上面。
是以高端流程分析和分解是建立全局思維，但是仍然要借助第二種方法收集完整的業務和活動。
從業務架構到資料架構
流程到子流程，再到業務活動，業務活動中承載的是業務單據和業務實體。即我們談到的業務流程分析和梳理還會識别和産出另外一個關鍵内容，即業務實體和資料單元。
流程中的業務活動可以是産生資料單元，也可以是對資料單元屬性狀态進行變更。
比如采購訂單制作和送出業務活動，自然這個業務功能就會産生采購訂單這個關鍵資料單元。而對應采購訂單審批這個業務活動，則僅僅是對訂單審批流狀态進行變更。
資料架構貫穿業務和IT兩個層面的規劃
對于企業架構裡面的資料架構規劃，大家可能會有一個疑問，即資料架構究竟是偏業務層面的内容還是偏IT規劃層面的内容，今天在此進一步說下我的看法。
即資料架構規劃是一個貫穿業務和IT兩部分規劃的内容。即在業務階段你可能隻做到資料域劃分，核心的資料概念模型和主資料識别。而到了應用架構規劃階段，你就需要進一步對資料進行邏輯模型和實體模型的設計。
在業務層面資料架構規劃做到識别關鍵的業務對象即可。而到了技術層面資料架構規劃必須細化到具體的資料庫表和表裡面的核心字段定義。
資料域-》資料概念模型-》資料邏輯和實體模型
資料域和資料分類是資料規劃的頂層，這個時候如何确定資料域？
簡單來講如果你所在的行業有标準的資料模型标準，那麼參考業界标準來做，比如電信行業的SID資料模型分類。如果沒有标準，那麼業務架構規劃裡面核心價值鍊模型的業務域即是資料域。
從這個圖我們可以看到大的資料域實際和我業務域是完全對應的。
資料域出來後，我們可以對單個資料域再進行細化分析，這個時候就到了單個資料域裡面所有和業務相關的業務對象和資料對象的識别，資料的概念模型定義。
比如對于供應鍊資料域，我們在完整梳理了供應鍊業務後即可識别出所有的業務對象，然後對這些業務對象單獨拿出來進行資料模組化，并分析資料對象之間的關聯和依賴關系。
是以資料架構規劃需要關注資料分域，資料對象和主資料識别，跨業務子產品的核心業務單據資料。資料的問題最終都将對應到應用架構和資訊架構，SOA解決的是業務內建和協同，而資料內建是有其它系統解決方案，包括BI，資料中心，MDM系統等。流程分析偏業務操作和事件，而資料正是業務操作的對象。SOA中強調操作和資料解耦，則正好是分析的兩個次元。
IT藍圖規劃包括了業務架構，資訊架構，應用架構，內建架構，技術架構和 IT基礎設施架構等方面的内容。特别的是，IT規劃藍圖包括了業務架構，業務和IT是密不可分的。所有的藍圖規劃都自頂向下，逐層分解，互相融合和協同。業務架構重點是在流程，資訊架構的重點是在資料。
而對于IT方面則包括了應用架構，內建架構，技術架構和IT基礎設施架構。應用架構在最上層，而內建和技術架構在平台層，IT基礎架構在基礎設施和實體資源層。從現有的雲和集中化趨勢來看，更加需要考慮基礎設施和平台層的集中化建設，上層的應用架構重點集中在應用和功能層面，展現業務元件化和能力化，展現業務元件本身的獨立性和可內建性。
業務架構和資訊架構最終要落地到應用架構中
業務架構展現到具體的業務元件和功能
而資訊架構落地到具體的資料模型和資料庫設計
如果再落地到具體的系統分析和設計，即演進到應用系統中的高端架構設計，包括用例模型和邏輯模型，用例模型展現業務和流程，邏輯模型展現資訊和資料。
以上分析後，将推進到應用架構規劃領域。很可惜的是，在大多數的規劃項目當中，業務架構和應用架構出現了嚴重脫節，兩階段之間出現斷層，沒有通過科學的分析方法在兩者之間平滑的進行映射。這裡進行着重的強調，在應用架構規劃時，首先進行總體應用規劃，應用架構和業務架構對應，但不一樣的地方是，流程優化分析和業務架構不會考慮太多應用平台層面的内容，而應用架構必須考慮。
其中兩大核心就是集中化和協同，兩大技術就是雲計算和SOA。
這些内容需要引入到IT總體應用架構規劃中。談到傳統IT建設呈現豎井式，互相之間協同難的現象，在引入SOA思想後并不是沒有豎井現象了，一個個核心的業務元件和能力提供單元還是獨立的，但是應用層中共性的内容完全下沉到最底部，并提供互相內建的機制。
應用架構規劃需要展現逐層展開的核心思路，總體應用架構清楚後将細化到第二個層次：功能架構和內建架構。這個時候細化相當重要，真正解決業務目标和業務功能的落地問題。功能架構包括功能子產品和具體核心功能點，這些梳理出來後我們需要明确當初提到的業務架構和業務需求在功能架構中如何落地。其次，以某個應用為核心，來觀察該應用和外部應用間的內建關系以及內建後如何協同。前者為功能性需求，後者為接口需求。
應用架構如何形成？
可以看到應用架構基本是和業務架構對應的，隻是有兩點差異
其一是增加了非業務相關的技術平台内容和上層類似門戶內建等内容
其二是對業務架構中的業務域可能出現拆分和合并的過程
我們先拿一個應用架構規劃做說明：
從圖裡面可以看到底層增加了類似門戶，SOA內建平台等非業務内容。但是整體應用劃分仍然和業務架構規劃對應和比對。在這個時候的差異點往往展現在業務到系統建設的合并和拆分。
比如對應供應鍊業務域，我們是建設一個供應鍊系統，還是建設類似招投标，采購管理，物流平台等多個子系統。而這點實際和企業本身的業務組織架構關系很大。但是到了目前微服務架構思想下你可以看到，一定是安裝業務架構底層最小業務域單元進行微服務子產品拆分。
應用架構規劃仍然會展現分層，到了最底層即回歸到我們單個系統的功能架構設計。比如對于供應鍊管理，我們最底層就是系統的功能架構圖，如下：
為何我如此強調CRUD分析？
不論是在業務規劃階段，還是到了應用架構規劃階段，随時都存在CRUD矩陣分析。
資訊架構與業務、應用的映射涉及幾個矩陣分析，在業務架構階段重點的是業務對象和業務流程、業務元件、業務功能間的類CRUD矩陣分析。
而在應用架構階段重點則會是邏輯或實體模型對象和具體的應用子產品或應用功能間的矩陣分析。兩者關注層面不同，前者重點是主資料的識别和業務元件的分析，而後者的重點是應用功能子產品的劃分和子產品間內建接口的初步分析。
在應用架構階段的CRUD分析有兩個關鍵點。
其一，某個業務功能究竟劃分到哪個系統更能夠實作松耦合
其二，某個資料對象其Owner究竟屬于哪個系統能夠實作松耦合
目前我們經常看到企業實施微服務後，微服務子產品間大量的接口網狀調用，導緻各個子產品間耦合更緊，這就是典型的微服務子產品拆分時候沒有做好類似CRUD等分析導緻。
內建架構規劃-接口服務如何來？
這個也是大部分做IT規劃咨詢的人沒能搞清楚的問題。
即知道有這些接口，但是這些接口和內建點是如何一步步的分析和識别出來的不清楚。
我們先思考下為何會出現系統間內建？
簡單來說就是企業的業務流程本身是端到端和連貫的，但是我在應用架構規劃設計的時候，為了降低系統建構複雜度，将應用拆分為了多個系統進行實作，每個系統實作業務流程中的某一部分内容。
即業務連貫，但是業務實作在多個系統中導緻了割裂。是以是以業務系統必須高效協同起來才能夠完成一個端到端的業務流程。
有了這個了解，基本就清楚了內建架構規劃的重點，即：用你規劃好的應用架構各系統功能提供來重新驗證你前期梳理出來的端到端業務流程。即去回答和自己演算用各個系統功能的協同如何來完成完整的業務流程。
即原有的流程梳理圖-》跨系統業務互動流程圖
所有跨系統互動流程圖中的豎線和紅色三角形點即是潛在的系統內建點。在這個分析中，你就詳細完成了業務系統間究竟有哪些內建點，內建點如何協同來完成完整業務的分析，如下：
當然上面的分析方法可能會遺留類似資料服務接口，技術服務接口等。而實際上要做一個完整的服務架構規劃又有詳細的指導方法。其核心仍然是從企業架構的業務，資料，技術各類架構輸出入手，去分析和識别類似業務服務，資料服務，技術服務等各種類型的服務，最終形成完整的服務目錄庫。
具體如下圖：
在把單個跨越業務流程的內建點全部梳理和識别清楚後。我們接着進行接口的分析和歸納等工作，在這裡不再展開。最終所有接口都識别出來後，可以進一步朝上聚合完整的內建架構規劃視圖。
技術架構描述了企業開發、實施和管理應用系統和資料所需的IT技術體系和IT基礎設施。技術體系定義企業IT的科技管理和技術标準，從最高層次的政策、原則、指導綱要到技術領域的技術标準化、技術選擇和技術元件。
基礎設施是企業整個IT系統的基礎，包括硬體、軟體作業系統、資料庫系統、網絡系統等企業資料和應用程式可以運作的環境。
在整個基礎設施架構規劃中，高可用性規劃和設計又是一個重要内容。
技術架構在業務架構、應用架構的基礎上提供了一個架構，這個架構為發展和開發一個互動不同的業務部門和業務領域的、在技術層面上的、與業務相一緻的解決方案提供了一個基礎。重要的是它保持了企業的技術标準、技術選型、應用設計、系統産品選型、系統技術架構、系統部署、整個企業的技術部署等一切技術層面的組合群組件，與企業的戰略規劃、業務架構和應用架構的實際需求保持了一緻性。
傳統的技術架構規劃，由于較少融入雲計算和SOA思想，内容上偏向IT基礎設施架構設計。雖然在TOGAF的技術架構規劃中也談到了技術和應用平台，但是卻沒有具體的落地方式。
而實際上我們可以了解為基于SOA和雲計算思想的技術平台都可以劃歸到技術架構規劃裡面。比如我在前面給出了企業私有雲PaaS平台規劃，就可以屬于技術架構規劃内容。如下圖：
而對于我最近在整理的雲原生解決方案中的平台層能力提供，也完全可以納入到技術規劃的内容。這部分能力既包括了IaaS資源層能，也包括了PaaS服務層能力提供。如下：
實施規劃直接影響到IT藍圖規劃的可落地性，影響到IT建設投資是否真正展現業務價值，為業務目标服務。實施規劃重點方法論主要為組合管理和項目群管理。可以從成本投入，建設難易程度，對業務價值實作的貢獻，推廣實施難度等多個方面來評估建設内容的優先級。預算和成本投入，在實施規劃中同時也要考慮到。
實施規劃按照組合管理的目标來說，就是要用最少的IT資源投入創造最大的業務價值。
我們要建設哪些IT系統，如何分階段建設，如何來支撐業務流程，IT系統建設的協同關系，如何加強項目管理和管控，如何推進系統的建設，如何減少重複建設，這些關鍵資訊在實施規劃時都必須要考慮到。