こんにちは。ネオシステムの高橋です。
前回の記事ではPowerAppsについて紹介しました。
今回は業務フローをドキュメント化する方法についてご紹介したいと思います。

現状の業務フローを整理・分析することで、アプリを導入する必要があるのか、どういったアプリを作れば業務改善につながるかを明確にすることができます。
社内向けのアプリを作ってみたいが、どんなアプリが求められているのかわからない人はぜひ参考にしてみてください。
また、今回の記事は現在のビジネスプロセスを理解するという記事を参考に作成していますので、こちらも併せてご活用ください。

目次

作業を書き起こす
誰が、いつ、どこでそのタスクをしているのかを理解する
作業の詳細を整理する
どのようなデータが必要か
どのようなデータフォームが必要か
承認やエスカレーションが必要か
どのように次のタスクに渡されるのか
プロセスをマッピングする

作業を書き起こす

業務フローの全体像を把握するために、まずは全ての作業を洗い出していきましょう。自分一人で考えるのではなくステークホルダと一緒に実施することをお勧めします。

業務の範囲を明確にするのがポイントです。

誰が、いつ、どこでそのタスクをしているのかを理解する

ここでは、その人が果たしている役割を理解することが重要です。
役割を理解すると、アプリの画面の設計やアクセスとセキュリティの構成に役立ちます。

人物を特定できたら、以下のことについて考えてみましょう。

どのデバイスを使用してるか(デスクトップパソコン、タブレット、モバイル端末)
この作業の主な場所はどこか(オフィス、在宅、工事現場、どこでも)
タスクが実行される頻度は(毎日、年に1度、不定期)
ほかにどんなシステムを使っているか
その人はアプリを使用することで何を得ることができるのか
その人はアプリ導入に肯定的か

これらを探るための一番良い方法は、その人々と直接話すことです。
将来的にどのようにやりたいのか簡単な会話で学ぶことが重要です。

ペルソナ分析

タスクの実施者と話すことができたら、そこで見つけた役割やワークスタイルをまとめましょう。

タスクの理想をドキュメント化する

タスクの実施者にとって理想的なタスクを分析した結果をまとめましょう

タスクの詳細を整理する

ここでは各ステップの完了判断を明確にしていきます。
また、前後のタスクがどのように関係しているかを明らかにして、不足している作業がないか確認します。

どのようなデータが必要か

タスクの実施者へ提示するデータはどのようなデータか、確認していきます。以下の点を明確にしましょう。

提示されているデータは前のタスクから引き継がれたデータか
それとも既存システムから輸出されたデータか
作業者はデータにアクセスすることができるか
市場データや気象データなど外部システムからのデータか

道路補修工事の場合の例

工事受注者が補修情報を登録する際、作業員名を登録する必要がある

その際、対象の事業所を自動で紐づけられるようにする

データのプライバシーと権限に気を付ける

上で列挙した点のほかに次のことにも気を付けましょう。
そうすることでプライバシー制御を定義することはもちろん、どれくらいのデータを扱える必要があるか定義することにも役立ちます。

既存データに対して、作業者はどのデータにアクセスする必要があるか
他の人がアクセスしてはならないデータに対して、対象者はアクセスする必要があるか
対象者は他の人が実行不可能なタスクを実行できるか

道路補修工事の場合の例

工事受注者は自分が実施した作業のみが表示される

工事管理者は自分の事業所のみの情報が表示される

事務所担当者は全ての補修情報を確認できる必要がある

データの更新に気を付ける

受信データはどのくらいの頻度で変更されるのか
このデータはデバイスまたはシステムからリアルタイムで送信されるのか
このデータが変更されることはめったにないのか
アプリはどのくらいの頻度で新しいデータに更新する必要があるのか

道路補修工事の場合の例

工事受注者が補修情報を更新するのは1日1回程度である

前日の記録を見たいことがあるので、翌日には更新されたデータをアプリで確認できるようにする

工事の計画を見直した場合は、アプリ内のデータもすぐに変更してほしい

どのようなデータフォームが必要か

ここでは具体的なデータ項目について考えます。

既に入力フォームが存在しているか

紙媒体の入力フォームが存在するのであれば有効に活用しましょう。
その場合は、以下のことに注意してください。

項目の順序を変更する必要があるか
フォームを分割する必要があるか
複数のプロセスを並行して実行できるか

どのようなデータを取り込んでいるか

そのデータは何と呼ばれてるか
これはデータソースで呼ばれている名前か、それとも業務で使われている通称か

データソースのデータ名をわかりやすい名前にマッピングした方がよい場合もあるので、取り込みデータの名称を今一度確認してください。

そのデータは必要なのか

そのデータは特定の場合のみ必要なのか、常に保存する必要があるのかを整理しましょう。またその理由も明確にしておきましょう。

そのデータはどこへ置かれるのか

既存のシステムへ保存するのか、スプレッドシートとして保存するのかなど、保存先を明確にする必要があります。
また、対象の業務とは別のプロセスで価値のあるデータかどうかも確認することにつながります。

データ項目の作成

以上を踏まえたうえでデータ項目を洗い出しましょう。

報告書表紙:複数の報告書をまとめたもの
報告書: 1日の作業についてまとめたもの
報告書明細: 1日の中で複数回実施される作業

承認やエスカレーションが必要か

ここでは、作成されたデータの判定とその後の伝達について考えます。

データの評価

何らかのデータが作成された後、そのデータは判定されるのか
その判定結果は誰かに伝える必要があるのか、だとしたらどのように伝えるのか
その判定結果によって次のステップが変わるのか、だとしたらどのように切り替えるのか

承認フローの有無

承認が必要な場合は、以下のことを明確にしておきましょう。

承認はどのように得られるのか
承認できる特定のユーザーやロールはあるか
このユーザーはアプリにアクセスできるのか、それとも別の方法を使うのか

承認フローを導入する場合は、承認後の次のステップに対しても配慮が必要です。

次のステップのユーザーに対して、どのように承認結果を通知するか
次のステップを進めることができるのか

エスカレーションの有無

エスカレーションが必要な場合は、以下のことを明確にしておきましょう。

特定の条件下で、項目を自動的にエスカレーションする必要はあるか
ステップ内に時間枠はあるのか
担当者が承認を見逃した場合、別の作業担当者に承認を求めるのか、またその時間はどのくらいか
それとも別の通知を送信するのか
エスカレーションする権限を誰に与えるか
エスカレーションが必要な場合、どのように表示するのか
期限に遅延している作業項目から順に表示させるのか、それとも表示色をかえるのか
アラートまたは通知を用意する必要があるのか

道路補修工事の場合の例

工事受注者が補修作業時に事故を起こした場合は、エスカレーションする必要がある

アプリで事故有のデータを作成した場合は、自動で工事管理者の佐藤さんにメールを送信する

佐藤さんの返事が3日以上ない場合は、佐藤さんの上司にメールを転送し、確認してもらう

どのように次の作業に渡されるのか

次の実施者へ作業を受け渡す場合、どのように作業の開始を知らせるか確認します。

プロセスをマッピングする

ここまで出来たら、業務フロー図を書いていきましょう。

この図は、作成しようとしているアプリに直接関連するステップだけでなく、その前後のステップも含める必要があります。
これにより、アプリが業務全体にどのように適合しているかを確認することができます。

業務フロー図が完成したら関係者に確認してもらいましょう。
その後の流れについては業務の最適化を参照してみてください。

参考資料

現在のビジネスプロセスを理解する