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

下周的文章会谈一谈RPA的演进路径，敬请关注。

感谢您的关注和阅读，希望这篇文章能为您带来帮助。