漫谈从交付视角来看框架的迭代
**简介：作为一个15年入职Oracle部门的“老”人，走过了Oracle从本地到云的发展，使用了Oracle体系下二开积累的HSS、HDSP等自研产品，经历了后续HAP、Hzero的发展，实施了基于两个框架的产品实施，从产品、框架、实施来看IT交付的演变。**
**当然，作为交付部门的大头兵，更多是从项目实施的角度来看这个事情，并不是在谱写我手司的发展史，所以一些思考跟观点只代表个人意见。**
**另如有偏颇，敬请斧正。**
** 降本增效”是一个组织持续发展的长期实践 **
在这两年，无论是因为疫情的持续影响，还是因为国际局势的持续紧张，可见的是我们正在经历又一轮经济的下行；特别是在互联网带来消息的便捷性、还是受众的广泛性，各大厂的毕业讯息，一波又一波的在增加着我们的焦虑。从大厂来讲，优化掉边缘以及盈利模式尚不清晰但又持续高水位投入的业务，可见的能够消减企业的运营成本。
从经济发展规律简单来讲，经济发展对于处在其中的人来讲，带来可支配收入的提升，从而带动需求的扩大，进而因供需关系导致的价格上升，因
而也反向拉动了对收入提升的要求。
而对于一个IT服务行业的公司来讲，其收入增长极度依赖人力资源，要么提高交付效率，用同样的人力规模创造更多的价值，要么快速扩张，用更多的人来支持更多的项目，而当人员规模上升则会带来管理成本上升与整体交付效率下降。
综上来看，手司的各种调整背后的核心逻辑都是在想方设法的提升交付效率，带着这个核心逻辑，就能理解各个阶段的发展为什么走向了当前的结果。
** 从标准化到产品化，从HAP到Hzero **
HDSP标准化是怎么出现的
由于进公司时候EBS已经进入了R12的版本了，同时处于快速发展阶段后期，经过了超过13年的行业与产品沉淀，对于标准功能的研究与使用可以说是已经炉火纯青了。同时，在这个阶段，还处于移动互联网全面发展的初期，外部诱惑尚不具备吸引力，所以沉淀了一大帮行业沉淀深入、个人能力突出的大佬。而服务的行业，主要也分布在公共事业等重资产行业、大型制造集团以及跨国公司，这个时候更多提到的概念是信息化。
这个周期的实施更多是在做best
practice的行业推广，因为汉得的行业沉淀与头部企业的成功实践方案，因此也更容易在行业的其他公司的ERP系统建设需要中，成为中选供应商。
这个环节也是由于刚进公司进了一个新搬迁的钢铁企业的优化项目，因为行业内基于OPM +
PMAC建立的成本费用归集与管理分摊方案已经基本完善了。因此在做的是把另一个项目上比较完善的程序迁移完成之后，基于新客户的数据规范等做适配性改造。可以理解为这个环节已经形成出了一个行业比较成熟的标准化方案跟功能了，解决了很大的一笔研发与测试支出，将主要的工作落到了差异化改造上。
通过上述这种方式已经在顾问的能力要求上降低了非常多的标准了，原来一个资深业务+ 技术经理才能干的事情，通过上述这种模式实现了一个初级业务 +
初级技术就能在项目风险可控的范围内完成原来复杂的平台实现。
而标准化正式在上述的模式中复盘跟总结出来的，既然一个开发，绝大多数项目都在用，那么通过一个项目构建初版，两三个项目打磨成熟，把配置相关的差异化内容独立出来，就构成了一个通用性的功能。这一点在数据初始化环节的WEBADI或通用导入的工具体现的淋漓尽致。
既然这个模式能够降低项目成本、减少项目开发、控制项目风险，同时有效降低项目对顾问资源的能力要求，便通过技术部门牵头，归集整理了一系列的HSS与HDSP的标准接口、导入工具、报表与平台。
这个阶段的的逻辑是在标准套件实施中，通过提高标准化产品的应用占比，实现对项目人力成本的控制（降低资源能力要求）与交付周期的缩短（减少开发投入），从而提升交付。
HAP是怎么发展起来的
随着企业内部管理的进一步成熟，更加细节与个性化的管理控制内容，对企业内部的核心ERP软件也带来了更多的二次开发的需求。而同时，互联网的蓬勃发展，网页浏览的体验优化，也提高了用户对于内部系统的使用便捷性与操作友好性的提升。
而对于ERP的交付环节也出现了两个发展方向，一类在ERP产品深化应用以及深度二次开发上持续挖掘，更加复杂的开发带来体验与运维的难度提高；一类通过java套壳的方式，为用户提供更好的体验，毕竟对比OAF开发，java构建的自由度更丰富，而且这个模式在售前展示给客户时，越来越多的客户也在要求脱离form的操作模式。
而中台概念的适时出现，也给产品定位提出了一个新思路，毕竟ERP太强大也太重了，可能一个业务只会用到表单中1/10之一的能力，但是剩下的9/10带来的用户疑问跟使用体验则严重影响实施环节的进展。那么把ERP其强大稳定的逻辑能力作为后端，将简单的单据录入以及处理放在中台似乎是一个比较好的方案。
开始的HAP便是挂在Oracle之上的一个产物，由于每个项目都有这样的需要，那么把这个外挂的工具标准化，是不是能够在这个过程中提高此类项目的产出呢。而客户对于体验跟性能的要求则带来了进一步的发展，就是从外挂直接调用Oracle
API发展成使用Oracle标准接口异步同步，而外挂的HAP雏形实现从权限、表单设计标准化、数据存储标准化、报表工具标准化能力。这个阶段的一些实践也就成了现在汉得几个子公司的产品雏形，比如：SRM、结算、合同等产品。
但是随即又面临了另一个问题，就是形成的这些产品雏形，必须依托于Oracle的库，而如果客户有使用ERP还好，客户要是没有的话，就需要花费大价钱去获取商业license，那么这个产品的很大一部分成本将会在给Oracle贡献纯利润从而失去市场竞争力，因此，基于Mysql的异构工作就成为了第二个阶段的发展。
这个阶段的逻辑是在通过标准化外挂开发工具，减少各个项目在实现ERP能力外迁与细化过程中的重复工作提升交付效率。而后逐步形成相对成熟的产品构建新的收入来源。
为什么会走向Hzero
随着移动互联网的进一步发展带来移动化的应用需求的提升，无论是对于独立APP的需要，还是随着钉钉、lark、企业微信在企业中的逐步铺开，对于系统的服务能力，不再仅仅限于PC端的单体应用。
这也就意味着，相同的能力现在不仅仅要提供在PC端，更要面向移动端app、IM应用等更多的移动场景使用，这也就意味着，更多的规则沉淀在了服务定义与服务的编排上，回看HAP框架，在适配这个场景上是存在比较多的重复工作与运营成本的。
因此前后端分离、负载均衡、分库分表等一系列基础架构的能力成为了IT项目交付的基本配置，而一个能力比较全面的技术基座，能够减少构建应 用时在高级别技术的需要。
同时由于各友商平台的服务能力的标准化，比如标准化的电子签能力、标准化的发票查验能力、钉钉与企业微信开放接口等，也为应用的外部衔接能力，构建了基础。
这个阶段的逻辑是在通过标准化基础技术平台，沉淀通用能力，通过集成开源、外部友商开放服务等能力，减少在项目开发中在通用能力上的重复建设。
站在短期来看，因为大量的研发支出，拖累了整体的业绩表现。但是一个技术中台不会持续性处于的大规模投入阶段，一定会存在成熟稳定期，再次将研发能力释放到交付或产品研发。站在长期来看，成熟的技术底座，对整体项目来看，一定会有效降低后续项目在领域上的成本支出的，也相对降低了交付技术对知识领域的要求，对后续项目开展是一个增益与助力的过程。
同时，通过架构在H0上的项目实施实现对产品的反馈与改进，推动自研产品的完善与市场影响力，毕竟产品的成熟会带来交付环节开发成本的显著降低。
鸡零狗碎的漫谈
上面从交付视角啰里八嗦的把接触到的标准化产品与框架迭代做了回顾，本来还想从实施方法、组织架构、项目人员构成等角度来谈谈这个事情的，但是篇幅就太长了，留点内容下次再聊。
回头来看，IT应用框架的发展最终结果依然落在了敏捷高效的服务业务，做的事情，还是在于通过工具的完善，降低交付能力要求与减少重复工作提高交付效率以达到降本增效。同时作为工具的框架再先进、功能再全面、研发投入再多，如果没有架构在框架上的产品或解决方案来适配客户业务、解决问题、带来客户的降本增效，客户也不会buy
in这套没有战略威慑与战术打击能力的“航空母舰”，毕竟这个行业是为解决问题而存在的，而且不同客户环境不同，没有通用解，只有有效期间内的最优解。
所以对于业务顾问来讲，掌握Hzero的能力是工具，其价值在于通过能力的规划与复用，让你在项目上事半功倍。而掌握业务领域头部的best
practice，行业不同发展阶段的解决方案，同时能够基于客户现状输出业务与流程改善建议以及IT建设规划与产品选型，才是价值的体现。
**E · N · D**
作者|审核：熊旭 东
编 辑 ：朱思聪
