來源：信息化協同創新專委會
今天準備談下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系統建設的協同關係，如何加強項目管理和管控，如何推進系統的建設，如何減少重複建設，這些關鍵信息在實施規劃時都必須要考慮到。
對於這部分內容，我今天不再做太詳細的展開。
以上即是對企業架構和信息化規劃諮詢中的一些關鍵邏輯關係的思考，供大家參考。也歡迎各位留言討論IT規劃建設中遇到的問題點。
轉載自：企業數位化諮詢