業務改善プロジェクトにおける4つの分類と特徴とは

Photo by Annie Spratt on Unsplash コンサルティング
Photo by Annie Spratt on Unsplash

 

昨今、大小問わず様々な企業が業務改善(BPR)に取り組んでいる。業務改善に取り組む際には、プロジェクトと言うかたちで社内からメンバーを募集し、体制をつくりすすめることが多い。

本記事は、これから業務改善プロジェクトを立ち上げる方、特にプロジェクトマネージャーなどの責任者を対象とし、業務改善の特性ごとに、適切な体制と期間を整理したい。

 

業務改善プロジェクトの4つの分類

 

はじめに、業務改善プロジェクトを2つの特性を使い、4つのマトリクスに分類してみる。

 

2つの特性とは、

1.システム刷新の有無

2.全社的か部門内か

である。

 

上記2つの特性を縦横軸にとった表にあらわすと次のようになる。

 

表. システム刷新の有無と改善範囲にみる業務改善プロジェクトの類型

全社的な改善 部門内の改善
システム刷新あり 類型A

システム刷新を伴う全社的な業務改善

類型B

システム刷新を伴う部門内の業務改善

システム刷新なし 類型C

システム刷新を伴わない全社的な業務改善

類型D

システム刷新を伴わない部門内の業務改善

 

類型Aから類型Dまでの4つの分類について、それぞれの適切な体制と期間を整理してみる。

 

類型A システム刷新を伴う全社的な業務改善

 

類型Aは、システムを伴う全社的な業務改善である。社内広範で、部署横断的な業務を対象とし、かつシステム刷新を前提としている。統合型基幹システム(ERP)を刷新する際によく見られる類型である。

 

プロジェクトの体制と期間

 

全社ERPの導入もしくは刷新の際は、経営企画部門、経理部門あるいは情報システム部門が事務局を組成し、経営層が主導していくのが特徴である。

体制は、全社からメンバを募集する。また、予算規模が大きく、かつプロジェクト発生の頻度が高くないことから、外部の専門家にプロジェクト管理のノウハウを求めることが多い。ITコンサルティング会社がPMOとして参画し、プロジェクト計画立案やヒアリング、プロジェクトの進捗管理などを担う。

期間は短くても2年程度、長い場合は3年以上を要する。

プロジェクトの進め方は、

  1. 現行業務の分析
  2. 課題の洗い出し
  3. 新システムの要件確定
  4. 課題解決が可能なERPパッケージの選定
  5. 設計
  6. 開発・テスト
  7. 移行

となる。業務改善は1.−3.および5.のフェイズにておこなう。

 

類型B システム刷新を伴う部門内の業務改善

 

類型Bは、システムの刷新伴う部門内の業務改善である。営業部や経理部など部門内でおこなう業務改善で、CRMや会計ソフトなど部門の業務システム導入や更新をともなう類型である。

 

プロジェクトの体制と期間

 

体制は、業務部門が主導していくのが特徴。業務部門の予算で実施され、部門長がプロジェクト責任者となる。部門内で選抜されたメンバがプロジェクトマネージャーやプロジェクトメンバーとして参画。

システムの規模が比較的大きい場合はITコンサルティング会社がPMO参画することがあり、小さい場合は社内だけで進める。

期間は3ヶ月から1年程度を要する。

業務改善の対象となる課題はプロジェクト発足とともに抽出し、課題を解決してくれるパッケージ/サービスを選定する。システムの導入とともに業務改善を狙うという進め方になる。

 

類型C システム刷新を伴わない全社的な業務改善

 

類型Cは、システム刷新を伴わない全社的な業務改善プロジェクトである。

例えば、社歴の長い会社において、長年業務を積み重ねてきたが基本となる業務が議論され形成されていない場合に見られる。ERP導入ありきではなく、会社独自の業務をつくることが重視される。業務を積み重ねてきたが「なんとなく」仕事をしていて、業務ルールがあいまいでかつ仕事が属人化しているという課題感である。

幹となる業務を作り終えた後にERPを導入することもあるが、類型Cではシステム刷新を必須としない。あくまで全社的なルールを含めた標準業務をつくることである。

 

プロジェクトの体制と期間

 

体制は経営企画部門もしくは情報システム部が主導するケースが多い。

全社的な業務改善を社内単独ですすめるには相当なエネルギーと経験が求められるため、外部の専門会に参画してもらうことが多い。ITコンサルティング会社がPMOとして参画し、プロジェクト全体の進行を推進する。

期間は6ヶ月から1年程度を要する。

現行業務の分析から課題の抽出、解決方針の決定と進める。解決方針が定まったのちに、担当部門ごとにリーダーを決め、並行して課題解決をおこなう。

 

類型D システム刷新を伴わない部門内の業務改善

 

類型Dは、システム刷新を伴わない部門内の業務改善である。

例えば、経理部門で請求業務の改善プロジェクトや、営業部門で日報管理の改善プロジェクトなどがある。固有業務の改善も多々あり、この類型はプロジェクトの種類が無数に存在する。

 

プロジェクトの体制と期間

 

体制は、業務担当部門の部門長か、あるいは業務担当者のリーダークラスが主導する。

予算規模は小さく、小規模プロジェクトのため、外部の専門家が入ることは少ない。

期間は3ヶ月から6ヶ月程度を要する。

課題が顕在化してからのプロジェクト発足となり、解決方針を部門内で議論し、実行までをおこなう。規模は小さく、短期で終えるプロジェクトになるのが特徴。

 

まとめ

 

業務改善プロジェクトを4つに分類し、その体制や期間の特徴を整理した。

DXがメディア等でも露出するようになり、システム刷新をともなうプロジェクトが増えてくると想像される。しかし、システム導入ありきではなく業務改善を通じて成し遂げたいことを明確にし、適切なメンバを招集し、プロジェクトを進めていきたい。

 

システム開発におけるプロジェクトの目的とシステムの目的の違い
社内向けおよび社外向けのシステムを開発する際のプロジェクトを想定している。社内向けは主にERPやCRMなど、社外は各社事業の顧客向けシステムとなる。 新規で”システム開発のプロジェクト”を立ち上げる際、プロジェクト計画として目...

 

 

タイトルとURLをコピーしました