目次

改善の進め方(全体像)

気づきの収集

課題の設定

施策の定義

業務フローへのフィードバック

評価法の設計と実践

まとめ：業務フローを対象に改善サイクルを回す方法

改善の進め方(全体像)

前回までに、業務を棚卸しし、業務フローを描くまでの手順をお話ししました。ご紹介した手順で、業務の役割分担、開始条件、インプット・アウトプットなどが明確になる (または曖昧であることがわかる) ことにより、既にうすうす課題がたくさんあることに気づき始めていることと思います。今回はこの業務フローを対象として、課題を洗い出し、対応策を検討して、改善プロジェクトを立ち上げてゆく工程を解説してゆきます。

その全体像は図1のように5つのステップに分解されます。まずは業務フローを当事者に見てもらいながら「気づき」を収集します。その「気づき」をカテゴリー分けして「課題」を設定します。概ねどんな「課題」にも、その対応策となり得る「処方箋」があります。その中からメリット・デメリットを検討して選択したものを「施策」と呼びます。最後に「施策」の推進プロジェクトを立ち上げ、具体的な実行手順に落としたものを「タスク」とします。

図1. 業務フローを起点とする改善の進め方(全体像)

気づきの収集

それではステップ毎にもう少し詳しく解説してゆきます。気づきの収集段階では、その業務を実際にやっている方に業務フローを見てもらい、日々感じている課題認識、困り事、こうなったら良いのにと思うことをざっくばらんに書き出してもらいます。図2のように、業務フローに付箋を貼ってもらう形式で良いでしょう。時間がかかる、待たされる、やり直しが多い等、どんな業務にも、もっと改善できる余地は必ずあるものです。業務フローの余白が付箋でいっぱいに埋まるくらいを目標に書き出してもらってください。

図2. 業務フローに「気づき」を収集するイメージ

気づきを書き出してもらう際には、図3のような観点で日々の業務を思い返してもらうことで、より多くの意見を引き出すことができます。QCD (キューシーディー) はモノ作りの世界で重要とされる三つの観点の頭文字を並べたものですが、業務プロセスの設計・評価においても、このフレームワークがよく適用されます。

図3. 業務上の問題を探す時の観点・目の付け所

業務上の問題を探すにはQCDのDから目を付けてゆくのが良いでしょう。Deliveryの”D”では納期や期日に関連する問題を探します。遅れる、待たされる、期日が変更される、別の仕事が割り込んできて期日が前倒しになる等が該当します。表面化しやすい事象なので、気づくことは容易だと思います。

次はCostの”C”です。期日が早くなる、遅くなるということは、何かが変更されたり、何かに手間取ったりしていることが想定されますね。その要因を探して下さい。要求が追加/変更された、取り下げられた、それに伴って作業がやり直しになった等の事象です。また、過剰なルールや役割分担が設けられていて、常に時間がかかる、情報収集が大変、人が捕まらない、タライ回しになるといった事も”C”に該当するよくある事象です。

最後にQualityの”Q”を検討します。変更、取り消し、やり直しが多いという事は、業務上の品質に問題があることが想定されます。どこかで誰かが何かをミスっているからそうなる訳です。依頼内容の確認ミス、社内の情報伝達ミス、判断ミスなどが発生していないか、振り返ってみましょう。このように、”D”の原因は”C”、”C”の原因は”Q”にあることが多いとされています。なのでモノ作りではQCDの順に重要とされているのですね。システム運用でも全く同じです。

課題の設定

さて、「気づき」が十分に集まったら、付箋を別の紙 (またはスクリーン) に移し、似たもの同士を束ねてゆきます。業務改善の話ではないご意見や愚痴などは、脇に避けても良いでしょう。概ね5〜6個のグループ (単品があっても構いません) にすることを目安にして仕分けを行ったら、それぞれのグループで言っていることを要約して名前を付けます。QCD観点で集めれば、前述のようにQCD間の因果関係がありますので、自然に図4のような因果関係図に近づいてゆきます。

図4. 気づきを束ねて課題を設定し、互いの関係性を図示した例

このように現場の声を収集・分析した上で、対策に取り組もうと思うものが特定できたら、これを「課題」とします。短期課題、中長期課題などと区別しても良いでしょう。ここでご紹介した意見の集約方法はKJ法と呼ばれ、ブレインストーミング手法の一つとしてネット上にも多くの解説がありますので、より詳しく学びたい方は調べてみて下さい。

施策の定義

課題が設定できたら、次は処方箋探しと施策の定義です。業務の役割分担やルールの見直し、業務手順の入れ替えや共通化、情報の一元化や部門/システム間のデータ連携・自動化など、対策となり得る処方箋は一般的に複数ありますので、それらを書き出してゆき、組み合わせや手段の比較評価を行います。捻出できる費用、人、時間には限りがありますので、できることから少しずつ理想像に近づいて行けるようタスク(WBS)とスケジュールを描きましょう。そのプランを資料化して組織内の合意形成を図ります。これが大規模な改革であれば、RFI→RFP→ソリューション選定→キックオフといった、IT界隈でよくあるプロジェクトの進め方に繋がってゆく訳ですが、現場の小さな改善活動においても考え方は同じです。

業務フローへのフィードバック

施策によって業務フローが変わる場合には、As-Isの業務フローをコピーして、To-Beの業務フローを作ります。業務手順自体に変更がないとしても、ルール、開始条件、インプット、アウトプット、利用するシステムやITツール等に変更があるなら、その事を業務フローにフィードバックするようにして下さい。システムの設計・開発・テストの過程で新たな気づきがあれば、前述の気づきの収集と同様に、To-Be業務フローに対して気づきを貼り付け、プロジェクト課題として扱いましょう。運用に入った後も同様です。このようにして、継続的な業務改善サイクルが回り始めます。

評価法の設計と実践

最後に、改善活動の評価法について触れておきます。課題の設定の節で述べたように、課題同士には因果関係があります。裏を返せば、効果にも因果関係があるということになります。図5は、効果が下から上へ伝達されてゆくロジックを表現したものです。KPIツリーまたはCSF (重要成功要因) の因果関係図と言います。改善活動において今現在、対策を施そうとしているのは、この図の中のどこなのかを指差せるようにしておき、その結果コストが下がるとか、顧客満足度が上がるということを明確にしておくことが重要です。評価法の設計は施策を実行に移す前に行いましょう。下位から上位へ効果が表れてくるのには、月から年単位でタイムラグが生じることが一般的です。施策に当たり外れはあれども、この因果関係は普遍的なものだと思いますので、改善サイクルのPDCAを行う中で施策を評価し、必要に応じて施策を入れ替えるという進め方をご推奨します。

図5. KPIツリー/重要成功要因の因果関係図

まとめ：業務フローを対象に改善サイクルを回す方法

業務フローを対象とした課題の洗い出しと分析、施策の立案、評価の実践方法を解説させて頂きました。図6のような改善サイクルを確立させ、システム運用のQCDをどんどん良くしてゆきましょう。

図6. 業務フローを起点とする改善サイクル(イメージ)

補足 本稿でご説明した改善の進め方は、株式会社ユニリタが提供する業務改善ツール Ranabase (ラーナベース) で実践することが出来ます。業務フローを描き、付箋を貼り、仕分けして、課題の設定、施策の定義、KPIツリーの設計など、全てオンラインで行うことが出来ます。無償トライアルも可能ですので、ご興味があれば是非お試し頂ければ幸いです。 RanabaseのWebサイトはこちら： https://lp.ranabase.com/