業務の構成要素をドキュメント化する【RPAシナリオ設計】

RPA設計

RPAシナリオを作り始める最初の一歩がわからない…。

という人に向けて、「業務の構成要素のドキュメント化」について解説します。

まず、この記事にある要素を把握してドキュメント化することから始めましょう。

業務構造を理解していないとドキュメント化もできないので、まだ読んでいない方は、次の記事を読んでから本記事をお読みください。

それではどうぞ!

この記事を書いた人
この記事を書いた人
こさい
こさい

(株)完全自動化研究所代表のこさいです。

1) エンジニア歴25年超。開発から業務改善まで幅広く経験してきました
2) 複数の企業においてRPAのコンサルティングを行っています
3) RPA関連の書籍を5冊出版しています

  1. オープンソースで作る!RPAシステム開発入門
  2. 実務者のための失敗しないRPAシナリオ設計入門
  3. UiPath業務自動化最強レシピ
  4. WinActor業務自動化最強レシピ
  5. Power Automate for desktop業務自動化最強レシピ

現在はChatGPTとPower Automate for desktopの書籍を執筆中!

業務の構成要素をドキュメント化する【RPAシナリオ設計】

こさい
こさい

次の手順で業務の構成要素を把握してドキュメント化しましょう

業務の基本構造をつかむ

最初にやることは、業務の構成要素を明確にすることです。表1の[内容]を埋めます。

はじめのうちは、これだけでも悩んでしまうでしょう。

まずはあまり深く悩まず書いてしまうことが大事です。間違っている場合、設計しているうちに「何か違うな」と思うときが来ます。そのときに修正しても遅くありません。

ただし、アウトプットだけはこの時点で明確にしましょう。印刷物、CSVデータなどの
データ、もしくはシステムへの入力など明確なアウトプットがあるはずです。

項目内容
業務名業務名
インプットシステム名やファイル名、データ名
処理処理内容
アウトプットシステム名やファイル名、データ名

【表1】業務の概要

めーたん
めーたん

実現したい自動化のイメージがわかってきたわ

業務の目的をつかむ

追加情報として記述しておく項目は表2です。

項目内容
目的業務の目的
担当者この業務を担当する人、部署、役職
発生条件発生タイミング(毎営業日の9時、毎月1日など)

【表2】業務の概要(追加情報)

以下の記事で、「業務には目的がある」と述べました。

めーたん
めーたん

なんで自動化に目的が必要なの?

目的を書いておく意味は次の通りです。

  • 目的をはっきりさせることで開発方針をぶらさない
  • 費用対効果を説明するときの根拠となる
  • 経営層やマネージャー層との会話のベースとなる

例えば、売上集計表を作成する業務の目的は「売上集計表を作成すること」ではありません。「営業担当者毎の売上実績を可視化し、売上の向上につなげること」とすることで目的がはっきりします。

会話のレベルを合わせよう
業務の目的を明らかにすることが「経営層やマネージャー層との会話のベースとなる」ということについて、詳しく解説します。
通常、経営層と実務者層では会話のレベルが合っていません。
自動化案件の会議で経営層からよく出てくる質問は「なんのために、その業務を自動化するの?」です。実務者の答えはだいたいこうです。
「帳票作成工数を削減します。」

しかし、経営層が欲しい答えは違います。
「売上向上につなげます。そのために、週一回だった売上実績の把握を、自動化により毎日朝一番に把握できるようにし、PDCAを早く回せるようにします。」
「在庫削減のためです。週次の発注書作成に2日かかり、水曜日発注になっていましたが、自動化により月曜日の午前中に行えるよう改善し、余分な在庫を削減します。」

売上・在庫・コストなどのレベルの話なら、経営者もアドバイスできます。
「じゃあ、あの部署も交えると、もっと改善できるよ。」
「今、その部署の部長も会議に参加させよう。」
ということもできるでしょう。

同様に費用対効果の判断も変わってきます。「30 分かかる帳票作成が、2分で作成できます!」ならば、「ふーん、なるほど。」で終わりです。しかし、売上向上やコスト低減につながる自動化なら、経営的判断も変わってきます。
「もっと投資して、RPAを加速させた方がいいかもしれない。」
「RPA部署を立ち上げて、全社的に取り組んだ方がいいかもしれない。」
と考えるかもしれません。
RPAについて報告する人が目線を上げて、RPAの本当の効果を経営層に伝えることが、RPAの可能性を無限に広げます。ただの時間短縮のツールで終わらせないでください。

作成者も重要

加えて、作成者、作成日、更新日も書いておきましょう(表3)。

この設計書を見直すのが数か月後、数年後、ということもあり得ます。そのとき、作成者や作成日というのは大切なキーワードになります。

「いつ誰が作ったかわからないので、誰に聞けばいいのかわからない」という謎シナリオの調査も必要なくなります。

項目内容
作成日作成日
更新日更新日
作成者部署/名前

【表3】作成者、作成日の情報

フォーマットに落とす

こさい
こさい

すべて把握できたら、表4のフォーマットにまとめておこう!

項目内容
業務名業務名
目的業務の目的
担当者

この業務を担当する人、部署、役職

インプットシステム名やファイル名、データ名
処理処理内容
アウトプットシステム名やファイル名、データ名
発生条件発生タイミング(毎営業日の9時、毎月1日など)
項目内容
作成日作成日
更新日更新日
作成者部署/名前

【表4】業務シナリオのヘッダーフォーマット

めーたん
めーたん

できたわ!