供应商关系管理（SRM）是用来改善与供应链上下游供应商关系的，是一种致力于实现与供应商建立和维持长久、紧密伙伴关系的管理思想和软件技术的解决方案。旨在改善企业与供应商之间关系的新型管理机制，实施于围绕企业采购业务相关的领域。

随着数字化营销的展开，如何依托SRM来提升供应链管理的效率，在CIO发展中心旗下的高科技群内，某企业的CIO M总就发出了这样的疑问：A供应商负责上百家客户的供货业务，A需要进入这百家客户的SRM系统进行管理。他想知道，有多少供应商实现了一套平台对接N家客户的SRM系统？客户方并非供应链的链主，花费大力气也无法推进供应商注册登录到我们SRM平台，大部分都是自己来录入信息，这个局怎么破？

针对这位CIO提出的问题，某企业的H总认为：“不管是客户端，还是供应商端，都需要自身具备足够强大的影响力，能带来更大的收益，上下链条方才能顺利配合。例如，目前一些行业的头部企业打造了自己的工业互联平台，除了满足自己使用，还共享给小企业使用，掌握了话语权。”

对此，群内的L总也提到：“CRM的客户社区也是如此。大客户是否愿意进供应商的系统处理业务？长期合作的合作方大多都可以支持与配合，包括系统集成的方式。甚至有些还包括INTEL主动要求对接，做好相关的权限与授权管理即可。”

某航天企业的G总则认为这是一个发展中的问题，很难一步解决。具体发展方向可能有2条路径：一种是强化供应链集权的背景下，从分裂割据逐渐走向兼并整合（不论是自发的还是第三方主导的）；另一种是摆脱供应链集权转向扁平化，搭建一个独立于特定供应链的厂商信息平台，在这样一个平台的基础上，可以为不同用户定制供应链管理模块。

客观来说，SRM在近几年的发展比较迟缓，依然处于传统采购过程线上化的阶段。对此，有群友认为在真正实现平台化之前，SRM的厂商应该率先发力，来推动对接的标准化，从而为平台化打下基础。也有群友表示大部分厂商的推动力天生不足，除非是SAAS产品，产品本身规范性好，否则都是按照客户要求进行。因此，还是某个行业的头部企业强力推广做大，这样行业内小企业跟着入平台，可能是一种更好的解决办法。

就在这时，群内的一位群友D总，联想到了之前与某厂商合作的过往，便拉开了吐槽的话匣子。他说到：“去年我们与某知名厂商签约实施SRM系统的合同（本地化布署），到现在还未上线。在签约前厂商表示有70%的业务是相匹配，签约后，经过实际调研，变成70%需要修改或开发！我都不知道为什么差距会那么大？”那么对于企业来说，究竟应该怎样处理自身与厂商的关系，来保证项目的顺利落地并实施呢？

CIO如何保证项目顺利落地

对于这位群友的遭遇，L总也再次发表了他的看法：“平台或系统策划，有条件时一定要自己策划，不要过度依赖合作方。因此我们一贯坚持：方案自主，系统可控！”同时他还向大家分享了他的一张预警图（如下）。

L总补充说：“在立项前，我的蓝图方案实际就已经全部出来了。例如，哪些是标准功能，哪些是配置，哪些需开发，能实现到什么程度，哪些坑，坑在哪，基本了然于心了。其次，我会明确核心诉求、解决的主要痛点，哪些本期实现，哪些分阶段走，内容明确、边界清楚等等，这样更利于项目的成功实施。” 谈及项目成功的标准，大家一定会提出这样的疑问，那么该如何来衡量项目的成功与否？有哪些判断的标准呢？L总也分享了他的评估标准。 

第一层级-起步阶段：范围内需求全部实现、预算受控、计划受控，顺利上线。 第二层级-应用推广：系统主体功能能用起来，数据能跑出来，数据逐步准确。 第三层级-上线成功：主业务全面执行，运营数据与报表全面输出； 业务角度：运行顺畅，运营仪表盘与报表数据准确、实时。

系统与业务运营仪表盘与报表趋势：呈正向发展趋势，稳步接近目标或超越目标；公司经营管理层能对数据进行分析、洞察。核心评价要素：经营指标呈正向稳定发展趋势！

如今随着数字化的逐步深入，IT部门迎来了前所未有的机会和挑战。企业数字化转型，IT部门必须站出来，做转型工作的推动者。对上要争取领导重视和支持，对下要培养数字化技术人才、建立数字化技术体系，中间还要做好技术和业务的衔接。大家的讨论点也由如何促成项目成功转向了IT部门在项目中扮演的角色，以及未来的发展机会。

IT部门在项目中扮演什么角色

首先来看群内B总的观点，他为我们总结了项目失败的几个关键因素：

管理层和业务期望值过高

业务本身没理顺，希望通过系统改善

不关注数据、变革太大等。

他认为IT的价值最终都是靠业务运行改善体现出来的，因此IT部门要“成为业务”，往运营端走。

IT不但要懂业务，同时还要具备多种能力，当前SaaS厂商对于实施交付，都是定义为“客户成功”的角色。但客户成功只是美好的愿景，甲方各家都有各家的难处，乙方同样要考虑越来越低的年租费、产品费能不能cover住客户的痛点，所以只能抓核心点去突破。这个“核心”可以是某个具象的痛点，也可以某个具体的角色。大多数有更高价值的诉求，都是必须多种IT能力组合才能完成的，所以要懂得取舍。

E总谈到：未来的CIO应该是从业务端走出来的。难者不会，会者不难，现在的SaaS产品经理还是以功能为导向，产品和顾问脱节，顾问变成了高级销售。事实上这样无法真正的为客户解决问题，最终沦为工具。现在的打法是把厂商视为资源，把系统视为工具，但是真正数字化的能力是买不来的，只能自己搭建。我今年主导的4个项目，除了一个业务属性比较强的SRM我会采用成熟产品+二开的方式，其他三个项目都是基于LCAP的自主开发。

所谓“只强调‘道’，不讲‘术’，难以服众，还是适用于各个环境下才能证明是可行的方法论。”B总也表示：道术应该都要，天上和地上都得抓，要有规划，顶层设计，也要有实质性交付，还要群众基础来证明。业务问题的解决是多种因才能造就果。中间是需要自身硬的部分，不能完全依赖厂商。

在讨论中，H总提出了一个角色——BPM，他认为这一角色很大程度上能够平衡业务与IT之间的关系。

很多群友也认为这一角色能够在一定程度上让IT部门更加容易开展工作，也有企业将这一岗位称为“业务BA”。在数字化转型的过程中，离不开IT与业务部门之间配合，需要有人来整理和翻译业务部门的需求，并按照一定的方法论开展，有了这样的桥梁，那么IT部门也将更加得心应手。如果没有专门的BP、BA的团队，IT或者业务部门的流程变革能力就要很强。所以，看起来目前数字化的瓶颈还是在于“组织”。

对于以上提到的“IT成为业务”的观点，群内的Z总也分享了他在过去实际工作中面临的一些挑战：

“IT往业务运营走”，传统企业的IT被认为是支撑，甚至部分制造业，CIO隶属汇报给CFO，很固化的文化共识中，IT“不具备”思考运营、业务的能力，这个文化的转化，是个关键点；

“IT成为业务”，首先，并不是所有的企业中IT组织都具备形成独立业务的合理性及基础，强扭的瓜可能不甜，且会不会舍本逐末？其次，“补位不越位”与业务双轮驱动，共生共存会不会是直接“成为业务”之外的一个选择？

当下很多企业都比较年轻，业务也无法很快明确自身的需求，或者是需求碎片化，比较“劳民伤财”。因此，不论是IT要懂业务还是业务要懂IT，都需要时间的沉淀，所以BA这一角色应运而生。业内普遍有一种说法是：IT要超前业务。对于这一观点，群友们也分别发表了自己的看法，有人认为IT要适当超前于一部分业务，尤其是内部的业务专家或者BT团队。也有人谈到想让IT领先业务，非常困难，除非IT人员都是乙方出来的，况且大部分企业都是业务领导IT，IT难以自身处于领先的位置。

基因是天生的，但企业诉求是趋同的，在不具备更常规、更快速、更直接基因的企业中，如何找到解决数字化转型的路径值得深入思考。

其实与其谈论谁领先谁，倒不如具体问题具体分析，让IT和业务在变革过程中成为共同体，支配角色并不重要，合理的路径设计、必要的支持获得才更重要。一位颇具实战经验的群友也分享到：

我们做过两个场景，效果不一：1、把企业日常工作建模，通过数据MOT驱动地区一线人员去运转。这个跟业务的结果导向式管理来比，是有超前的。但这个项目后面推动比较困难，业务还是不想革命。2、建立了一些中台资产，比如用户的画像标签。长达一年的时间没人用这个，等到业务走到精细化运营这一步，突然发现IT这个是真香，然后就有用起来。

所以，在整个数字化转型的过程中，颠覆性的变革挑战很大，进行现有的数字化融合升级，采取变化，或者渗透的方式来快速迭代，持续挖掘数字升级机遇，并且与业务不断沟通优化，可能更机会更大，数字化更容易成功。数字化转型是业务战略转型，如果CIO不参与战略制定，或组织文化不认同科技的定位价值，还是立足本位，所以数字化不要学互联网，上来就是“颠覆、重构，再做一遍”。

正所谓：“数字化和智能化是”改“出来的，而不是”建“出来的！” 

参考文章：

CPSM《SRM供应商关系管理（Supplier Relationship Management）》

谈数据《企业数字化转型：IT部门的未来》