百木园
一、专题概述
OCR我相信没有必要给大家做概念普及了，OCR的识别能力在深度学习的一些算法加持下，在识别率上已极有保障。不解决实际业务问题的技术都是耍流氓。秉承实用主义原则和实践出真知的原则，本文将只回答在企业内落地OCR的几个关键痛点：
针对如上4个问题，为了分阶段清晰的说明，本专题将分为三篇文章，本文为该专题的第二篇：
二、变革的实践方法
任何的变革成功均不是一个单一部门或团队就可承担的。特别是现在很多新变革（比如数字化转型、私域运营、财经变革等）都是业务和IT一起携手共进才可推动。
某一方掉链子，不是100分减50剩余50分这么简单，而是100分减50分等于0分。
我们的发票OCR项目能够获得成功，很大原因就是业务和IT形成了利益共同体。在目标上、行动上都保持着一致。
我相信很多小伙伴一定会说，这句话谁都会说、可要做起来可就很困难了。哪有这么容易形成利益共同体啊。
我非常赞同！确实，变革本身就是触动大家立身之本的事情，每个人在面对这种事情上，第一时间是想到这件事情会不会触动自己的利益；第二才会想到这件事情会不会让我获得利益。
而要让大家都放下戒心，拥抱变化，我的实践方法就是：决策要慢、责任共担。这两个方法也是所有变革的组织准备工作。
1. 决策要慢
就是说高层决定要做件事情的决策，要多次反复、不厌其烦的讨论。高层领导没想清楚，没想清楚为什么做？做什么？不做什么？谁来做？谁不做？怎么衡量效果？
那这件事情十有八九会失败，要么做下去执行达不到预期，要么换了个领导换个想法。
所以，决策周期要慢，多一些论证，多一些博弈、多一些争吵。都比在最后上线后大家哑口无言、袖手旁观得好。
2. 责任共担
有些企业会建立一个独立的变革部门来推动变革，这其实是非常危险的行为。独立的变革部门首先在组织级别上就和现有部门难以分清楚高低、谁领导谁？
其次这个部门的利益是自己独占，而事情又要其他部门来做，其他部门还获取不到利益，那其他部门也不傻，还不得想发设法磨洋工？再次就是新的变革部门人员很难选，年轻的怕压不住事，年纪大又怕动力不足。
所以变革就应该让现有部门去承担，或者干脆就独立一个利润中心出来，预算独立、人员考核独立。
而大部分公司是很难独立一个利润中心出来，很难掌握这个尺度，也很难拥有这么大的资源。
那比较保险的方法就是“现有组织人员责任共担”。比如私域运营，就应该营销 + IT团队 + 产品三方共担责任。产品做好私域产品、IT搭建好私域空间、营销做好私域运营。
做不好，三个大领导都受罚。
下图是变革的实践方法和行动指南。
管理变革 + 技术变革 = 变革成功，在实践的“发票OCR变革项目中”，管理变革的行动指南就是“自动率考核法”和“硬性减人法则”，技术变革的行动指南是“能力叠加法则”和“技术架构法则”。而且变革成功要有两个组织准备工作，分别是“决策要慢、责任共担”。
三、行动指南详述
1. 能力叠加法则
所谓政治、就是把朋友搞得多多的，敌人搞得少少的 ——-领袖
单一的识别能力、就如同战场上的一支小分队，执行一些小的战斗任务还是没有问题，当然在残酷的战场上，这只小分队的力量也是非常薄弱的，受到的威胁也非常的多。
可要是这支小分队肯协同其他军种一起战斗，那力量就大大的加成。比如协同炮兵，就可以执行侦察轰炸任务；比如协同坦克，就可以执行步坦协同突击任务；比如协同海军、就可以执行海陆突击任务。
就比如我们已实施的一个发票OCR识别项目，为了达成能力叠加效应，我们对接税务平台，实现了发票验真的能力叠加。
对接了已报销和在途发票库、实现了发票的验重能力叠加；对接了法人库，实现了发票抬头和税号的校验；对接了报销单审核规则库，实现了票单规则一致性校验；
那能力叠加法则有没有什么管理模型么？有的！下图就是能力叠加法则的管理模型。在“变革难度”这个陡峭的坡道上，OCR新技术要发力爬升，需要有两层能力叠加。
2. 技术架构法则
在对能力有了一个清晰的思考后，下来就要进入具体的实施环节了。若只是实现第一层的能力叠加，也根本没有必要做什么架构图，因为直接写死规则、引入API，开干就完了。
可要是我们想让OCR能力在企业内价值最大化，滚动到第二层的能力叠加，即走向票单校验、走向税务抵扣、走向风控预警、走向统计分析。
那我们就有必要好好设计下技术架构图。我们可以尝试回答下这些问题，从这些问题上我们就可以感悟到做技术架构图的必要性：
这个技术架构图左右牵手了管理目标和运营目标。
底层全面实施数据中台管理所有结构化数据。在中台层搭建四个核心能力，分别为“规则中心、单据中心、接口对接中心、通知中心”。
这四个能力可体系化的支持填单、审核、稽核、风控这四个场景。最终交付出看板、报表、通知和账单服务。
从架构上就可回答上上面的哪些问题。
在架构搭建的实操之中，其实也有很多的经验积累。这些经验都是实操中需要各位重点关注的。在此也总结分享给大家。
1）经验1：审核节点先行：充分跑通规则后，再推行到填单节点；
任何的技术能力都是需要训练的，OCR能力也概莫能外，专票/普票对抬头的校验上强度不一样（专票不可忽略全半角、而普票可以）、通讯类发票无需校验抬头、电子发票无需打印即可报销、专票需提供抵扣联入账等等、这些规则均需要在对内实施中沉淀下来、然后才复制到用户侧。
这其实也反映了To B产品在实施项目的一个方法论，要提升市场竞争力、让用户侧的体验最佳，就必须先做厚企业侧能力、打造后端强大的支撑能力。从而构建“小前端、大后台”的运营模式。
2）经验2：移动端先行：PC端其次；因为移动端可兼容多种场景；
很多人会说现在电子发票大范围推行，在某宝、某东上购物都是开具电子发票。而且电子发票以PDF居多，那PC端自然就是最先突破的场景。
做产品切不可停留在想当然，PC端报销只有一种场景“坐在办公室抽出大块时间安静的报销”，而移动端可兼容多个场景“开票现场直接验证发票、随时拍一张发票存入票夹、坐在办公室抽出大块时间安排的报销”。
并且因为PC端存在PDF的附件形式，就意味着需要报销人去管理PDF文件，哪些已报销，哪些没有报销，得用多个文件夹进行管理、或者对PDF进行重命名做区分；
3）经验3：规则先行：规则中心要思考实施落地的节奏推进；
建立规则中心，考验的不仅仅是产品人的规则引擎架构能力，还考验实施落地的节奏推进能力。
举几个例子，规则中心是一套，而生效的角色有用户、接单员、会计、稽核。可实际推进时要接单员先行，那是否代表规则中心必须配置角色维度、而且在第一期应该是接单员强控、用户端弱控。
还有一个例子就是规则中心有些规则是犯错就不可以提交、有些是犯错可以提交/ 提醒要提交，那么是否就代表规则中心对规则还有强/弱的校验。
最后一个例子就是，若一个规则已前置在用户端、或该规则已不用，那是否可直接不控，而不用去修改代码。
4）经验4：合规先行：票的合规要一次性完成、要关注OCR所隐藏的结构化数据的业务实质；
很多TO B的产品在思考一个场景的时候，经常会犯一个错误，就是局部最优，而不是全局最优。
OCR绝对不应该单纯的认为只是一个识别能力，而应该透彻的看到OCR所带来的结构化数据和结构化数据后面所隐藏的业务发生实质。
就比如实施OCR识别发票这个业务而言，局部最优就是在为了追求识别准确度，追求识别通过率，则只是将发票识别、发票验真作为“发票是否符合报销条件”的校验准则，这就是局部最优，因为这样的准则一定会让发票的通过率达到最优。
而全局就有问题了，因为“发票是否符合报销条件”还有很多其他校验准则，比如“发票是否已报销或在途报销、发票的抬头和税号是否符合公司法人、专票的抬头税号是否完全不忽略大小写和全半角、发票销售方是否有经营风险”。
若这些准则若不在发票校验中一次性完成，就会在其他环节报错，若其他节点没有有效控制，就会带来风险事故的发生，当然在驳回和沟通中，自然带来组织效率的低下。
所以，追求全局最优、关注数据价值和业务实质，才是To B产品在实施落地的指导思想。
给作者点赞，鼓励TA抓紧创作！
来源：http://www.woshipm.com/pd/5442123.html
本站部分图文来源于网络，如有侵权请联系删除。