完全自動化の要件定義の具体例を「食雑貨小売チェーンの営業日報」を使って解説します。
1 現状把握(全体)
現状の全社システム構成を把握する
個別の自動化案件に入る前に、会社全体のシステム構成を把握します。
RPA(ロボティック・プロセス・オートメーション)を検討されたならば、「現状の業務をまったく変えずに、そのままロボットにさせればいい」と思っている方も多いかもしれません。これならば、全体のシステム構成を把握する必要はありませんね。
しかし、現場担当者だけにヒアリングすると「伝統的にやっていたデータ取得方法」しか分かりません。システム的に見て、非常に非合理的な方法でデータを扱っている場合が多く、後からの修正も難しくなります。
実際には、正確かつ効率的にデータを操作する方法が他にあるケースが多々ありますので、全体を把握する事が必要です。
課題を把握する
「経営層・マネージャ層から見た課題」と「現場担当者から見た課題」は異なります。DAFチームは双方の課題に加え、「自動化の観点から見た課題」を把握しましょう。
【現場担当者から見た課題】
- 複数のシステムが混在し、どこに正しいデータがあるのか分からない
- BIシステムが遅く、業務に支障が出る
- 簡単なデータ作成にも手入力、手作業が多く、工数がかかる
【経営層からみた課題】
- 正確なデータを把握できるタイミングが遅い
- 属人化業務が多い
【DAFチームから見た課題】
- 現場担当者はシステムに詳しくない
- 情報システム部にも一貫したシステム設計はないようだ
- 現状の業務のデータ入手方法は正しくないようだ
- BIシステムは遅く不具合も多い為、自動化には使いたくない
- 飲食システムから食雑貨システムへの売上入力はムダかも
これでほぼ全体図と課題が分かりました。しかし、会社全体、もしくはシステム全体の課題を解決するのはDAFチームの仕事ではありません。問題は把握した中で、最も全員にメリットをもたらす自動化を素早く提供することが大事です。
2 現状把握(個別案件)
個別の自動化案件でおさえるべき項目
以下の項目をヒアリングします。
- 部署名
- 業務名
- 業務の目的
- 実行タイミング(日次、月次など)
- 現在の作業工数
- インプット(データソース)
- 加工内容
- アウトプット(帳票、ファイル、DB書込み)
まず、半手動で作られている営業日報の自動化から取り組むことになりました。経営層の狙いは、工数削減はもちろんの事、現在の日報の中身の改善にもあるようです。
あなたは上記の項目を関係者にヒアリングしまとめます。
項目 | 内容 |
部署名 | 営業部 |
業務名 | 営業日報配信業務 |
業務の目的 | 前日の店舗別売上/客数を営業マネージャ以上に伝える事 |
実行タイミング | 日次 |
現在の作業工数 | 1時間 |
インプット | グループウェアに張り付けられたExcel |
加工内容 | 前日の日報にシートを追加し、当日分の日報を張り付ける |
アウトプット | Excelファイルをメールで関係者に送る |
サンプル
インプット、アウトプットのサンプルを提出してもらいます。また、現状使っているアプリケーションの画面イメージもハードコピーしてもらいます。
現在使用している営業日報の例を提出してもらいました。業態別店舗別の単日と月の累計データになっています。報告される値は売上金額と数量になります。
業務フローの図式化
正確に現状を把握するために、現場にヒアリングし、以下のような業務フロー図を作成します。
2つの基幹システム、BIシステム、グループウェアを通して、日報を入手していることが分かります。日報を配信する担当者は、自分で数値を取らず、本社社員がグループウェアに手動でアップロードしてくれるデータを使っています。
3 個別案件の要件定義
ユーザーに提供するサービスの内容を定義します。開発時や運用開始後に変更になる場合もたびたびありますが、際限なく変更を受け入れていては運用にたどり着けませんので、この段階で要件を文書でまとめておき、ユーザーや自動化プロジェクトのリーダー層と合意を形成しておくことが重要です。
成果物イメージ
アウトプットする帳票のイメージを作成します。
要件定義チームが中心となり、関係者と協議し、新しい営業日報のフォーマットを作成しました。
【変更点】
- 組織(エリア分け)を追加
- 既存店集計を追加
- 売上数量ではなく、客数(伝票件数)を載せる
このように、現状のままではなく、業務改善を含んで自動化を行います。
現状の業務フローでは、営業日報を配信する担当者は、自分で数値を取らず、本社社員がグループウェアに手動でアップロードしてくれるデータを配信しているだけので、この要件を満たすことは不可能です。
本社社員に頼らず、データソースから直接データを取得するフローに変えなければいけないことが明らかになりました。
粒度分析
粒度とはデータの細かさです。成果物を作成するために、必要なデータの粒度を洗い出します。
管理ポイント | |||||
管理項目 | 日 | 月 | 店舗 | エリア | 既存店区分 |
売上金額 | ○ | ○ | ○ | ○ | ○ |
客数 | ○ | ○ | ○ | ○ | ○ |
同曜日売上金額 | ○ | ○ | ○ | ○ | ○ |
同曜日客数 | ○ | ○ | ○ | ○ | ○ |
累計売上金額 | ○ | ○ | ○ | ○ | |
累計客数 | ○ | ○ | ○ | ○ | |
累計同曜日売上金額 | ○ | ○ | ○ | ○ | |
累計同曜日客数 | ○ | ○ | ○ | ○ |
データソース分析
粒度分析したデータの要件を満たすデータソースを特定します。「現状分析」で把握したシステム構成をもとにデータソースを探り当てましょう。
データソースを特定したら表にまとめます。(ここまで手順を踏んでも、データソースが後から変わることがありますので、開発しながら修正することもあります。)
項目 | ソースシステム | データソース | カラム |
食雑貨売上金額 | 食雑貨基幹システム | 売上明細 | 売上金額 |
食雑貨客数 | 〃 | 売上明細から計算 | |
飲食売上金額 | 飲食基幹システム | 店舗別実績 | 売上金額 |
飲食客数 | 〃 | 店舗別実績 | 客数 |
事業部 | エクセル | 店舗マスタ | DIV |
エリア | 〃 | 〃 | AREA |
店舗 | 〃 | 〃 | SHOP |
オープン日 | 〃 | 〃 | OPENDATE |
データソースを調査した結果、飲食事業の実績は飲食基幹システムから取得できることが分かりました。そのため、食雑貨基幹システムに店別売上を手入力する作業が必要なくなります。
また、本社社員によるグループウェアへの登録も必要なくなります。
自動化後のフローを図で示すと以下のようになります。
ずいぶん、簡潔になりました。
コメント ログインすると書き込めます