这个软件系统是如何为企业创收的？——深圳兴森科技ESM实施简报
2021年国庆节之前，笔者收到深圳兴森科技ESM项目机会的时候，正在北方出差，在当时北方“无上清凉”的气候环境中，着实感觉是个好消息，有在“管理成熟度方面”一心向善、并且利用管理软件“增收”的客户就很好！一个“业务需求”(Business Demand)经过一系列工作变成“运营状态的服务”(Operating Services)，新的收入渠道就有了。他们利用管理软件提升业务服务健康度、杜绝业务漏洞、利用流程化打破“部门墙”与各种“系统孤岛”、降本增效、同时又提升工作者的工作体验。当然，关键是，他们理智地决定“不自研非本单位主营业务之软件”。
ESM系统相关的思考
磨刀不误砍柴工，借着介绍项目案例的机会，我们首先顺便讨论讨论国内上ESM管理软件必需的一些思考。
ESM除了传统的ITSM概念扩展应用之外，还有一点颇为实用、颇为特别：ESM其实也是一种“服务创收管理系统”。服务本来就能够变现挣钱，更何况是利用一套成熟的服务管理系统来滴水不漏地变现呢？一个“业务需求”(Business Demand)经过一系列工作变成“运营状态的服务”(Operating Services)，新的收入渠道就有了。
例如，一种简单的情况是，某科技公司给客户新开通了一种售后服务“定期做系统巡检”，经过相关的“服务设计”(Service Design)之后，纳入服务地图，那么这个当然是个收费项目，相关的现场工程师巡检工单从此在系统里面有所记录、并且作为可以追溯的收费依据，这不就是一种“企业增收系统”的表现吗？而比较复杂的情况例如，某科技公司新开发的一种软件平台是服务客户的，那么刚开始的“服务需求分析、服务设计”就需要一系列的工作、并且有相关“服务投资人”(Service Investor)与“利益相关人”(Stake-holders)的审核，然后软件平台的开发或者采购也需要相关的“服务变更与服务交付”工作，然后该服务进入“服务运营”阶段，开始正式发挥作用，企业由此多了一个创收渠道。ESM的这些最佳实践也一样是符合 ISO20000国际标准的。
又如，某基金公司新开通了一项基金服务，也经过相关严密的“服务分析与设计”之后、纳入服务地图，从此该基金就多了一个收入来源。
而服务地图的“服务健康度监管”作用，则让管理者能够及时发现业务漏洞、流程漏洞。如果流程执行不力、服务效率有问题，则相关服务会在地图里面标红。由此，杜绝业务漏洞带来的降本增效，也从另外一个角度增加了企业利润，也是一种增收。正所谓“一图在手，老板无忧”。
【关于“为了管理而管理”】有朋友说，国内不少单位上管理系统都是“面子工程”，是为了给领导看、给参观者看的，标明自己单位这方面“与国际接轨”、“引入先进管理体系”。这种情况客观来讲肯定也是好事情，因为毕竟先进的理念会逐步渗透、慢慢地给人们带来一些观念改变。但是还有一种情况是另外一个极端，“我们不需要面子工程，也不想为了管理而管理，所以国际先进的管理体系我们不考虑”，处于野蛮生长期的企业尤其会这么想。国内的大企业家参观美国硅谷的同行业公司，就发现自己号称国内一流的管理水平，跟人家美国同行没法儿比，所以效率就明显不如人家。“降本增效”不是挂在嘴上说说的，需要具体的体系、软件工具、执行与实施。长远而言，谁不注重降本增效，谁的竞争力肯定就会越弱。
有一种说法，直接用道理教育人们、扭转他们的观念是很难的，但是如果他们自己遇到事情了、被事情教育就会真正有效。南方的一个很大很重要的数据灾备中心，里面的驻场外包服务工程师已经在那里工作了多年，业务操作颇为熟练、和客户的关系也很好；但是有一天，系统出了一个故障，他因为种种原因，就没有上报；随后这个系统故障引发了连锁反应、出了一连串问题，被该中心的领导向服务商严正警告投诉。那么，出了这样的漏洞，管理者自然就会反思，没有一个ESM管理系统和服务地图(Service Map)来严格跟踪所有的业务服务相关事件(Event)、告警(Alert)、故障或者严重事件(Incident)，后果会如何？上了ESM服务地图，所有的系统故障会被各种相关的监控工具自动抓取，然后流入流程系统、服务地图上相关的服务色块会标红、管理者能够逐层打开追溯具体出故障的节点。紧跟着系统会自动确认优先级、自动指派负责人(这种自动化、国际标准称为Automation)。如果该故障无需指派工程师手动解决、而是能够触发相关的“自动化修复脚本”、那么这种自动化、国际标准就称为Orchestration，然后，系统恢复正常、该服务模块呈现绿色。如果该故障尚未解决，则服务地图色块会持续偏红。单位里面各种业务服务的健康程度就这样得到了有效的监管。
题外话：朋友们可以顺便留意一下，上面有三个英文词是国际ESM行业标准用词，表示业务服务可能引发的事件与问题的三个层次：最底层的是事件(Event)，里面能够产生负面结果的，就可以提升为告警(Alert)、Alert里面必须找出解决方案予以处理的，就必须提升为“故障或者严重事件”(Incident)。这些术语英文表达颇为精准，而翻译成汉语反而总觉得“差那么点儿意思”。
还有一个部分是关于“软件是否应该自研”，是在本文末尾附录里面的，欢迎参阅。
兴森科技ESM项目实施简报
---有限的披露
【客户简介】深圳兴森科技成立于1999年，为深交所上市企业，公司总部设在中国深圳，并在广州、江苏宜兴及英国建立了生产运营基地；目前海内外已建立数十个客户服务中心，形成了全球化的营销和技术服务网络，为全球四千多家客户提供优质服务。公司致力“成为世界一流的硬件方案提供商”，立足印制电路板制造服务，积极打造板卡业务、半导体业务、一站式业务。公司未来的目标是在PCB样板及多品种小批量领域建立起全球规模最大的快速制造平台；并将构建开放式技术服务平台，打造业内资深的技术顾问专家团队，形成电子硬件设计领域通用核心技术的综合解决方案能力，结合配套的多品种快速贴装服务能力，为客户提供个性化的一站式服务。
【项目经理手记】
项目开始时间是2021年10月11日，项目部署之后、用户试用到2022年2月底，然后开始正式项目实施，2022年4月19日项目实施完成。
项目实现细节的特别之处：用户手机端使用企业微信报障；工单执行满意度是在客户的OA系统里面“待办”中进行评价。
【关于客户痛点与相关的国际标准】按照高瓴资本的说法，只要能够解决客户痛点、能够给客户带来实际价值的企业、肯定都有生存发展空间、都是值得投资的一个基本条件，此即所谓“价值投资”理念。当时从客户沟通的情况来看，IT管理的痛点是确实存在的，例如、我们项目经理Harry后来记录的：
1、低效率的信息传递渠道。工作信息在IT服务人员之间只能通过文件或是电话传递，一方面导致问题处理速度缓慢（甚至由于工单的遗失，问题没有最终得到妥善解决），引发业务部门的不满；另一方面由于无法控制工作流程，业务部门更加倾向于直接与各IT服务人员/管理者沟通（以期获得更好的服务），从而进一步加剧了工作的无序状态。
2、个人经验无法有效地转化为企业知识。运维人员依靠自身经验解决故障，没有统一的知识库，工程师无法进行经验共享。
3、IT部门主管无法及时、全面地了解工作的整体状况。IT服务人员虽然一天到晚四处奔忙，但还会经常收到业务部门的投诉，主管不知缘由。
这些混乱无序情况、英国军方的后勤技术管理部门在二战期间就遇到过，所以他们赶快安排制定了相关的流程化管理标准，以保障战时技术服务工作的有效管理，不然战争所依赖的高效技术保障都恐怕无从谈起。这就是服务管理国际标准“ITIL”、“ISO20000”最早的由来。二战给人类带来的不光有武器技术乃至后来“军转民用”的快速发展，还有管理水平的提升。不能不佩服，当时依然属于“日不落帝国”的英国人纠错能力极强。英国人最早发明那些“ISO”管理最佳实践、国际标准的时候，他们有个基本想法，工作人员可以不精明，但是只要按照流程化管理来走，不会因为不精明而干不好工作。工作效果不依赖于相关的人员是否精明强干。
与这套国际标准匹配、帮助企业实际落地这些管理理念的是我们国津科技的ESM流程管理系统、包括ITSM系统。
本项目用到的用户需求说明书之部分截图如下（图中URS即 User Request Specification），仅仅作为参考样本给朋友们分享。里面除了节选的需求列表之外，还有一条简洁而且比较典型的“事件管理”流程：
而上线ESM系统之后的价值就至少体现在如下几点：
１、提高工作效率：普通用户可以通过一个统一的平台去提单，IT服务人员可以通过系统进行自动配单处理，整体工作进度可以通过ITSM系统进行查看，使得工作能够快捷、有序进行；电子工单的记录有效解决了纸质工单和电话通知造成的历史工单保存不完善的问题。部门主管能够及时了解到每个技术员的工作量等。
2、知识能够传承下去：通过系统的知识库，将个人经验转换为企业知识，能够将公司的知识、公司的文化传承下去。
使用ITSM，主要是为各单位提供稳定、安全、持续的服务，提高工作效率，降低IT服务风险，节省运营成本，实现服务请求高效流转和快速解决。有相关的“系统验收功能测试记录”、“服务目录”和“请求规则”可以参考：
系统验收基本功能测试记录（参考样本）
附录
关于“软件自研”的思考——ESM系统思辨之二
有朋友说，对于这种流程管理软件，稍有实力的公司是可以自研（自己开发）的吧？
先分享给朋友们一个真实的情况，而且这种事情我见过不止一次（因为我们公司给客户实施ESM软件已经十三年了，历史足够长就有这个好处 —— 友商可能还没有遇到过的，我们已经见过好多次了）。什么情况呢？就是客户提出了30多个实际工作场景，要求软件厂商现场拿着软件系统来录入样本数据、现场操作演示出来，例如，“如果某个业务服务因为技术过时等等种种原因要退役了，完成了其生命周期，经过相关流程退出服务地图；同时相关的配置项、产能等等资源也都要重新纳入ESM资源池、以利于后续重新分配产能；请你们演示一下相关的流程操作、场景操作，谢谢！”
姑且我们就只列出这一个用户实际场景，我们想问问，决定“自研”的朋友们，你们在自研的计划或者过程中，有谁能够最起码有个意识是、管理软件最终是要落地为用户要的数量繁多的复杂的实际场景的？然后，又有谁能够有个意识是想办法搜集到客观上存在的一千多个用户实际场景(Business Scenarios by Users)、并且还要确保自己的软件设计逻辑足以实现？这可不是你们有多少优秀的架构师、优秀的Java程序员、优秀的AI科学家就能够解决的。这也是为什么，那么多厂商数十年来挑战SAP，最终SAP还是那个全球ERP的Number One. 人家的场景咨询累积在那里摆着的。
关于上面说的客户提出的30多个实际工作场景的演示要求，我不止一次听说，我的一些友商拿着他们的产品甚至一个都演示不出来。
十余年来，我们见过若干自研的实际案例，且不说他们对相关管理概念的专业理解深度如何、里面复杂的业务底层逻辑究竟是否熟悉了解，且说他们过两三年、连自己维护这套软件都难以为继、无力迭代，更何谈持续创新？
笔者亲手参与服务地图相关功能的软件设计、逻辑设计，深知其中逻辑的复杂性，远非表面看起来那么简单。所以为什么大型管理软件例如SAP、专门会产生一个“SAP咨询”这个专家级别的行业、而且全球五大咨询公司都乐于参与？管理软件的实施、如果没有相关的咨询专家、其实根本就无法有效进行。不光SAP、其它的管理软件都一样。笔者在深圳几年前亲眼见到，一个很大的央企、竟然被金蝶财务软件实施与售后中的种种服务低效问题搞得颇为头疼、找我们国津团队咨询流程系统来解决他们实施不顺利的种种问题。
如果自研，且不说研发本身投入的各种人力成本、相关的咨询成本、管理成本、维护与运营成本；更关键的是，长期而言，软件产品的一个很大的特殊性在于、软件本身都是有生命周期的，自研也要考虑这种生命周期、这样其实长期的迭代成本就超高。我亲眼见过某金融行业大单位就发生过这样的事情，几年前和我们交流产品的时候、不听我们的建议，说决定自己研发。结果三年后他又给我打电话，说单位的系统出大事了，被领导批评了一顿，又决定采购市场上的成熟产品。
有国内的软件行业大咖朋友跟我说，国外的软件公司都是相互合作的、大家共同把产品生态做好、每个公司聚焦于自己的“定位”(Positioning)。美国同行Servicenow做了全球2000强的大部分企业客户，要价都不低，从未听说哪个数亿乃至数千亿美元营收的外国客户对Servicenow说：“我要自研！”。他们为什么不说：“我自己研发的东西更加可控”？因为他们深知，长期而言其实并不可控。笔者曾经在外企工作过多年，也曾经在英国工作过一段时间，据我观察，老外的思维里面、根本就不可能有半点自研一个跟自己主营业务不搭界的专业管理软件的想法。查理芒格说，“不要做Crazy的事情！”
国内则不然，不少大单位明明自己研发的东西不能用、不专业，但是还是要自研，因为对管理软件研发的客观情况其实不太懂。结果成本投入了、几年后终于醒悟发现是个巨大的浪费。想吃鱼，就去市场买鱼就好啦，为什么要自己挖鱼塘、引入鱼苗来养鱼？记得有位企业家说，“客观规律不尊重、现实情况不敬畏，那么过几年的后果都是自找的”。笔者深以为然。
