首页/文章/ 详情

关于“是否为‘变更’之扯皮”的感触

2年前浏览1342


1

扯皮流派


这在汽车行业相当相当普遍。

 

主机厂提出某项要求,供应商认为这是变更,需要走变更流程,要求主机厂下变更单,然后供应商重新报价,商务再去谈钱;而主机厂呢,又认为这是之前需求的澄清,而且就这么点功能,加个DID,改个报文,要啥钱……

 

扯皮大战就此开始。扯皮有各种流派,之前没说清楚派,你们没讲派,有没有邮件认可派,需求没有冻结派,这是常识派,难度太大派,技术不可行派,要延期派,秉持合作派,我们实在有难处派……

 

基于现实情况,各有胜负。


2

店大欺客,还是客大欺店


胜负之分呢,一来要看当事人扯皮功力,但更主要看店大还是客大。

 

没什么量的主机厂,属于小店,面对强势的供应商,就失去了顾客是上帝这个资格,甚至还需要低声下气地把项目交给供应商做,即使配置的项目人员是老弱病残,也能将主机厂的需求怼回去。

 

但是对于我们熟知的几家国内OEM,随着市场占有率的提高,已经从边陲小店成长成了京都大店,虽说可能还没有五星级的水准,但也是往来人员络绎不绝啊。


这种情况下,作为乙方的供应商就恢复了孙子本色,商务也好,领导也好,都是无所不用其极地支持。配置的人员也自然要精兵强将,至少也是肯卷肯干的。很多情况下,纵使你有三寸不烂之舌,新需求、新任务进来,也得做,还没钱。

 

道理也很简单,这就是我们总说的业务。挣钱嘛,生意,不寒碜。

 

不过,店大客大也都是相对的,以上叙述,或显极端。对于店客均衡的,扯皮之争,你来我往,或许也是迁延日久。

 

毕竟,主机厂会开B点,也会避免单一询价。供应商呢,也总有竞争对手,垄断谈何容易。

 

这样,是否为“变更”的扯皮之争,就会慢慢地形成汽车业内的一种模式,双方都排斥变更


3

很痛,且不变?


当然,是否为变更,谁要吃进去这部分成本,仅仅是变更给大家带来的痛苦或顾虑之一。变更,最多只有变更提出者,或者说整个组织层面可能受益。对于最重要的执行层,人性使然,多一事不如少一事,自然不愿变更。

 

所以,汽车行业往常经常会有这种现象发生,判断一个汽车PM老到与否,可以看其能否早期就将项目范围明确下来,并控制后期变更,且能否留一手自证清白。

 

传统汽车行业会设置非常刚性的交付节点,对于这类瀑布式的和目标刚性的项目的成功,也常常取决于此。


之前的汽车呢,功能成熟稳定,汽车是离终端消费者很远的专业的人做的事,造出什么,只能买什么,只能用什么。这种前提下,这样去做也是未必不可。

 

但是,时代开始变化了,变更越来越难控制,系统越来越复杂,使用场景越来越多元,很多需求需要持续澄清,需求方的需求也在变化,还有很多依赖制约因素,很难找到一个节点去锁定需求和方案,非要去找,也就要以功能或体验损失为代价。


4

敏捷来了,拥抱变化


大约是发现变更无法规避,敏捷的拥抱变化就应运而生了。


既然无法抵抗,不如躺倒接受。

 

学过马原的都听过这句话,世界是物质的,物质是运动的,运动是有规律的,规律是可以认识的。

 

运动,即变。变本是常态,变更也就不是洪水猛兽,行业发展也自然是周期性的相对静止和绝对变化。

 

VUCA时代就是绝对的变的周期回来了。


终端消费者作为这一大系统的一员,强势参与进来了,他们的所思所想,他们想把钱花在哪里,仍然有诸多变化。拥抱这变化才是我们需要当下最该考虑的。

 

落地一点呢,就是现在如何做好变更管理。

 

然而,现在大家都在摸索中,技术还在进步中,尚未形成新的规范。而且真正的好的管理方式要因时因地,因产品不同而不同,因人不同而不同。

 

暂留一个主题,后续实践一段时间后,再来写。



       

来源:汽车软件质量

汽车控制
著作权归作者所有,欢迎分享,未经许可,不得转载
首次发布时间:2022-10-11
最近编辑:2年前
Bruce Yang
签名征集中
获赞 0粉丝 6文章 48课程 0
点赞
收藏
未登录
还没有评论
课程
培训
服务
行家
VIP会员 学习 福利任务 兑换礼品
下载APP
联系我们
帮助与反馈