RPA Implementation Methodology Fundamentals

L1關於這門課程

本課程概述了UiPath根據實踐經驗和從主要客戶那裡收集的反饋設計的實施方法。.  此外，它還將重點介紹一組最佳實踐，包括管理方法指南、機會評估方法和基礎設施設定建議。

議程、學習目標和前提條件

大家好，歡迎參加UiPath實施方法論培訓！

 本學院模組介紹由UiPath設計的實施方法基於從主要客戶那裡收集的實踐經驗和反饋。

這種方法可以適應不同的環境。

我們建議使用這些指導方針來加強控制超越您的RPA計劃，並確保您的RPA體驗取得成功。

我們即將回顧RPA之旅的不同階段，比如(1.)不同部門的入職以及在您的組織內啟用卓越中心。

以下章節包括(2.)專案管理方法指南，(3.)RPA機會評估方法和基礎架構設定建議。

我們還將介紹(4.)重複性任務，如流程設計、開發最佳實踐、測試以及指南如何(5.)維持自動化過程。

方法的某些部分只應用一次，而另一些則以迭代的方式使用在實施的每一波浪潮中。

本課程旨在指導專案經理和專案經理理解預期從RPA實施中獲得哪些輸出。

該課程對技術主管和解決方案架構師也很有幫助，使他們能夠為他們的團隊創造一個可管理且高效的環境。

各種專案團隊成員也可以從此模組中受益，因為它提供了一種手段來深入瞭解他們參與的RPA實施流程。

After following this course, the trainee should be able to fully understand the UiPath RPA Implementation Methodology, to identify the processes that are the best candidate for automation, and to differentiate the stages of the implementation process.

完成本課程後，學員應該能夠要完全理解UiPath RPA實施方法，為了識別最適合自動化的工藝，並區分實施過程的各個階段。

The trainees are enabled to drive an RPA Project according to the proposed automation best practices, and to raise RPA awareness within their organization.

受訓人員可以根據以下要求推動RPA專案建議的自動化最佳實踐，並提高其組織內的RPA意識。

在本模組之前，我們鼓勵觀眾參加並完成RPA感知會話，該會話也可用在UiPath學院的平臺上。

在學習實施方法論之前，我們假設發生了以下情況：組織內部已啟動RPA，機器人流程自動化的高階業務案例已構建並獲得批准，核心RPA團隊已建立幷包括專案發起人和專案經理。

我們還假設PoC已經成功執行，並且已經選擇了RPA技術(UiPath)。

L2入職和CoE支援（Onboarding & CoE Enablement ）

本課結束時，您將能夠：

討論UiPath客戶和合作夥伴共享的實施方法最佳實踐。

Video

大家好，歡迎參加UiPath實施方法論培訓！

在本模組中，我們將向您介紹本模組，我們將向您介紹UiPath實現方法，這是我們基於關於UiPath的實踐經驗和共享的最佳實踐來自我們的客戶和合作夥伴。

我們推薦使用這種通用的方法作為指南加強對RPA計劃的控制，並確保RPA行程成功。

RPA實施過程中有多個部門。

讓我們從關注入職階段推薦的最佳實踐開始，這些最佳實踐是確保這些部門之間順利而富有成效的協作的最佳實踐，同時確保他們的熟練程度。

在視訊的第二部分，我們將討論結構卓越中心的門戶或組織提供RPA專業知識。

好了，我們開始吧！

RPA通常由業務運營驅動。

但是，有幾個部門需要參與RPA計劃把它變成一段欣欣向榮的旅程。

RPA通常由業務運營驅動。

為了優化實施流程，我們建議入職在RPA的最早階段，儘快與所有相關各方進行協商。. 

第一方是負責基礎設施的IT部門， IT支援和資訊保安問題。

UiPath生態系統的部署需要基礎架構支援以及實體伺服器和虛擬伺服器的配置。

IT部門還為測試環境提供最新資料在自動化範圍內使用的應用程式。

團隊成員在入職階段需要獲得的所有與基礎設施相關的知識都可以在線上UiPath Studio、Robot和Orchestrator指南以及UiPath Academy基礎設施培訓中找到。

強烈建議至少有一名基礎設施團隊成員將接受RPA方面的培訓。

這意味著有必要安排RPA專家參加研討會。.

資訊保安審批可能是最被忽視的部分在RPA專案中，儘管它非常重要。

UiPath安全指南必須與安全團隊共享通過與安全專家的專門會議。

一個好的做法是列出所需的步驟以獲得RPA平臺的證書。

IT支援團隊在機器人支撐中起著至關重要的作用，在第一個過程的開發完成之後。

因此，從一開始就為團隊提供培訓，它的成員有足夠的時間完成他們的培訓並建立RPA支援的內部能力。

這樣，他們還可以簽署指導其工作的所有程式，例如將自動化專案轉移到生產、監控它們、管理更改請求和上報問題。

我們建議IT支援團隊分配一個專門的RPA團隊完成UiPath提供的學院培訓。

業務入職是該流程的另一個重要部分。

RPA技術仍然是新技術，所以不是每個人都獲得了對它的好處和侷限性還沒有完全瞭解。

在進行機會評估之前，需要向業務團隊介紹RPA帶來的變化，這是RPA旅程中的關鍵步驟之一。

公司級別的機會評估方法可獲得最佳結果。

為了讓業務團隊轉變他們的工作方式，為了讓業務團隊轉變他們的工作方式，  儘早入職至關重要。

如您所見，讓IT和業務團隊上崗越快越重要，確保公司內部的RPA採用順利進行。

現在讓我們來看另一個關鍵元素成功實施RPA-卓越中心(COE)。

讓我們來分析一下RPA卓越中心的結構，每個角色的職責是什麼？以及履行這些角色需要哪些技能。

典型的RPA計劃結構包含以下角色：一名專案經理，負責整個RPA運營。

專案經理的技術對應人員是專案技術主管，負責端到端技術解決方案，包括安全和基礎設施。

基礎設施工程師負責確保環境和機器人已正確部署並且每個機器人上都安裝了必要的前提條件。

取決於可用開發人員的數量，他們可以分成一名業務分析師的不同團隊，一組開發人員由一名解決方案架構師領導。

根據每家公司的需要，組織模式可能會有所不同。集中式….  混血式……聯合起來，每個人都有一份利弊清單。

在大規模考慮企業RPA部署專案時，到目前為止，推薦的COE模型是集中式的。

RPA卓越中心的目標是建立，涵蓋所有必要角色的完整專案團隊。

機器人操作團隊由多個角色組成。

需要填寫的初始角色之一是RPA發起人，這將引發自動化的想法並支援自動化的努力。

還需要RPA計劃/專案經理確保實施工作的順利進行。

專案經理通常是團隊的第一批成員之一。並負責監督該專案。

技術開發角色包括RPA開發人員和RPA解決方案架構師。

他們將負責構建技術解決方案。

基礎設施工程師將確保順利部署不僅適用於核心RPA平臺，也適用於核心RPA平臺，也可用於自動化範圍內的其他應用。

職能業務分析員負責確定記錄機會並充當橋梁

需要更改管理員來驗證所有更改請求。這將出現在整個專案中。

此角色也可以由其他團隊成員扮演，例如專案經理。

最後，RPA專案需要強大的支援團隊以確保自動化投產的平穩生命週期。

上述所有角色的專用培訓均可用。在UiPath學院的平臺上。

讓我們從RPA開發人員開始吧！

在開始開發自動化工作流之前，RPA開發人員將與業務分析師合作要記錄流程並捕獲業務需求，考慮到自動化標準。

有兩個因素可以提高這一步驟的效率。第一個是一般的理解將實現自動化的業務流程。

第二個是向業務團隊解釋技術方面的能力。

良好的溝通至關重要。

作為RPA專案部署團隊和RPA運營團隊的成員，RPA開發人員建立和測試自動化工作流以確保其質量、啟用異常處理並在整個RPA解決方案實施過程中提供支援。

當RPA開發人員構建自動化時，他們需要定期更新進度狀態並報告，如果初始工作流設計發生任何更改。

開發完成後，RPA開發人員將移動工作流至UAT，並作為可能發生的任何問題的上報地點。

一個重要的最佳實踐是運行同行評審，同時解決開發、UAT和黃金交易中的問題。

黃金交易是指機器人之後的第一週，是投產的關鍵時期，也是實現自動化的關鍵時期。

在測試和保修期內，RPA開發人員在測試和保修期內為第一級支援團隊提供幫助。

。

RPA解決方案架構師轉換捕獲的需求由功能分析人員建立體系結構和設計構件。.

在RPA中，解決方案架構師不僅負責不僅領導整體技術解決方案的開發工作，而且還領導開發工作並保證交付成果的質量。

儘管解決方案架構師很少自己編寫程式碼，他領導團隊，經常進行程式碼評審。

。

RPA業務分析師是RPA部署專案團隊的成員，負責收集業務需求以及建立用於自動化的過程定義，在對優化區域進行評估之後。

業務分析師通常與客戶團隊一起工作在詳細的原樣和將要繪製的過程圖上..。在需要時讓IT和RPA團隊參與，為了進一步識別和量化RPA商機.並準備文件以移交給RPA開發團隊。

參與了從交易形成階段到過渡的過程，BA能夠跳出框框思考並提出流程和工具集改進建議。

業務分析師在詳細說明流程文件方面起著重要作用，關愛需求討論與客戶中小企業一起全程實施。

。

RPA基礎架構工程師是兩個RPA部署專案團隊的成員(或過渡)和未來的RPA運營團隊.，負責端到端的基礎設施設定，考慮到伺服器、資料庫、檔案共享機器人機器和應用程式安裝。

RPA基礎架構工程師必須確保RPA專案有強大的執行基礎。

如前所述，UiPath Academy平台上提供了針對我們剛剛描述的角色的專門培訓。 

例如，RPA開發人員課程包括三個級別的培訓：

級別1-基礎、級別2-Orchestrator和級別3-高階. 緊隨其後的是高階開發人員認證考試。

雖然UiPath很好用，不需要深厚的技術知識，我們認為應該是高規模的自動化和複雜的流程體系結構擁有技術技能有助於更快地實現自動化和擴充套件。

我們建議參加UiPath Academy的所有培訓並進行練習在開始自動化生產流程之前。

這將使你對大局有全面的瞭解。以及您可以通過RPA方式實現的功能。

啟用訓練有素的RPA卓越中心是基礎為成功的RPA之旅乾杯。

L3製備（Preparation ）

本課結束時，您將能夠：

瞭解UiPath生態系統的元件。

Video

大家好，歡迎回到實施方法論培訓、準備階段。

As a first Preparation step we are going to discuss about infrastructure enablement, so let’s start by defining the components of the UiPath ecosystem.

作為準備的第一步，我們將討論有關基礎架構支持的問題，因此，讓我們從定義UiPath生態系統的組件開始。

UiPath Studio是開發人員用來建立自動化指令碼的工具。

UiPath Orchestrator是支援以下功能的單介面平臺控制和監控多個機器人。

UiPath Robot是執行以下操作的Windows服務儲存的用於自動執行任務的指令。

對自動化指令碼進行編碼需要UiPath Studio使用拖放介面。

Studio是可以部署在桌面上的桌面應用程式或執行Windows的膝上型電腦，或在虛擬機器(VDI)上，開發人員是可以遠端使用的。

在開發人員的膝上型電腦上部署UiPath Studio通常是效能更好的解決方案。

儘管如此，由於安全限制，一些公司可能更喜歡使用虛擬化替代方案。

例如，在某些情況下，開發人員是顧問或應用程式僅限於某些環境-因此不可能直接從本地計算機擁有完全訪問許可權。

當發生這種情況時，虛擬安全環境(如Citrix例項將為開發人員提供正確型別的訪問業務流程自動化所需的應用。

UiPath Orchestrator部署在Windows伺服器上，並使用IIS執行。

它部署了一個Web應用程式來監視和控制機器人。

Orchestrator提供多種功能，例如機器人健康報告，日誌檢視、流程執行和排程以及佇列和資產。

可以使用使用者名稱和密碼登入Orchestrator或通過Active Directory整合。

伺服器具有儲存使用的憑據的能力由機器人在加密的資料庫中，並且只允許訪問在業務案例需要時提供給他們。

現在您可能已經知道了，有兩種型別UiPath機器人：有人值守和無人值守。

有人值守的機器人在由人類使用者操作的計算機上執行，共享相同的工作空間，並由他們觸發。

它們適用於輸入以下內容的業務場景需要來自人類使用者，或者當無法應用預定模式時。

有人值守的機器人的一個很好的例子就是自動連線到銀行網站，並下載財務報表以供稍後處理。

由於登入銀行門戶通常需要物理令牌，在本地計算機上輸入令牌碼很容易但是需要人類使用者來啟動該過程。

使用者完全控制自動化開始時間並且一旦令牌準備好就可以觸發它。

雖然人工觸發有人值守的機器人，它們與Orchestrator通訊，以便將日誌儲存在一箇中央儲存庫中並且用於自動包版本管理。

無人值守機器人通常在執行Windows作業系統的虛擬機器(VDI)上執行。

它們還可以在高密度伺服器上執行。

通常，它們執行的任務是重複性的，不需要人工輸入。

這類任務的一個例子是發票處理……

要部署多個機器人，我們可以使用一臺伺服器，執行Windows Server作業系統。

There is no limit on the number of robots that can run on one server; the only limitation is the number of available hardware resources on the server.

一臺伺服器上可以執行的機器人數量沒有限制；唯一的限制是伺服器上可用硬體資源的數量。

Each robot instance will run in a separate session using a different set of Windows credentials.

每個機器人實例將使用一組不同的Windows憑據在單獨的會話中運行。

The unattended robots will be controlled from the Orchestrator web interface.

無人值守機器人將通過Orchestrator Web介面進行控制。

It’s important to note that the installation package for the attended and unattended robots is the same.

請務必注意，有人值守和無人值守的機器人的安裝程序包是相同的。

Only when applying the license for an unattended robot, the additional features of controlling the robot from Orchestrator will be enabled.

僅當將許可證應用於無人值守的機器人時，才會啟用從Orchestrator控制機器人的其他功能。

讓我們將基礎設施支援拆分為三部分：伺服器基礎架構、開發人員基礎架構和機器人基礎設施。

伺服器基礎架構包含Orchestrator以及預設的報表平臺ElasticStack。

以下是用於生產環境的典型基礎設施。

為了實現高可用性我們將使用一個負載平衡器和兩個Orchestrator節點。

配置將始終處於主動-主動狀態。

開箱即用不支援主動-被動.

流量將在兩個節點之間重定向

使用輪詢演算法。

可以根據需要新增多個節點.

伺服器正在使用的持久資訊將儲存在Microsoft SQL資料庫中。

為了實現冗餘，資料庫將使用提供的本機機制按SQL Server，如AlwaysOn可用性組。

要實現完全冗餘，Orchestrator伺服器需要訪問到一個公共檔案共享，該檔案共享將儲存機器人將要執行的包。

為了獲得更好的效能，建議將軟體包儲存在本地並將資料夾與分散式檔案系統(DFS)同步。

涵蓋了平臺的報告部分通過ElasticSearch NoSQL資料庫和Kibana web介面進行報告。

ElasticSearch叢集使用最少3個節點。

我們已包含2臺連結的Kibana Web伺服器通過負載均衡器實現冗餘。

由於報告部分並不重要，一些客戶可能更喜歡僅將一個節點與Kibana配合使用；他們可以在一臺伺服器上部署ElasticSearch無冗餘，並定期備份ElasticSearch資料庫。

在圖中，推薦的作業系統和硬體規格因為伺服器已經包括在內。

有關更詳細的基礎架構資訊和災難恢復選項，請參閱請參閱學院網站上的基礎設施培訓。

一旦定義了生產架構，我們需要克隆測試環境的配置。

這通常是生產的一對一克隆。

開發環境可以只包含一個伺服器(無冗餘)，將Orchestrator和SQL資料庫安裝在一臺計算機上。

此外，還可以為Kibana和ElasticSearch新增另一臺計算機用於發展，但這不是強制性的。

首先配置開發環境，緊隨其後的是UAT和生產環境。

對於團隊來說，對元件有一個清晰的理解是至關重要的以及如何訪問它們，這就是為什麼我們推薦使用共享Excel模板Infrastructure Components。

此模板包含每個環境的選項卡(開發、測試和生產)涵蓋所有元件。

它還包含將負責安裝的基礎設施工程師的核對錶。

核對表旨在確保涵蓋所有步驟並且資訊被整合在一個地方。

這些詳細資訊需要可用並安全儲存在整個RPA過程中，為了幫助簡化任何故障排除，升級或遷移伺服器。

在設定機器人機器時，請考慮混合使用有人值守的和無人值守機器人，並設計易於擴充套件的解決方案為了增加機器人的數量。

一種好的方法是還定義至少兩個不同的無人值守機器人的硬體配置，具有不同的RAM和處理器引數。

對於使用更多記憶體的自動化，建議使用此選項或處理器密集型應用程式，因為它們需要在更強大的機器上執行。

例如，你可以讓執行自動化的機器人使用功能較弱的機器只使用有限數量的應用程式-例如網站和Excel-以及另一套功能更強大的程序機器需要通過OCR引擎進行影象處理，密集的檔案編輯或計算。

規劃可擴充套件的解決方案非常重要，因為沒有確切的方法來估計所需的機器人數量從專案開始，不分析每個過程在自動化範圍內並定義解決方案。

開發人員計算機將在物理計算機之間進行選擇或基於訪問便利性的虛擬化環境到自動化範圍內的應用。

建議將功能強大的機器分配給開發者因為用於建立自動化的技術有時會消耗計算最佳選擇器的強大處理能力以及其他記憶體密集型任務。

這意味著開發人員計算機通常是比機器人更強大。

部署有人值守、無人值守的機器人UiPath Studio也是以同樣的方式完成的。

安裝工具包包含所有元件；它是許可證這將啟用所需的功能。

需要注意的是，Developer Studio許可證將新增預設情況下，是開發人員可以使用的無人值守本地機器人。

部署和許可證啟用可以手動或自動完成，使用Microsoft SCCM等靜默安裝和部署工具。

安全是公司的重要話題，RPA也不例外。

IT安全部門負責稽核RPA解決方案以保證其符合公司的安全標準。

一些常見的安全問題是相關的到資料加密、機器人與伺服器之間的通訊保護，憑證傳輸、不同埠網路協議和認證方法等。

雖然在RFX階段解決了一些問題，建議在伺服器上啟動安全審計。

一旦配置了UAT環境。一些最常見的安全問題可以通過以下幻燈片回答。

有一些特定的設定方面需要參與來自IT安全部門的聯合決策流程。

這些方面將在以下幻燈片中介紹並參考機器人的認證機制，在Orchestrator中進行使用者身份驗證，並安全地儲存憑據。

機器人需要在它們操作的機器上進行專用的Windows會話。

他們用於在該Windows會話中進行身份驗證的憑據並啟動工作流，將儲存在Orchestrator中。

值得一提的是，這些機器人不需要管理員許可權即可執行。

根據自動化方案的不同，您可以選擇使用通用帳戶..機器人的多個技術帳戶或使用者帳戶。

全面分析與每個選項相關的優勢會給你指明正確的方向。

現在……大多數情況下，機器人需要憑據為了訪問應用程式這是自動化業務流程的一部分。

這些憑據可以本地儲存在Windows憑據儲存中，也可以在Orchestrator資料庫中對它們進行加密。

每個機器人都可以使用其自己的證書集，並且由於機器人操作與人類代理一樣，它也可以以同樣的方式使用單點登入。

除了上述兩種方法外，還可以選擇使用第三方解決方案儲存憑證，例如CyberArk。

機器人管理模組中的使用者認證在Orchestrator Server上，可以使用本地帳戶(通過安全儲存的使用者名稱和密碼組合在Orchestrator資料庫中)，或者可以這樣做使用Active Directory整合。

關聯的角色可以根據粒度許可權進行完全自定義。

在RPA設定中應考慮的重要決策是使用開發協作工具。

這一點很重要，不僅因為它允許多個人同時處理同一專案，但因為它還提供了程式碼庫和程式碼版本化能力，同時使程式碼審查活動變得容易得多。

UiPath Studio具有與TFS和SVN解決方案的本地整合。

也可以使用GitHub，但是它需要手動同步專案。

Orchestrator環境設定是另一個重要的因素專案團隊的決策。

環境是機器人的邏輯分組。

通常，機器人也可以分組在相同的環境中基於它們執行的程序，所涉及的應用程式或兩者的組合。

為一個程序設定專用環境使管理變得更容易，而且在某些情況下還降低了靈活性和機器人利用率。

當按應用程式進行分組時，機器人利用率會增加，但是，管理過程可能會變得更加複雜。

為了達到最佳效果，我們建議結合使用這兩種策略。

關於機器人、程序、環境、資產和佇列極其重要。

需要在整個團隊中同意和遵循相同的開發標準，促進程式碼理解、審查和維護。

例如，程序的命名約定可以是：Region_Process_Subprocess。

自動機的命名約定可以是ServerName_WindowsIdentity。

下一張幻燈片介紹一些最常見的方法

第一種方法是UiPath推薦的本地檔案儲存因為它是這裡提到的4箇中最容易實現的。

此方法涉及將可重用元件儲存在檔案共享上並將它們與UiPath Studio中的庫同步。

缺點是，此方法不提供任何版本管理機制因此，如果可重用元件發生變化，所有軟體包都必須手動更新和重新發布。

第二種解決方案也很容易實現，但是，存在與網路延遲或中斷相關的風險這將阻止機器人奔跑。

第三種解決方案將在成熟的開發團隊中提供最好的結果，只要他們能夠遵循元件版本控制的所有步驟。

不推薦使用第四種方法，但是，據觀察，對於已經擁有非常有經驗的開發人員和首選的自定義打包方法的客戶來說，它可以產生很好的效果。

為了跟蹤可重用元件，我們建議使用文件章節中提供的“可重用元件”模板。

請記住，可重用元件的所有者解決方案架構師是否因此要了解更多資訊，請確保您可以檢視解決方案架構師培訓。

本課程中也提供了“RPA準備”文件，將為專案決策提供正反兩方面的指導，命名約定和編碼最佳實踐。

我們來看看專案管理的方法論，具有RPA特有的味道。

旨在推動RPA專案，該方法將瀑布方法與敏捷元素相結合，例如團隊成員之間的日常站立會議。

RPA專案中的典型挑戰包括實施時間較短時間框架以及在不同階段可能出現的各種問題。

在傳統的軟體開發專案中，團隊有幾周的時間準備訪問UAT環境或重新整理測試資料。

在機器人過程自動化中，由於實施時間較短，這類問題需要在幾天內解決。

在預先確定了專案範圍的情況下，比如瀑布專案，開發商之間的日常會議，需要專案團隊和商業中小企業為了順利交付RPA專案。

明確的角色和責任至關重要啟動RPA專案時-除了經驗豐富的RPA開發人員外，一個成功的專案需要RPA專案管理技能，解決方案架構專業知識和業務分析知識。

建議建立專案需求圖表在倡議的早期階段。

專案組負責確保所有必要的角色都具有適當的資格，得到專案發起人的大力支援，並確保專案指導委員會、變更批准委員會和變更管理流程都得到了明確定義。

我們來看看典型的RPA專案團隊角色：有技術解決方案架構師、RPA開發人員、業務分析師、流程所有者和專案經理。

在此方案中，每個角色都通過不同的顏色進行描繪。

任務矩形中的職位代表他們的職責對於該特定任務：所有者、參與者或上報地點。

我們將要研究的另外兩個方面是先決條件以及完成每項任務的可交付成果。

在我們開始審查專案階段之前，重要的是要記住所描述的專案管理方法論是指在過程級別上應用，即在自動化工作流程的實現，從而實現自動化過程。

該方法不適用於整個管道，其通常首先經歷機會識別階段，其次是機會評價。

好的，如你所見，一共有6個階段，每個開發的工作流程都要經過以下幾個階段：分析、設計、開發、系統整合測試、使用者驗收測試和保修。

讓我們把它們一個一個地拿出來。

分析階段側重於業務流程選擇，通常在初始管道評估和流程優先順序確定之後進行。

業務分析師是所有者，負責選擇最適合自動化的流程，並建立流程設計文件(PDD)，在該文件中捕獲流程需求。

該階段涉及的其他參與者是主題專家，解決方案架構師和專案經理。

業務分析員將與SME一起組織研討會，以便詳細審查流程並收集PDD草案的細節。

草案准備好後，業務分析師將需求移交給技術解決方案架構師，從那時起，技術解決方案架構師將成為自動化範圍的所有者。

通常，業務分析師和流程SME執行流程與解決方案架構師一起演練，解釋“原樣”過程，並討論“將來”的情景。

建議一兩個開發人員也參加這些研討會就像在專案早期熟悉流程一樣在開發開始時將節省更多的時間。

一旦所有利益相關者簽署了PDD，分析階段被認為已完成.

接下來是設計階段。

根據從業務分析師收到的PDD，解決方案架構師將建立技術設計，將專案拆分成不同的功能以及定義審計度量。

需要注意的是，“目標”流程和技術設計是兩個不同的東西，因為第一個包含元素業務分析師通常難以預見或評估的問題。

本練習的輸出是初稿解決方案設計文件(SDD)。
作為下一步，解決方案架構師將為專案的每個不同塊的“in”和“out”引數。

基本上，一旦將專案拆分成多個功能(或通常稱為塊)，解決方案架構師需要以確保這些模組相互通訊。

這通常包含在解決方案設計文件的第二稿中。

定義了塊和引數後，解決方案架構師將繼續將任務分配給開發團隊成員。

同時，業務分析師將開始準備測試用例和測試資料，與流程SME協作。

在開發開始之前完成這項任務是極其重要的。

RPA開發人員需要能夠訪問和導航應用程式這將被用作自動化程序的一部分；這就是為什麼要準備測試帳戶和測試資料的原因在開發啟動之前是至關重要的。

如果測試用例文件沒有及時準備好，那麼會有很大的延遲會影響專案時間表。

開發階段涉及兩個角色：RPA開發人員和解決方案架構師。

出於本次培訓的目的，我們展示了典型的活動只能在兩個執行緒上使用，但在實際專案中可以增加這個數量。

作為第一個活動，每個開發人員都要處理分配的任務由解決方案架構師提供，並將繼續執行單元測試，最短的，基於小型開發的功能。

這裡有兩個交付件：包含開發的程式碼的包和更新的解決方案設計文件。

單元測試完成後，同行評審將開始：每個開發人員將檢查由另一個團隊成員開發的程式碼，檢視異常、程式碼可靠性和開發最佳實踐。

接下來，作為額外的質量檢查，解決方案架構師還將執行程式碼審查，檢視每個功能，確保使用正確的In和Out引數，檢查變數範圍並確保最佳實踐整個團隊都緊隨其後。

解決方案架構師還將檢查可靠性並實現正確的日誌欄位。

此時，端到端程式碼應該已經準備好了因此會進行團隊專案程式碼審查。

範圍是確保所有包都已建立並且已經為系統整合測試(SIT)做好了一切準備。

開發是在Orchestrator例項中完成的，在開發環境中。

在系統整合測試階段，我們將切換環境。

在系統整合測試階段，端到端工作流已經過測試，並且所有元件都已整合。

作為這一階段的先決條件，我們將擁有測試資料和測試用例，而輸出將是解決方案設計文件的最終版本。

開發人員負責端到端的測試並修復已識別的錯誤。

一旦完成，解決方案架構師將召集UAT準備會議，與開發人員一起，將為UAT做出非正式的“去”或“不去”的決定。

系統整合測試與使用者驗收測試兩者都發生在UAT環境中。

接下來是UAT階段，由主題專家領導，在這一點上，他們應該對自動化過程感到滿意。

端到端測試的交付內容是否識別了UAT結果和錯誤。

這些錯誤應該由開發人員定期檢查和修復-在程式碼或整體自動化被更改的情況下在錯誤修復過程中，這應該記錄在SDD中。

端到端測試通常需要2到4周的時間，並且通常以正式的簽收會議結束在投產之前。

會議由主題專家領導，在業務分析師的參與下，解決方案架構師和專案經理。

需要注意的是，開發人員完成了他們的工作在開發和UAT環境中，但通常在生產中不起作用。

這意味著在這個階段，還需要準備描述程式的檔案用於將自動化流程轉移到生產中(也稱為MTP文件)。

這是支援團隊需要的，因為他們正在在生產環境中進行配置。

最後一個階段是保修。

UAT完成後，現在是支援團隊移動流程的時候了在生產中並完成配置，為了開始保修期，通常持續2到3周。

專案團隊仍在參與並負責修復錯誤。

SME是所有者，而解決方案架構師將採取行動作為整個保修階段的升級點。

一旦這個過程穩定下來，可以重新分配專案團隊以開始新的任務。

現在就到這裡吧。

檢視下一段視訊，瞭解有關機會評估的資訊。