你好，我是付晓岩。
咱们都听过一句话，“事在人为”。事情都是人做的，无论我们在进行数字化转型时有多少奇思妙想，如果没有人去落地，或者是落地的人对这些想法理解不到位，“打了折扣”，那成功转型也就只能是梦想了。
所以，很多企业都在拼命寻找数字化人才，尤其是同时懂业务和技术的复合型人才。但是，现实情况是，复合型人才很难培养。根据我自己的实践经验和跟众多企业的交流，我发现，没有5到8年的实践，是很难培养出来的。
另外，除了人才呢，做事情也是需要方法的。没有合适的方法，就很难满足工作的质量和效率要求。而且，方法不仅对做事重要，对人也很重要。没有方法作指导，我们也很难去培育人才。
所以，今天，在咱们最后的这节课里，我想跟你认真地聊聊，怎么解决对企业数字化转型至关重要的两个基础性问题：人才培养和企业架构方法论建设。当然，即使你现在不是站在企业决策中，如果想“自学成才”，也可以通过这节课，找到自己的发展方向。
先说说如何解决人才培养问题吧。
首先，你要明确一点，数字化人才不是单指技术人员，而是指所有具备数字化技能的人才。那啥是数字化技能呢？我认为，能支持技术人员快速开发软件的都可以算是数字化技能。
所以，在培养数字化人才时，我们不仅需要增加和培养技术人员、培养业务架构师，还要建立起业技融合的工作机制，这样才能培养出强大的梯队型数字化人才队伍，更好地提升内部人才转化能力。接下来，我就具体和你聊一聊怎么做到这3点。
技术人员是我们改变企业人员能力结构的基础，没有他们提供技术技能以及对技术的理解，我们企业的“技术基因”就很难补全。
最快速的培养技术人员的办法当然是直接引进。不过，我需要提醒你的是，引进什么样的技术人员，要考虑企业的成本覆盖能力和人力资源结构设计目标，一味追求高端人才并不可取。因为人才的作用与企业环境是匹配的，现在市场上的人才也都很现实，如果没有适合自己发展的环境，即便待遇不错，高端人才也未必会来。而且，企业的数字化建设也不单单是靠高端人才领军的，集体智慧也很重要。
由于市场供给有限，找到足够多的技术人员不容易。所以，我们要分期、分批，从不同年龄段、不同技能水平的技术人员中逐步引进，再加上通过开发实践、职业教育，加大对员工的培养力度，有步骤地提高技术人员占比。不要幻想一步到位，数字化是长跑不是冲刺，人才培养也是这个道理。
除了引进技术人员，企业也需要让对技术的合理应用理念传导到业务一侧，让技术真正能够帮到业务。而这方面现在大家达成的共识是，一定需要有复合型人才进行推动。但是，什么是所谓的复合型人才呢？
关于复合型人才，我的理解是，不是单纯地把业务和技术知识都学习了就行了，他们更重要的特质其实是结构化的分析和理解能力。这样才能让他们不受制于领域的差别。他们看不同领域时的底层思维是一样的，就是他们会去研究一个领域的结构、组成部分之间的关系、发展和变化可能遵循的规律，灵活而不死板地看待问题。这是对复合型人才的基本要求。
所以，所谓的复合型人才，不是什么都懂的人，而是能够跨领域学习和实践的人。
那你可能会问，怎么培养复合型人才呢？我认为，学习架构思维是一条路。其实你想想，刚才说的复合型人才的基本要求不就是架构思维吗？
对于传统企业而言，由于大多数人员都是业务人员，即便培养架构思维，也很难让业务人员一下子领会技术的事情。所以，我建议你先以业务架构为目标进行培养。业务架构正好处于业务和技术的连接点上，要一手托着业务，一手托着技术，也非常符合我们对复合型人才的期望。
根据我多年的经验，我认为，对企业而言，培养业务架构师的时候，有几点是需要重点考虑的，下面我来具体介绍下。
第一，切记不要一个一个培养，应该一小批一小批培养，或者根据企业规模决定每批次的数量。这样既是为了保证成功率，也是为了防止出现技术上常讲的“单点问题”。毕竟，如果只培养一个，他跳槽了怎么办呢？
第二，在培养的初期，因为更重要的是如何通过业务架构向IT侧传导战略和需求，如何把业务架构与IT架构的关联关系建立到位，所以，与技术沟通比较重要。所以，在每个批次中，技术人员的比例可以略高，这样可以保证沟通顺畅。然后，逐渐提高业务侧人员的占比，因为最终业务架构是要向业务侧推广的。
第三，培训一定要得法。架构师思维和胸怀一定要开放，别把架构搞得像一个审批部门一样，把控制权放在第一位，更不能为了自圆其说，就不挑战、不改变自己，搞架构的僵化。当然，也不能胡思乱想，不顾实现能力、实现条件的限制，太理想化地去做企业级整合，这些都是做企业架构中会遇到的常见问题。
在学习时，我们每个人都要建立正确的“架构观”，也就是要根据全局、结构、灵活、演进四个关键理念，正确看待架构的作用和价值。
我必须要说，业务架构师不好找，因为这个领域从提出开始就没被真正重视，到现在很多企业觉得重要了，却发现之前基本没有企业培养过，有的企业更是把应用架构与业务架构混为一谈。所以，人才市场发育起来之前，还是努力在自己家认真培养吧，一些科技公司也是这么看的，比如阿里巴巴早在2018年就有位领导公开说过，好的业务架构师很难找，只能自己培养。
说过了专业技术人才、业务架构师的培养，我再来说说最后一点，如何广泛地提高全员的数字化能力。这个需要工作机制来保障，不是靠挖人或者重点培养的方式就可以解决的。
谈到业务和技术深度融合的工作机制，你可能经常会想，是不是有什么神奇的方法能让业务人员和技术人员碰撞出智慧的火花呢？方法有，但是没有那么神奇，这方法就是“聊”，两边坐在一起经常交流。融合一定是从沟通开始的，如果面儿都见不到，还谈什么融合啊？
这是我一直鼓励传统企业多增加技术人员的原因。如果你学习互联网企业时，把精力都放在敏捷开发、技术栈上，那你学的就只是“筋骨皮”了，是外在功夫；他们真正做得好的地方是有大量的技术人员可以直接支持业务人员，一起去谈怎么解决问题，这才是最有价值的那“一口气”，是内在功夫。所以，谈融合，先从怎么增加有效的交流时间开始吧。
在这个层面，业务架构师的工作方式也很重要。我建议你直接把业务架构师派到业务部门去工作，在业务需求萌生的第一时间，业务架构师就和业务人员一起进行基于业务架构的讨论，让讨论成为技术为业务提供“咨询”服务的机会。
在业务部门中，业务架构师可以经常把架构思维推广给业务人员，持续改变业务人员的思考方式。业务部门也可以采用业务模型去培训业务，通过业务模型谈业务改进，这样做的好处是，业务想法可以快速转化成对IT的需求，并且是准确定位到实现位置的需求。
通过推广业务架构，能够让更多的业务人员形成结构化思考的习惯，让企业架构在各个层面得到使用。
业务人员的数字化能力培养不仅仅是了解数字化工具的使用，更重要的是具有支持业务和技术深度融合的基础能力。融合就是沟通，就是能一起研究同一个问题，这就需要具有相近的底层思维模式。大家都结构化地看问题，并且聚集在同一个企业架构框架下，那么，互相的理解必然会加深。
通过业务架构，我们就可以帮助企业内的业务人员完成关键性数字化能力的转型。
好，谈过了人的培养，再看看工具吧，俗话说，“人巧不如家什妙”，想把事情做好，总得有个好方法做支撑，这样才能把经验转化成知识，才能把纷繁复杂的各类业务需求、技术实现方案都连接起来，这就得靠咱们反复强调的企业架构了。
企业该怎么建设这种看似艰深难懂的东西呢？我认为要做好五个方面，选定主线、持续实践、定期复盘、开放吸收和分享共建。
架构方法论的研究是要花费不少精力的，每个方法论发展的历程都证明了这一点。所以，搞架构建设，要选定一条主线发展下去，避免频繁切换赛道，浪费时间。
如果你深入研究下去，就会发现，各种架构理论的主张虽然不同，但是最终目标是一样的，都是希望企业能够具有更强的整体性，更好地适应变化。
那怎么选定主线呢？对于传统企业，我建议你选择稍微传统一点儿的方法，因为实践过这些方法的企业相对比较多，方法论也经受了批评和修正，有不少实践者已经有深入的认知了。而且，可以讲方法的人和机构也比较多，我们很容易获得学习资源。这些传统方法大多是建立在比较严格的对企业现状分析的基础上的，这也是一些新方法考虑不周的地方。
对于新兴科技企业来说，因为技术本来就是我们的强项，当然要在新架构、新方法上使劲儿。但是，我要提醒你的是，企业不只是技术，还有经营。所以这些企业最好在吸收传统方法的基础上自己尝试创新，不要盲从。
另外，我也建议新兴科技企业补一补管理、历史、政治方面的课，因为这些领域凝聚了前人的管理智慧，是无数成功者和失败者总结出来的经验教训。虽然马斯克曾经抨击很多企业过于看重商学院那套方法，但是，毕竟马斯克领导下的企业属于极少数的成功案例，更多的企业还是得搞明白“收入、成本、利润”的关系和社会环境，这样才能活下去。
说到这儿，我还想再提醒你一句，在你最开始学习架构方法论的时候，还是需要多在思维层面琢磨琢磨，不要急着看案例。案例是方法论的实践经验，而不是方法论本身，这些经验往往带有实施企业的特色调整。如果企业在学习架构方法论的过程中，过于关注其他企业的案例，有可能在学习阶段就“跑偏”了。
虽然我说在学习阶段不要急于关注案例，但企业搞架构方法论，毕竟不是纯理论研究，是指导实践的。所以，除了学习之外，你得持续实践，用实践反哺理论，做到知行合一。
“知行合一”是我对架构方法论研究的一贯主张，而且这种思路也有助于企业把自己以往的优秀经验提炼出来。比如企业做架构决策时可以依据的一些原则，你可以通过对架构实践的总结，把做决策时积累的判断方法、经验上升为架构原则，让大家共同遵守。
而企业做过的所有架构设计，无论是业务架构的模型、技术架构设计，还是应用架构设计，都属于企业积累出来的架构资产，既可以用于指导以后的开发实践，也是企业员工学习本企业架构最好的学习材料。
没有一支部队能够连续作战而不用休整，企业架构师团队也一样。所以，我们必须采用哪怕很短暂，甚至是轮休的方式，让企业架构师团队能够定期有正式的“复盘”时间，集体讨论得失，讨论对方法论的修正。
思想的统一，可以充分凝聚战斗力，经验的分享，也可以促进战斗力的提升。
企业架构师在长时间的工作后，根据实际环境进行的灵活性抉择，是有可能导致架构方法论发展方向“分叉”的：这些“分叉”有些是有好处的，比如，对业务和数据应如何更加一体化设计的思考；有些则未必，比如，持续放宽对重复设计的容忍度，或者过于看重只适合于某些环境的复杂化设计思路。
那么，在复盘时，要集体讨论这些“分叉”的得失，及时纠正偏差，让架构师知道什么该做、什么不该做，以维护架构设计思路和标准的统一。
当然，最重要的，还是鼓励架构发展的新方向、新尝试。毕竟，架构是要与时俱进的，而且要整个架构师团队一起前进。
所以，我们必须要定期对这些内容进行检讨，以保持更合理的“架构观”和进步方向。
架构方法论不但要吸收内部经验，还得对外吸收经验。你可以研究下其他企业做得好的地方，比如架构设计、管理、企业经营等方面的领先之处。关于别人的优点，你都可以在搞懂了的情况下，结构化地吸收进来，改进我们自己的方法论和架构资产。
在这方面，我很赞同杰夫·萨瑟兰在《敏捷革命》一书中提到的一个观点，大意是，他创立敏捷方法论时其实没打算创立一个新方法，只是想把以前工程实践的优秀经验总结起来。你看，敏捷创始人都这么看问题，那我们做企业架构，尤其是采用传统企业架构理论的实践者，也更应该这么想问题。切记，我们搞方法论只是为了把事情做得更好而已。
搞企业架构方法论比较困难的一点就是周期长，需要实践检验、经验补充和概念更迭，所以，一个企业自己关起门来搞方法论确实是件很痛苦的事情，能够分享共建是最好的。方法论本身是不能变成专利的，所以，不应该过度保护这个。
当然，架构实施难免涉及到商业秘密，已经设计好的架构资产也确实有拿去卖钱的可能。但是，从互惠互利的角度看，开放对大家都有好处，就像开源。
架构方法论、适当屏蔽细节的参考架构，这些东西的共享有助于提升整个行业的架构能力水平。为什么一些咨询公司在企业架构方面很有建树，就是因为他们坚持方法论研究，并且能够接触到更多的实践案例，经验的反馈更快。所以，企业如果想在这方面有更好的发展，通过联盟等形式建立一些架构经验共享机制，可能会更好。
作为课程的收尾，今天我把重点放在了人才和方法论上。做事情得靠人，人做事得有方法，整个数字化转型也是一样。咱们前面说过的一系列内容，其实落脚点都在这里，也就是人和做事的方法。
我认为，企业培养数字化人才要分成三种类型，逐步推进：
在企业架构方法论方面，也有5个要点：
到这里，咱们课程的核心内容就都讲完了。课程的最后，我想再强调一下，在数字化转型中至关重要的几个点，你一定要从现在就重视起来。
你觉得，自己的企业选择哪种企业架构方法论作为主线比较好呢？
欢迎你畅所欲言，和我一起交流讨论。如果你觉得今天的内容对你有所帮助，也欢迎你分享给你的朋友或同事。
评论