一个费力不讨好的项目，让我损失了近一半的绩效！

vhCpOQS

年度绩效因为JNZ项目没有达到绩效目标被打了低绩效，这个是我从业这么多年来第一次低绩效，记一下我在这个项目中犯的错误。
项目起源

公司业务是一个ToB的电商场景，已经经营数年了，公司会给大客户一定账期，然后在履约、开票之后到账期后再将货款收回。但由于整体从销售到回款环节在不同场景有有20个多个节点，通过的比如客户下单后就涉及打包、出库、送货、妥投、用户确认完成、出账、对账、开票、入库验收等，特殊的环节可能像有些商品客户在送检后先需要拿去第三方检验，才能在内部验收，才能开始内部报账支付；有些客户采购是基于项目的，也就是客户不会统一按账期给你钱，而是得等他项目完成之后才会给你钱。但我们侧的账期因为背后靠了一个金融机构（保理），所以是固定的，客户不给我们钱就会涉及到这个订单逾期我们会兜底。当时逾期高的时候有将近20%左右，急需要进行治理。
当然逾期治理有很多方法比如销售政策、信用控制、绩效等；但公司里有不同部门在管理，特别是我们并不直接负责客户而是有具体项目组在负责。类似于矩阵管理，我们作为一个运营数字化部门管理运营条线的职业化和数字化系统，但不负责具体的客户。由于公司认为运营需要对应收负责，因此当有逾期发生或者逾期比较严重的时候我们部门就会成为被问责，逾期率也是我们最重要的考核指标。
 
产品构想

在项目盘点过程中发现运营在订单的应收环节能够按期及时跟进的话其实是能够在一定程度上减少逾期的情况，逾期金额里开票及时的要比不及时的要低30%左右。原先都是各项目组自己线下通过Excel在进行各种客户或订单的管理，如果职能部门想了解情况的话就各种开会盘点，Excel漫天飞的情况，信息非常不通畅，而且也无法及时了解情况。当时令我特别震惊的是比如全国主要逾期原因及占比这一个数据都没有，只能问各个项目具体的原因或者在某次盘点过程中了解的原因情况，因为各个项目的问题分类都不统一。
因此策划了一个叫JNZ的系统。这个系统的主要作用就是将订单中没有按期去完成一些主要环节比较出账、开票、售后、还款等工作的时候会提示运营去做相应的操作，然后运营或相应的受理人进行相应的定位问题分类（全国统一），如果是别人的处理的也可以直接在线上派发给别人，如果别人处理不及时也能够及时进行提醒或升级。后续还可以将这些异常与自动外呼、自动开票、逾期预测、坏账提报等结合起来达到异常的自动化处理、自动标识和升级处理。这样就能够实现订单异常在线上进行精细化的管理。
 
产品发展

最开始在策划和建设产品的时候时间紧任务重，考虑基于之前已经有一个类似的产品基础上进行建设，然后大概花三个月的时间第一版本要上线了，期间由于公司研发资源紧张不少人还是借调过来的。刚上线我就发现糟糕，很多功能没有实现且功能都不完整，根本没有办法使用啊，因此提了100多个问题，研发进行不断的修改勉勉强强可以试点使用了。最开始定位的是各项目组自愿去使用，私下找了几个项目进行试点，项目组的反馈是有通知提醒很好，我们也能够更清楚的看到各种异常问题分类了。项目组普遍把他当作一下提醒的工具。
试运行推了两个月左右，老板觉得不应该是十几个项目自愿使用，应该要强制让所有项目都使用，全部进行线上精细化管理，因此就组织力量把千把个项目在一个月之内就全部搞成线上化。然后各项目组开始往线上去处理异常问题、问题定位和分发问题。有了线上化之后老板还是觉得不够应该设立全国统一的指标，每天同步所有的管理者和项目，产品认知也从原来自原提效的系统变成了一个线上管理的平台。
全国统一指标秉着“及时发现问题、及时解决问题”的原则，设定了及时开票率、问题定位率和及时解决率三个关键指标。有了指标之后就开始要有每周的总结和每月的总结，然后组织考核，比如及时解决率之前是30多%的值，然后设想一年能提到60%左右就非常不错了。然后组长去汇报的时候老板直接拍了一个近80%的指标，还不能变更口径、目标，美其名曰还有20%空间留给你呢。
有了指标之后就开始天天晒，老板希望的是指标能够不断的向上。指标一降低就会被Q为啥降低了，我记得有一次一个指标在某个月是89%，上个月是90%，然后就被Q为啥没有上90%？为啥差了1%。由于全国有数千个项目你其实是不可能了解各个项目每时每刻的情况的，因此就要各种问。同时由于指标设定里很多还是需要人工填写的，如果不填写这些指标就会降低，因此也需要不断的提醒运营去填写，各种收作业和整理数据。最关键是组长还觉得80%指标是能够实现的甚至100%都是可以实现的，把一次情况剔除、该关了关了就好了，天天PUA你产品没有价值。
最后产品从上线到年底大概有8个月的时间，年底做明年规划的时候，在各项目组作了调研，各项目组都在吐槽这个系统只是收作业的并没有实际解决问题。之前一些提醒、专项的问题解决也基本都不谈了。导致整个项目组年度绩效都被打了低。
 
产品反思

思维问题，技术背景的人去了解业务的时候很容易就想拿技术来解决问题，其实可能很多问题是不需要解决的，他存在一定有他存在的道理。要了解其背后最根本的原因，看是否需要技术解决。像我做的这个场景，其实业务已经经营多年，全国都没有统一的问题原因分类，最主要是组织架构矩阵式的原因，并不是强有力的管理。不一定需要靠系统去解决。
 
组织问题，其实与组长在产品最被设想的时候是没有达成一致的，这一块目前来看是没有达成一致的，按照自己以为的方式把系统推进上线然后后续的所有动作与组长的预期都有很大差异，最后组长就会撇清关系认为这一切都是你一个人的想法来做的，与他无关。当然这里也有人的问题，组长本身之前是从运营出身，对技术也不一定了解，要嘛不做要嘛就要做全部都是智能化自动化这种大的无法落地的理念，且她的管理风格是平时开会或汇报玩手机，想听就听一下，只有她在意的事情才会偶尔关心一下。
 
产研问题，最开始这个项目为了加快上线计划，直接在原有一个小系统上做二次开发，但是后来发现这个是错误的决定，原来这个小系统不完善且没有人维护了，因此体验上非常差，在这么差的体验系统上作的开发再加上相应的人员变动，期间换了四个产品经理，十来个研发，都是短期的介入。造成最终我这个产品的体验非常差。
 
我的问题，这个项目我的问题是非常大的。
1）是否有必要做这个系统，当然从架构上可以规划很大而全的系统，实现各种线上化、智能化。但是实际业务是否有必要，最最关键是否在我能掌控的取得良好的结果，目前来看显然是没有必要做这样的系统，或者是做这个系统的时候不要大而全，全是先解决一下具体的场景，取得好的成绩然后再不断拓展比如适合在这种弱管理的组织中
2）向上管理问题，期间其实我自己有无数次感觉这个项目不对劲，但是陷于每天的日常工作总是倾向于先解决目前的问题，而不是解决为什么会有这些问题。没有及时做好向上管理，虽然也沟通了几次但是无法说服组长及老板
3）个人抉择问题，其实在加入这个组织也有2年时间了，在加入之前及过程中也有一些大大小小的机会，但考虑到自己的学习、家庭等因素没有及时进行抉择，还是惯性的在这样的组织中每天做着重复日常的工作。我认为在自己在这个组织中只想着每天上班拿工资，并没有为自已的工作目标和使命去奋斗造成陷入惯性的很大原因。而且刚加入 这个组织的时候已经见识过这个组长与之前其他同事的矛盾闹到仲裁去了，自己却没有任何反应和及时抉择！