この工程では現状と完全自動化に必要な要件を把握し、文書にまとめます。一度で完結することはありませんので、難しく考えず早く手を付けて進めることが大切です。まとめている間に疑問点が湧いてきますので、その都度、現場に確認して進めてください。

 

1.現状把握(全体)

現状のシステム概要を把握する

個別の完全自動化案件に深入りする前に、案件に関わるシステムの概要を把握します。

デスクトップ型RPAツールの知識がある方は、「現状の業務をまったく変えずに、そのままRPAツールに覚えさせればいいので、システム概要の把握は必要ない」と思っているかもしれません。

しかし実際の業務は、システム・エンジニアの視点からみると非合理的な方法でシステムを利用している場面が多く見られます。

例えば「別のシステムから、集計されたデータが取り出せるのに、明細データを手作業で集計している」「複数の人が同じデータをダウンロードしているので、システム負荷がかかって余計に処理が遅くなっている」などです。これらの業務をそのままRPAツールに覚えさせてはいけません。

正確かつ効率的に業務を自動化するためには、案件に関わるシステム概要を把握することが必要なのです。

 

システム概要の文書を作る意味

もう1つ、この段階で全体を把握し、文書を作成することには意味があります。それは、経営層に見せるためです。

完全自動化を行う時には経営層の支持が必要です。部署間の垣根を超えて行う自動化もありますので、利害関係の調整にひと肌脱いでもらう必要も出てくるでしょう。

その時に経営層がまったくシステム概要を把握していなかったら、あなたも予期しない方向に話を持っていかれてしまうかもしれません。

そもそも、あなたが何をやっているのか理解してもらえず、まったく評価してもらえないかもしれません。そうなると、あなたも周りもモチベーションが上がらず、完全自動化は頓挫することでしょう。

「システム部が昔作った難しいシステム概要図」は、忙しい経営層は見たくないものです。もっとシンプルで親切なシステム概要図を作り、経営層を味方に付けて、「応援してもらえる自動化」を目指しましょう。

 

課題を把握する

「経営層・マネージャ層から見た課題」と「実務者から見た課題」は異なります。DAFチームは双方の課題に加え、「完全自動化の観点から見た課題」を把握しましょう。これらを表1 のように文書にまとめておきましょう。

表1:現状把握(全社)の文書の雛形

 

初期診断

現状の大枠と完全自動化したい案件が見えてきたところで、いったんゼロベースで眺めてみることが大事です。

なぜなら、「すべての業務を完全自動化できる」わけではないからです。また、完全自動化できるとしても、「仕様がわかる人がいない案件」「人の判断や手作業が絡んでいる案件」「複数の部署の思惑が複雑に絡んでいる案件」などは調査や調整に多くの工数がかかってしまいます。

要件定義する中で「今の自分の力量では自動化できない」と判断したら、いったん保留するか、優先順位を落とすことも念頭に置いてください。

ただし、コンサルタントが行う初期診断とは違います。コンサルタントは診断から解決までを間違わずに提示することが仕事ですが、実務の現場で求められるのは行動と結果です。

行動することによってのみ得られる情報があるので、試行錯誤は避けられません。筆者も何回も失敗しました。本書をガイドラインとしながら、試行錯誤することであなたにあった完全自動化のガイドラインを見つけていってください。

 

2.現状把握(個別案件)

個別の完全自動化案件で押さえるべき項目

具体的に個別案件に入る際に押さえておくべき項目は以下のものです。
(1) 部署名
(2) 業務名
(3) 業務の目的
(4) 実行タイミング(日次、月次など)
(5) 現在の作業工数
(6) インプット(システムからのダウロード、データベースなど)
(7) 加工内容
(8) アウトプット(帳票、ファイル、システム入力など)
(9) 例外パターン
 これらを押さえたらドキュメント化しておきましょう。

現行資料を集める

インプット、アウトプットの現行資料を実務者から提出してもらいます。数ヶ月分をサンプルとしてもらうとよいでしょう。主に、CSVファイルやExcelファイル形式になります。

 

業務フローの図式化

正確に現状を把握するために、実務者にヒアリングし、業務フロー図を作成します。できる限り、実務者側に業務フロー図や業務手順書を作成してもらいます。

レアケースですが、業務手順書を持っている場合もあります。業務システムや完全自動化の概念とインフラの設計Excelを使った業務であれば、画面のハードコピーを手順どおりにとってもらいます。

この段階では改善案など入れずに、現状のままを把握することに注力しましょう。

業務フローは、一般的なフローチャートで書いてもよいのですが、ビジネスプロセスを記述しやすいBPMNというモデル記述言語をお勧めします。

BPMNは、Business Process Modeling Notation(ビジネスプロセス・モデリング表記法)の略で、業務手順をわかりやすく図示して可視化するための表記
ルールを定めたものです。

発注書を作成し、部長が承認をして、業者Aに発注書送付するまでの簡単な流れを示すと図1 のようになります。

 

発注プロセスフロー

図1:BPMNの例

3.個別案件の要件定義

個別案件の現状を把握した上で、完全自動化の要件をまとめます。

開発時や運用開始後に変更になる場合もたびたびありますが、際限なく変更を受け入れていてはゴールにたどり着けませんので、この段階で要件を文書でまとめておき、関係者の間で合意を形成しておくことが重要です。

 

成果物の定義

アウトプットを定義します。帳票の自動作成案件であれば、帳票イメージを定義します。これが完全自動化のゴールとなります。

 

粒度分析

成果物を作成するために、必要なデータの粒度を洗い出します。粒度とは数値データの集計単位のことです。時間軸なら日単位(粒度が細かい)、年単位(粒度が粗い)などがあります。

アウトプット作成のために必要な一番細かい粒度のデータを取得できなければいけません。

 

データソース分析

粒度分析したデータの要件を満たすデータソースを特定します。現状の実務者の使っているデータソースが正解とは限りませんので、「現状分析」で把握したシステム概要をもとにデータソースを探り当てましょう。

粒度とデータソースを表2 のようにまとめて漏れのないようにします。

粒度とデータソース分析表

表2:粒度とデータソース分析表

 

完全自動化後の業務フローの図式化

完全自動化した業務だけを見ると、マスタの修正や成果物の印刷などを除いて実務者の業務はほとんどなくなります。

完全自動化後の業務フローを描いておき、関係者の認識を合わせます。また、ここで作成した自動化フローがこの後のインフラ設計、自動化の設計・開発につながってきます。