RPA機器人如何精準瞭解客戶需求

導語：雲擴科技作為一家專注於研發RPA+AI平臺的高科技公司，在不斷迭代產品為使用者提供“簡單·智慧，人人可用”的RPA+AI機器人產品與解決方案的同時，也更加註重RPA專案的交付及服務，經過多年行業積累，總結出一套雲擴獨有的實施方法論。

【稿源】喬金麟@雲擴資深交付專家

RPA實施方法論之需求調研篇

通常，RPA專案在啟動前後需要進行需求調研工作，可以說需求調研的好壞是決定專案成敗的直接因素，前期如果沒有掌握並且合理的規劃需求，將會大大增加專案失敗的風險，所以關於需求調研的工作，就必須要有一個系統化的執行思路。
今天就由雲擴RPA實施專家喬金麟，與大家共同分享如何進行需求調研工作。

前期工作準備

需求調研大部分是由專案經理或者專業的需求分析師參與，面對客戶需求，要儘量做好以下準備：

l 客戶背景：瞭解客戶所在行業，提出需求的部門，以及部門職能；
l 系統背景：瞭解客戶所使用的系統；
l 需求背景：瞭解客戶痛點以及預期目標。

會議準備

當前期準備工作完成後，來到客戶現場進行調研環節，一般情況下需要做好以下準備：

l 會議室：獨立的會議室（給到足夠的儀式感，及專業性）
l 白板：用於需求梳理和頭腦風暴（透過白板的方式將客戶所有的需求線路串聯起來）
l 使用者：直接使用者和間接使用者（可以理解為軟體的使用者和軟體的擁有者，就是專案中的需求部門和IT部門的相關負責人）

核心思路一：知曉業務模式
調研會議開始，首先由客戶方專案經理或者RPA專案實施經理向與會人員傳達本次會議目標。

以某財務機器人專案為例，專案經理在會議上首先向與會人員表述：本次會議主要目的是召集專案需求人員，為RPA專案的實施落地蒐集相關需求。專案目標主要是為了減少財務工作人員的工作量，收集財務人員的日常工作中有規律的重複性的工作，來作為後續機器人的工作內容。同時，對於不確定的需求進行進一步討論。專案的最終目標是要提高工作效率，減少重複性工作給業務人員造成的負荷。

當實施人員與使用者統一專案目標之後，就可以進行系統化的需求調研，針對大型需求，我們需要有自上而下，由淺到深的線性思維，切不可一開始就深入細節的操作點，讓大家直接陷入進去，就以某財務機器人專案為例：

雲擴的實施人員首先與業務部門溝通了關於驅動財務的業務背景前提，是財務部門每個月都需要在規定的時間內進行對賬處理，對賬處理的結果就是需要將他們的客戶提供的交易資料進行分類後，按照對應的操作模式錄入到財務系統中。

從上述案例中，可以總結出需求調研的第一個核心思路： 業務模式的知曉。知曉業務流程實際的驅動背景和流程執行後的結果。這樣我們就有了一個需求主幹：獲取對賬資料，按照對應邏輯，做系統操作。

核心思路二：資料往來的模式

第二個核心思路：資料往來的模式。瞭解在流程操作過程中，相關的資料來源。帶著已經瞭解的需求主幹，深入瞭解資料的往來的模式。

以某財務機器人專案為例，雲擴實施人員瞭解到：被提供的對賬資訊，來源於第三方商戶平臺（類似Amazon、WalMart等），需要從第三方商戶平臺中主動下載當天的對賬資訊，並且在後續的流程處理中，部分資料邏輯區分來源於業務部門提供的自制的合同清單。

從上述案例中，我們知曉在整個流程操作過程中，需要兩個資料來源表，一個是網站的自動獲取，另一個是使用者自身維護的excel對照表。

核心思路三：直接需求的理解、間接需求的引申

按照自上而下，由淺到深的調研模式，實施人員開始調研實際的系統操作需求，這裡我們提出兩個基本要素：直接需求的理解和間接需求的引申。

直接需求的理解固然是對流程操作細節的需求蒐集，而間接需求的引申則是對流程的完善性進行擴充，以入庫單需求為例：正常情況下，機器人可以根據使用者提供的excel表對WMS系統進行制單操作，但是需要考慮額外場景，輸入的物料資訊是否在物料庫中存在，如果不存在，則需先對物料資訊進行填補後，再進行入庫單的制單操作。這就是在對直接需求的理解後，繼續做至間接需求的引申操作。

間接需求的引申不僅如此，還要考慮到資料來源的驗真操作，如果資料來源存在出入，是否會引發其他操作，這些都需要在調研的過程中討論到。

核心思路四：結果導向

自動化流程的初衷並不是模擬人的操作去替代工作，而是儘可能地透過自動化工具加快客戶處理業務的速度，所以對於使用者而言，他們的訴求在於RPA的結果，而不在於RPA的過程，讓RPA用合規的方式及最短的時間完成使用者想要達到的效果，或許就是他最大的價值。

以上只是一些基本的調研方法，讀者如果想要真正瞭解使用者需求，光靠這些內容不足夠的。下期我們將會繼續講解關於需求調研的實施方法論，透過更多的案例場景向大家分享雲擴科技更多的實戰經驗與總結！