パッケージソフトとＥＲＰ
約７年ほど前から、このＥＲＰというものに関する
仕事に携わってきました。
今では、あまり、目新しさはありませんが、
ＥＲＰ導入時の問題点はなかなか解決していない
というのが実情と考えています。
以下の文章は、以前、ある会社のＥＲＰ部門を
立ち上げようとしたときに、同僚に説明するために
まとめたものです。極一般的な内容ですが、
ＥＲＰというものがどういうものなのかを理解するうえで
お役に立てれば、と思います。
--------------------------------------------------------------------------------
ERPはご存知の通り、Enterprise Resource Planning（企業資源計画）の略ですが、これは、企業全体の経営資源（つまり、ひと、もの、かね、の３大資源、または、情報を含めた４大資源）をその有効活用の観点から統合的に管理していこうという手法のことです。それを実現するために開発されたのが、SAPのR/3を代表とするERPパッケージです。（ちなみに、R/3で「ひと」を管理するのがHR、「かね」を管理するのが「Accounting」と呼ばれるFI/CO、「もの」を管理するのが「Logistics」と呼ばれるSD/MM/PPなどで、経営資源単位に各アプリケーションがうまく対応付けられています）
パッケージ・ソフトというのは、ERPパッケージが出てくる前から数多く存在していましたが、主に独自開発の代替策として利用されたもので、特定の業務や機能に限定したものが多く、また、その機能も最大公約数的なものに留まっていました。ユーザ独自の機能を実現するにはソースコードの修正で対応するのが通常でした。
一方、ERPパッケージは、上で述べたような企業経営の革新を目的として開発されたもので、対象範囲も企業全体をカバーしておりますし、機能も最小公倍数的なものとなっております。つまり、企業内で考えられるあらゆる業務をこなせるだけの機能があらかじめ用意されていて、各ユーザはその中から自分の業務に必要な機能だけを使用することになります。また、ユーザ独自の機能を実現するには、基本的にテーブル設定の変更だけで済むように作られています。
つまり、ERPパッケージは単なるパッケージ・ソフトではなく、企業経営の革新のためのパッケージ・ソフトであり、ERPパッケージ導入は、従来の基幹業務システムを単にパッケージ・ソフトに置き換えるといった話とは違うものだと考えています。
従来の基幹業務システムは、独自に開発するにせよ、パッケージ・ソフトを利用するにせよ、現場の業務の省力化を目指した「部分最適」のシステムが多かったと思います。たとえば、開発現場、生産現場、販売部門で管理している製品のレベルは当然異なります。開発現場では、製品の仕様変更まで含めて管理しようとしますし、生産現場はいつどの生産ラインで生産したかまで管理しようとします。販売部門では、同一製品であれば、若干の設計変更のあるものでも同一製品として扱いたいと考えるかもしれません。ましてや、生産ラインごとに製品コードが違っていたら、販売部門は受注・出荷の管理ができません。それぞれの業務要件に合わせてシステムを構築すると、当然、製品コードの体系が異なってしまいます。このため、原価データを持つ生産管理の情報が、販売管理の販売データとうまく結びつかずに製品単位の利益が掴めないといった状況にもなり勝ちです。
一方、ERPパッケージは、企業全体を統一した尺度で測れるように工夫されているので、このような場合でも、開発・生産・販売で同一コードを持つことになります。現場では、自分たちの望んでいる管理が１００％実現できるという訳にはいきませんが、トップの経営層にとっては、これにより、製品ごとの利益が掴めるというメリットが生まれます。これによって、売上志向から利益志向へ経営方針を変えることができます。つまり、ERPパッケージでは「全体最適」を求めていくがために、ある程度「部分最適」を犠牲にせざるを得ないのが実状です。
現場の要求に応じて「部分最適」を追っていくと、パッケージの外側に新たにシステムを構築するか、機能を新たに追加することになります。また、「全体最適」を前面に推し進めすぎますと、今度は、現場の業務が回っていかなくなり、ERPパッケージの導入は失敗してしまいます。「部分最適」＝「全体最適」ならば、まったく問題は発生しませんが、現実はトレードオフの関係になる場合が多いと感じています。
ぼくが思うには、ERPのコンサルタントの主要な仕事は、この「部分最適」と「全体最適」の間のどこかに妥協点を見出し、ERPパッケージのメリットをその企業が早期に享受できるように助言することかと思います。
この場合、現場のサービスレベルが下がることにもなりますので、現場の抵抗はかなり強くなります。その解決策は、業務の流れを変えて不要な業務を排除して現場の負荷を下げるか、強引に強権発動で我慢させるかしかありませんが、前者の業務の流れを変えるのは、部門を超えてみ直しをしないと効果はありませんし、部門間の調整でかなり苦労するところです。後者の強引に推し進める場合は、プロジェクトの中に担当役員に入ってもらい、そこから強力に指示していただくようにしないと、なかなか動いてくれません。どちらにせよ、時間のかかるところです。（教科書的には、前者の方法を推進してBPRを進めなさいということになるのでしょう）
「全体最適」がはっきりしている場合は、このようなこともできるのですが、「全体最適」とは何かがあまりはっきりしていないケースが多いのも実状です。つまり、トップの経営層が情報システムに何を望んでいるのが分からない場合が多く、そのような場合は、「部分最適」に偏りがちになります。結局、高いERPパッケージを買って、追加機能の開発のために莫大なコストを払い、使い勝手の悪いシステムを構築したことになります。その企業にとって「全体最適」とは何か、つまり、経営層にどのような経営情報を提供したらいいのかを見つけ出すのも、ERPコンサルタントの仕事になると思います。ただし、これには経営層がERP導入プロジェクトに直に参画していただかないと難しいことだと言えます。（経営層がそのような考えを持っていなかったら、そもそも、ERPパッケージの導入など無理かと思います）
このように考えると、ERPコンサルタントは、ERPパッケージの機能を熟知しているだけでなく、現場の業務も理解できて、しかも、経営的な視点からものを考えられるひとである必要があります。また、現場のひとと粘り強く交渉できるひとでなくてもなりません。そんなひとが本当にいるのかどうか…。それが、ERPパッケージ導入成功の鍵になるかと思います。
