タイトルにERPが含まれている市販の書籍10冊を調べてみた。

但し、00年以前の発行、特定のERPに関する書籍は除外した。

実際に調べた書籍は、

  1. ERPプロジェクトこうすれば成功する
  2. ERP経営革命
  3. 失敗しないERP導入ハンドブック
  4. ERP/サプライチェーン成功の法則
  5. ERP導入プロジェクト“最適解”
  6. 戦略的ERPの実践
  7. ERP活用による経営改革の秘訣
  8. ERPで学ぶビジネスプロセス
  9. 中堅・中小企業のためのERP導入実践ガイド
  10. ERP導入のツボを押さえる(ERPフォーラム研修資料)

“なんで、そんな面倒なことをしたの?”

実は、調べる前に一つの仮説を立てたのだ。

ERPを経営に効果的に活用している企業が少ない原因の一つは、

【仮説】

  • ERPに携わる方々は、ERPと業務改革との関係がわかっていない 
  • 1歩譲って、業務改革と業務分析との関係を理解していない 
  • 2歩譲って、仮に業務分析の意義は理解していても、業務フローを作成するノウハウを持っていない

のではないか...

そこで、ERPコンサルタントが執筆している書籍を調べてみることにしたのだ。

それでは、調査結果を、謹んで報告させていただく。

結論: 業務フローの作成方法について明確に書いている書籍は1冊

8番めの “ERPで学ぶビジネスプロセス” だけだった。

但し、この書籍は、文字通り、ERPよりもビジネスプロセスに重点を置いており、米国の複数の大学で使う教科書として書かれている。

ついでに、この書籍は、米国で出版された書籍の “翻訳本” だ。

ERPは、道具だ。

なんの道具?

業務を継続的に改善して、生産性を向上させるための道具だ。

BI、SCM、CRM、Eコマースを構築するための前提条件だ。

業務を改善するには、現状の業務プロセスがどうなっているのか調べないことには、目標状態と現状とのギャップはわからない。

問題とは?

そうです。 “目標状態と現状とのギャップ” です。

問題(課題) = 目標状態(あるべき姿) - 現状

閑話休題、

ERPというキーワードを含んでいる書籍で、業務フローの作成方法を説明している書籍は、どのくらいあるのか知りたかったのだ。

たったの1冊だった。それも翻訳本...

これまでの議論について、3つの解釈の仕方があると思う。

1 私の考え方が間違っている
    ERPと業務プロセスを、1冊の書物で扱うには無理がある

2 多数のERPコンサルタントが出版している書籍には、抜けがある

  • ERPと業務プロセスとの関係をきちんと理解していない
  • 関係は理解していても、業務フロー作成の意義を理解していない
  • 業務フロー作成の意義は理解していても、全社的な業務フローを作成するノウハウを持っていない

3 どっちでもない

ちなみに、選択肢3 は、読者の中には、モメゴトは嫌いな方がおられると思い、その読者のために追加した。

私は、業務プロセスについて書いている書籍が少ない理由は、2の可能性が高いと思っている。

(ここだけの話だが、1も準正解だと思っている。)

その根拠は、他の9冊の書籍でも “業務改革” というキーワードは使っているのだが、具体的な業務分析の方法を書いていないのだ。

そこで、今回のトピックスでは、全社的な業務フローの作成手順を具体的に説明することにした。


それでは、私の実体験の一つをご紹介する。

ERPを導入済みのある外資系企業に入社した時のことだ。

私の流儀は、ERPの経営への効果的な活用を推進するには、その企業の業務分析を行うことが最初の仕事であると思っている。

それが、私流の仕事の進め方なのだ。

業務分析を通じて、各部門のキーパーソンとの人間関係を作ることも、業務分析を行う際のネライの一つだ。

ところが、アジア太平洋地域のビジネスプロセスを担当しているマネージャーが、どうしても全社的な業務プロセスの分析作業に賛成しないのだ。

困ったことに、ビジネスプロセスの分析は、本来彼の守備範囲なので、私が彼の了承なしにやることは、予算の面からもできない組織の仕組みになっていた。

私は、彼から “必ず失敗する” と言われてしまった...

実は、私がこの会社に入社する2年半前に、このマネージャー氏は入社したのだが、最初にやったことが “業務プロセスの分析” だったのだ。

ということは、このビジネスプロセス担当者も、最初に取り組むのは業務プロセスの分析と思っていたということになる。

彼の成果物がイントラネットに載っていたのだが、多分、基幹業務プロセス全体の1割も出来上がっていないと思われた。

私から見て “使い物にならない” のだ。

現場の複数のできる社員に聞いてみても、みなさん同じ意見だ。

当の本人に、その業務フローの作成に、どういう風に取り組んだのか尋ねてみて、失敗の原因がすぐにわかった。

  • 現場の社員に業務フローの作成を依頼した
  • 業務フローの作成にエクセルを使った
  • 業務フロー作成に成功したことがない(コツを知らない)

ちなみに、このマネージャー氏は、SAPコンサルタントの認定資格を持っていてアジア太平洋地域全体を統括している社長の信頼を得ていた。

私は、全社的な業務フローの作成で今までに一度も失敗したことがなく、失敗する心配など全くしていない。

でも、私の担当はERPなのだ。アジア太平洋地域の...

現場のあるキーパーソンに “X Xから合意が得られないので業務分析ができない” と話したところ、“鎌田さんがうまくやってしまうとX Xの失敗がわかるから” と言われてしまった... 

そう言われるまで、人間的には申し分ないXXが、なぜ反対するのか理解できなかった。

ちなみに、このマネージャー氏は、プレゼンテーションが実にうまいのだ。

私など、とても太刀打ちできない。

今、思い出した。

ガースナーが、IBMのCEOに就任した際に、だれもかれもが素晴らしいプレゼンテーションをするので、プレゼンテーションにカラーを使うことを禁止したことを... 

見栄えではなく、中身、コンテンツが大事!

これも私の実体験だが、某外資系企業でERPベンダーの選定作業をしていた時に、IBMが持ってきたプレゼン資料は、左上(1か所)をホッチキスで止めてあった。

カバーもなく、単にA4用紙に印刷してホッチキス止め... 

でも、この点については、私も全く同じ考え方だ。

外見よりも中身!  Simple is the best!

閑話休題、

事程左様に、企業内で業務改革を推進するには、事前の予測ができない困難が待ち構えているのだ。

ほとんどの場合、人間に関係している...

まだ、ERPと業務改革との関係について一言も触れていない...

 “ERPは業務改革の手段” と書いている書籍がある。

“ERPの前に業務改革するか、ERPの導入中に業務改革するかは選択の問題” と書いているような書籍もある。

 “業務改革” という用語を、どういう意味で使っているのだろうか...

■ ERPの導入と業務改革は、区別して考える

ERPを説明するには、業務改革という言葉も使わざるをえないが、業務改革を説明するには、ERPという言葉を使う必要はない。

つまり、業務改革の方が、ERPよりも汎用的な(守備範囲が広い)言葉だということだ。

要は、“業務改革” という用語は、ERPを導入している企業にも導入していない企業にも適用できるということだ。

そろそろ、私の見解を書く。

ERPを導入するときには、事前の “業務改革” が必要だ。

但し、この場合の業務改革とは、『その業務改革を行わなかったら、ERPを導入しても所期の目的の達成に支障が出る』 ような業務改革を指す。

ERPの導入前(もしくは、導入中)に行うべき業務改革
   ※ ここでは、思いつくままに書くので、網羅性はない。

  • 勘定科目の再設計

もし、ERP導入目的の1つに、“前日までのセグメント毎の売上や営業利益を知って迅速な意思決定をしたい” があった場合、今までの勘定科目の体系をそのまま使ったら、この目的は達成できない。   

※ セグメント情報とは?
経営の分野では、企業グループの財務状況を事業別/地域別などによって区分して算出/開示する情報を「セグメント情報」と呼ぶ。

なぜなら、勘定科目がBIでセグメント毎の分析ができるような構造になっていないからだ。

ちなみに、再設計は経理(と財務)部門主導の “業務改革” だ。

まだ説明していないBIを使って説明してしまった...

     ※ BIについては、ERPのデータをBIで活用するを、ご覧ください。

  • 部品コード、顧客コード、業者(ベンダー)コードを、全社で統一する

グループ会社間や部門間で、同じ部品に違う部品コードを付けている場合、部品コードを1つに統一する必要がある。なぜなら、ERPにはマスターデータは重複して登録しないからだ。

この際なので、有意コード(※)を無意コードに切り替えた方がいいかも...
  ※ 特定の桁に意味を持つ ⇒ 有意コード、持たない ⇒ 無意コード

これをやるには、大変な手間がかかるが...

部門横断での(ということは、全社的な) “業務改革” だ。

バーコードやRFIDが普及すると、コードに意味を持たせても無意味になるとは思いませんか?

また、顧客コードを一元化していないと、CRMでの顧客分析に支障が出る。 

ERPの導入は、マスターファイルのコード体系を見直すチャンス!

ERPの導入前に行うべき業務改革を説明している。

  • 調達リードタイムの精度を上げたり、調達リードタイムを短くする

調達リードタイムや製造リードタイムの精度が低いと、MRPからの出力データが信頼できないので、MRPを回しても現場は使わない。

製造リードタイムの精度向上は、ERPが本番稼動してからでないと無理だが...

  • 実在庫と帳簿在庫の数を、限りなく一致させる

倉庫からの出庫や倉庫への入庫の際の業務ルールの遵守を徹底したり循環棚卸を行うことで、在庫差異を2%以下に抑えることが肝心だ。

在庫管理部門の業務改革だ。

お待たせしました!

ERPと業務改革との関係  - 私が説明するとすれば...

『 ERPの導入では、勘定科目の見直し、マスターファイルの一元化、調達リードタイムの精度向上、実在庫と帳簿在庫の精度向上など、ERPの本番稼動までに行わないと、ERPを導入してもERP本来の能力を発揮できないことがわかっている業務は、業務改革を行う。

それ以外の業務改革は、ERPの導入(パラメータの選択設定)によって現行の業務プロセスが変わってしまうので、導入前に業務改革しても時間とエネルギーの無駄になってしまう。』

ちなみに、パラメータをいくつかの選択肢から選んで設定する作業そのものが、業務改革(業務処理の仕組みの変更)を行うことになる。

さらっと、大事なこと( ERPの肝 )を説明してしまった。

なので、別の言葉で同じことを説明する。

■ ERPでは、パラメータの設定だけで、業務ルールや業務プロセスの変更が実現する

そういう意味で、ERPは業務改革を実現するための道具 と言える。

但し、この考え方には、ERPのカスタマイズは行わない(プログラム自体の変更は行わない)ことを、前提にしている。

また、ERPの導入後も、継続的な業務改革を行うには、パラメータの変更が、実際のシステム変更の役割を担うことになる。

これが、自社開発の業務システムだと、非常に面倒なことになる。

  レ (ドキュメントが残っていなかったら)プログラムの分析・・・

  レ 関係するプログラムの洗い出し・・・

  レ 修正したプログラムのテスト・・・

  レ 修正したプログラムに不具合がないことを祈るばかりです...

SAPの経験しかない読者は、ここで混乱しているかもしれない...

なぜなら、SAPの場合、パラメータ設定の作業を “カスタマイズ” と呼んでいるからだ。
   ※ “SAP” は、会社名だ。ERPとしての製品名は、SAP ERPとかSAP HANA... 

念のため、ERP業界での用語の定義を明確にしておく。

  • カスタマイズ - ERP自体のソースコードを書き換えること
    これをやると、ERPのバージョンアップが、事実上できなくなる。
  • アドオン(追加開発)- プログラムを追加開発すること
    追加開発は、ERPをバージョンアップした場合、そのまま動く場合とそのままでは動かなくなる場合がある。追加開発の仕方に依存するが、動作の確認テストが必要になる。
    但し、各種帳票を作成するためには、追加開発は必須だ。

ここで、ERPに詳しい読者は、こう思ったはずだ。

“ERPのデータ構造が変わったら、アドオンは使えなくなる” と。

はい。承知している。

このページは、ERPのプロ向けに書いているのではありません。

こうやって書いていると、自分としては専門用語と思っていないので、読者にまだ説明していない用語を無意識に使っていることがあるような気がしてくる...

そうであれば、謹んでお詫びする...

お待たせしました。

それでは、業務改革を行うために不可欠な仕事である業務分析(業務フロー作成)の手順を、具体的に説明することにする。

どの書籍にも書かれていない 『全社的な業務フロー作成の秘訣』 だ。

このノウハウは、本邦初公開だと思う。

1 業務フローを書く道具(ソフト)を準備する

  • エクセルやVisioでは、機能不足だ。[下記参照] 
  • 業務フロー作成ソフトに必要な機能
    1. イベントやフローの追加/移動/削除が簡単にできること
    2. 階層的に表現できること(業務フローのドリルダウン機能)
    3. レポジトリー管理ができること(同じ用語を一括変更できる)
    4. 業務フローと業務ルールを一元管理できること
    5. 利用者は、Web上でどこからでも参照できること
    6. グローバル企業の場合には、多言語に対応していること

読者は、具体的な製品名を知りたいと思っておられるかもしれない。

でも、このサイトの性格上、特定メーカーの製品名を載せることは避けたいと思っている。


2 業務フローの作成範囲を決める

全社的な業務分析を行なうといっても、ERPの導入で影響を受けない部門まで業務分析をする必要はない。  ※ このトピックスでは、内部統制とは関連付けていない。


3 分析する部門のヒヤリング対象者を決めて、本人から快諾してもらう

  • ヒヤリング対象者は、忙しい時間を割くことになる。
  • ここで、ヒヤリング対象者(現場のキーパーソン)と良好な関係が築けるかどうかは、ERP導入の成否を左右することになる。
  • ヒヤリング対象者の上司には、必ず事前の了解を得ておくこと

4 ヒヤリングの日程を立てて、関係部門に連絡する

  1回のヒヤリング時間は、2時間以下に設定する。
  逆に、2時間程度の(途中で中断されない)時間が必要だ。

5 ヒヤリング対象者にヒヤリングする

  • 一人ではヒヤリングしない(必ず二人で行う)。
  • 一人はヒヤリング担当、もう一人は記録担当だ。
  • 座る場所(配置)にも気を配りましょう。  ← 重要

ヒヤリング担当者の発言内容に沿って、質問をリアルタイムで次々に考える作業は、結構大変だ...

これができるようになるには、それなりの訓練と場数が必要だ。

6 聞き取った業務処理の流れを、業務フロー作成ソフトで “見える化” する

  • 間違っても、この仕事をユーザーにやってもらってはいけない。
    (ユーザーが作ると、できあがったフローの粒度がバラバラになってしうからだ。)
  • ユーザーには、そんな暇はない。
  • ユーザーが作っていた資料(データ)があれば、収集する。

7 作成(見える化)した業務フローを確認してもらい、必要なら訂正する

  • この工程は、非常に大事だ。(抜かしてはいけない。)
  • ヒヤリングの段階では漏れていた業務フローや、見える化したことで言い間違えていた箇所が発見されたりするからだ。 

8 次のヒヤリング対象者に前のヒヤリング対象者が書いた業務フローを
   チェックしてもらう(いわゆる、クロスチェック)

  • 人は “言い間違い” や “勘違い” をする。
  • きちんとわかっていないことでも “思い込み” で述べてしまう。

9 上記の5~8を、全てのヒヤリング対象者が終わるまで続ける。

  • この期間、分析担当者は、この仕事に専念する必要がある。
  • ユーザーからの日程の変更依頼には、最大限配慮しよう。
  • スケジュール調整は、大変面倒な作業だ... 会議室の再予約...

尚、ヒヤリングしていくうちに、業務フローをどう階層化するかが、業務フロー作成者の腕の見せ所になる。

10 全ての業務フローが出来上がったら、ワードやエクセルで作成した
     業務ルールを、業務フローの該当する箇所に添付(リンク)する。

これで、会社全体の業務プロセスの “見える化” が完成する。

この “見える化” した業務フローは会社の財産といえる。

なぜなら、できあがった業務フローを使えば複数の部門が同じテーブルについて業務の改善点を議論できるようになる からだ。

うっかり、“業務改革の進め方” まで説明してしまった...

テーマがERPなので、業務改革に深入りするつもりはない。

2兎を追うものは、1兎も得ず... 

いっそのこと “3兎を追う” という考え方もあるかもしれないが...

仕事は、忙しい人に頼め!

閑話休題、

ERPを導入しようとしまいと、この見える化された業務フローがあれば、業務処理に必要なノウハウを一元管理できるので、

  • 属人化していた業務ノウハウが、集中(一元)管理できるようになる
        ⇒ 経営リスクの回避につながるとは思いませんか?
  • 部門横断での業務改革を推進するための基盤が整う

ERPと業務改革との関係を、ご理解いただけただろうか?