大福帳としてのERPパッケージの終焉
私は、2000年頃までは、完全なアンチERPパッケージ派であった。しかし、海外販社の在庫販売システムにERPパッケージを使って以来、二つのERPパッケージの導入にかかわってきた。その結果、今ではアンチ・ERPパッケージはではないが、いろいろ思うことがあるので、私の今までの導入経験と日頃のシステムに対する考えから、ERPパッケージについて述べてみたい。
〔教科書的ERP定義とERPパッケージ〕
ERPは、Enterprise Resource Planningの略で、企業が利益をあげていくために、企業における経営資源である「人・もの・金」を部門レベルでなく、企業全体で最適配分していき、そのフィードバックをもとに継続的に改善を進めていくことを目指した手法・概念とされる。それを実現するために情報の可視化（Visibility）を提供するソフトウェアがERPパッケージというわけである。また、ERPパッケージは、財務・会計、販売管理、在庫管理、生産管理、人事・給与等の基幹業務を支援する情報システムを統合するパッケージとも言える。
〔大福帳としてのERP〕
ERPパッケージに関して、インターネットで調べてみると、『ERPは、「大福帳型データベース」ともいわれる統合データベースを介して、ビジネス・プロセスから見た基幹業務の有機的再結合を実現』するとか、『ＥＲＰでは、大福帳データベースと呼ばれる１つの大きなデータベースを介して、業務間がリアルタイムに結ばれる。』とか、『大福帳型データベースを採用することによって、競合優位性を築こうとする企業の一端を担っている。』というように書かれていることが多い。このように、発生するデータ（トランザクション・データ）を要約せずに、基幹業務全体のデータがそのまま蓄積していくタイプのデータベース・システムのことを「大福帳データベース」とし、ERPの中核データベースやデータ・ウェアハウス（DWH）の概念を「大福帳」（注１）という言葉を使って説明している場合が多く見られる。
そして、『大福帳型データベースを持たず、データが分散してしまっているような部分最適のシステムでは、情報にタイムラグが生じたり、データの不整合が起きるといった問題があり、部分的には優れているシステムでも、全体でみると最適とは言えません。』という意見を述べられている方もおられる。（注５）
（注１） 大福帳とは江戸時代の商人が使っていた金銭出納帳で、全業務にわたる個別の取引をすべて発生順に一つの帳面に記載したもの。
（注２） 私はそう思わない。分散データを如何にVirtualに一つのデータベースとして捉えることが出来るかが腕の見せ所であると思う。 私は、データは発生したところで保持（保存）するのがベストであると考えている。私は20年以上前、工場で品質保証をやっているときに、データは発生したところに出来るだけ近いところで処理、保存するべきだと感じて以来、物理的に一箇所に集めることが全て良いことだと思わなくなった。
〔私の最初のERPパッケージ導入経験〕
私にとっての初めてのERPパッケージ（注３）は、SAPでもOracleでもない。英語版しかなく、日本国内での導入実績がない（海外では、日系の会社で数社使っていた）ERPであった。このときは、海外の販社の再構築のために、在庫販売のシステムをアジアの拠点と日本国内の関係部署に導入するものであった。マニュアルも英語版しかなかった。しかし、このマニュアルがたいへん良く出来ていて、操作説明だけでなく、ビジネス・プロセスに関して詳しく説明されていた。Consignment Business（日本では、コックや預託と呼ばれる）に関しても細かく書かれており、動的ではない〔Threshold（閾値）を変数として定義できない（注４）〕もののの、Replenishment（在庫補充）も考慮に入れて、発注が出来るものであった。
（注３）二度目の経験は同じソフトウェア・ベンダーの異なるERPパッケージ（最初に導入したソフトウェア・ベンダーの買収によって、新たなパッケージがラインナップとなり、そのパッケージが受注生産〔MTO: Make-to-Order〕をサポートしていたため、それを採用した）を国内の販売・物流システムを中心に再構築する時のことである。
（注４）コック倉庫での在庫の上限（Max）や下限（Min）をDOS（Day of Supply/Stock：この値自体が不定）の何日分と定義することが出来ない。つまり客先の需要は毎日変わるが、その何日分というものをThreshold Forecastと連動して在庫の上限、下限を決定して在庫補充することが出来ない。（上限・下限を固定値としては設定できるが）
〔最初のERPパッケージを選んだ理由〕
ERPを決定する前に、各ERPパッケージ・ベンダーのHPの資料を読んだり、付き合いのあったSIerの方々の意見や、実際パッケージを使っている人の話をいろいろ聞いたりした。その結果、次に述べる理由により、私どもは現在使用しているERPパッケージを選んだ。 比較検討したERPパッケージは、SAP、Oracle、Microsoft Great Plain、Navision等であった。
（理由１）コンセプトが明確であった： マニュアルのそこここにビジネスのフローが書かれており、ビジネス・プロセスが明示されていた。また語句の定義もきちんとされており、このパッケージは何が出来、何が出来ないかが明確であった。
（理由２）コンパクトで、軽そうであった： 現在では、使用拠点も増えたが、私どもは当初、シンガポール、香港、中国、マレーシアでメインに使い、日本でも関係部署が利用できる必要があり、『重い』仕組みは望まなかった。（注５）、専用回線だけでなく、インターネットでも利用可能を条件にしていた。最終的にはMetaFrameを使用した形態をとっている。
（注５）In-houseシステムがメインの弊社の中で、国内にERPパッケージを入れることは大きな冒険であったので、まず海外の販社で実績を積んで、社内において信用を得てから、国内に導入するという考えでもあった。（外堀を埋める作戦）
（理由３）在庫の的確な把握が可能〔在庫管理機能の充実〕： 私どもが求めていたのは、在庫販売がきちんと運用できることであったため、在庫の状況が詳細に見られ、MPS/MRP機能が充実していることが必要であった。そのパッケージの在庫照会の画面からは関連画面に展開でき、全体を見ながらも詳細な情報も関連付けて把握できる仕組みであった。
（理由４）Consignment Business Compliant（コック・預託方式に適合していること）： 当時から、海外でもConsignment Businessの要求があり、これに最初から適合していることが必要であった。該当パッケージには、オーダーの種類に最初からConsigned Orderというオーダー・タイプを持っており、ビジネス・プロセスとして、Consignment Businessに対応するものであり、マニュアルに、Consumption Report後の売り上げに関しても詳述されていた。
（理由５）SIer（システム・インテグレータ）、コンサルタント会社等を使わなくても、ベンダー自体がフォローしてくれると言ってくれた
（理由６）テーブル構造、APIの使い方も公開されており、我々がAdd-onプログラムの開発が可能であると判断した： 当初から、私どものBusiness Processやプロセスの効率化のために、Add-onプログラムの開発が必要と考えていたのでで、そのサポートが必要であった。
〔私がERPパッケージ導入により学んだこと〕
初めてのERPパッケージ導入では、結果として、私は多くのことを学ぶこととなった。
（１）Business Processから見ることの大切さ
これは、大きな収穫であった。今まで機能毎しか見ていなかったのが、「プロセス」として、機能と機能をつなげるということの大切さを認識したのだ。また、ERPパッケージ・ベンダーのUSの技術者とオーストラリアのプリセールスとビジネス・プロセスに関して話をしているときに、Macro-viewとMicro-viewの違いを思い知った。（注６）
この「プロセス」という考えがわかったことにより、EIDXのBusiness Process Modelが頭に入ってくると同時に、RosettNetのSpecificationのBusiness Operational Viewの項目も素直に頭に入ってくるようになった。（RosettNetのSpecificationが何を言っているのかわかるようになった）
（注６）私は、大学時代から経済学をやっており、マクロ経済学、ミクロ経済学を学んだこともあり、マクロ、ミクロの違いはわかっているつもりだった。しかし、私のマクロの考えは、範囲の狭いものであった。私は、フォーキャストの受信において、お客様の各社各様のフォーマットを自社の標準フォーマットへ流し込み、それを自由に使うことを例に、マクロ的な視点を得意に説明していた。それに対して、彼らは最初から、フォーキャストだけでなく、確定注文請け、納期回答、ASN（先行出荷情報）、請求書情報、検収情報をいつでも送受信するという企業活動全般をマクロとして捉えており、それを当然のように話していた。確かに、彼らはコンセプトだけのところもあるが、発想が非常に大きな視点から見ていることが明確であり、自分との発想の違いを思い知った。
（２）海外のお客様の仕組み、考え方が理解できるようになった
たとえば、オーダーの構造 Header-Line（Lineitem）-Subline（Sublineitem）というMulti-line構造（RosetaNetのPIP3A4でも使用されている）が理解できた。日本の電子部品市場では、１注文に１品目を記載する場合が多い（JEITA方式）が、欧米では１注文に複数の品目を記載する場合が多いのであろう、ERPパッケージの場合も１注文に複数品目を入れる書式が基本的に用いられている。Header部に品目を入れずに、Line部に品目を入れ、これを複数もてる構造で各Lineの下にSubLineを複数持てる構造になっている。そのため、オーダーエントリの画面もその構造に合わせるため、我々にとっては使いにくいものになっている。しかし、この考えの違いが明確になったため、海外のお客様の考え方がより理解できるようになった（そらそうだ、彼らはERPをまともに使っているんだから！）し、RosettaNetのメッセージの構造も、より素直に理解できるようになった。
（３）在庫や需要の捉え方
ERPパッケージの在庫販売のビジネス・プロセスからCost Method（原価法）、在庫の管理の仕方や需要の捉え方（注７）が理解できた。
（注７）在庫の管理の仕方については、以下のようなことをERPパッケージから学んだ
ⅰ）在庫、需要をOn Hand（手持ち在庫）, Allocated（確保済み在庫）, Available（フリー在庫）, On Order（発注済み、未入庫分）, Demand（客先注文等の必要数）, Open Order Disposition（未確定発注分）から捉えるということ
ⅱ）在庫照会（On-hand Inquiry）のあり方
ⅲ）Nettable、Non-nettableという在庫の捉え方
ⅳ）マージン（販売利益）とCost Method（原価法）と在庫管理の関係やそれらの捉え方
ⅴ）需要として、確定注文とフォーキャストをどう組合すべきかのタイム・フェンス（Demand Time Fence）という概念が理解できた。
（４）〔ERPの弱点#1〕サプライヤ（Supplier）側としてのフォーキャスト管理機能の弱さ
ERPパッケージ、SCMツールにはバイヤ（Buyer）側のフォーキャスト作成、管理についての機能は種々あるが、サプライヤの視点に立ったフォーキャストの仕組みが非常に弱いことがわかった。そのため、私どもでは、フォーキャスト管理に関しては相当Add-onプログラムを開発せざるをえなかった。
（５）〔ERPの弱点#2〕汎用ゆえの効率の悪さにどう対応するか
ERPパッケージは汎用だから、いろいろ要らない項目があり、画面の展開も私どもにとって使いにくい（１画面でやりたいのに、２画面に別れるとか）ものも多くある。効率の悪さをどうカバーするか、ユーザーとの折り合いをどうつけるかが常に問題となる。その折り合いのつけ方にもだいぶ慣れるようになった。
（６）自分たちのビジネス・プロセスを明確にさえ出来れば、Sierやコンサルを使わなくても、ベンダーのある程度のサポートをいただければ、ERPパッケージも導入できることがわかった。
自分たちのビジネス・プロセスのAs-is（現状）とTo-be（どうあらねばならないのか）を明確にすることが大切であるが、なかなか難しいことでもある。しかし、自分たちのビジネス・プロセスをどうすべきか、コンサルが決めることではない。もちろんいろいろな人の意見を聞くことは必要であるのだが。そういう意味でも、自分たちが主体となって、自らの手でパッケージを導入することの大切さを学ぶことができた。
〔大手ERPパッケージ・ベンダーのウソ〕
私としては、ERPパッケージの導入でいろいろなことを学んだが、大手ERPパッケージ・ベンダーの言葉巧みな売り文句には正直あきれ返ってしまう。
BPR（Business Process Reengineering）が盛んに言及された頃、2000年問題対応の頃、最近ではSOX法絡みの内部統制のため現在のERPパッケージ・ベンダーの売り込みの文句を見れば、私が言いたいことはわかられると思う。ERPパッケージを入れれば、何でもすぐに解決するわけではない。
上述したが、自分たちのビジネス・プロセスが現在どうなっていて、どうあるべきかを明確にすべきである。この作業自体が、BPRであり、ERPパッケージ導入で解決するものではない。BPRのために、ERPパッケージを入れるとしても、無理にパッケージにプロセスをあわせると、せっかくの自社持っている競争力をなくしてしまうことにもなりうる。何が自社の強みか、何が弱いのかを全体のビジネス・プロセスから見ながら、必要なところを導入することを考えることも大切だと思うのだが、ERPパッケージを入れれば全てが解決するように宣伝しすぎだと私は感じる。競争優位な独自のプロセスとパッケージとどうインターフェイスを取るかを考えるべきだと思う。全プロセスを同一ソフトにする必要は本当にあるのか？ 全てパッケージ化することが良いことか？そういうことも考えなければならないと私は思っている。
ERPパッケージの特徴の中で、企業情報のリアルタイムの統合というものがあるが、これも、真に受けてはならない。私は正直に言って、全てをリアルタイムにする必要はないと考える（以前、『システム開発と連続の視点』で私は、Quasi-Real timeについて言及したので、参照のこと）。無理に全てをリアルタイムにすると、ユーザーが運用でついていけなくなる場合も往々にしてあり得る。実際そのような場面に何度も出会った。
また、ERPパッケージの全機能を入れないで、会計管理、財務管理等の一部だけの機能導入（注８）では、内部統制もあったものではないだろう。データベースが、大福帳であるべきとしても（私は、そう思わないが）、ERPパッケージの全機能を導入していないなら（一部だけであったら）、大福帳もあったものではない。 2006年6月24日の日経新聞に『内部統制とITフォーラム』という全面広告の中で、SAPジャパンの方が、「SAPでは、当然ながら自前のERPをベースに内部統制の仕組みを構築している。ERPには徹底した履歴管理や細かな権限設定、データ間の整合性確保など必要な機能がすべてビルドインされているからだ。その上に匿名通報機能や監査情報システム機能などが載っている。・・・」と述べられている。このことは事実だと思う。しかし、自社のビジネス・プロセスを全てSAPのERPパッケージで構築するもしくは、完全な連携を取らねば、内部統制ができないということの裏返しであると思う。私どもの場合でも、全プロセスにおいてERPパッケージを使っていないので、内部統制強化において、種々の見直し、マニュアル連携を行なっており、多くの時間を費やしているのが現状である。そう簡単に内部統制は完璧だといえるものではないと思うが。（そういう意味で、「大福帳」であれば、内部統制において完璧かもしれないが、ERPパッケージだけで、企業活動の全てをオペレーションしている会社が本当にあるのだろうか？）
（注８）『２００５ ＥＲＰユーザー白書』 （ＥＲＰ研究推進フォーラム発行）の「主要業務のＥＲＰ化の現状（2005年）と将来（2007年）」の調査結果を見ても、会計管理、財務管理、人事管理、販売・在庫、購買管理、生産管理、物流管理、ＳＣＭ、ＣＲＭ、経営管理の10の業務システムを調査対象とした場合、ERPパッケージを同時に全ての機能を導入している結果ではなく、会計管理、財務管理、人事管理の３業務でERPパッケージの利用率が4分の１程度で、販売・在庫、購買管理、生産管理、物流管理では、独自開発が主流と報告されている。ビッグバン方式の導入など極々わずかなのである。
ERPパッケージを導入するときに、よく「カスタマイズをするな、カスタマイズは最小に」と言われる。私は、この考えに疑問を持っている。私もオリジナルのパッケージのコードをカスタマイズするべきではないと思っているが、Add-onプログラムによる外付け方式によるパッケージのカスタマイズは大いに認める立場である。ただし、『カスタマイズしやすい構造』、『システムを捨てる』という考え方を明確にしておくという前提はあるが。（これについては『「システムを捨てること」と、「いつでも捨てられるための準備」』を参照のこと） また、カスタマイズを少なくするために、業務に合う「適切なERP」を選択する
べきで、そのために、コンサルテーションを受けることを薦められる。しかし、①コンサルタントが全てをわかっているとはいえない。コンサルにも得意の分野があると同時に、不得意の分野があるはずである ②コンサルタントが全てのベンダーのERPパッケージを知っているわけではないで、どこかのベンダーのパッケージに偏った見解を持たざるを得ないはずである ③コンサルタントが、現実のビジネス（ビジネス・プロセス）を何処まで知っているか疑問ということから、本当にコンサルテーションを受けるほうがいいかは、ケース・バイ・ケースということであろう。（本当に親身になってやってくれるコンサルタントもいるではあろうが・・・）
2006年7月5日付け日経新聞の『企業向け情報システム 「乗り換え」に大幅値引き』という記事に、「SAPジャパンは日本オラクルとグループの日本オラクルインフォメーションシステムズが販売するERPソフトからの乗り換え客に、過去に払ったソフト代金の75%を“補てん”する」ということが報じられていた。 この背景にはいろいろな理由が存在するのであろうし、またSAPジャパンだけの話ではないであろう。しかし、この業界いったい何をしようとしているのか？自分で自分の首を絞めているように感じるのだが…。
〔最近のERPパッケージの動き〕
（１） SAP、Oracleの動き（注９）
中堅・中小市場向けに、「パラメータやマスタ・データを事前設定」、「各種ドキュメント」、「導入方法論」のテンプレートを利用したパッケージ導入を行なっているようである。私は、この動きは当然のことだと思う。ただ、このよう考え方は、中堅・中小企業だからというものではないと思うのだが。
（注９）SAPジャパンのmySAP All-in-One、日本オラクルのOracle NeO
（２） 業種業態に合わせてモジュールが選択可能なコンポーネント型ＥＲＰパッケージ『IFS Applications』
モジュールの組み合わせというコンゼプトは、いい考え方と思うが、私は実際このパッケージを見たことがないので、中身についてはコメントできない。 NECとIndustrial and Financial Systems, IFS AB社(本社:スウェーデン)は協業関係の強化し、IFSのERPパッケージを展開しているようだ。
（３）GRANDIT
GRANDITは、①顧客視点でユーザビリティを追及した完全Web-ERP ②多彩な業務ノウハウを集大成させた究極のコンソーシアム方式 ③多彩な業務ノウハウを集大成させた究極のコンソーシアム方式 ④幅広い企業規模や業種に対応するすぐれたスケーラビリティといった特徴を謳った日本発のERPということらしい。（私にとっては、日本発であろうとなかろうとどうでもいいのだが） 現場の使い勝手重視というコンセプトとして、イベントドリブン操作、ポップアップウィンドウ、ファンクションキー、IMEの自動オンオフ、Enterキーによるカーソル移動などさまざまな画面操作といったことをやっているようだが、これは私が、弊社で対応してきたこととほぼ同じ考え方である。 HPを見ているにおいては、多くの共鳴する部分がある。しかし、「オール・イン・ワン」というコンセプトには抵抗を感じる。
（４）Compiere（コンピエール）
Compiere（コンピエール）は、オープンソースの中堅企業向けERP＆CRM統合ソフトウェアである。 HPを見る限り、基本機能は持っているようであるが、実際どうなのかはよくわからない。コンピエール自身はソフトウェアの開発とサポートに注力し、製品の販売流通は70社を超える全世界のパートナー・ネットワークに任せているらしいが、このようなオープンソースのERPパッケージというコンセプトも面白いかもしれない。GRADITのようなコンソーシアム方式の開発といい、Compiereのようなオープンソフト方式といい、新たなビジネスがERPパッケージ業界でも生まれているようだ。 なお、 『オープンソースERPベンダーが600万ドルの開発資金を調達』というCompiereに関連する記事も2006年06月21日付けで配信されていた。
〔私がERPパッケージに望むこと〕
私が、ERPパッケージに望むものは以下の4つである。
① 堅牢なデータベース（Robust Database） 堅牢と同時に、拡張可能なテーブル構造であれ
② 選択肢のある開発ツールと各種ドキュメント
複数の開発方法が存在し、APIやStored Procedure等が公開されており、ER図、テーブル・レイアウト等が用意されていること
私は、上述したように、オリジナル・コードのカスタマイズは行なうべきでないと思っているが、Add-on プログラムで、追加機能や効率化のための機能拡張は行なうべきだと思っている。それ故に、開発ツールは重要である。
③ グローバルな標準のビジネス・プロセス・モデルのテンプレート
EIDX、RosettaNet等で示されるビジネス・プロセスを該当のERPパッケージで実現するときの画面、機能の具体的な例が示されること
④ グローバルなサポート
海外での利用も考え、グローバルなサポートが得られること。
〔大福帳としてのERPパッケージ終焉とこれからの対応〕
私たちはERPパッケージを導入することが目的ではない。ビジネスを継続的に拡充していくことが目的である。だから、カスタマイズ（私は、パッケージのオリジナル・コードを変えるのでなく、上からソフトをかぶせるという意味で、アドオンと呼び、カスタマイズとは呼ばないが）が良くないと言われても余り問題とは思わない。むしろいつでもカスタマイズした部分を取り替えられるようにすること、いつでも捨てられるようにすることに注力している。とにかく、私たちの目的はシステムを入れることでなく、「ビジネス・プロセスありき」の観点を持ち、如何にビジネスをしていくかである。
また、全ての業務を同一のパッケージで対応すべきものか？ 私の答えは、「NO!」である。『大福帳』や『オール・イン・ワン』という概念より、如何にインターフェイスを取るか、『つなぐ、つなげる』ことが重要となる。そういう意味で、業界でビジネス・プロセスや用語の定義が標準化され、標準のインターフェイスが用意されれば一番楽なのだろうが、そういうことはありそうもない。だから、『つなぐ・つなげる』仕組みが、今後より大切になってくると思う。（Business Application Functionalities Federation）
自分のビジネスをERPパッケージに合わせるのでなく、パッケージのFunctionalities（モジュール）の組み合わせで、自分のビジネス・プロセスを実現するのである。業務をパッケージに合わせるのでなく、パッケージを業務に合わせる。つまり、該当のERPパッケージに必要なFunctionalitiesがないならば、ほかから持ってくるか、自ら作り、連携していくという形を取るべきだと、私は考えている。この方法が、大福帳としてのERPパッケージの終焉に対応するやり方だと思っている。
ERPパッケージ・ベンダーの甘い言葉に騙されないようにしよう。