网站首页 > 技术文章 正文
如何让人工智能真正融入企业,成为推动效率与创新的引擎?本文作者以亲身实践的AI审单项目为例,深入探讨了AI在企业落地的五步法,从成本节约到流程设计,再到运营策略,为AI的商业应用提供了一条清晰的路径。
一、引言
人人都在谈AI。可A的信任赤字、AI的投入成本,都让决策者和拥趸畏首畏尾。如何在企业内洞察机会、如何说服决策者投入资源、如何衡量价值达成。这些都是绕不过去的问题。笔者以个人践行的AI审单项目为例,历时一年多的痛苦与挣扎、现分享给各位,与各位共同探讨AI的落地方法。
二、AI应用的5步法概述
沿上篇文章《AI应用企业落地方法论:践行财务共享AI审单项目(第一篇)》所述,我们分享了“技术理解”和“机会洞察”两章。我们继续。
本系列文章将回答如下几个痛点,文章较长,收藏再看。
- AI如何在企业内找到落地场景,且能形成规模效应;
- AI是一个好东西、要投入多少钱、能产生多大的收益和价值;
- AI技术可理解性差,如何衡量落地场景的应用稳定性;
- AI会不会引发数据泄露,数据安全如何保障;
- AI要在企业内取得成功并复制成功,推进方法论是什么;
三、第三步:流程设计与产品设计
3.1 AI产品设计流程概述
AI大模型以字数收费、而且还不便宜。而实际我们真正需要的信息又少,那如何实现成本最节约下的AI技术引入呢。我总结了两个方法、亲测非常好用。分别为“AI成本最节约下的审单流程设计”和“对标工序和ROI的原型设计”。
前者是开放的思考流程情况、数据来源情况、附件类型情况、需要内容情况下的AI成本考量、并融入开放思考到流程设计中。从而在流程设计上就思考和设计成本问题。
后者是从工序分析和ROI的角度拆解用户操作步骤,变革新的流程做出新的产品原型。
3.2 AI成本最节约下的审单流程设计
日本质量大师田口玄一博士说过:“产品质量首先是设计出来的,其次才是制造出来的”。笔者认为、产品成本首先是设计出来的,其次才是管控出来的。
所以,若要实现最节约下的AI投入,就需要审单流程设计,笔者将审单流程方法,划分为两个步骤,先做脑暴、再做流程。脑暴就是开放思考AI的成本消耗点,不考虑技术实现性;然后拿着这些成本点再套入到审单流程之中。最终你会发现,AI的成本消耗变得透明和清晰。
第一步:AI成本节约脑暴
AI成本节约脑暴是从“流程”、“来源”、“附件类别”、“识别内容”角度发散思考成本节约的消耗点。脑暴是一种发散思维,可避免一下陷入到流程设计之中,流程设计会让人脑去修正逻辑、去修正合理性,会使得产品人员的注意力被流程合理性所吸引,结果哪些成本最节约策略,就会被产品所忽略,AI成本潜移默化下则增长了。
第二步:基于成本节约下的流程设计
基于上面的脑暴,我们对整个产品有一个结构概要,也知道要实现这些脑暴点的依赖条件,下一步我们就进入流程设计,在整个流程设计之前,我们还对规则进行分类,规则分类的原因也是因为脑暴有依赖(脑暴点1、脑暴点6),同时我们也建立了其他配置要素,
规则分类表:
系统后台配置:
有了上面的分类规则、系统后台配置、脑暴点。我们下来就进行具体的审单场景设计。如下是设计出来的两条流程。因企业保密需要,架构图等就不分享给各位。这些流程一方面是现在实现的,另外一方面也是我个人基于现状的畅想(当然也是可实现),是比较合理的流程,各位大可放心。
国内差旅报销场景(提单人自助识别发票和非票附件场景):
流程解析:
- 移动端拍照发票完成发票抬头、真伪、重复等“发票正确类规则校验”(下表有详细的规则分类);移动端拍照非票附件形成影像;
- PC和移动都有统一的个人影像中心(含发票和非票附件)、这时候非票附件并没有调用AI识别和AI大模型能力;
- 员工选择报销场景“国内差旅报销”、系统调用后台的规则引擎,告知需要提交的发票类型和非票附件;员工选中对应的发票和非票附件(规则引擎明确哪些非票附件必填,报销人需要选中附件,这里不用AI是因为附件太多,成本太高,分类也需额外收费的);
- 系统根据后台配置的“场景+发票的消费类别>费用科目”,自动生成对应的报销明细行,自动关联对对应的消费科目;(消费类别就是“用车>汽车油票”);
- 用户点击提交按钮,系统会先检查单据填写类规则、发票正确类规则、票单校验类规则、附件提供类规则。若错误,则异常报错;若正确,则系统会调用AI大模型去识别附件(AI识别和规则校验会耗时,系统会有载入提示);
- 系统识别非票附件为文本数据后,会调用“非票附件部分篇幅AI识别配置”功能、将精准的部分篇幅给到AI大模型去形成结构化数据,并返回给系统后台库,后台库统一发送给规则引擎进行“非票附件校验类规则”校验;
- 校验成功则返回正确结果、校验不通过则返回比对的结构化数据给前端;
- 审单助手页统计所有规则数、校验成功规则数、校验不通过规则数。审单人作人工判断。
流程图:
国内差旅报销场景(提单人不识别校验、由审单人识别校验单):
流程解析:
- 提单人提单时读取规则引擎、系统自动校验提单人必须提供的附件类型、提单人需准确提供;
- 单据到了审单人节点,系统会先对发票先做OCR校验、然后调用规则引擎去检查单据填写类规则、发票正确类规则、票单校验类规则、附件提供类规则。若错误,则异常报错;若正确,则系统会调用AI大模型去识别非票附件(AI识别和规则校验会耗时,系统会有载入提示);
- 系统识别非票附件为文本数据后,会调用“非票附件部分篇幅AI识别配置”功能、将精准的部分篇幅给到AI大模型去形成结构化数据,并返回给系统后台库,后台库统一发送给规则引擎进行“非票附件校验类规则”校验;
- 校验成功则返回正确结果、校验不通过则返回比对的结构化数据给前端;
- 审单助手页统计所有规则数、校验成功规则数、校验不通过规则数。审单人作人工判断。
流程图:
3.3 对标工序和ROI的原型设计
我们在做原型设计之前,需要回顾下《AI应用企业落地方法论:践行财务共享AI审单项目(第一篇)》文章的“5.2.2 分析步骤2:工序计算分析法、下钻机会下的耗时工序 ”和“5.2.6 分析步骤6:ROI分析方法”内容,从中找出原型设计的出发点。现在我们将部分原文截取过来
工序计算分析法中,将审单分为这几个工序:(1)在所有附件影像中找到对应附件;(2)在一份附件中找到具体关键信息;(3)计算和统计附件内容;(4)比对附件与单据的数据的一致性;(5)检查本岗位规则的审阅覆盖度。
ROI分析方法中,我们可以明确的是资源永远是有限的,而且大部分决策者的心理都是“花小钱办大事、最好是不花钱;ROI要对标具体的工序,拆解工序来做ROI测算。
对标工序和ROI后,我们就可以用下表做前后对标工序设计,以前的工序做参考、现在的工序基于上面新的流程进行详细设计。有了这个工序详细设计,接下来则可放心大胆的画原型了。
6.4.1 前后对标工序
下表是审单人员的AI引入前后的工序,并附有审单原型图,各位看官可详细阅读:
现在的审单助手页(也可应用在用户填单校验环节)
原型设计经验总结
- 产品原型需建立在流程重构的基础上,绝非优化原有流程和工序;
- 不切换页面、少点击,集中一个页面讲清所有,极大考验对工序的整合设计能力。产品的归属就是无需培训即可上手。
- 原型每个人都会画、但是比较有说服力(也可以说专业~~哈哈)的做法还是要先做完工序计算、ROI计算、流程设计后,再做工序设计。
四、第四步:速赢机会运营
4.1 速赢落地关键成功要素
很多小伙伴理解速赢就是“在最出效果的地方做项目开发”,这太过狭隘,速赢落地的核心而是“价值运营达成”。我们可看下速赢落地的关键成功要素:
- 速赢点上线了,可整个产品就是一个黑盒子,出现自动化率低问题后,无法判断问题根因,是AI识别能力、AI理解能力、规则引擎还是系统代码?到底是哪里出问题了!
- 产品上线后,团队反对者和部分领导会质疑产品效果,一句话否定你一切!而项目组无法拿出量化指标来证明;
- 速赢机会成功了,可要全面推广时,项目组信心不足,没有人可以拍着胸脯说上线一定没有问题;
上线只完成了整个产品的20%,剩下的80%时间则是运营、调优、再运营、再调优。在速赢阶段,我主要做的是如下几件事情:
- 监控运营指标和分析运营日志、提升产品能力:通过监控识别置信值、规则引擎通过率、驳回率这些指标、再每条异常日志打开来看,可以发现很多AI的能力不足点、更可以发现我们的规则引擎的函数的写法问题;
- 用BI平台监控作业提效变化,证明提效可行性:数据不会说谎、通过监控审单耗时和规则校验通过率、不断让团队和关键意见领袖认可产品。
4.2 速赢运营指标
4.3 AI审单运营的经验
在实际运营过程中,个人踩过了很多坑,当然也总结了点滴经验。在一定的脱敏后分享给大家,希望大家在引入AI的时候能够更成功:
- 单据不是必填,造成规则校验失效、所以需要再运营中或规则梳理时仔细甄别。
- 附件存在一些特定类型无法提供准确数据源,造成规则失效;比如合同是框架合同则没有合同金额;这就需要对合同做AI识别看是否是框架合同,这都是需要再运营中去发现。
- 规则没有做合理的命名,造成审单人无法理解;规则是给人看的,团队leader没有做统一命名则会造成规则阅读成本极高,信任度大打折扣。
- 规则没有考虑多行情况,比如A和B需校验,采用相等,可后来发现A中存在多行,则就需要修改为包含或分组后再对比;所以在规则梳理时、一定要多多考虑异常情况,
- 合同印章识别不准、手写内容识别不准;手写的内容识别不准可推动业务前端进行修改;
- 能用开源的就先用开源的,只要有投入就会有沉没成本,即不要一下去买一家厂商的成熟包装后的产品,先去用SAAS产品吧,跑通逻辑后掌握了主动权,再去选购成熟产品。
- 规则引擎的核心是规则函数,而非前端规则配置页面,其实Drools workbench就足够了,没必要再去搭建一个人人可用的规则配置页面;个人在这里差点掉到坑里了,设计了好久,还特意做了几千个字的规则引擎调研报告,幸亏是这份报告,让我意识到规则引擎的核心是什么,我自己能做什么,我最应该做什么。这也给所有人提一个醒,要是对某件事情有疑问,那就写研究报告吧,你可以相信身边的人,可他们不能替代你的思考,主意还得自己拿!
- 分析不仅仅只是看最终经营指标,比如规则自动化通过率,还要重点看日志,我们花了非常多的时间去看日志,从日志中发现了很多问题,每一条日志都是上天的恩赐,都是团队迈向更成功的垫脚石。重视日志就是尊重现实、就是一个“唯物主义者”哈哈!
- 无论是支持者、观望着、反对者,所有人都有一个信任过程、你需要“让朋友搞得多多的,让敌人搞得少少的”,方法就是持续运营、不断优化。让数据告诉项目干系人,你是尊重他们的,你也希望得到他们的信任。感激你的朋友、也感谢你的敌人!
附录图:提示词工程
五、全面推广和下一步规划
路漫漫其修远兮吾将上下而求索!要全面推广和走向自动化,还需要很长的路来走,我也做了一些整个AI产品的下一步计划,梦想还是得有嘛:
- 保障AI审单准确率的核心是:规则越清晰、附件越标准、单据量越大;所以,下面的全面推广就需要建立这个选择标准进行推进。
- 印章问题是一个老大难问题,可以考虑相似度算法+代码个性逻辑来算出百分比,如下是一些典型问题 :印章都盖在甲乙方上面,在识别的时候就存在错误;印章有名字类型的,顺序无法判断,比如王明印、结果识别成为王印明;
- 每一个规则设定“自动化必须通过”的标志、比如发票与法人的关系,要是错了,哪怕其他规则都通过了,只要这条规则不通过,那么自动化就不会通过;这可以降低成本;
- 每一条规则返回的时候都带了“校验准确率”,普通规则则要么100%、要么0%;而采用相似度算法的则会返回具体的校验准确率,即相似度算法校验后的结果;最终结合“自动化必须通过”和“校验准确率”来判断是否可自动化通过;也得出一个最终的“总校验准确率”;通过这个阈值,低于这个值的则人工、高的则自动;
- AI的成本还需要进一步降低,希望国内各大厂商进一步推进吧,AI的引入决策成本还是蛮高的,其实若AI真的没有这么贵,我也没必要写这篇文章了。
- 前置规则到用户和本地接单人人员,审单本身就是一个流程冗余的动作、要是每个人都填得对、每个人填单就校验完毕,那么流程的成本将极大降低,没有审单人员、没有管理成本,审单人会去做更重要、更有价值的事情。世界将会变得更加美好!
六、最后
AI从产生概念到实际应用已是许久,我们对AI还是那么期待,而在恐怖谷理论中,当下的AI还没有让我们反感和害怕,这是否正说明AI还是很弱~~这确实让人心塞。
AI的未来一方面是三算的提升,另一方面还是企业应用的探索。希望更多的企业和个人能够放心大胆的信任AI,去探索AI场景。个人也希望这篇文章能为AI践行之路的人们指明一条可复制的方法。
本文由 @boyka 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
猜你喜欢
- 2024-11-16 drools的类型声明(Type declarations)
- 2024-11-16 规则引擎drools-实战个人所得税计算器
- 2024-11-16 基于 Flink 和 Drools 的实时日志处理
- 2024-11-16 开源、强大的工作流引擎:camunda入门介绍
- 2024-11-16 53-SpringBoot整合Drools_2(springboot整合zuul)
- 2024-11-16 开启灵活开发编码模式:规则引擎drools——LHS部分
- 2024-11-16 开启灵活开发编码模式:规则引擎drools——RHS部分
- 2024-11-16 开启灵活开发编码模式:规则引擎drools——高级语法global
- 2024-11-16 43-drools基础语法(比较操作符_memberof)
- 2024-11-16 Google Aviator——轻量级 Java 表达式引擎实战
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)