#1.はじめに
本記事は、UiPathアカデミーの各コースの受講記録を記載したものである。
###関連記事
#2.RPAができること
| 業務 | 説明 | 事例 |
|---|---|---|
| 入力 | 抽出した内容をフォームに入力 | 所定のフォーマットで申請される従業員の給与支払口座の変更を人事システムに入力・更新 |
| 転記 | データをもとに文章を作成 | 営業が顧客を訪問する際に各種データベースや、外部サイトから顧客情報を収集・転記し、レポートを作成 |
| 照合 | 内容に差異がないかの確認 | 請求金額と支払い予定額を照合し、担当者に差異の確認後、社内システムの支払予定額を更新 |
| モニタリング | 異常を検知 | 社内規定に基づき、従業員の経費申請を確認し、規定外の申請を報告、担当者に差し戻す |
| 送付 | 取得した情報を通知 | システムのログインIDの照会依頼を受領後、確認し依頼者に通知 |
| 集約・加工 | 情報を収集し、データに反映 | 競合商品の情報を特定のサイトから取得し、社内データベースを更新 |
#3.センター・オブ・エクセレンス(Center of Excellence)
CoEとは、RPA導入・運用に必要な専門性を持ち、組織横断的に機能する「RPA専門チーム」のこと。
| 役職 | 説明 |
|---|---|
| RPAスポンサー | 経営層や組織層が従事することが多く、RPA導入~保守に至るまでビジネス的スポンサーを行う責任を担う。 |
| RPAチャンピオン | RPAの導入~保守に至るまでの過程を組織全体で推進するために、トップダウンなアプローチで指示を出し、全体を管理しながらスポンサー・現場・IT部署などと定期的にコミュニケーションをとり、自動化を迅速かつ安全に推し進める責任を担う。 |
| プロジェクトマネージャー | RPAチームを作成・管理チームメンバーの稼働管理・プロジェクト計画立案・小規模プロジェクトを複数かけ持つことがあり、様々な質問に回答するための窓口としてメンバーの質問を集約し、戦略的なイニシアチブを取る。 |
| RPAソリューションアーキテクト | 現場・管理者(ビジネス)側の要求に対して、RPAの最適解を提案し、RPAソリューション・アーキテクトを定義する開発と、実装フェーズの両面で支援を行う適切な技術や機能を選出する。 |
| RPA開発者 | 主にUiPath Studioを活用し、ワークフローの設計・開発・テスト、またRPAソリューションの実装を支援する。 |
| RPAビジネスアナリスト | ビジネスユーザーと開発チームの橋渡し役。自動化におけるプロセスの資料化、及びRPA化対象業務の選定を業務担当者と共に、RPA化に適した業務プロセスを見極め、RPA化に必要な要件を定義し、業務プロセス定義書(PDD)や業務フローを作成する。 |
| RPAチェンジマネージャー | プロジェクトマネージャーが兼務することが多く、プロジェクトの成果物と連携し、RPA導入による要件変更、及び実装に向けて、各ステークホルダーとコミュニケーションをとり、要件変更に対し無理なく調節できているかを把握する。 |
| RPAスーパーバイザー | 主にUiPath Orchestratorを活用し、操作環境に一環としてロボット・プロセスの管理する。レポート機能・分析ツールを活用し、ロボットの運用性能とリソース割り当ての持続的な改良に取り組む。 |
| RPAサービスサポート | RPAに関するサポートの問い合わせ窓口を担う。問い合わせの内容の一時切り分けを行い、より技術的な問い合わせの対応をRPAデベロッパーへエスカレーションを行う。 |
| RPAインフラエンジニア | RPAプロジェクトにおけるソリューションアーキテクチャの決定にも関わり、サーバーの構築・トラブルシューティングにおけるインフラ支援担当適切なRPA運用のためのインフラ環境を整備する。 |
#4.RPAジャーニー
RPAジャーニーとは、RPA導入における「準備」「設計」「開発テスト」「運用」の過程やサイクルを示したもの。
##4-1.プロジェクト管理者レベルのRPAジャーニー
| ステップ | 内容 |
|---|---|
| RPA導入の準備 | 業務プロセスの棚卸、RPA対象プロセスアセスメント・選定、RPA対象プロセス優先順位の決定、本稼働前の計画・内容変更の管理 |
| ソリューション設計 | テスト用業務プロセス用意、業務プロセス定義書(PDD)作成、セキュリティ・インフラの確認、Robotのタイプ/数・サーバー構成などのソリューション設計、テスト環境の用意、詳細設計書(DSD)作成 |
| RPA開発 | 業務プロセスのRPA化、単体テストとバグ修正、テスト用データの用意、変更による影響の評価、UATテスト環境作成、詳細設計書(DSD)アップデート |
| ユーザー受け入れテスト | UATのコーディネート、UAT実施、バグ修正、本稼働前承認取得 |
| 本稼働 | 本番稼働準備(手順書作成・展開)、本稼働実施、本稼働監視、予想された結果と実績の比較、運用上の注意ポイントの明確化、書類化、展開 |
| 運用・管理・継続的改善 | ROI・パフォーマンス計測、有益な点・不具合レポート、変更の管理、ワークフロー修正 |
##4-2.ひとつの自動化案件におけるRPAジャーニー
| ステップ | 内容 |
|---|---|
| 業務管理 | 業務の選定基準を考え、RPA化できる業務・難しい業務を整理する。業務の流れや作業手順を決め、誰にでもわかるような形に可視化する。 |
| 要件定義 | 業務担当者により、RPA化対象の業務の内容を業務プロセス定義書として作成する。業務プロセス定義書は操作マニュアルに近いものになることもある。 |
| 開発テスト | 開発チームを作り、操作権限・開発標準などの開発ルールを決定後、開発を行いRPA化の目的を達成しているか、プロセスは安定した動作をしているかをテストする。 |
| 運用管理 | エラー発生時・業務の要件に変更が発生した場合、正しく運用できるように対処し、日々のロボットの稼働状況の確認を行う。 |
##4-3.RPA導入における注意事項
###①RPA製品選定の対する知識不足
ビジネスニーズを解決できるRPA製品を正しく選ぶことができないといった知識不足が起こりうる。
###②業務選定&整理における知識不足
複雑な業務プロセスのみ自動化すること自体が目的化するため、必要のない業務に対し自動化してしまうということもよくある。
自動化の難易度が低いものかを選び、業務整理によって無駄な作業を無くしてから自動化をするべきである。
###③概念実証(PoC)の失敗
PoC検証の目的や、PoC成功の判断基準、判断の決定者の不在により、PoCが失敗に終わることがある。
これらを確定させた上で実際の業務プロセスを使用し、選定したRPA製品がビジネスニーズを満たすかの評価を行うべきである。
##4-4.RPA化に適した業務の見つけ方
###①「RPA化ができること×RPA化対象を考える着眼点」を持つ
####I.RPA化ができること
「2.RPA化ができること」参照
####II.RPA化対象を考える着眼点
| 着眼点 | 着目の対象 |
|---|---|
| 人に着目 | 人が持つ単調・反復作業自体、派遣社員・外部委託している業務 |
| システムに着目 | ユーザの不満が高いシステム、導入からしばらく経過しているシステムに付帯する業務 |
| 組織に着目 | 部門をまたがる業務 |
###②まずは「業務」ではなく「作業手順」に着目する
e.g.業務：「営業事務」
→作業：「顧客情報確認(Webページなどで情報収集)」、「データを集約(PDFやExcelにまとめる)」
###③「繰り返される&ボリュームがある」作業を探す
####I.繰り返される作業
毎日・毎週頻繁に実行し、手作業で人的ミスを起こしやすい分量の多い作業。
また、毎日ではないが特定の時期に必ず行う作業。
####II.ボリュームがある作業
量が多く、手動で処理するには負荷が大きい作業
#5.RPA化前に行うステップ
| ステップ | 内容 | 説明 |
|---|---|---|
| ステップ１ | 業務の棚卸 | 業務の棚卸の行い、その業務の詳細まで明確に可視化し、第三者の目で客観的にレビューをする。業務フロー図を作る前に、まずは紙媒体でアナログに行う。 |
| ステップ２ | 開発必須要件の確認 | 扱う電子データ(Excel/Word/Eメール)や「Aの場合は、○○○を行う」のような作業のルールや例外処理を確認する。 |
| ステップ３ | 開発難易度の確認 | 開発の難易度を高める要因を確認する。(e.g.手順数・条件分岐・利用アプリケーションが多い、非デジタルデータ・不規則なデータの割合が多い、画面遷移の頻度が高い) |
| ステップ４ | 開発優先度の決定 | ステップ３(開発難易度の確認)で取り上げられた、難易度が高くなる要因と対象となる業務を照らし合わせ、点数化して難易度の低いステップから開発を始める。 |
| ステップ５ | 業務プロセス定義書(PDD)の作成 | RPA化する業務プロセスの一連の手順、業務プロセスの処理条件やルール、RPA化後のプロセスが部分的、または全体としてどのように機能するかを説明する、プロセスを自動化するたのに必要な資料(業務プロセス定義書)を作成する。 |
#6.UiPathプラットフォーム
| フロー | 製品名 | 製品概要 |
|---|---|---|
| 開発 | StudioX/Studio | Robotsによる、処理に必要な「ワークフロー」を開発する。StudioXはプログラミング言語を使わずに比較的シンプルな作業を、Studioはプログラミング言語を使用して複雑な作業を自動化する。 |
| 管理 | Orchestrator | ロボット・自動化プロセス(ワークフロー)を一元管理し、モニタリングする。 |
| 実行 | Robots | 自動化プロセスを実行する。種類は「Attended(ユーザを監視下に置いて、ユーザのタイミングで自動化した業務を実行する)」と「Unattended(ユーザーの監視を必要とせず、任意の数のプロセスをバックグラウンドや仮想環境にて、自動化した業務を実行する)」がある。 |
| 協働 | Assistant | 自動化済みプロセスの実行を容易にする。 |