前回のSolution Architect Trainingに続きBusiness Analyst Trainingにも挑戦したので、興味を持たれている方の受講のきっかけになるよう、事前にインプットしておくと理解が進みやすい知識をまとめました。
・コースが想定する受講者層
・各章で”だいたいこんな事を学ぶよ”的な概略
・登場する専門(?)英語とその意味
※私の解釈で書きますので、あくまで参考程度にご覧下さい・・・
コースが想定する受講者層
このコースでは最初のCourse descriptionに想定受講者が書いてあり、"RPAにおける業務分析(Business Analysis)の基礎を学びたいBusiness Analysts, Business Managers, Process Managers"とあります。
Process Managerは社内の業務プロセスを組織横断で評価し、KPIやスループットなど何かしらの指標を最大化するようプロセスの改善を提案・実行する人の事です。日本では聞きなれない職業ですが、欧米ではひっぱりだことSAPの人がこの前言ってました。
各章で”だいたいこんな事を学ぶよ”的な概略
特に2 & 3章のビデオの時間が長いので覚悟して下さい（寝オチ的な意味で）
1. RPAにおけるBusiness analystの役割
この章ではBusiness analystの役割と必要なスキルセットが語られます。
ざっくり言うと、BAは業務部門(Business owner)とIT部門(Technology team)の架け橋として業務部門の抱える課題を吸い上げ整理し、IT部門に伝える。またIT部門が提案するSolutionが課題にマッチしたものか評価する役割を持ちます。
必要なスキルセットはいくつかありますが、好奇心(curiosity)・コミュニケーションスキル・忍耐(patience)といった人間的なスキルが前面に出てくるのは、架け橋として複数のステークホルダーと付き合う役割上、その通りだと思います。
また後半では、RPAプロジェクトの6つのフェーズそれぞれでBAの果たす役割が語られます。
- Prepare (業務の棚卸し、対象の絞込みと分析)
- Design (対象プロセスの文書化、テストシナリオ用意)
- Build (RPA開発中に発生する追加・変更要件の管理)
- Test (テストの主導と本番化サインオフ)
- Stabilize (効果測定、期待値vs測定値の差異分析)
- Improvement (成果を出し続けるための継続的な変更管理)
SAの時とフェーズ分けが微妙に違いますね。
2. Prepareフェーズ - Opportunity assessment
※セリフと字幕が全然違う・・・英語でやられると混乱して頭に入らないのでやめてくれ～
RPA対象業務の優先順位を付ける上で、業務棚卸しでリストアップされた業務１つ１つについてRPAとの相性を評価します。評価手法として業務プロセスの複雑度(complexity level)をパーセントで表現するというユニークなやり方が提案されますが、その％の重み付けは↓の通り。
- Free text 15%
- Standard input 30%
- Number of Application 20%
- Number of the step 35%
1と2がわかりにくいので（私の想像込みで）解説すると、
"1. Free text"とは扱う情報が構造化データか非構造化データかという意味で、例えばメール本文のような非構造化データは取り出したい情報がどこにあるか特定しにくいため、複雑度が高いと言えます。
また"2. Standard input"とは入力元／出力先が定型フォーマットかどうか、例えば取引先ごとに受け取る請求書のレイアウトが違うとそれぞれ読み取り方を変える必要があるため複雑度が高くなります。
その他、複雑度に影響する要素として以下を挙げています。
- 手順や分岐が決まりきった(rule-based)プロセスか、そうでないか(judgement-based)
- 操作するアプリケーションの種類（メインフレームやSAPは複雑）
- 操作対象がVDI先か（画像認識でしか操作できないのは複雑）
ちなみに優先順位はプロセスの複雑度だけで付けるのではなく、業務効率化・コスト削減・品質向上といったビジネスへの貢献度を考慮するのはもちろんで、そこまで含めてのOpportunity assessmentです。
この記事を書いている2019年末ではRPAの普及が一段落し、複雑度が低く効果が刈り取りやすいQuick wins・Low hanging fruits案件が終わりを迎えつつあるため、複雑度の高い案件への対応としてUiPath含めRPA各社がAIとの連携を打ち出しているわけですね。
3. Designフェーズ - Process deep dive
DesignフェーズではRPA化の対象業務が決まった前提でプロセスのAS-ISを描くところから始め、RPA化したTO-BEプロセスを定義してRPA Developerに引き渡せるドキュメント(PDD, Process Definition Document)を用意する事をゴールとします。
AS-ISについては対象業務をよく知る人と一緒に、プロセスのフローだけでなく１件あたり／トータルの工数・頻度・制約・関係者など多面的に洗い出します。社内の業務プロセスを横断で管理する部署(Process SPOC)があれば、TO-BEに進む前にHi-Levelなドキュメントで検証してもらう事も有効です。
TO-BEプロセスの作成はSIPOC分析とかProcess mapping (Level 1~4)といったプロセスモデリングのフレームワークに沿って進めるのが良く、またプロセスのInput/Outputの種類や形式を定義する、作業ステップ１つ１つをスクリーンショット付きで手順書にまとめる、といった徹底的なドキュメンテーションを行いPDDとして仕上げます。
最終的にPDDを関係者とサインオフした後は、Solution Architectと一緒にSolution Designを進め、RPA Developerがオートメーション開発に着手します。
※ビデオ視聴を終えるとPDDのサンプルがダウンロードできます（All English...OMG...）
4. Testフェーズ
オートメーションのテスト(UAT)のステップと、スムーズにテストを回すために必要な準備が語られます。おおよそITシステムのUATと同じなので目新しい情報は無いものの、「人間が作業した結果とロボットが作業した結果が同じであるか」の確認はRPAならではですね。
5. Testフェーズ - Go-live Preparation
ユーザーマニュアル整備、利用者へのトレーニング、業務の切り替え方法の検討など、本番化(Go-live)前の準備の章です。ここも"まぁそうだよね"という内容が多いですが、「ユーザーマニュアルにはリトライ時の手順を書く」のがちょっとした環境の変化で止まりやすいRPAならではのポイントです。
6. Improvementフェーズ - Change management
オートメーションの本番稼動後も業務の変化に合わせて継続的にPDDやオートメーションの変更が発生するため、必須となる変更管理(Change management)の考え方やステップが説明されます。
ここで言う"Change"は"PDDの内容に変更が必要なもの"という事で、オートメーションの修正だけでなく前後のプロセスや実行頻度・タイミングの変更まで広く含んでいます。一方でバグ修正は含まれません（Management以前に、直すのが当たり前）
7. 全フェーズ通して - Traceablity Matrix
この章ではTraceablity Matrix Sheetという新たなツール（といってもExcelシートですが）が登場します。ビデオを視聴し終えるとSheetのサンプルがダウンロードできますが、中を開けると単なるプロセス毎の進捗管理表でした。
おかしいな・・・スライドだともうちょっと高尚な事が謳われてたはずなんだけど。自分で足せって事かな？
最終テスト 20問
複数選択方式の割合が多いです・・・キツい。なんとか正答率75%で通りましたが、選択肢の英語が「ちょっと何言ってるかわからない」ために間違えたのが多かったです。
例えば "The output of that manual out of scope activity might need to be used or not by the robot" とあるのですが、本当に何の事を言ってるのかわからない…（もちろん間違えた）
以上です。Non-technical Trainingだけどバッヂもらえました（ただし10ポイント）
登場する専門(?)英語とその意味
| 英語 | 意味 | 補足 |
|---|---|---|
| Inventory of the processes | 業務の棚卸し | Inventoryって"棚卸し"の意味もあるのね |
| Opportunity assessment | 対象業務を優先順位付けするために、プロセスの複雑度やビジネスへの貢献の面から評価する事 | |
| Quadrant derivation | 縦と横の軸で４つの領域に分類する事、PPM分析の絵をイメージするとわかりやすい | このコースではプロセスの複雑度(Complexity)と業務への貢献(Benefit)の軸で４分類 |
| FTE (Full-Time Equivalent) | フルタイム勤務の仕事に換算した場合、何人分に相当するか | |
| AHT (Average Handling Time) | １件あたりの平均処理時間 | |
| Low hanging fruit | 効果を刈り取りやすい案件 | 木の低いところに生ってる実ってことね |
| PDD (Process Definition Document) | RPA対象業務のプロセス記述書、およびロボットに実行させるステップをフロー形式で記述したもの | BAが作る |
| Extensive documentation | 膨大なドキュメント（Agile的な進め方ではあまり役に立たない） | このコースでは否定的な意味で登場 |
| Deliverables | 成果物 | |
| SME (Subject matter expert) | 対象領域の専門家 | ここではRPA化対象の業務に精通した人 |
| SPOC (Single Point of Contac) | 社内の業務プロセスを横断で見れて、プロセスの抜け漏れを検証できる専門？部署 | 一般用語としてはサービスデスクのような"単一窓口"を指すが、このコースでは不自然 |
| SIPOC | 業務プロセスを整理・分析するためのダイアグラム | 分析に切り口であるSupplier、Input、Process、Output、Customerの頭文字 |
| Four-level process map | プロセスのフロー記述の作法と粒度（L1~4まである） | 数字が大きいほど粒度が細かくなり、L4は全ての作業ステップを記述する |
| KSD (Key stroke document) | "どのキーを押した"レベルまで落とし込んだ、スクリーンショット付きのプロセス説明書 | |
| Pipeline Prioritization | Pipelineを通るようにフィルタをくぐらせながら対象を絞り込んでゆく事 | ↓にイメージ描いてみました |
|
今回はここまで。
Solution Architect Trainingと違い、自分の経験してきた領域と異なる内容だったため理解するのにかなり苦戦しました。（Solution Architectの倍近くかかったかも）
特に2~3章は長い上にプロセス分析の用語が頻出するので、そもそも言葉の意味がわからないのがツラい。
"Approval Matrix"って言葉がサラっと出てきて"承認マトリックスって何？？"となる。
ググれば「ああコレの事か」ってなるんだけど、その繰り返しが大変なのです。