供应商关系管理(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%需要修改或开发!我都不知道为什么差距会那么大?”那么对于企业来说,究竟应该怎样处理自身与厂商的关系,来保证项目的顺利落地并实施呢?
对于这位群友的遭遇,L总也再次发表了他的看法:“平台或系统策划,有条件时一定要自己策划,不要过度依赖合作方。因此我们一贯坚持:方案自主,系统可控!”同时他还向大家分享了他的一张预警图(如下)。
L总补充说:“在立项前,我的蓝图方案实际就已经全部出来了。例如,哪些是标准功能,哪些是配置,哪些需开发,能实现到什么程度,哪些坑,坑在哪,基本了然于心了。其次,我会明确核心诉求、解决的主要痛点,哪些本期实现,哪些分阶段走,内容明确、边界清楚等等,这样更利于项目的成功实施。”谈及项目成功的标准,大家一定会提出这样的疑问,那么该如何来衡量项目的成功与否?有哪些判断的标准呢?L总也分享了他的评估标准。
第一层级-起步阶段:范围内需求全部实现、预算受控、计划受控,顺利上线。
第二层级-应用推广:系统主体功能能用起来,数据能跑出来,数据逐步准确。
第三层级-上线成功:主业务全面执行,运营数据与报表全面输出;
业务角度:运行顺畅,运营仪表盘与报表数据准确、实时。
系统与业务运营仪表盘与报表趋势:呈正向发展趋势,稳步接近目标或超越目标;公司经营管理层能对数据进行分析、洞察。核心评价要素:经营指标呈正向稳定发展趋势!如今随着数字化的逐步深入,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不参与战略制定,或组织文化不认同科技的定位价值,还是立足本位,所以数字化不要学互联网,上来就是“颠覆、重构,再做一遍”。正所谓:“数字化和智能化是”改“出来的,而不是”建“出来的!”
文章来源:CIO发展中心
编辑:云朵匠 | 数商云(微信公众号名称:“数商云”)
【数商云www.shushangyun.com】专注为企业提供供应链系统搭建服务,长期为大中型企业打造数据化、商业化、智能化的b2b电子商务平台服务解决方案,为传统企业搭建一站式供应链系统服务平台闭环体系,实现供应商系统服务平台数据互通、全链融合,综合提升平台运营效率与平台收益。