大语言模型的出现让很多人担心劳动岗位替代的问题，但是，首先要“瑟瑟发抖”应该是企业当前的开发模式，这是释放工具潜力的关键。
GPT 最近几乎刮起了“完美风暴”，从大语言模型迭代到微软 office 系列软件升级再到硬件厂商 NVIDIA 的拱火，全网燃爆各种小案例，从训练编程、合作著书到“AI出逃”，再加上大佬创业，几乎能算是最近十几年 AI 浪潮的最高点了，原本去年 AI 投资都退烧了，这下子可能又激动了，连盖茨都称其为计算机领域近四十年来的最重要发明。不过笔者自己作为在银行业多年的前从业人员，也算是看到过落地层面的 AI，在自己的通识类课程中也坦言，这项技术前景广阔，但现阶段还不足以改变行业业态，撇开一些高光的宣传，倒是 OCR、智能客服、反欺诈之类的常见用法用得更踏实些。
不过这轮的 GPT 确实让我感受到一些不同，也结合自己最近在企业数字化转型，尤其是管理思维方面的实践与思考，与读者一起做个探索。
本文的研究方向，也就是标题，可能会让读者觉得跳跃，数字企业、企业管理、GPT、软件个性化、软件工业化，似乎各个论述对象之间的鸿沟不止一道，传统企业管理现在面临数字化思维的冲击，GPT 显然是多数业务人员乃至业务领导一时半会儿很难真正理解的话题，用在管理上的思路现在还非常模糊，软件的个性化和规模化的冲突由来以及，GPT 又与这对儿难兄难弟有啥关系？如同上文所述，GPT 确实给了笔者一些思路，似乎能把之前笔者在各个方向上的思考连接起来，如同微软给自己的 GPT-4 应用起名“Copilot（副驾驶）”，笔者也感受到了 GPT 带来的“贾维斯时刻（电影《钢铁侠》里神通广大的人工智能管家）”正在逼近。
不过阐述这个思路还是要绕些弯路，还是先从大家最关心的企业数字化转型说起吧。
大范围数字化转型必然催生的企业形态
本轮国内的数字化转型有一个最强的力量推手，这就是国家政策，笔者之前曾经总结过国家数字化转型政策结构图，这些政策汇编起来也就是一本书，是中国式数字化转型的必读书，是数字中国的必读书，该结构图如下：
从结构图中可以感受到数字化政策体系的完备和国家倾注的力量，而其中作为数字社会基础设施的“东数西算”工程在 2022 年 3 月也正式启动了，数字时代的国家级基础设施已经在路上了。
除了社会基础设施，很多企业也逐渐意识到，随着数字化的发展，企业里的软件是越来越多了，无论是金融、制造、航空、能源、医疗、餐饮，还是街边零售，聊天工具、扫码枪加支付工具的组合，已经让今天的零售店迥异于当年的“小卖铺”。企业正在越来越大范围地“软件化”，随着企业规模的增大，企业内有十几个、几十个乃至上百个软件，部分行业的超大型企业甚至可以达到上千个，如此多的软件又会催生更多的业务需求，所以在“需求-系统-需求-系统”的无尽循环中，业务的数字化思维、感觉越好，软件需求就会越多，加上国家级基础设施的支持，很多企业可以不再自建基础设施而是专心于应用侧的开发，这也会导致对需求的进一步增加，所以，“软件型企业”就是数字企业的必然发展形态，但是这一形态势必会给企业管理带来日渐增大的冲击和改变。
数字企业管理面临的新课题
所有的事物都在通过数字化升级，那么我们的管理思维需要升级吗？需要向什么方向升级？如果企业会变成“软件型企业”，那么管理思维中需要加入什么新元素吗？
数字企业管理的一大难题常被说成是“业技融合”，也就是打破技术鸿沟，让技术和业务成为志同道合、心有灵犀的业务伙伴，克服隔行隔山的困难。但是，“隔行”毕竟“隔山”，数字化转型、数字人才培养并非是要把业务人员培养成技术人员或者把技术人员培养成业务人员，而是提升二者的沟通效率，此外，为了提升对业务需求的响应速度，一定程度上也要把低强度开发工作向业务侧转移，从而提升业务侧“自我实现”的能力，但这并非是专业开发技能的转移，只是低强度开发工具的“跨界”。所以，根本上来讲，还是要提升双方沟通效率，但是沟通意味着语言模式的接近，而语言模式背后反映的是思维模式，所以，真正要接近的是思维模式，就数字化管理来讲，首先拉近业务人员和技术人员的思维模式是管理上的第一要务，如果希望涌现式的创新能够出现，那就先拉近可促进沟通的共同思维模式吧，也就是结构化思维。
结构化思维听起来很抽象、很高端，其实不然，这是每个人都有的东西，其差别主要在结构化程度、表达习惯方面，这些对可以通过企业环境来进行磨合的，通过环境磨合会逐渐接近。不过，建立共同的结构化思维模式，听起来似乎与企业的日常经营管理无关，好像更像是人际关系管理、沟通管理，其实不然，这是小看了结构化思维对数字化转型、对数字企业的意义。
数字企业发展的趋势是“软件型企业”，但是软件也有简单有复杂、有低知识密度有高知识密度，对于希望形成竞争力的企业而言，如何把业务优势、业务知识浓缩进软件，进而形成自己独特的“管理系统”，这是数字企业的一大竞争优势，也是避免软件你也有我也有，最终没啥区别的同质化管理困境，很多企业做的软件最终觉得不如意，其实最重要的不是开发问题，而是有没有把“意”注入软件，没有注入“意”，当然就不可能如“意”。管理中有个不精确的经验分析结论，就是企业中有 20% 的流程是会塑造企业的差异性竞争优势的，那么，有没有找到这 20% 的流程，这 20% 的流程是带着业务知识注入了系统，还是只把过程搬上了系统，这是软件是否属于有价值的高知识密度软件的关键。
那把业务流程、业务知识设计好并转化到系统里，就离不开结构化思维了，甚至面向企业来讲，需要的是全局性结构化思维，因为，找到这 20% 的流程本身就要经历全局化的比较。考虑到怎么把这 20% 的流程强化得“无以伦比”，还要系统化下来，数字企业就必然是个知识型企业，是一个不断萃取业务知识的企业，而且要“自己教自己”，所以，知识管理是数字化企业的核心竞争力，这一点过去也强调，但是知识的形式经常是专利、制度、文档、图表，但现在是系统化的流程、规则、数据，他们比专利转化的更快、变化的更快，比制度、文档、图表更易于数字化管理，并且是直接融合在生产过程中的。数字企业的竞争性差距，就在于知识的萃取速度、转化速度，因为这种速度在“软件型企业”的企业形态加持下，会显得更快。
数字企业“321管理法”
综合结构化思维、知识萃取、软件型企业等视角，也许可以为企业管理提出一个新思路，一个面向数字企业管理的管理法，笔者称其为“321 管理法”，其结构图如下：
笔者认为，企业管理必然离不开对企业格局，也就是企业结构的研究，企业的各种格局中，结合软件型企业方向，最重要的结构莫过于企业能力布局，也就是企业到底需要那些能力才能实现自己的业务目标，这些能力分布在什么样的结构上，传统的管理学会研究这个，数字企业管理依然会，只是能力的载体在随着时代发生改变。
最初科学管理时代，关注的是人和机械之间的关系，关注人的标准化操作，与生产线的配合，逐渐，管理学开始更加人文化，关注人的作用，之后又增加了对战略和目标的关注，管理学关注的体系逐渐完善了。从人与机器的协同，到人与人的协同，再到战略与战略、目标与目标的协同，那么，对数字企业而言，这些关系又会有什么变化呢？数字企业依然会研究三大类协同的关系，但是这三类协同指的是：人与人的协同、系统与系统的协同、人与系统的人机协同，除了传统的人人协同外，系统的增多，尤其是竖井式开发产生的弊端，使企业已经不得不重视系统的协同问题了，而随着系统能力的演进，“自治”系统的概念开始被接受，“超级自动化”也成为可追求的目标，我们已经希望和愿意让系统自己完成更多的任务，在“自治”系统的发展中，系统间协同的重要性已经不仅限于解决竖井式问题了，我们需要越来越把系统当“人”看了，一些信息化程度高的企业，很多时候人们已经只记得系统名字，而忘记了做这个系统当初是要替代什么岗位的工作了，系统已经挺“独立”了。而随着智能化、“自治”化系统的增加，人与系统间协同的关系也是管理上要设计的了。这三大协同就代表了上文提到的，能力的布局，企业所需要的业务能力是如何在人、系统之间分布的，基于人的线下能力、基于系统的线上能力和基于人机协同的混合能力。
那么，既然要谈布局，就得先找到能力，能力如何定义呢？可以通过战略拆解的方式自上而下定义，也可以基于对业务的萃取，不断在底层进行积累，二者结合，不过，就方法而言，业务能力的萃取，无论自上而下还是自下而上，都离不开对流程（业务协作）、规则（业务算法）、数据（新生产要素）的清晰表达和定义，毕竟，离开这些，萃取的知识就算人能听懂个七七八八，也是做不进系统的。这个过程听起来就是传统的技术实现，是的，就是传统的技术实现，但是技术实现和技术实现之间的差别是什么？是软件的知识密度，是我们把什么样的流程、规则、数据做进了系统，所以笔者把这个事情定义为数字企业在管理上的一个任务：“旧知识转移”。尽可能把我们在业务过程中已经意识到知识转移到系统，而非转移一个单纯的业务过程。系统拥有了越来越多的“旧知识”，在一些新技术能力的加持下，可以与企业人员共同完成一个更有竞争力的任务：“新知识探索”。
无论是“旧知识转移”还是“新知识探索”，都离不开结构化思维，甚至是全局性结构化思维，这一思维也有一些其他的表述方式，比如系统观念，从笔者自己的专业角度，更愿意称它为“架构思维”，业务架构就是对业务流程、规则、数据进行全局性结构化定义的、可以被业务人员和技术人员都容易掌握的方法。
总结下，所谓的数字企业“321 管理法”就是面向业务能力布局去设计人与人、系统与系统、人与系统三大协同关系，完成“旧知识转移”和“新知识探索”两大任务，通过在企业中全面推动结构化思维普及，完成数字企业管理思维从上到下的全员转型，这种转型就是创造了一个碳基（人）、硅基（计算机）融合的“双基混合大系统”，从而使企业作为一个复杂系统对企业主动输入的“目标”和受环境影响被动输入的“信号”都能经过计算产生理想的“结果”，这就是一个“软件型企业”的内在处理逻辑，也是充分发挥数字生产力的逻辑。
在这个转型过程中，企业架构，尤其是业务架构，是推动业务侧数字企业管理思维转变的一大有利武器。
数字企业的需求膨胀如何解决
如果数字企业的管理逻辑按照上文的模式调整，那最终会催生更多的软件需求，在“旧知识转移”和“新知识探索”的过程中，业务人员表现越好、创造力越丰富，需求就越多，笔者在《聚合架构：面向数字生态的构件化企业架构》一书中所阐述的软件生产力矛盾：超大规模软件需求和较低标准化产出能力之间的矛盾，就会越突出。这一矛盾使我们的开发模式一直处于“大规模小团队手工作坊”的状态，也就是说，IT 行业规模很大，一些企业技术人员也很多，但是具体到项目上就是几个人的小团队在开发，实现上基本是手工业状态，没有大批量生产能力，只能靠加班赶时间、赶工期。
目前技术实现上逐渐增强了“开发左移”的趋势，通过 RPA、低代码技术让业务侧能够进行一定的低强度开发工作。RPA 也就是流程自动化机器人，让业务人员通过流程配置的方式，将一些重复的跨系统业务操作变成自动化的工作流，由“数字员工”自动完成。而低代码实现能力更强，业务人员可以在没有技术人员支持的情况下，通过低代码工具生成一些相对而言不太复杂的应用软件，这些软件虽然业务逻辑不复杂，但是如果采用传统开发模式还是需要一定费用和周期的，业务侧自己做，不仅节省成本，更重要的是让业务人员具备了一定的实现能力，可以更好地扩展“跨边界能力”，提升对技术工具和实现方式的理解。
低代码还可以面向技术侧提供更方便的系统升级维护能力，即便是ERP这样相对复杂的业务系统，也可以基于低代码平台先进行一次“全代码”开发，之后将部分可以通过低代码形式开放的功能转换为低代码维护模式，技术人员可以通过较少的开发工作量进行一定的升级维护，但是遇到功能模块新增之类的需求，还是要先通过全代码方式做好这个模块，再转为低代码方式维护，总体而言，还是能力节省力量、提高效率，其中部分能力也可以开放给业务人员自己配置，提高业务参与度。
这些方法都有助于提升开发效率，但是从软件生产总体效率的角度而言，既然同类型企业中有很多流程是没必要搞差异化，搞了差异化也不提升竞争力的，那么，基于行业级标准化的开发才是具有最好的外部性效果的手段，大家都受益，又不带来太多的威胁。行业级标准化对于支持大规模开发，尤其是中小企业根据自己需要改进自己软件工具而言，是非常有利的。
但是行业级标准化的形成有些难题一直得不到解决，一是标准化和定制化之间的矛盾，企业能接受基于标准化的改进，但不太愿意直接接受标准化；二是统一版本的形成，也就是基础软件库，如果是面向高度工业化的开发，那需要的不是行业里的某个标准版本，而是一堆标准零件，因为从零件出发进行基于标准化的定制化，比从整个产品出发进行同类操作可能效率会更高，至少工业中的标准化尤其是离散制造中，这个效率还是很明显的，软件是符合离散制造理念的；三是对零件库的高效检索，如果这样的零件库可以设立，即便分行业、分企业规模设计零件库，零件数量和可组合的复杂性也是很高的，无法靠人脑搞定，需要有高效的架构管理工具、设计工具支持。
所以，我们能看到一种通过行业及标准化零件库解决开发效率问题，来支持业务需求的高速膨胀，但是，实现它尚有很大困难。
GPT 带来了新曙光？
这轮 GPT 的发展有助于我们解决上述问题吗？应该是有的。很多 GPT 玩家在干的一件事都是训练 GPT 写代码，NVIDIA 的黄老师说以后可能不用像过去那样学习写代码了，虽然笔者对这件事没那么乐观也没那么着急，但是，GPT 可以提升技术人员的个人生产力是确定无疑的，尽管涉及一些知识产权问题，但是从各种开源渠道学习的代码样本、自身对程序的理解确实让大语言模型写代码的能力让人震惊，GPT-4 根据一张草图能做网站的事情估计动摇了很多人，本来大家就感叹现在在技术上做个全栈有多难，结果冒出一个不知疲倦、学无止境还没法拼手速的 GPT-4 来，这真是催人奋进也让人无语。
结合大语言模型的全民编程时代确实不远了，有程序员基础的人训练 GPT 的效果肯定会更好，而且计算机在本科基本上是普及教育了，稍微认真点儿，都能有个不错的编程基础，在这个条件上再累加 GPT 的能力，那全民编程确实不是什么难事儿，效率也未见得差，主要是从业者素养的转变和生产力的释放是毋庸置疑的，如果大语言模型应用真的全面走进企业，那么大约 2-3 年之间，就可能让一个企业的应用能力脱胎换骨了，这里笔者指的不仅是技术侧，也包括业务侧自身的软件生产能力，因为类似的情况笔者在某些企业对低代码应用的普及上见到过，大语言模型可以释放的力量显然比低代码更强烈。
当然，笔者认为大语言模型不代表我们真的能用“一句话需求”就直接走进开发了，像 GPT-4 演示的例子，需求者至少得画出网站的结构图吧，这其实需要功夫的，没有良好的结构化思维能力，没有一定的架构功夫，跟大语言模型的交流也会低效，所以，为了能跟大语言模型好好聊天，为了能有一个高效的编程助手，业务人员还是要像为了跟技术人员提升沟通效率那样，提升下结构化思维能力和架构能力。
这个能力的提升还是十分必要的，毕竟，有些应用软件功能不复杂，业务人员可以通过有效“诱导”大语言模型产生出完整的应用，但是，有些业务系统还是很复杂的，越是复杂的编排可能越代表了复杂的语义，复杂的语义在语言理解上也容易出现歧义，人与人的交流也是如此，所以，有效地将复杂业务切分为小的构件，由大语言模型生成小的构件，再通过类似低代码的编排能力生成更复杂的应用，也许是较为高效的方式，也就是架构思维、GPT 再加低代码技术。这些即需要技术平台的持续演进，也需要使用者自身能力的建设，尤其是在架构层面，对复杂业务的架构能力可能是我们最后的“防线”。
GPT 可以带来的也许还不止是助手这么简单，笔者上文提到的关于采用行业级标准化构件的方式提升开发效率的问题，其中一大困难就是对零件库的高效检索，有时候并非技术人员不愿意复用，而是检索需要的代码、对代码进行修改耗费的时间可能还大于自己动手的时间，这也会导致复用意愿的降低，但是如果有GPT 助手在中间，这个效率可能就不同了，GPT 不仅能够快速检索可用代码，也可以在技术人员的指导下进行修改，复用的效率会高很多，所以，这种条件下，开源标准化的思路就有了可以高效利用的场景，这种逻辑关系如下图所示：
通过 GPT 去检索构件库，获取企业内部的企业级标准化构件和企业外部的行业级标准化构件，再进行修改产生个性化构件，而用途理想的个性化构件可以再返回到企业级标准化构建库，并通过行业级共享机制回补到行业级标准化构件库中，技术人员甚至可能是业务人员通过与 GPT 助手共同进行的交互式编程，完成新应用的构件，在这一构建模式下，可以相对高效的兼容标准化和个性化，并且新的设计结构还能够返回到构件库中。当然，这种模式仍然需要对构件库的索引、知识产权问题做进一步的设计，但是从模式上来讲，GPT 助手的出现可以有效解决构件检索以及标准化与个性化的冲突问题，毕竟 GPT 可以自己对新构件进行良好的注释并从注释中提取构件描述，从而对构件的再次复用起到良好的设计指引。
在这一模式下，业务人员和技术人员之间共同开展的架构设计，从业务架构、数据架构到应用架构的划分，将是开发中最需要由人工澄清的部分，之后，基于这种结构划分的交互式编程就可以通过 GPT 助手快速地进行下去。在业务人员和技术人员的架构设计环节中，如果由架构治理工具结合 GPT 提供辅助的话，对架构资产的检索效率也可以提升，但是其效率可能没有编程的 GPT 助手效率那么高，因为这一时期的需求构思仍需要一个人脑澄清过程。
大语言模型确实能够带来一个开发模式的演进，也就是笔者说的“贾维斯时刻”，我们通过 GPT 助手加强对标准化构件的利用，进而实现更为高级和智能的低代码开发平台，其与架构治理工具结合，也会使架构设计效率有一定的提升；而架构设计的提升，又会进一步增强低代码的覆盖能力，低代码的覆盖能力又会提升对标准化构件的使用，进而提升 GPT 助手基于标准化构件的个性化定制能力，这会形成一个有益的循环，而循环的关键是 GPT 助手可以解决技术人员在构件描述和复用方面的准确性和效率问题，既能解决个性化需求，又能解决过于个性化造成的不利影响，当然，这影响的消除是因为 GPT 助手可以高效地检索海量的构件库，所以，我们不必担心具有多个功能相近的构件产生的构件版本问题。不具复用价值的构件，可以根据复用情况逐渐从构件库中进行剔除，由复用度高的构件进行替代，这种模式提高了通过实测提升构件标准化的可能性，而之所以可以进行此类操作，其前提正是 GPT 助手对开发效率的提升。
大语言模型的应用可能会为我们在实现标准化与个性化的平衡中走向基于标准化构件的软件大规模快速工业化开发提供可行路径，而且，笔者认为，我们不应该由于 GPT 助手对开发效能的提升而走向更加手工业的路线，那样似乎“可惜”了 GPT 助手的价值，我们要迎来的应该是全民编程的构件式工业化软件快速量产之路。而软件的大规模快速构建能力也是未来综合国力竞争中的一部分。
我们还是要加强结构化思维的普及
GPT 助手虽然能力很强，但是掌握正确的沟通方式才会带来最高的效率，所以，企业全员的结构化思维提升势在必行，这种思维的提升并不复杂，我们梳理业务流程、业务规则、业务数据就是在将结构化思维用于业务的优化和梳理，通过这种方式梳理业务，识别业务能力，确定业务能力布局，其产生的结构化分析结果会充分提升通过 GPT 助手准确开发新应用的能力。
很多企业都认为业务人员的数字化转型很难推动，这其实是没有将焦点放在最应该做的基础能力提升上，甚至误将精力放在一些特殊技术的深入学习上，其实就业务人员而言，数字化转型的基础能力正是结构化思维能力，通过学习业务架构、数据建模可以较快获得结构化基础能力的提升，而企业内部提供通过业务架构进行业务优化、战略落地的实践，则可以充分锻炼这种能力，当这种能力遇上 GPT 助手之类的高效生产工具时，其可能释放出的潜力是非常值得期待的。
大语言模型的出现让很多人担心劳动岗位替代的问题，但是，在笔者来看，首先要“瑟瑟发抖”应该是企业当前的开发模式，这是释放工具潜力的关键。而开发模式的调整其实也是企业管理思维的调整，围绕“321 管理法”去构建数字企业的管理思路，再将工具的作用发挥出来，这是整个企业的业技融合。架构思维、GPT “贾维斯”助手、融合架构治理的低代码平台，可能会产生从企业管理层到业务人员再到技术人员的一个“结构化思维”冲击波，也许可以认为企业的经营管理还是有很多经典东西不会变，确实，但也有很多东西一定会变，新的经典正在路上。
作者简介：
付晓岩，北京天润聚粮咨询服务有限公司执行董事、总经理；数孪模型科技高级副总裁，原互联网头部企业数字企业架构团队资深总监（P9级）；原国际著名咨询公司企业架构交付总监（Band 10级）；原国有大行企业级业务架构师，银行从业20年工作经验，其中业务条线12年，IT条线8年，复合型人才，《企业级业务架构设计：方法论与实践》、《银行数字化转型》和《聚合架构：面向数字生态的构件化企业架构》作者。
☞程序员再“整活”，在 Dos 上也能玩 ChatGPT 客户端！ ☞亚马逊云科技 Serverless Data：数字经济下的创新动能