As-Is業務フローとTo-Be業務フローを徹底解説

はじめに

ビジネスプロセスの改善は、多くの企業が直面する重要な課題です。しかし、「改善」という言葉は簡単に口にできても、実際に効果的な改善を実現することは容易ではありません。その理由の一つは、現状のプロセスを正確に理解し、あるべき姿を明確にすることが難しいからです。

そこで重要な役割を果たすのが、As-Is業務フローとTo-Be業務フローです。これらは、業務改善を成功に導くための重要なツールとして、多くの組織で活用されています。

本記事では、As-Is業務フローとTo-Be業務フローの違いを詳しく解説し、それぞれの特徴や活用方法について、実践的な例を交えながら説明していきます。

As-Is業務フローとTo-Be業務フローの基本的な違い

それぞれAs-Is業務フローとTo-Be業務フローは２つの側面で違いがあります。

時間軸の違い

• As-Is業務フロー
  • 「現在」の業務の流れを表現
  • 現状のプロセスをありのままに描写
  • 実際に行われている作業や手順を詳細に記録
• To-Be業務フロー
  • 「将来」あるべき姿の業務の流れを表現
  • 改善後の理想的なプロセスを描写
  • 効率化や最適化を反映した新しい手順を設計

作成目的の違い

• As-Is業務フロー
  • 現状の問題点や非効率な部分の発見
  • 既存のプロセスの理解と共有
  • 改善が必要な箇所の特定
• To-Be業務フロー
  • 業務改善の方向性の提示
  • 新しいシステムや手順の設計
  • 目標とする業務プロセスの共有

作成手順の違い

• As-Is業務フロー
  • 現場観察とインタビュー
  • 実際の作業時間の計測
  • 現状のツールや書類の確認
• To-Be業務フロー
  • As-Isの分析結果の活用
  • 新技術や手法の検討
  • ステークホルダーとの協議

具体例

具体的にあるイタリアンレストランを例にして違いを見てみましょう。

実際の動き

1. お客様がレストランに来店し、席に着く。
2. ウェイターが注文を取りに来る。
3. お客様が注文をする。
4. ウェイターが厨房に注文を伝える。
5. シェフが料理を作る。
6. ウェイターが料理をお客様に運ぶ。
7. お客様が食事し会計をする。

これをAs-Is業務フローにするとこうなります。

合計８つのアクションが行われていることがわかります。また、ウェイターの負担が大きいことも気づくと思います。
ここにはありませんが、客が会計をするときは必ずウェイターが相手をするので、さらにウェイターの負担が増えることが想像できます。

解決策を洗い出す

そこで、ウェイターの負担を減らすにはどうすればよいのかを検討します。ここでは第一ステップなので思いつくものをすべてあげてみます。

1. シェフも注文をとる
2. シェフもできた料理を運ぶ
3. 客ができた料理をとりにいく
4. ウェイターが端末をもって注文をとり、それが厨房にダイレクトに表示されるようにする
5. 客が自分のスマートフォンでQRコードを読み込むことで注文をすると厨房にダイレクトに表示される
6. できた料理をロボットが運ぶ
7. 顧客がテーブルでQRコード決済または電子マネーで支払い

解決策を深掘りする

解決策を洗い出した後は、その解決策がどこまで実現性があるのか深掘りします。それぞれ店の事情や費用面などバックグラウンドが異なるので必ずしもこの深掘りが最適解かはケースによって変わりますが、ここでは一例としてあげています。

1. シェフも注文をとる
   確かにウェイターの負担は減りますが、ランチなど混雑時には厨房が回らなくなります。ウェイターの代わりはできてもシェフの代わりをするのは現実的ではないので、この案は却下です。
2. シェフもできた料理を運ぶ
   こちらも1.と同様の理由で却下となりました。
3. 客ができた料理をとりにいく
   一見いい案のように思えますが、この場合もランチなど混雑時にはいろいろな人が店内を移動することになり混乱のもとになります。
   また、その店のポリシーや雰囲気などから客に料理をとりに行かせることをよしとしないところもあり、そのようなところではこの案は却下です。
4. ウェイターが端末をもって注文をとり、それが厨房にダイレクトに表示されるようにする
   この案は現実的ないい案だと思います。あとは、この次の5.案との費用面での優劣次第です。
5. 客が自分のスマートフォンでQRコードを読み込むことで注文をすると厨房にダイレクトに表示される
   この案も現実的ないい案だと思います。QRコードを客のスマートフォンで読み込ませることで端末を用意する費用がかかりません。
6. できた料理をロボットが運ぶ
   この案は人件費がかからないという点で検討の余地があると思います。ただ、ロボットだけではいざトラブルが起こったときに対応する人員が必要になります。そうなると人件費にプラスしてロボットの投資が必須となりかえって費用がかかってしまう可能性があります。
   それであればウェイターの注文の手間を省くことで、空いた時間を料理を運ぶことで吸収することができる可能性が高く、この案は却下です。
7. 顧客がテーブルでQRコード決済または電子マネーで支払い
   こちらも人件費の削減、業務の効率化、間違いの防止（おつりを渡し間違える等）、客へのサービス向上（レジを待たなくて済む）が期待でき良案だと思います。
   また、支払い情報がダイレクトにシステムに溜まりますので集計も簡単になり間違いも減ります。
   それでも一定数現金払いをもとめる客はいますので、それぞれの効果は限定的かもしれませんが試してみる価値はあるかと思います。

解決策の決定

これまでおこなってきた解決策の検討から以下の施策を行うこととしました。

1. 客が自分のスマートフォンでQRコードを読み込むことで注文をすると厨房にダイレクトに表示される
2. 顧客がテーブルでQRコード決済または電子マネーで支払い

To-Be業務フロー

行われる施策によってどう業務フローが変わるのかをお見せします。

ウェイターから見ると業務が料理を運ぶこと、たまにうまく注文できない客、支払いがうまくできない客の対応をすることがありますが、全体的に業務の量は減っています。

この後、この施策を行うことによってデメリットが発生することがありますが、そのときは作成したTo-Be業務フローをAs-Is業務フローとして使用し業務の問題点を洗い出せばいいのです。

注意点

As-IsからTo-Beへの移行を検討する際は、以下の点に注意が必要です。

• 急激な変更は避け、段階的な改善を計画する
• 実現可能性を十分に検討する
• 必要なリソースと時間を適切に見積もる
• 関係者全員の理解と協力を得る

このように、As-Is業務フローとTo-Be業務フローは、業務改善の「現在地」と「目的地」を示す重要なツールです。両者を適切に活用することで、効果的な業務改善を実現することができます。