今天给大家简谈一下有关COE方面的一些认识。

记得当初刚进入RPA行业的时候，对RPA还不是很了解，但是幸运的是所在的公司基于RPA有一个专门的数字化中心。我们可以称之为COE，里面的人员配置大概是这样的：有多年技术积累的项目经理，基本都至少擅长一门外语，英语或者日语，因为内部项目并不是做不完的，也会接外部的项目，比如欧美或者日本。会有配套的擅长技术的实施人员，如果不是需要英语或者日语的翻译，通常会直接负责和客户沟通交流理清逻辑负责开发和交付，如果需要，会有专门的项目经理去做前期的整理。如果是内部，也会以按日报价的形式去做RPA项目，但是基于市场并不高。这样的架构是比较简单清晰的，精通外语的项目经理加上擅长技术的实施人员。

另外还有的就是架构会很大的标准化COE，基于总部建立，分部设立的配置，通常会有业务积累很多年经验的自动化经理，可以协调各个部门提出需求，但是这里面呢，会把各个部门PM提出的RPA项目作为KPI，所以部门提需求会很积极，这里面的推动者就是C-Lever,还有就是熟悉一门外语并有多年技术经验的项目经理，以及一些擅长开发的实施人员，这些项目的进行，通常是部门经理带上自动化经理然后还有RPA项目经理以及实施人员一起进行前期流程的工作。

  以上都是国内通常的COE架构配置，当然也遇见过一些公司想建立COE，但是却想的非常简单，就觉得找一个会RPA的开发人员就觉得行了，笑而不语。

以下为大家整理了一份图表，这是比较标准化的COE配置，通常在国外的一些大公司，会设置这样的架构，来服务于整个公司内部的RPA。

看完之后是不是感觉很高大上，里面全是非常专业的人员，从架构，设计，转换，梳理，优化，开发，测试等配置非常全面，而通常对于从事RPA项目工程的人来说，我们觉得一个项目单兵作战就可以了，干嘛耗费那么多，但是如果在整个公司内部进行跨部门协作，并不是一件容易的事情，拿一个简单的例子，也是我之前遇到过的，有时候一个部门的RPA项目流程，可能和其他三个甚至四个部门的流程有超过百分之七十到八十都是一样的，那么如果缺少一个自动化经理，是不是最后要浪费大量的人力财力和物力去给各个部门都做一个，但是实际情况呢，其实只需要汇总成一个流程，只在最后分支根据各个部门特定的需求做参数灵活配置就能达到要求。通常因为局限，还会遇见耗费许久做出来的项目因为公司业务流程调整而用不上的，还会遇见IT技术支持跟不上整个项目垮掉的等等。所以全面的配置对于公司内部整个RPA的部署是优质而必要的。每一个角色看来都不可缺少。

以最基本的实施人员来说，要求是比较高的，最起码技术是最基本的硬性指标，我们并不反对业务人员去做RPA，毕竟RPA软件的最终目的是希望业务人员能人手一台自己去做一些RPA项目来帮助自己协调工作，但是基于目前任何一款RPA产品，在给公司做一些较大的RPA项目来说，还没有哪一个能完全脱离源码或者代码脚本去完成它，更不用说基于流程的异常处理，消息机制和日志追溯。所以目前的建议还是需要有技术经验比较丰富的配套人员去实施RPA工程而不是简简单单觉得熟悉一个RPA软件就可以去做这样的项目，顾眼前而不顾长远，最终会把一个RPA项目搞死或者拖死。

对RPA项目经理，这是一个非常重要的角色，也是很多技术人员想要达到的一个职业目标，他需要统筹全局，把控整体项目，会技术不会管理不行，会管理不会技术更不行，任何一个缺失，都会给项目的进程挖下一个大坑，你可能会遇见把流程梳理一团糟甚至连精细化流程图都没有的，最后实施完客户说这不是我们想要的，连懵逼的机会都没有，也可能遇见前期让客户连最起码的基础设施都还没准备好就贸然进入实施的，结果工期可能拉长了一倍甚至二倍。当然，坑遇见得多了，成长的也就快了吧 （A joke）。

基础架构架构师那是部署RPA机器人的强力后盾了，得不到部门IT技术的支持，想做RPA那是痴人说梦，从电脑配置，账号管理到权限申请，哪一样都离不开他们，更别说一些莫名的故障需要排除了。

而项目架构师呢，这是一个非常厉害的角色，通常从技术角度来讲，要至少拥有九年的技术积累和项目经验积累才能有资格考证架构师。但简单就架构来说，他是源于对重复性业务的抽象和对未来业务扩展的前瞻，即你的经验和预见。

以上就是对COE的一些认识，通常的布局与公司内部C-Lever层领导的推动和眼界有很大的关系，当然和RPA厂商的关系也脱离不开。

继续阅读：

未经允许不得转载：RPA中国 | RPA全球生态 | 数字化劳动力 | RPA新闻 | 推动中国RPA生态发展 | 流 > RPA工程里面的COE