rpa專案poc 梁巴里吐槽 RPA專案的日常

2021-10-14 07:04:59 字數 2386 閱讀 6061

有的小夥伴可能明天就要到辦公室上班了,希望大家的生活可以早日回到正軌!

1. rpa宣講

對於初次接觸rpa的客戶,都需要先宣講一下,拋磚引玉嘛。

好幾次給乙個新客戶組織rpa的介紹,一開始只有幾個人來聽。聽完之後覺得不錯,又拉了其他幾個部門的人來重新講一遍。過幾天傳到別的部門又來重新了解一遍。

看來宣講也是個大量重複的工作呢。

2. 收集需求

宣講完接下來就是期待有良玉回來--收集需求。

嘗試過好幾版需求收集表,效果總是不好。明明也就幾個格仔,例子也給了,為什麼就是不填呢。非得後續乙個流程乙個流程地問回來。

這是拋磚引磚麼。

3. 流程調研

找到了合適的流程後,就要進一步了解這個流程。

已經選中需要調研的流程一般都是有價值去實現的。能夠好好介紹這個流程就不錯了。但是和業務老師聊high了之後,很容易會把話題扯遠,一下子需求就氾濫了。

專心點專心點,一口吃不成胖子的。

4. 概念驗證

概念驗證英文是proof of concept,簡稱poc。目的是確認用機械人來實現流程自動化是可行的。

但是往往許多客戶的業務人員在poc階段就丟一大堆需求,甚至是要求完全實現所有功能。

5. 需求確認

完成了前面的工作後,就要整理好需求讓客戶確認。包括功能性和非功能性需求。確認完專案就要啟動了。

專案管理理論都讓我們要重視這乙個環節,因為確認後變更是會產生成本的。但是哪怕得到了客戶的確認,到了後期還是經常要免費改動。甚至有一些時候就是死活不確認的。

爸爸就是爸爸。

6. 流程設計

這時候需要把最終落地的方案設計出來。包括機械人的部署、人機互動、機械人與系統的互動等。

在梳理的時候經常會遇到一些莫名其妙的操作,問回業務人員為什麼要這麼做的時候竟然會說不知道,以前就一直是這麼做的。後來搞清楚了,原來有的是一些歷史遺留的操作,有的還是系統公升級之後不需要這麼做的操作。

大家聽說過「猴子定律」麼?

7. 機械人開發

到了開發階段,就純粹是實施工程師的事情了。

年資尚淺的工程師寫的**一定要找人複核。遇到乙個例子,一段重複的功能沒有抽出來打包成通用模組,而是在主程式裡多次出現。導致整個程式複雜得不得了。正常跑一遍需要乙個多小時。我重寫了之後只需要1分鐘就跑完了。

有時候我覺得葉問這種乙個打十個真不是吹的。

8. 測試機械人

測試的時候目的是確保開發好的機械人能夠滿足需求,一般需要通過單元測試、整合測試、使用者接收測試。

很多時候我看到測試人員在測試的時候腦筋沒有轉過來。舉個例子,乙個流程有abc三步,需要測b這一步。有的人就是要讓機械人從a開始跑。硬是把單元測試做成了整合測試。

做rpa的人不能把自己變成了個機械人啊。

9. 部署機械人

所有測試都通過了之後,就要部署到正式的環境準備上線了。

rpa的一大特點就是對執行環境非常敏感。如果生產環境跟開發的有區別,很容易出現跑得好好的**一跑就掛。最尷尬的是自己跑的時候都好好的,一叫客戶來看就失靈了。

每次啟動機械人的時候都有點感覺在**。

往期回顧:第五篇:梁巴里分享|什麼樣的流程適合用rpa來實現自動化第四篇:梁巴里分享|為何有些企業能推進rpa而有些不行?第三篇:梁巴里分享|rpa的核心技術與ipa第二篇:我看好rpa的幾個原因第一篇:梁巴里對rpa的理解

關於梁巴里

我叫梁一綱,英文名是barry。目前在金融科技公司擔任rpa產品總監,曾在銀行當過大型機(mainframe)開發,資料分析師,流程優化顧問;在四大當過稅務資訊化與rpa流程自動化諮詢師,在某外資it諮詢巨頭打了幾個月醬油。希望能夠繼續以rpa為切入點,在金融科技(fintech)的道路上發(duo)光(zhuan)發(dian)熱(qian)。

rpa專案poc 企業如何進行RPA專案的POC?

講師介紹 rpa之家資深講師,uipath教程撰文作者,rpa方 實踐者,擁有近10年軟體開發經驗,5年的專案管理經驗。參與過多個大型網際網路專案 傳統業務專案開發。曾專注於o2o 區塊鏈等領域。擔任過工程師 產品經理 專案經理等角色。曾帶領團隊實施多個rpa專案。對市場上主流的多種rpa產品具有較...

rpa專案poc RPA專案如何順利部署實施POC

poc proof of concept 常譯作 概念驗證 是企業部署rpa的必經環節。作為業界流行的針對客戶具體應用的驗證性測試,poc的關鍵特點即匹配使用者真實的業務場景。根據客戶對系統提出的需求和標準,在指定的業務場景,通過對編寫好的指令碼進行測試,以發現其侷限性,幫助確保rpa機械人按預期工...

藝賽旗rpa專案分享

首先我要強調rpa專案開發需具備的三大特性 長期穩定性 後期擴充套件性 易維護性 這三大特性也是我們設計整體流程框架應該遵循的思想。一 專案準備階段 需求分析階段 該階段需要我們熟悉業務提供的 不完整 的需求文件,分析並深入理解需求,梳理出需求中不明確的地方,以便同業務部門確認。需求確認階段 該階段...