知其然并知其所以然 明天预备谈下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配合营业优化改良办法的落地。从这个思绪根基也就清楚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分析有两个关键点。
当前我们经常看到企业实施微办事后，微办事模块间大量的接口网状挪用，致使各个模块间耦合更紧，这就是典型的微办事模块拆分时辰没有做好类似CRUD等分析致使。 集成架构计划-接口办事若何来？ 这个也是大部分做IT计划征询的人没能搞清楚的题目。 即晓得有这些接口，可是这些接口和集成点是若何一步步的分析和识别出来的不清楚。 我们先思考下为何会出现系统间集成？ 简单来说就是企业的营业流程自己是端到端和联贯的，可是我在利用架构计划设想的时辰，为了下降系统构建复杂度，将利用拆分为了多个系统停止实现，每个系统实现营业流程中的某一部份内容。 即营业联贯，可是营业实现在多个系统中致使了割裂。是以是以营业系统必须高效协同起来才可以完成一个端到真个营业流程。 有了这个了解，根基就清楚了集成架构计划的重点，即：用你计划好的利用架构各系统功用供给来重新考证你前期梳理出来的端到端营业流程。即去回答和自己演算用各个系统功用的协同若何来完成完整的营业流程。 即原本的流程梳理图-》跨系统营业交互流程图  一切跨系统交互流程图中的竖线和红色三角形点即是潜伏的系统集成点。在这个分析中，你就具体完成了营业系统间究竟有哪些集成点，集成点若何协同来完成完整营业的分析，以下：  固然上面的分析方式能够会遗留类似数据办事接口，技术办事接口等。而现实上要做一个完整的办事架构计划又有具体的指导方式。其焦点仍然是从企业架构的营业，数据，技术各类架构输收支手，去分析和识别类似营业办事，数据办事，技术办事等各类范例的办事，终极构成完整的办事目录库。 具体以下图：  在把单个跨越营业流程的集成点全数梳理和识别清楚后。我们接着停止接口的分析和归纳等工作，在这里不再展开。终极一切接口都识别出来后，可以进一步朝上聚合完整的集成架构计划视图。  技术架构计划技术架构描写了企业开辟、实施和治理利用系统和数据所需的IT技术系统和IT根本设备。技术系统界说企业IT的科技治理和技术标准，从最高条理的政策、原则、指导纲领到技术范畴的技术标准化、技术挑选和技术组件。 根本设备是企业全部IT系统的根本，包括硬件、软件操纵系统、数据库系统、收集系统等企业数据和利用法式可以运转的情况。  在全部根本设备架构计划中，高可用性计划和设想又是一个重要内容。  技术架构在营业架构、利用架构的根本上供给了一个框架，这个框架为成长和开辟一个交互分歧的营业部分和营业范畴的、在技术层面上的、与营业相分歧的处理计划供给了一个根本。重要的是它连结了企业的技术标准、技术选型、利用设想、系统产物选型、系统技术架构、系统摆设、全部企业的技术摆设等一切技术层面的组合和组件，与企业的计谋计划、营业架构和利用架构的现实需求连结了分歧性。 传统的技术架构计划，由于较少融入云计较和SOA思惟，内容上偏向IT根本设备架构设想。虽然在TOGAF的技术架构计划中也谈到了技术和利用平台，可是却没有具体的落地方式。 而现实上我们可以了解为基于SOA和云计较思惟的技术平台都可以划归到技术架构计划里面。比如我在前面给出了企业私有云PaaS平台计划，便可以属于技术架构计划内容。以下图：  而对于我比来在整理的云原生处理计划中的平台层才能供给，也完全可以归入到技术计划的内容。这部分才能既包括了IaaS资本层能，也包括了PaaS办事层才能供给。以下：  实施计划和演进线路 实施计划间接影响到IT蓝图计划的可落地性，影响到IT扶植投资能否真正表现营业代价，为营业方针办事。实施计划重点方式论首要为组合治理和项目群治理。可以从本钱投入，扶植难易水平，对营业代价实现的进献，推行实施难度等多个方面来评价扶植内容的优先级。预算和本钱投入，在实施计划中同时也要斟酌到。 实施计划依照组合治理的方针来说，就是要用最少的IT资本投入缔造最大的营业代价。  我们要扶植哪些IT系统，若何分阶段扶植，若何来支持营业流程，IT系统扶植的协同关系，若何增刚强目治理和管控，若何推动系统的扶植，若何削减反复扶植，这些关键信息在实施计划时都必必要斟酌到。 对于这部份内容，我明天不再做太具体的展开。 以上即是对企业架构和信息化计划征询中的一些关键逻辑关系的思考，供大师参考。也接待列位留言会商IT计划扶植中碰到的题目点。 |
微信扫一扫
