今天給大家簡談一下有關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