以下の資料は、著作権法と不正競争防止法の保護を受けています。
従って、資料の一部あるいは全部について、ＣＩＯパートナーズ株式会社からの承諾を得ずに、いかなる方法においても無断で、複製、ノウハウの使用、企業の展開等をすることは禁じられています。
恐れ入りますが、上記をご承諾頂ける場合のみ、以下のレポート名をクリックして頂き、本編にお進みください。
業務改革における４つの課題（クリックして開く）
アジェンダ
当レポートの要約
業務改革には、４つの局面があります。
各局面では、それぞれの課題を的確に認識し、対応施策を策定し、次の局面へ展開・具体化していくことが必要です。
また、システム導入を伴う業務改革を成功させるためには、業務改革の目的を常に念頭に置いて業務改革とシステム化を進めていくことが重要です。
システムありきで業務プロセスを考えるのではなく、業務ありきでシステムを検討し、必要な業務プロセスと不要な業務プロセスを切り分け、
情報システムとして
必要な機能と不要な機能を明確にしたシステム化構想を策定
して、システム改修またはシステム構築を行うことが必要です。
１．はじめに
ERPパッケージをはじめとする情報システムの導入時の目的として業務改革を謳うケースをよく目にします。
しかし、このような形で提案され開始した業務改革が成功したという話は、あまり聞きません。
それよりもシステム導入後に、
「ユーザーにとって不便になった」
「今まで使っていた必要な資料が出せなくなった」
「業績に悪影響を及ぼしている」
といった話のほうがよく耳にするようにも思えます。
ではなぜ、ベンダー提案に基づく業務改革の多くが、このような結果に陥るのでしょうか。
それはベンダー提案の業務改革の主目的がシステム再構築であり、
業務改革という名のもと、経営課題だけを論じて業務運用の検討を端折り、
新システムありきで業務運用を決定するケースが少なくないからではないでしょうか。
そもそも業務改革とは、
経営課題を解決するために、情報システムを含めた全社業務プロセスの再設計・再構築を行い、経営資源の最適化を目指すこと
であり、現状の業務にこだわらず、ビジネスプロセスを抜本的に再設計・再構築することです。
ERPをはじめとする情報システムは業務改革の実現手段としては非常に有効ですが、
あくまで実現のための手段であり、業務改革の目的とはなり得ないのです。
このように、情報システムのプロセスありきで新しい業務プロセスを再構築していくことが業務改革に繋がらないことは、
過去多くの企業がシステム導入の失敗を通じて経験しているにもかかわらず、
失敗の原因を追及することなく、同じ過ちが繰り返されているように感じます。
このレポートでは業務改革一連の流れを局面に分類し、
業務改革の目的である経営課題を深掘し、具体化されてゆく課題とそれぞれの局面について、
その関連と策定方法について説明していきたいと考えています。
２．業務改革における４つの局面
業務改革には、４つの局面があります。
- 経営の視点で経営課題を策定する仮説定義局面
- 経営課題を実現すべく業務の切り口で深掘りし実現課題を策定する構想策定局面
- さらに実現課題を実現すべく業務プロセス単位に深掘りし具体化された実行課題を策定するシステム構築、及び並行して業務改善に取組む局面
※1～3の各局面では、それぞれの課題を的確に認識し、対応施策を策定し、次の局面へ展開・具体化していくことが必要です。 - 新業務への移行に合わせて、実行課題が実行され想定通りの結果が出ているか評価を行う移行・運用局面
※移行・運用局面では、できなかった課題、新しく発生した課題については改善課題として、次の業務改革のサイクルで策定されることになります。
以下に、各局面の概要を述べます。
１．「仮説定義」局面
この局面では仮説を立てて経営層を取り巻く問題を絞り込み、検証して経営課題を特定します。
２．「構想策定」局面
仮説定義局面で立案した経営課題を解決し、目標値をクリアするために関連する業務を検証し実現課題を策定します。
- 現状業務の確認（見える化）
業務プロセス一覧を作成して関連するすべての業務の洗い出しを行い、業務プロセスの相関関係を明確にし、業務マトリクス分析(※3)を行います。
また、問題がある業務プロセスについて業務フローを作成します。業務フロー作成では、5W1Hに注意してできるだけ詳細なフローを作成することが重要となります。 - 問題点の洗い出しと原因の深掘り
作成した業務フローを使用して業務フロー分析(※4)を行います。
問題点を洗い出す着眼点は以下の通りです。- どこで発生しているか
- いつ発生しているか
- 定例業務か臨時業務か
- この業務で問題が発生すると前工程、後工程にどのような影響を与えるか
- 問題がなぜ発生するのか（上流工程でチェックできないか）
- 業務分掌や規程と異なる仕事ではないか
- 承認、決裁権限が曖昧でないか、または不要な承認、決裁プロセスはないか
- マニュアル通りの仕事がされているか等
- 実現課題の策定
問題を洗い出した後で、課題構造分析(※4)を行います。よく言われる「なぜを5回」繰り返すことで、経営課題の深掘りを行い、整理をします。
次に原因の分析を行い、何を・どうすれば解決できるのか改善策を策定します。
策定した改善策について、業務パレート分析(※5)を行い業務の優先度と重要度を決定し、改善策の優先順位付けを行います。
システムを見直すことで実現可能な改善策も多く出てくると思いますが、新しい業務要件からシステムの要求仕様を明確にして、システムの改修もしくは再構築に臨むことが必要です。 - 改善計画立案
改善策を策定した後で、その改善策の実行計画を立てます。
ここでの注意事項は、すべての改善策を一度に実行するのではなく、中長期に取り組むことと短期で実行することを優先順位に沿って切り分け、無理のない実現可能な改善計画を立てることが重要です。
３．「システム構築・業務改善」局面
構想策定局面で立案した実現課題を解決するために、実現課題を業務プロセス毎に、より具体化し実行課題を策定します。
この実行課題を実現する業務要件・システム要件を整理して、
①新業務フローと新業務マニュアル、②システム設計書（仕様書）、等を作成します。
- 新業務フローと新業務マニュアルの作成
「構想策定」局面で明確にした各業務プロセスの改善策を盛り込んだ新業務フローを作成します。業務マニュアルを作成することで、新業務の担当を明確にして運用切り替えの混乱を避けるとともに、改善策が実現可能かの検証を行います。新業務マニュアルに沿ったテストを行い、システムの検証を行います。
また、新旧システムの並行稼働といった特別処理が発生することもあるため、こういった作業についてもマニュアル化が必要となります。 - システム設計書の作成
システム設計書は新システムを作成する場合の設計書としての役割だけでなく、運用局面においてもプログラムの改修、業務の引き継ぎ等でも必要となります。プログラムのプロセスを記述するだけでなく、そのプログラムの目的を明確にしておくことが重要です。
４．「運用・評価」局面
システム開発後十分なテスト・検証を行い、本番稼働が可能と判断後に、本番運用を行います。
「システム構築・業務改善」局面で策定した実行課題が実現できたか評価を行い、次回の業務改革プロセスの改善目標となる改善課題を策定します。
- データ移行と本番稼働
新業務に移行して稼働を行います。
新システムの導入とともに運用を開始するケースの場合、データ移行を確実に行い、業務マニュアル通りに運用されることが重要です。 - 評価
業務マニュアル通りでないこと（不具合）と業務マニュアル通りだが運用に支障がある（変更要望）を明確に切り分け、新業務の評価を行います。
実行課題に対して実現しなかった事だけでなく、新たに発生した課題についても洗い出し、さらなる「改善課題」を策定することになります。
評価は継続的に行うことが重要です。定期的な評価を行い、経営層に対する経営課題とその目標に対する進捗報告が要求されます。
３．業務改革の流れと課題解決サイクル
業務改革の一連の局面と概要について述べましたが、
これらの局面はそれぞれが独立しているのではなく、一連（PDCAサイクル）の流れとして繋がっています。
これは、経営の視点から策定した経営課題から、
- 会社の仕事の切り口で経営課題の実現を目指す実現課題
- 業務プロセス単位で実現を目指す実現課題の実現を目指す実行課題
のようにそれぞれの立場で課題を掘り下げ、１つ１つ具体化して実行することこそが業務改革であるといえます。
さらにそれぞれの局面の個々の課題に於いても小さなPDCAサイクルが存在し、
それぞれの局面における課題に対する解決策を策定したから終わりではなく、
“その解決策が実行できたか”の評価と見直しが重要です。
この大きな業務改革のループと個々の局面でのループが有機的に結合して、
常にループが回っている状況があって初めて完成度の高い無理のない業務改革は実現します。
おわりに
システム導入を伴う業務改革を成功させるためには、業務改革の目的を常に念頭に置いて業務改革とシステム化を進めていくことが重要です。
システムありきで業務プロセスを考えるのではなく、業務ありきでシステムを検討し、必要な業務プロセスと不要な業務プロセスを切り分け、
情報システムとして必要な機能と不要な機能を明確にしたシステム化構想を策定してシステム改修またはシステム構築を行うことが必要です。
評価は特に重要です。
システム稼働後に行う実行課題の評価だけでなく、稼働後一定期間後に経営課題、実現課題それぞれの視点で実現度を評価していくことも有効です。
実現できなかったことについて、
「何故できなかったのか」「どうすれば実現できたのか」
について評価・反省し、新しい課題とともに再度課題の検証を行い、次の業務改革サイクルに盛り込んでいくことが重要です。
業務改革に終わりはありません。
常に問題意識を持ち、課題を深掘りして具体化し実行課題を明確にし、常に業務改革サイクルが回っている
こういった会社は間違いなく成長し続ける会社といえます。
【本編の注釈】
※1 ベンチマーク分析
指標(ベンチマーク)となる企業と比較して、自社の良いところと悪いところ(強み弱み)を明らかにする
※2 課題構造分析
課題を階層別に分類することで混在する課題の整理を行い、課題の強弱を明確にする
※3 業務マトリクス分析
業務をプロセスに分解しこれを時系列に整理し、ボトルネックとなるプロセスを明確にする
※4 業務フロー分析
業務処理をプロセスの流れとして表示し、それぞれのプロセスの目的と必要性を明確にする
※5 業務パレート分析
業務の重要性・発生頻度を基にシステム化の必要性を評価し、その優先順位をつける
ＣＩＯパートナーズ株式会社
吉田 明弘