【任子旭】专栏

作者介绍

本文作者：任子旭 Zack Ren

微信号：rrenzixu

公众号号：RPA2018

公众号名称：RPA流程自动化机器人

1001-什么是RPA？(上)

2018年马上就要开始了，跨年之际发出这个公众号的第一篇文章。

本着“一篇文章只说一件事儿”的原则，今天只回答一个问题：什么是RPA？

RPA是RoboticProcess Automation的缩写，翻译为：流程自动化机器人。

===============================

我们的理解：

传统场景下，员工的工作绝大部分是通过电脑操作完成。机器人通过记录员工在电脑桌面上的操作行为，将规则和行为熟记于“心”，并模拟人的方式自动执行一系列特定的工作流程，就是流程自动化机器人，英文简称RPA。

对四大咨询公司的定义作了收集（版权归四大所有，本文纯属引用，如有冒犯，请联系删除），归纳如下：

From 普华永道PwC：

RPA又可以称为“Digital Labor”，即：数字化劳动力。这是一种智能化软件,通过模拟并增强人类与计算机的交互过程,实现工作流程中的自动化。RPA具有对企业现有系统影响小,基本不编码，实施周期短，而且对非技术的业务人员友好等特性。

RPA不仅可以模拟人类，而且可以利用和融合现有各项技术，实现其流程自动化的目标。如：规则引擎、光学字符识别、语音识别、机器学习及人工智能等前沿技术。

From 德勤DTT：

财务机器人是一款能够将手工工作自动化的机器人软件。机器人的作用是代替人工在用户界面完成：高重复、标准化、规则明确、大批量的日常事务操作。

与一般软件或程序的区别在于：普通程序被动地由业务人员操作、机器人则替代人工主动操作其他软件。

From 安永EY：

一项允许公司员工通过配置计算机软件或‘机器人’抓取并解析现有应用程序来处理事务、操纵数据、触发响应并与其他数字系统通信的技术应用。

企业正在不断寻求可以实现自动化的流程。可实现RPA的基本流程应具备三个关键特征：操作一致，重复执行相同的步骤；模板化驱动，数据以重复的方式输入到特定字段中；基于标准规则操作，允许决策动态大幅改变。

From 毕马威KPMG：

可以定义为“AI，机器学习等认知技术在业务自动化中的灵活使用”，可以是针对重复性工作的自动化以及高度智能处理的自动化。

RPA是数字化的支持性工具，可以替代在此之前认为只有人类才可以完成的工作，或者在高强度的工作中作为人工的补充，是企业组织中出现的新概念劳动力（DigitalLabor：数字劳动力：虚拟脑力劳动力）。

===============================

看完了这些比较概括性的定义，还是会很迷茫，那么重要知识点来了：

1、RPA是软件，不是实体机器人；（想评价具体颜值的可以散了~）

2、RAP应用的场景：大量重复（让RPA有必要）、规则明确（让RPA有可能）。

3、只要满足第2条的要素，那么RPA可以应用于任何行业，应用于任何场景。

4、举个例子：如果

应用于财务领域，RPA=财务机器人；

应用于税务领域，RPA=税务机器人；

应用于HR领域，RPA=HR机器人。

===============================

2018年打算每周至少一篇文章，或简单或复杂讨论一个问题。

共同努力，让RPA成为每个企业必备的应用工具。

这篇文章就先聊到这儿，下周见！

（正文结束）

===============================

1002-什么是RPA？(下)

上篇文章介绍了对于RPA的定义，并且重点强调了：

1、RPA是软件，不是实体机器人（至少目前来看还不是）

2、适用于“大量重复”和“规则明确”的条件场景，不限于具体行业，不限于业务场景。

这篇文章概括介绍RPA的具体功能。

拿出我们关于RPA的定义：机器人通过记录员工在电脑桌面上的操作行为，将规则和行为熟记于“心”，并模拟人的方式自动执行一系列特定的工作流程，就是流程自动化机器人。

拿出其中的关键内容：

1、记录员工在电脑的操作行为

2、将规则和行为熟记于“心”，并自动执行

解释下这两个关键内容：

1、既然RPA是一个软件，那么这个软件就要记录员工的操作行为，包括键盘录入（基础）、鼠标移动和点击（基础）、触发调用Windows系统操作（例如文件夹和文件操作）、以及触发调用各类应用程序（例如网页操作、收发邮件、Word/Excel操作等）。

记录这些行为操作，是RPA软件非常重要的功能。而且，RPA软件不光要记录这些操作，而且要将这些操作抽象化，变成计算机能够理解和处理的“对象”。

RPA软件记录这些行为操作的方式，一般称为捕获（Capture）。

2、RPA软件捕获到了全部鼠标、键盘、系统、应用程序的操作后，然后在电脑中按照约定的规则（我们约定的第二个适用场景条件：规则明确）自动执行这些“对象”应该不是稀奇的事儿了。

说到“捕获”和“自动执行”，有以下几个现有的产品/功能相信大家可能会有同感：

1、按键精灵软件（不了解的可以自行百度之）

2、Excel的VBA（也称宏）

3、SAP的LSMW（戏称“老师摸我”）

4、QQ或者微信软件，使用截图功能时，会捕获当前对话框（出一个红框）

这些熟悉的软件在其专业的领域（例如：游戏、软件测试、办公、ERP等）为用户带来了很多便利和效率的提升。（关于RPA和以上产品/功能的对比以后可能会聊一下~）

同样，RPA作为商业化的流程自动化应用势必会带来更具有震撼性效果的效率提升。

RPA目前作为一个非常热门的话题，一个非常重要的原因是RPA相对于人工进行大量重复操作（我们约定的第一个适用场景条件：大量重复）有着非常明显的优势。

我们将RPA的优势总结为以下五点：

1、效率高

2、成本低

3、速度快

4、质量好

5、态度优

关于RPA优势更多详细介绍，下周的文章会涉及到。

这篇文章就先聊到这儿，下周见！

（正文结束）

===============================

1003-RPA的优势

上篇文章对于RPA进行稍微展开的介绍，并且提及了RPA能够：

1、记录员工在电脑的操作行为

2、将规则和行为熟记于“心”，并自动执行

这篇文章概括介绍RPA的优势。

上一篇文章末尾提到过，我们将RPA的优势总结为以下五点：

1、效率高

2、成本低

3、速度快

4、质量好

5、态度优

以上五个优势非常容易理解，就不多作解释了。

我们换个角度，从RPA能够解决企业的什么痛点来凸显RPA的优势。

其实RPA产品（部分提供商）已经推出超过10年甚至更久，很自然的一个问题：为什么恰好是2017年（不是更晚，也不是更早？）RPA才进入公众视野并迅速火爆起来？

以下是三点思考，分别是：关于人的集成、关于信息系统的集成、关于未来的集成。

1、关于人的集成。

过去的二十年经历的是ERP由高速发展走向成熟的过程，也是ERP由奢侈品变成必需品的过程（举个例子：2008年前后，国家电网SAP项目基本上都是由国际咨询公司负责实施的，且顾问难求；10年之后的今天，国内的SAP实施厂商已经有非常成熟的实施能力了，一些中型的企业甚至可以不用建机房也同样可以使用SAP/Oracle的ERP产品服务）。

这个过程中，人和信息系统发生了非常紧密的集成。也许10年前，我们可以说信息水平比较高的部门是财务部门和HR部门，而现在已经没有人会提哪个部门信息化水平比较高了（因为大家的信息化水平都很高了）。

当人使用信息系统由稀缺变成普遍，大家一定会追求：如何能够更加体现人的价值？如何能够让人和信息系统有更高效的集成？

所以我们就会分析，哪些人和机器的交互是必要的、高附加值的、有创造性的？而哪些交互是机械的、低附加值的、可以让机器完成的？

在这样的大背景下，RPA就变得非常有价值。（如果ERP没有完成普及，RPA便不会有如此的紧迫性）

2、关于信息系统的集成。

虽然ERP已经“飞入寻常百姓家”，但系统间的集成一直是很多企业讳莫如深的痛点。

为了解决这个问题，我们提出了很多的概念（非IT人员请忽略后面的英文缩写）：ESB、WebService、OLTP/OLAP、数据仓库、MDM、BPM等等，试图从多个抽象层面（技术接口、数据、流程等角度）解决这个问题。

涉及到部门之间信息交互时，这个场景/结论出现的频率依旧是最频繁的：“这个需求挺急的，IT开发这个需求的周期也挺长的，要不我每月/每天导出固定格式的Excel文件发给你吧！”

这个问题可总结为两个主要矛盾：

矛盾1：企业日益增长的对IT系统的需求与IT系统有限的资源投入之间的矛盾。

矛盾2：企业对业务变更迅速响应需求的与IT系统建设需遵循固有周期之间的矛盾。

关于矛盾1的关键字是：成本。

提升信息系统群对业务的可扩展性，便意味着设计复杂度的增加，同时也意味着投资成本的增加；而信息系统的建设从来都是需求与成本的权衡。俗话说：“一分耕耘一分收获”、“一文价钱一文货”。

RPA在解决现有信息系统间的交互问题上，具有得天独厚的优势。

从业务人员的角度看，RPA解决系统集成的问题方式和人处理的方式非常类似。

从IT人员的角度看，RPA解决系统集成的问题方式非常符合软件工程中“高内聚，低耦合”的原则。

关于矛盾2的关键字是：速度。

业务部门有需求变更时，最不想得到的答复是：“IT需要排期”。IT部门最痛苦的莫过于人手本来不足，各个业务部门报需求的紧迫性都是“非常高”。这个矛盾不仅短期存在，而且未来相当长的时间内都会存在。

RPA项目实施周期短（后续关于实施策略的文章会分析），见效快（后续关于RPA投资回报率的文章会分析）的特点，能够非常有效的缓解业务部门和IT部门之间的矛盾。

3、关于未来的集成。

都说“未来已来”，都在讨论“机器会不会替代人”，不过这些问题都不是我们短期做IT规划需要重点考虑的问题（主要是当前可行性不太够，毕竟企业门口栓一条“阿尔法狗”来看家护院，投入和产出明显不划算）。

要展望未来，也要脚踏实地，RPA可以是一个很好的连接点。

为什么说RPA可以让AI离我们近一些？

RPA是流程自动化机器人；如果是机器“人”，就需要有眼睛、有耳朵、有嘴巴、有手、有脑袋。

其中：

眼睛=OCR、图像识别、语义识别等

耳朵=语音识别

嘴巴=语音合成

手=初级阶段的RPA、机械手臂

脑袋=统计分析、机器学习等

这些单项的技术已经相对成熟， RPA可以将这些散落的珍珠串成美丽的项链，戴在企业的脖子上（以可以承受的价格），使其以更加优雅的姿态参与日益严酷的市场竞争。

这篇文章就先聊到这儿，下周见！

（正文结束）

===============================

1004-RPA的产品选择

上篇文章概括介绍了RPA的优势。从RPA能够解决企业哪些痛点的角度（关于人的集成、关于信息系统的集成、关于未来的集成）介绍了RPA的优势。

这篇文章概括介绍RPA的产品选择以及一些附加思考。

1、软件清单和软件选型

为避免失之偏颇，直接列出距今最近的第三方公司（Forrester于2017年2月13日出具）的调查报告结论，如下图所示：

这个图里列示了11个产品，均来自于国外产品。分了三个维度：现有功能、战略方向、市场份额。

在图中的位置越靠上，软件功能越强大；

在图中位置越靠右侧，说明公司更专注于RPA领域（部分公司RPA只是其产品群的一部分）；

在图中图示的圈越大，说明该产品的用户越多，市场占有率越高，市场表现便更加优异一些。

报告出具时，还没有国产软件上榜。寄希望使用纯国产软件的话，要等一段时间了。

这个图，看看就好，可作为RPA产品选型的参考，但不可盲从，因为产品选型时要考虑更多的因素，也是更加个性化综合分析的结果。（举个例子，除了公司规模、产品功能与需求的契合度、案例对比等各种因素外，可能是否在国内有办事机构和合作伙伴也需要纳入考虑范围）

2、合作伙伴和公司品牌

说起软件选型，可以讲很多故事，“成功项目的经验总是千篇一律，失败项目的教训却是各有千秋”。

当被问到：“SAP和Oracle的ERP产品哪个好？哪个更适合？”的时候，我们应该知道，这个问题缺了一个维度，是不能够回答全面的。

SAP纵使是“世界500强后的管理大师”，在国内失败的案例比比皆是。同样，Oracle成功案例也绝非少数。

其中，实施方是一个非常重要的因素。

应避免纯粹单维度地比较两款软件产品（例如UiPath or NICE）或两家实施方（国外咨询公司or国内实施公司），结合起来才更有意义。

如果问题是：“【A公司的某团队咨询实施X产品】与【B公司的某团队咨询实施Y产品】，哪个能够有更好的落地效果？”的话，接下来的调研才会更加务实。

3、成本是放弃了的最大代价，沉默成本不是成本

软件选型，不能不考虑成本。软件成本和实施成本，是市场决定的，应留一份敬畏给市场，暂不讨论。

本文谈谈回归本源的成本。

财务上的成本核算最常用的是历史成本法，就是投资一项资产，投入了多少价值的资源，这个资产就值多少钱。

而成本的本源定义是：成本是放弃了的最大代价。一项资产的价值不取决于为购买这项资产而投入的成本，而取决于市场上同类资产的价值（这个价值是实时变动的）。（这个概念不太容易接受，但却是事实）

财务上为了满足可计量以及谨慎性的要求，常用历史成本法是没有问题的。但是IT投资决策时，应遵循成本的本源，才能做出更好的选择。

举个最简单的例子：不考虑折旧（某些IT类无形资产不摊销）：

10年前的笔记本电脑，到现在已经没什么价值了。不是因为财务账务上没有价值，而是因为外部的技术升级。

而10年前的房子，到现在就非常有价值。也不是因为当初买的特别贵，而是因为旁边的楼盘一路上扬。

==============================

文末彩蛋：

本周RPA动态：

1、有一款RPA报关机器人正式投入使用，成为全国首个在出口报关业务上应用运行的RPA机器人

2、继四大会计师事务所之后，又一家国际化事务所（致同Grant Thornton）宣布进入RPA市场

这篇文章就先聊到这儿，下周见！

（正文结束）

1005-RPA的技术架构

上篇文章概括介绍了RPA的软件选择。借助于第三方预测机构的报告列示出可供选择的RPA厂商，以及进行合作伙伴选择的建议。

这篇文章概括介绍RPA的技术架构，包括内部架构和外部接口两个部分。

1、关于RPA内部技术架构

话不多说，直接看图说话，RPA的内部架构（或者称为产品架构吧）如下图所示。总体来说包括RPA客户端③和④、RPA服务器端②、以及RPA集成开发环境①三部分（集成开发环境缩写为IDE，IDE算不上技术架构的部分，每家RPA产品都会提供一个IDE）；其中RPA客户端包括交互式③和非交互式④两类。

图中总体来讲包括RPA客户端和RPA服务器端。RPA客户端安装在PC端，模拟人进行“大量重复”且“规则固定”的业务流程处理；RPA服务器端则用来管理RPA客户端。

关于RPA服务器端

也可理解为RPA管家，就是负责管理“机器人”的“机器人”。

RPA管家的职责包括：RPA功能版本管理、RPA客户端运行监控、任务分配、运行结果展现及日志分析等。

关于RPA客户端

依据是否需要与用户进行交互，分为交互式RPA和非交互式RPA。

非交互式RPA就是完全不需要人参与的机器人（也称为后台机器人）。

交互式RPA的“交互”，从业务角度理解应该为“人机交互”（如何实现人机交互后续文章再专门讨论）。

另外一种“交互”的理解是：机器人的启动是否需要人工触发？（必须由人工触发启动的机器人也称为前台机器人）。

关于RPA的集成开发环境（IDE）

是机器人开发实施人员的设计和发布平台，类似于RPA的VCStudio或者Eclipse。

关于参与的人员

需要有“RPA前台用户”处理RPA无法处理的数据；

需要有“RPA系统管理员”维护和监控RPA管家的运行情况；

需要有“RPA工程师”开发设计和实施落地RPA。

2、关于RPA外部接口

RPA也有很多不能处理的业务场景，那么就需要通过外部接口扩展其功能。设计外部接口目的是为了让RPA专注于其擅长的领域。需要设计考虑的接口包括：PowerShell、Webservice、数据库、DLL插件。如下图所示：

关于PowerShell：后续专门的文章介绍PowerShell的使用。PowerShell名副其实，是很Power的“Shell”脚本工具。另外如果处理Excel还可以考虑使用VBScript（脚本版本的VBA，也就是宏）

关于WebService：这是个万能的套路。

关于数据库：这也是个万能的套路。

关于DLL插件：这个算是基于RPA产品的二次开发。

这篇文章就先聊到这儿，下周见！

（正文结束）

1006-RPA的实施方法

上篇文章概括介绍RPA的技术架构，包括内部架构和外部接口两个部分。

这篇文章概括介绍RPA的实施方法，浅谈ASAP和敏捷开发，以及RPA项目的实施建议。

2017年有幸以监理的身份参与了一个涵盖SAP系统实施和自开发软件的综合项目。其中SAP系统实施采用的方法论是ASAP，自开发软件项目采用的方法论是敏捷开发。在项目进行的过程中，两类项目组看待彼此的眼光都是充满了不解与疑惑，最终双方还是带着“关我毛事”的心态相视一笑，相忘于江湖。

这篇文章会给出ASAP和敏捷开发两种方法论的简要介绍，最后对RPA项目的实施方法给出选择建议。

一、关于ASAP实施方法论

ASAP实施方法论是SAP系统实施的方法论。一直被称为“世界500强背后的管理大师”的SAP公司，推出了这套实施方法论，在业界获得了极大的成功。其合作伙伴在落地实施的过程中，基本都遵循了这个方法论的主要精神（虽然各家也会进行包装，发布各自的实施方法论）。ASAP实施方法论属于典型的瀑布模型。

二、关于敏捷开发

敏捷宣言：

个体和互动高于流程和工具

可工作软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

敏捷12原则：

1、我们最优先考虑的是尽早和持续不断地交付有价值的软件，从而使客户满意。

2、即使在开发后期也欢迎需求变更。敏捷过程利用变更可以为客户创造竞争优势。

3、采用较短的项目周期（从几周到几个月），不断地交付可工作软件。

4、业务人员和开发人员必须在整个项目期间每天一起工作。

5、围绕富有进取心的个体而创建项目。为他们提供所需的环境和支持，信任他们所开展的工作。

6、不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈。

7、可工作软件是度量进度的首要指标。

8、敏捷过程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。

9、坚持不懈的追求技术卓越和良好的设计，从而增强敏捷能力。

10、以简洁为本，最大限度的减少工作量。

11、最好的架构、需求和设计出自于自组织团队。

12、团队定期地反思如何提高成效，并相应地协调和调整自身的行为。

三、RPA项目，我们要怎么做？

首先，实施方法论属于价值观讨论的范畴。一旦涉及价值观的讨论，基本上是没有对错之分，重点是能够自圆其说。

其次，这种“自圆其说”不仅要体现在项目开始前，也要体现在项目执行过程中，还要体现在项目结束的后评价中。类似“不管白猫、黑猫，抓到老鼠就是好猫”的论点，不能否定实施方法论的必要性和重要性。

最后，在“佛系”弥漫的氛围里，也借用《金刚经》里的一句话，表达下对实施方法论的认识：“如来所说法，皆不可取、不可说、非法、非非法。所以者何？一切圣贤，皆以无为法而有差别。”

务虚结束，开始务实。以下观点，供参考：

1、试点类型的RPA项目（3个流程以内，也称为速赢项目），1-2个月完成。类似的项目，总体瀑布模型，其中蓝图和实现两个阶段可作2-3次迭代。如下图所示：

2、大型的RPA项目建议单独启动管理咨询项目，后续落地借鉴管理咨询成果（含系统顶层设计原则）。

3、涉及整个部门RPA项目，必然会对待变革流程的岗位和岗位职责形成冲击。业务流程梳理和管理变革的相关工作应该及时跟进（不论是请独立咨询方还是由RPA实施方负责，项目负责人均应给予足够的重视）。

4、RPA项目系统落地可以分期分批实现，但应遵循系统顶层设计的约束。工期设计要合理，涉及管理或者流程变革的项目，以6-8个月为宜，但最好不少于4个月。

5、依托于成熟的产品进行系统实施，技术复杂度相对较低，业务蓝图成熟度相对较高，采用类似ASAP方法论（重视业务蓝图的个性化设计）较为合适。

反之，软件开发类项目，涉及较多开发人员参与，采用类似敏捷开发（重视每次迭代产生的可使用软件产品）较为合适。

RPA项目（非试点或速赢类项目）通常会是以上两种情况的组合。

6、瀑布模型和敏捷模型不是完全对立的，是可以相辅相成的。瀑布模型里面的环节可以打包迭代（或者是增量开发）；敏捷模型的每次迭代也同样需要有蓝图设计。再举个例子，敏捷开发宣言：“可工作软件高于详尽的文档”，也并不意味着不需要文档。

7、《人月神话》中提到“概念的完整性”非常重要；这个观点同样适用于RPA项目，就是类同于系统顶层设计的输出物。个人对于“概念的完整性”的理解就是最贴近业务实质的技术架构设计。

8、最能“自圆其说”的实施方法论，离开了高水平的实施团队，不会产生任何价值。项目管理的“依依东望，望的是人心”。

这篇文章就先聊到这儿，下周见！

（正文结束）

1007-RPA的演进路线

上篇篇文章概括介绍RPA的实施方法，浅谈ASAP和敏捷开发，以及RPA项目的实施建议。

这篇文章从“RPA本身的演进路线”和“新技术的应用全过程”两个角度概括介绍RPA的演进路线。

最初接触RPA项目开始，对于RPA的态度一直是：这只“旧时王谢堂前燕”终将要“飞入寻常百姓家”。

“演进路线”的主旨是立足于RPA的今天，展望RPA的未来。

说到“RPA”+“未来”这两个关键字，拙作《1003-RPA的优势》中介绍过“RPA与人的集成”、“RPA与信息系统的集成”以及“RPA与未来的集成”。

本文将从另外两个角度（RPA本身的演进路线、新技术的应用全过程）探讨RPA的现在与将来。

一、RPA的演进路线

对于RPA的演进路线，软件产品厂商有产品演进策略（以后可能有文章单独介绍），咨询公司和实施方也会有各自的观点和理解。为避免失之偏颇，本文选取独立第三方（Everest）的报告进行解读和介绍，如下图所示：

重点可关注以下几点：

1、关于RPA发展（演进）阶段的划分。

图中将RPA划分为1.0~4.0共四个阶段，

其中RPA1.0被称为虚拟化助手（Virtual Assistant），后续三个阶段被称为虚拟劳工（Virtual Workforce）。

2、这个框架化的定义是非常有价值的，框出了RPA的过去，现在，将来。

RPA1.0是过去，涵盖了现有的全部的桌面自动化软件。

RPA2.0和RPA3.0是现在，涵盖机器人流程自动化的主要功能。

RPA4.0则是未来机器人流程自动化需要涵盖的功能。

3、这个框架化的定义不仅适用于RPA产品提供商，也同样适用于企业，适用于实施方。

· 对于RPA软件产品提供商，主要是集中在RPA2.0和RPA3.0之间。从产品完善角度来讲，一方面要提升RPA流程自动化程度（解决2.0和3.0的问题），另一方面还要积极探索4.0（AI）技术的引入。

· 对于企业来讲，也可以借助这个框架来判断自身对于RPA的引入程度。例如是观望阶段，还是试点应用，或者甚至已经有在规划RPA卓越中心。

· 对于实施方来讲，需要不断反省能够为客户提供的咨询建议及解决方案能够涵盖RPA的哪些阶段，优势聚焦在哪个部分。

4、无需太多关注框架中的每个阶段定义的具体内容。上图中的细节定义仅是Everest研究人员的一家之言，其他相关方也会依据情景设计不同的细节定义。相关原则类似于拙作《1006-RPA的实施方法》提到的“能够自圆其说”。

5、这个框架化的定义可以为回答以下两个问题提供很好的思路。

为什么RPA能够成为RPA，而不在是原来的桌面自动化工具？

为什么RPA目前还是RPA，而不是AI？

二、新技术的应用全过程

每次介绍RPA，都会觉得：“哇~好高大上！”“会不会很贵啊？”“我们公司用得着吗？”。的确，RPA对于很多用户来讲，是一项新技术。那么我们可以借助Hype曲线来解释下“新技术的应用全过程”，如下图所示：

这个图的解读如下：

1、关于解释这幅图更好的版本。关于这幅图我认为宁向东老师解释得特别到位，所以便摘抄宁老师在《宁向东的清华管理学课》138讲的笔记如下（略作修改）：

Gartner公司把一个新技术从出现到最后得到应用的全过程分为五个阶段。

第一个阶段，也可被称为“先驱阶段”，是这个产品没什么人知道，只在专家和业内讨论的阶段。

第二个阶段，就可以被称为“极盛阶段”。等它到了曝光度极高、显现率增长极快的时候，往往处于第二个阶段。在这个阶段，技术其实还没有成熟，产品也还不够完善，但是，市场已经炒得火热，人们对待它的期望已经很高。大家天天都挂在嘴边上说的那些技术，都处于技术周期的第二阶段。今年说得越凶，到了明年，基本被遗忘得越快。就像去年的VR，今年没有那么多人说了吧。

第三个阶段，是一种“幻像破灭”的阶段。当幻像破灭之后，这个技术已经进入到了低谷，甚至连做风险投资的人，对此都没有兴趣了。这项技术从大众的嘴里，又重新回到了专业人士的手里。

第四个发展阶段的特点就是变：应用的领域可能会变得非常细，产品可能也改变了版本，甚至技术就是完全在一个以前从来没有谈论过的新用途上得到了应用。技术不再像原来说的那么普适，但是，在它的应用领域确实做得非常扎实，只是从大众话题变成了小众话题。

第五个阶段，大家不再谈论这项技术，但大家都在细分领域里有条不紊地应用着这项技术。而且这项技术实实在在地带来了盈利，而不是热热闹闹地烧钱。

2、RPA目前在哪个阶段？

上图中与RPA相关的新技术Virtual Assistants，位于Hype曲线的最顶端（第二个阶段）。

笔者认为RPA这项新技术在2018年所处的阶段可能会比Hype曲线的预测要更靠右一些，可能处于第三阶段和第四阶段之间，即“幻灭期”到“复苏期”之间。

说两个判断理由：

理由1：RPA产品厂商经历了超过了十年的技术积累，并且已经在资本市场有比较稳定的表现。请参见下表：

理由2：RPA在亚洲市场的表现非常优异，在国内各行各业的应用已经逐步开启，而且我们已经通过项目培养出了专业的实施团队。

这篇文章就先聊到这儿，下周见！

（正文结束）

1008-RPA与卓越中心

上篇文章聊了聊老本行的东西：全面预算管理、SAP BPC、以及RPA的破局。

本文再换个角度，谈谈企业应该如何定位RPA技术以及建立卓越中心的一些思考。

一、源起

场景一：模拟了如下的的对话：

IT部门：你们用RPA能做的事儿，我们都可以开发出来呀。

RPA售前：嗯，理论上是的。不过借助RPA产品，可以加快开发的进度。

IT部门：如果拿你说的这个案例来说，咱们的开发速度差不多，我们现在也是敏捷开发。

RPA售前：对于一些没有办法直接开发接口的系统，RPA的优势比较明显。

IT部门：（略作思考）其实，RPA本身并没有涉及特别高级的技术。

RPA售前：RPA在各个业务领域已经有了很多的落地应用，取得了很好的效益。

IT部门：……

场景二：模拟了如下的的对话：

财务专员：RPA能帮我解决增值税发票勾选以及对账的问题吗？

RPA售前：必须能啊~来，我给做个演示。

财务专员：嗯嗯，这就是我想要的！我向领导汇报。

财务总监：嗯~~~，RPA是很不错的技术，我们不能仅仅聚焦在这个单个的需求，要从全集团层面统一规划。

接下来，我们解读下这两段模拟对话，同时基于RPA当前的发展阶段，谈谈对于实现卓越中心的一些思考。

二、对RPA技术/RPA项目的定位

上面的模拟场景是两个具有代表性的现状。

场景一中，IT人员从技术先进性的角度对于RPA并不会特别追捧；

场景二中，业务人员在“AI&机器人”的宣传下会对RPA有非常高的期望，希望能够建立“机器人卓越中心”或者“创新中心”。

从RPA发展历程看来，可以将2017年定义为RPA元年（国外稍微早一点儿，也没有早太多），2018年算是第二年。如果谈到“卓越中心”，彼此的差别可能在于“有或者没有规划？”，所以大家都是“在路上……”。

一路前行的路上，谈谈我的看法和建议。先提三点吧：

2.1、用RPA来解决最棘手的问题，而不是全部的问题

当前阶段下，虽然RPA的AI属性并不强，但是对于满足“规则明确”和“大量重复”两个特征（原创总结，请随意借用）的业务场景，有着天然的适应性，杀伤力极大，收益极为明显。

作个类比，现在不上RPA，相当于有钱（不牺牲流动性）不存余额宝（4.1%），非要存银行活期（0.35%）。

RPA的优势有很多，但请不要试图用RPA解决所有的问题，并认为RPA是最好的解决方案。

例如，对于企业来讲，解决银行对账最有效的办法是借助于专业资金管理系统（含银企直联功能），其次是用RPA，最后是人工对账。

再比如：纳税自动申报，如果企业法人实体的数量并不多（例如10个以下），那么非要用RPA自动申报，实际的收益并不大。（如果应用于财务外包中心的话，就是另外一个故事了）

2.2、RPA项目是一项信息系统项目（IT实施的项目）

RPA项目“实施周期短”，“见效快”，“开发工作量较少”，无论如何强调RPA项目与传统IT系统实施的区别，RPA在企业的落地终究还是IT系统实施类项目。

IT系统实施永远会涉及到企业内部的两方密切配合：IT部门和业务部门（包括财务部）。

一般来讲：业务部门负责需求确认，IT部门负责系统落地。

需求确认的部分需要咨询、流程梳理、涉及组织架构、岗位职责、规章制度等等；

系统落地的部分需要系统规划、实施方案、系统上线、后续运维。

让专业的人做专业的事儿，在RPA落地有两个层面：

在企业内部，让使用的人提需求，让IT的人来落地。

在选择外部的服务商时，聘请有丰富IT咨询实施经验的团队。（从事RPA开发一年经验只能算比较早的介入了，但从IT咨询实施的角度来讲，一年经验只是刚入门而已）

2.3、卓越就让RPA连接AI，而不是固守传统

关于RPA的优势，在拙作《1003-RPA的优势》中提到了三点思考，从关于人的集成、关于信息系统的集成、关于未来的集成进行了阐述。

应用新技术（RPA/AI）和创新本身不是目的，解决实际问题（获取竞争优势）才是目的。

卓越中心的“卓越”是体现在能够在最短时间和有限资源的约束下，借助适合的新技术，解决企业当前最棘手的问题。

卓越中心的组织架构，技术架构，路线规划等话题，以后再讨论，先谈谈“关于时间和资源的约束”以及“关于AI相关新技术的适用”。

a、关于时间和资源的约束：

之前我总结过IT系统建设的两个主要矛盾（全文参见《1003-RPA的优势》）：

矛盾1：企业日益增长的对IT系统的需求与IT系统有限的资源投入之间的矛盾。

矛盾2：企业对业务变更迅速响应需求的与IT系统建设需遵循固有周期之间的矛盾。

RPA的快速部署特性以及亲民的价格，可以在一定程度上缓解这两个矛盾。

b、关于AI相关新技术的适用：

RPA本身并不是AI，但是RPA可以轻松地连接AI，“让AI变得触手可及”。

互联网企业借助大量技术人员的力量，用“试错+快速迭代”的方式占领了一个又一个的技术高点，但同时也付出了高昂的人力成本。

RPA从某个角度提供了弯道超车的机会，更多地企业可以以较低成本参与到“试错+快速迭代”的模式中，让AI相关的新技术为企业发展保驾护航。

这篇文章就先聊到这儿，下周见！

（正文结束）

2001-RPA与爬虫

面通过七篇系列文章，介绍了RPA的基本概念，包括RPA的定义、RPA的优势、RPA的软件选择、RPA的技术架构、RPA的实施方法、RPA的演进路线。

通过阅读这七篇系列文章，相信对于RPA已经有了总体的概念和印象。

接下来，本公众号将和大家一起登堂入室，开启第二道RPA大门，暨一个新的RPA文章系列：RPA的功能漫谈。

RPA功能漫谈，先从网页操作开始。

本文要说的事儿是：RPA与爬虫。

一、源起

笔者所在的咨询公司需要在市场上赢取自己擅长的项目（例如RPA项目机会等），便需要特别关注各大招投标网站的信息。鉴于我们有RPA的团队，领导便安排了任务：用RPA每天搜集各个招投标网站信息，将结果发给相关负责人。

需求迅速被明确定义，然后分配任务到对口的RPA团队小伙伴，这时路过的同事问了一个问题：为什么不用Python爬虫？

这篇文章，我们谈谈爬虫、Python、以及和RPA的关系。

二、爬虫和Python

这是一个关于RPA的公众号，爬虫和Python的内容，只提问题，不作回答，顺便提些思考和观点。

什么是爬虫？（百度百科可以看个大概，维基要更专业些）

什么是Python？（一种解释性编程语言，目前非常火爆）

关于爬虫的观点：

1、爬虫技术使用最多的公司：Google、百度。还有我们非常熟悉的：去哪儿。

2、爬虫经常会被要求短时间内抓取大量数据，可能会对目标网站造成一定的流量压力。频繁和大量被竞争对手获取网站数据，可能导致竞争优势的稀释。

3、爬虫会被区分为“好”爬虫和“坏”爬虫。（网站所有者来决定孰好孰坏，通常搜索引擎是“好”爬虫，竞争对手的爬虫都是“坏”爬虫）。

4、每个网站可以按照规范（robot.txt文件）定义允许爬虫爬取的内容，但从来都是“防君子不防小人”。

5、网站和爬虫之间互有攻防，就出现了这样的概念：爬虫、反爬虫、反反爬虫。

这个对抗可以一直循环下去，图形越来越大，而图形越大代表着双方付出的代价越高（涉及的内容有：间隔时间、Cookies、user-agent、IP、文字图片化、假链接、假数据、误伤率等）。

让这个循环达到平衡不是因为双方顿悟，而是因为彼此的边际贡献趋近于负数。

6、边际贡献这个事儿，适用于所有的IT项目，包括RPA项目。

说简单点儿就是：追求完美的成果，代价一定是对应“完美”的价格。适可而止是一门艺术。

关于Python的观点：

1、“存在即合理”。这么火一定是有道理的。

2、回归本质，Phthon也是一门编程语言。对编程人员越友好，对效率就越不友好。

3、编程语言、数据结构、算法永远是不同的概念，也永远是相辅相成的。

4、当初做C语言程序员，觉得Java不操作指针，不释放内存，怎么能长久？现在来看，C和Java各自安好。

现在Python（还有R语言）的语句更加简洁，不断降低编程的入门门槛确实是件好事儿。

5、用Python写爬虫，资源很多，上手很快；同时，程序员也很贵。

三、RPA和爬虫

现在来回答最初的问题：

1、针对于从网页获取招标信息来讲，爬虫可以实现，RPA也可以实现。均不存在技术难度的问题。

2、针对这个需求，RPA实现更加容易，周期更短，速度更快。

跳出这个需求，一般来讲：

3、爬虫在处理网页内容时，直接操作HTML，可以非常灵活和精细（借助正则表达式几乎无所不能）；RPA操作的是可见的网页元素，模拟人的操作可以，替代爬虫的功能是比较困难的。

4、利用RPA爬取网站信息的场景，多数不算是“坏”爬虫。因为前提是模拟人的操作，提升工作效率。

关于RPA和反爬虫：

5、从必要性角度来讲，如果RPA获取网页数据的数据量相对不多、而且频率相对较低的话，反爬虫大概率不会进行封锁（误伤率是反爬虫非常在意的指标）。

6、从复杂性角度来讲，如果RPA仅仅是模拟人的操作，执行特定操作的话，反爬虫是很难通过模式识别的手段，精准区分人的操作和RPA的操作的（幽默的是：最难抓的爬虫之一是人肉爬虫，但人肉爬虫还是算爬虫吗？）。

7、验证码是反爬虫（包括防止RPA）很有效的办法。验证码和OCR的事儿，我们以后再聊。

这篇文章就先聊到这儿，下周见！

（正文结束）

===============================

2002-RPA与网页（增值税发票验真场景）

上篇文章开启了一个新的RPA系列文章：RPA的功能漫谈。从网页操作说起，聊了聊RPA、Python和爬虫的一部分内容。

本文将继续这个话题，结合增值税发票验真的场景，说下RPA的网页操作。

一、源起

增值税发票验真是一项重要的财务审核工作。目前采用的主要方法是登录《国家税务总局全国增值税发票查验平台》（网址：https://inv-veri.chinatax.gov.cn/）进行查验。登录页面信息如下图所示：

发票验真需要四项发票信息：发票代码、发票号码、开票日期、校验码（或者开票金额）。以上信息在网页中输入完成后，输入正确的验证码，点击“查验”按钮，即可查询发票信息（如下图所示）。

如果是财务共享中心人员进行人工核对，那么逐一核对相关信息即可。但我们要讨论的是借助RPA完成发票验真的自动化，可能会稍微遇到一些问题：

由于查询结果不可选中，RPA软件无法直接识别上述发票信息，例如公司名称、纳税人识别号、价税合计等信息（选用了2款RPA产品进行测试）。这个问题该如何解决？

二、问题的分析

1、最直接（或者称为“粗暴”）的方法：借助OCR（Optical Character Recognition，光学字符识别）。

这是一个算是“万能”的办法，但是存在的待识别信息定位和OCR识别率的问题。在这个特定的场景下，绝非是最佳选择。

如果上述发票信息是一张图片，那么OCR将是我们唯一的选择。

幸运的是：这些发票信息不是以图片形式存储。

2、借助浏览器的“Web开发者”→“查看器”（笔者使用FireFox 25.0.2版本的浏览器），发现可以在HTML代码中找到发票的各项信息。如下图所示：

这种情况下，要相信：如果下载的网页中包含了需要的信息，那么通过调整RPA的设置，就一定可以获取到这些信息；从而避免在类似场景下使用OCR。

三、问题的解决

通过分析网页代码，可以发现发票的信息都有唯一ID（例如，公司名称对应的ID是：gfmc_pp）。

依据该ID，RPA能够识别到相关信息，便可完成后续的流程自动化动作。

最后，将问题一般化，网页操作的一般套路，总结为三步：

1、下载网页

2、网页元素定位（RPA开发需要重点关注的部分）

3、网页具体操作或者数据下载

网页设计会涉及到三个主要技术：

1、HTML（框架）

2、CSS（样式，决定网页长得好看不好看）

3、JavaScript（动作，决定网页可以支持哪些动态操作）

上例中发票验真的网页相对比较简单，不涉及多个网址之间的切换。如果涉及到多个网址的切换，则需要关注当前激活（Active）的网页是否是预期待操作的网页（通过句柄handle判断或者网页名称判断）以及网页内容是否完成加载。

如需更多关于网页操作的探讨，可以给我们留言或者发邮件。

这篇文章就先聊到这儿，下周见！

（正文结束）

===============================

3001-RPA与财务共享中心

上篇文章比较偏技术，结合增值税发票验真的场景，介绍RPA的网页操作，提到如果能够截取网页元素获取到相关信息，应避免使用OCR“野蛮”识别获取数据。

本文将重归业务讨论的范畴，概括性介绍RPA和财务共享中心（后续再逐步展开）。

一、源起

最近在准备一个财务共享中心的RPA投标，做个不完整的初步总结。

文章的技术属性太多，大家都不喜欢（请参见文章阅读人数的对比）；所以还是要多从业务角度切入。（不过技术文章不会停，后续还是要继续探讨的）

做RPA咨询和实施，财务共享中心是绕不开的话题，也是最先能够联想到的场景。所以，本文概括性介绍RPA和财务共享中心。（后续再逐步展开）

二、对财务共享中心的理解

早在2013年，财政部印发《企业会计信息化工作规范》中第三十四条便提到：“分公司、子公司数量多、分布广的大型企业、企业集团应当探索利用信息技术促进会计工作的集中，逐步建立财务共享服务中心。”

时至今日，财务共享中心的概念已经深入人心，拥有财务共享中心的企业数量已经非常庞大，整个产业生态相对趋于成熟。

本文从财务共享中心的概念外延、建设目的、运作模型、绩效考核、服务内容，共五个点进行简要论述。

2.1、财务共享中心的外延

财务共享中心=“财务”+“共享服务中心”。

换句话说是：“共享服务中心”在“财务”领域的应用。

再换一个角度：“共享服务中心”在“人力资本”领域的应用=人力资本共享中心。

2.2、财务共享中心的目的

建设财务共享中心的目的（进行一般化归纳后）有两个：成本节约（省钱）、集中管控（省心）。

关于成本节约（省钱）：

a、财务共享中心建设本身是需要投资，需要付出成本代价的（场地租赁、软硬件设备、人员工资），在日常运营过程中，基本都算是固定成本。

b、规模化的运营可以带来效率的提升和成本的节约。

关于集中管控（省心）：

c、任何管理活动都是要付出成本代价的，想实现“集中管控”的管理目标也不例外。

d、“集中管控”模式下，“内控合规、风险评价”的落地成本可以降低很多。

补充一句，关于赚钱：

e、如果某家财务共享中心运营成为一个利润中心，能够具备市场竞争力，并且带来现金的净流入；那么初步可以认为这个财务共享中心是一个被主业耽误的财务咨询公司。

2.3、财务共享中心运作模型

如果从头开始建立财务共享中心，可以从以下六个角度进行设计规划：

a、选址落地（选择前会纠结很久，定了也就定了）

b、管控模式（运营模式以及在集团中的定位和汇报关系）

c、组织设计（共享中心内部的组织结构和管理模式）

d、业务流程（参见后续2.5、财务共享中心服务范围）

e、技术支撑（系统架构，软硬件支撑，供应商选择）

f、服务框架（参见后续2.4、财务共享中心绩效考核）

更为详细的内容，可咨询您合作咨询公司，或者联系我们。

2.4、财务共享中心绩效考核

财务共享中心建立后，绩效考核包括三个考核对象：

a、财务共享中心在集团内部的使用部门或组织（对于输入的考核、督促其他部门积极配合财务共享中心的工作）

b、财务共享中心内部的部门或者岗位（对于执行过程的考核、评价财务共享中心内部业务处理的效率）

c、财务共享中心的服务水平协议指标（对于输出的考核、评价财务共享中心提供服务的能力水平）

2.5、财务共享中心服务范围

从财务管理的角度，服务业务内容可选范围包括：

总账会计

采购到付款

销售到收款

固定资产

费用报销

成本管理

法定报表（单体+合并）

管理报表（单体+合并）

税务管理

预算管理

资金管理（含投融资）

稽核内控

风险管理

投资者关系

财务战略管理

财务人员管理

日常职能管理

三、财务共享中心与RPA

3.1、场景匹配

之前的文章提到：目前阶段，RPA适用于“大量重复”和“规则明确”的业务场景。

财务共享中心在建设之初就考虑到了流程的标准化设计，符合“规则明确”的条件；同时，集中化，规模化的运营模式，势必会涉及到很多“大量重复”的业务场景。

所以财务共享中心是RPA应用落地的非常契合的场景，同样RPA也能够为提升财务共享中心的服务水平带来很大的帮助。（所以也有人会把RPA称为财务机器人）

3.2、外延匹配

前面提到：财务共享中心=“财务”+“共享服务中心”。

RPA与“共享服务中心”是非常好的搭配。

那么适用的场景就可以从“财务共享中心”扩展到“人力资本共享中心”、“IT共享中心”、“呼叫共享中心”、“运营共享中心”……

3.3、较佳切入点

如果选择试点的流程，进行自动化程度的提升，往往会选择与外部网站（或外部系统）交互的流程场景作为突破口。

举几个最常见的例子：税务网站（含税控系统，报税系统）、银行网站、物流网站等等。与这些网站相关的业务流程就不用多解释了。

此外，跨内部系统间特定规则的自动比对校验也是常见的选择点。本来需要开发很多系统间接口才能实现的功能，对于RPA来讲实现相对比较轻松。

这篇文章就先聊到这儿，下周见！

（正文结束）

===============================

3101-RPA与全面预算管理

上篇文章从业务讨论的范畴，概括性介绍RPA和财务共享中心（后续再逐步展开）。

本文将继续跑马圈地，换一个新的领域进行框架概念性的介绍：RPA与全面预算管理。

上周连续的加班，没有能够更新文章，也要道个歉：不好意思，会持续努力的。

一、源起

最近做了个SAP BPC预算项目的POC，也和客户交流关于如何能够解决预算编制人工工作量大的问题。

客户对于全面预算的概念已经不再陌生，是有些经验的成熟用户，能够比较明确地表达自己的业务需求；对于项目管理的过程也比较了解，希望能够对于项目执行过程有更多的控制权和主导权。这样的氛围下需要进行快速迭代交付。

借着这个机会，整理下对于全面预算管理的理解，以及其中可以涉及到RPA的部分。

二、全面预算管理

全面预算管理使用的软件是SAP BPC。目前来讲，大型企业进行预算管理的软件选型，从软件功能，成熟度，成功案例，市场占有率等多个维度考虑，SAPBPC几乎变成了唯一的选择（采用本地化部署的模式）。原因不细说，不服来辩，有问题可以单聊。

这款产品（SAP BPC）从2011年发布10.0版本开始，一路开挂，我们见证了她从几乎在国内没有成功案例，到如今几乎是一家独大的整个过程（最大的竞争对手是Oracle的海波龙）。

做了很多年SAP BPC顾问，很遗憾没有完整地记录每个项目的收获和心得。有最近一次的售前经历正好可以借机做个整理，想了很多的切入点，最终决定从我理解的全面预算管理最重要的三个点说起，分别是：沟通以建立契约、深入骨髓的预算观念、快是绝对的追求。

2.1、沟通以建立契约

预算的沟通，最主要的是公司决策层和执行层的沟通，并建立关于预算期间的契约。

用通俗的语言再描述一遍：最主要的沟通是：集团预算部门向上要向总经理/总裁等提供预算编制的数据，有效地为大老板们提供决策支持；同时还要组织和主要业务部门的负责人的预算访谈，商讨如何把大老板的宏伟目标，布置给各主要部门的小老板们。

这个沟通的过程是全面预算管理实践中最有价值，也最有意思的部分。

这个层面的沟通时间越充分越好，沟通的主要方式以线下交流为主，需要预算管理部门默默支撑的是下属各部门翔实的预算编制数据以及历史同期数据（以上两点需要SAP BPC系统支持）。高层决策其实还需要外部环境的数据，例如经济发展总体情况，竞争对手情况等（这部分的数据的获取，RPA可以提供部分帮助）。

大老板拍板的结果一般不会特别明细，更多是方向性的，或者粗粒度的指标，或者宏观性的增长率，可能后续需要预算管理部门组织各业务部门进行明细化的分解。也可以把这个过程叫做目标设定和分解。

预算目标一旦确定，就应具有严肃性，因为契约是要被严格遵守的。

2.2、深入骨髓的预算观念

契约关系建立后，执行落地的精髓不在于费力不讨好的几上几下，也不在于对住宿标准或餐费报销的严格管控， 而是在于让深入骨髓的预算观念指导每位员工的日常行为。

关于“预算观念”，让我叹为观止的四大对于人员成本和收入的极致管控。

例如：

所有刚入职的小朋友都知道自己顺利升Grade取决一年的Performance，这个Performance中非常硬性的指标是Chargeable Hour的数量。所以，有Manager让小朋友干活儿，小朋友就会问：我要Charge哪个项目？

所有的Manager都要考虑两个指标：Win和Revenue（四大各家对每个指标的解释会有不同）。一个指标代表新拿的项目金额，另一个代表现有项目的完结金额落在自己头上的部分。对于Revenue的约束要求便是考核MIC（Manager In Charge）不可以让项目爆掉（成本+费用不可以大于收入）。

合伙人会在每周周会上强调Win和Revenue的完成情况，不断加强大家对于这些数字型指标的重视程度。大家都看着数字说话，公平性相对是可以保障的，人际关系就相对比较简单。

这个例子不仅仅是业务和财务在预算管理维度上实现一体化的案例，更是量身定制的KPI指标和企业文化相融合的案例。因为在公司里每个Level的员工随时都知道自己在特定环节背负的最主要的指标是什么，以及如何努力才能够通过让自己的绩效最优，从而实现团队预算目标。

2.3、快是绝对的追求

上文中提到目标设定的沟通过程以线下沟通为主，并且时间越充分越好。那么在预算编制花费总时间不变的情况下，预算编制所占用的时间越少越好，预算编制的速度越快越好。

预算编制的重要目的是为决策层（大老板）提供决策参考，只有编制花费的时间足够短，那么用于决策层和执行层（大老板和小老板们）之间线下沟通的时间才够充分，数据才够有说服力。

最常见的两个误区：

a、让预算管理系统提供复杂的审批流功能。（错误）

说实话，老外设计系统的时候确实没想什么是“会签”。复杂的审批流程很难说清白一件事儿就是：某一层面的审批人签署的“同意”，是针对于预算数据的哪一个部分（子集）发表意见并承担责任？

往往见到某个SAP BPC项目集成了复杂的审批流，很大可能性这是个失败的项目。

b、希望借助预算管理系统，解决目前跨部门沟通的问题。（部分错误）

如果跨部门沟通的问题在于数据不能够实现有效共享，那么借助预算系统多维模型，可以让数据在各部门之间友好地共享。

如果存在跨部门间本身的沟通不畅，希望借助预算管理系统完美解决，基本上不可能。面对面沟通都没有办法确定的分歧，不可能仅仅通过系统就能快速解决。（预算的沟通，最高效最有价值的地方是上下级和平行部门之间的当面有效沟通），因为分歧本身不会因为上预算系统而自行解决。

三、RPA的破局

经历个好多个预算周期，有萦绕在心头的两个问题一直不能够很好的解决，分别是分析和预测。

粗暴地分个类：分析是对过去的总结、预测是对未来的展望。

两者需求的共同点都是：需要数据的支持，需要算法的引入。

3.1、关于数据

数据是分析和预测的基础。

以下两种情况是数据获取比较不容易处理的：

a. 跨多个内部应用系统的数据抽取。ETL和ELT本身都是成熟的，麻烦在于数据之间的逻辑关系在业务层面和系统层面如何有效说明定义以及接口开发的复杂性和固有开发周期。借助RPA直接从业务前端获取数据，可以部分省掉/减轻数据仓库后台开发运维的工作量。

b. 外部数据获取。爬虫技术和RPA技术都是不错的可选方案。

3.2、关于算法

算法的事情最简单是Excel公式，之外还有Python，还有R语言，还有SPSS/SAS。

之前如何集成是个小问题，有了RPA，相当于大量的算法库对预测和分析敞开了大门。

3.3、关于可视化

数据的可视化是帮助管理者看到数据背后秘密的最直观的方式。

解决了数据源的问题和可视化软件使用的问题（RPA负责总体串联），可视化的数据可以让决策更科学，更有说服力。

这篇文章就先聊到这儿，下周见！

（正文结束）

===============================