ナニワハイテク：ERP 実装事例
ロバート・コール
同志社ビジネスケース 05-01
2005 年 8 月

ナニワハイテク: ERP 実装事例
同志社大学オムロンチェアプロフェッサー

ロバート・コール

本事例は同志社大学及び同志社大学技術・企業・国際競争力研究センター(ITEC)の協力の下Robert E. Cole により作成。作成にあたり、ERP の複雑さを我慢強く説明してくださった米国
Oracle の Michael Ger 氏、日本オラクルの山岸秀之氏、Enterprise Applications Consulting の Joshua
Greenbaum 氏、及び会見のために時間をいただき、経験を共有していただいたナニワハイテクのマネージャの皆様に心から感謝を申し上げます。
Copyright © 2003 by Professor Robert E. Cole, the Doshisha University. No part of this publication may
be reproduced, stored in a retrieval system, or transmitted in any form or by any means – electronic,
mechanical, photocopying, recording, or otherwise – without permission from the Doshisha Business
School.

著者及び同志社ビジネススクールの許諾なしにこの出版物の一部または全てを複製複写、情報検索システムへの保存、またいかなる形態いかなる手段（電子的、機械的、写真複写、録音録画ほか）により配信することを禁ず。

序章
かなりこぢんまりとした大阪オフィスビルの 8 階で椅子の背にもたれながら、キ
クチ・トシは自分が今おかれている状況を沈思していた。4 年前、彼は国内主要製造会社のとある役職からこの重要関連会社、ナニワテックに出向した。彼の肩書きは副社長兼製造部門長。彼の最初の使命は、全社的情報システム統合を目的とする大規模なソフトウェ
ア適用イニシアチブとしての ERP(基幹業務ソフト)の実装であり、またこの実装を社内改革の基礎として使うことをも期待されていた。熱血幹部社員の彼には、この 4 年間でのナ
ニワテックの発展は不満が残るものだった。しかし、多くの日本企業が ERP 導入に行き
詰まり、また導入拒否をした一方で、自社は ERP 導入により多くの企業目標を達成できたと彼は信じている。その見返りとして彼は親会社に戻り、主要子会社全般にわたる同様のイニシアチブをとることになっていた。
新しい業務に際し、キクチ氏は、この 4 年間を評価し、ナニワテックの ERP 実装
における成功例、そして今後別のアプローチを必要とする失敗例を特定しなければならなかった。さらに、ERP 実装のひな型が「全対応型」でないことも彼にはわかっていた。
別の会社では別のアプローチが必要となる。事実、ナニワテック内ですら、ある工場で使えるものが他の工場でも使えるとは限らなかった。それでもやはり今回は、子会社全体に効果的に適用できるよう、ナニワテックでの教訓を列挙する必要があった。
2002 年度、ナニワテックのプリンター製品売上高は 3250 億円。携帯電話用小型プリンターを含む自社ブランドのプリンターを製造しており、近年特にアジアで急成長中の高解像度レーザープリンター市場に格別の強みを持つ。日本、中国、タイ、シンガポー
ル、イタリア、英国および米国の製造工場に 6000 人の社員を擁し、日本以外では 23 の国と地域に販売オフィスを持つ。海外売上比率は 45％。多くの企業顧客を持ち、密接な関係の中でカスタム商品を提供している。ナニワテックが属する市場は不安定で変化が激し

Doshisha Business Case 05-01

1

ナニワハイテク: ERP 実装事例
ロバート・コール

いため、地域分散型プラント間の緊密な連携の必要性と同時に、的確でタイムリーな売上予測および環境変化に即応できる能力が最重要視される。国内外で、プリンターがワーク
グループやネットワーク印刷ソリューションとリンクするようになり、この業界は目覚し
い成長を遂げている。と同時に、市場では多くの製造業者がシェアを争い、市場価格引き下げ競争が激化している。

全世界および日本国内における情報技術（IT）出現の背景
1970 年代と 1980 年代、日本の製造業の経営陣は工場レベルの最適化手腕に磨きをかけていた。この時期、ソフトウェア開発の商業化が進み、様々なツール（データベー
ス・フォーム、入力レポート）が企業で使用されるようになっていた。特注アプリケーシ
ョンの構築にはデータベース・ソフトウェアとソフトウェア・ツールが使われた。そういったカスタム情報技術（IT）ツールが開発されると、工場レベルの最適化をサポートするために利用されはじめる。これらの手法と、工場への集中的アプローチを用いることでこの時期、多くの日本製造業がすばらしい成功をおさめた。工場レベルに及ぶ分権的意思決定の「現場主義」戦略を海外市場で活用し、多大な効果を得たのである。
1990 年代に入ると、世界中で競争環境が変化する。既存企業および新規参入者が日本の工場レベルの経営効率に肩を並べてきたのだ。同時期、企業が会社全体の効率を求めるにつれ、システムレベルでの最適化が重要視され始めた。OEM のサプライヤー管理
のみならず、どのようにサプライチェーン全体を管理するかが焦点となった。効果的な製造プロセスだけではもはや不十分であり、それを販売プロセスに組み込むことが不可欠となった。国内事業での強力な最適化だけでは不十分であり、海外事業との緊密な協力が必要となった。莫大なコスト削減は全社的な一括購入方針により可能だが、そのためには
様々な工場で使用される部品の標準化が、そしてその標準化の裏では製品コードの統一が必要となる。つまりサプライチェーン全体の最適化は、在庫削減、在庫回転数の増加、そして納期短縮による顧客満足度の上昇など、途方もない可能性を秘めている。ただしその場合、各部署が単に自分の最適化のみを考えていては意味がない。
このような状況は、工場レベルの最適化が焦点となっていた 1980 年代の日本の製造業では特に見られることではなく、もちろんナニワテックも例外ではなかった。結果として、多くの大規模製造会社では、工場間のデータ保全に関する問題が多発した。同じ部品を使用する工場同士で異なる定義づけを使っている例も多く見られた。企業がデータア
クセスを中央集権化し、共有データ定義、統一された製品コードおよび部品ナンバー定義、そして工程・部品の標準化をおこなって初めて、情報管理コストの削減が可能となり、ス
ピーディでより良い判断を下すことができるのだ。さらにこれは、OEM でバラバラな部
品番号を使用している顧客やサプライヤーらにも適用できる。中央集権化の恩恵にあずかるためには標準化を進めなければならない。これは、様々な提携企業、工場、部門ごとの企業風土が衝突するため、至難の業である。
1980 年代には、集中型プロセシングよりも有利とされた分散型プロセシングが広がりを見せたが、実際のところ、それはかえって状況を悪化させた。特定ユーザーのニーズに応える特注アプリケーションが普及し、企業レベルの経営情報を崩壊させたからだ 1 。
1Doane, Michael, 5th edition 2002, SAP Blue Book, Michael Doane.

Doshisha Business Case 05-01

2

ナニワハイテク: ERP 実装事例
ロバート・コール

この流れをくんで、日本のソフトウェア供給会社は独自の専用プラットホーム（富士通、
日立、NEC等）を基にした特注アプリケーションを開発していった。つまり、各企業、工場、部門が独自のハードウェアおよびソフトウェアを持ち、異なるインターフェースが錯綜する中、データの連結に多大な時間を割いていたのだ。
1988 年頃にERP型アプリケーションが全世界的に法人ユーザーの間で使われはじめ、1992 年終盤には、ERP初の統合アプリケーション・パッケージソフトR/3をSAPが発表する。1990 年代中頃からは企業がインターネットへアクセスするようになり、異なる
専用システムを持った提携企業や、従業員らさえもがアクセス可能な、中央集権的データ格納場所を得ることとなった。標準通信プロトコル（TCP/IP）と低価格ハードウェア・ソ
フトウェアを基に、インターネットは高度な流通システム運営のための、よりすっきりとした扱いやすい技術環境をもたらした。ブラウザ関連システムはデスクトップ・コンピュータを簡素化・低価格化し、また訓練・管理を容易にすると同時に拡張性をも高めた。セキュリティ、特に企業間転送時の問題が課題として残されてはいたものの、もはや企業にはブラウザさえあれば十分なのだった。
ERP の企業導入は 1990 年代に躍進する。ただ当初はヨーロッパ、その後も米国に限られており、アジア、特に日本は立ち遅れていた。Exhibit1 が示すように、1990 年代後半、日本企業の ERP 導入は、ヨーロッパ・米国のみならずアジア経済圏の競合企業にも遅れをとっていた。
この遅延には多くの要因があるといわれる。日本企業は、自社の大量な情報ニーズに完璧に応える特注ソフトを使用していたことが指摘されている。パッケージソフトは大雑把かつ未成熟であり、こういったニーズとは到底マッチしないだろうと考えられていたのだ。さらに、SAP やオラクル、PeopleSoft など ERP ソフト供給業者は全て欧米企業であり、その成功事例も欧米諸国のユーザーに限られていた。彼らのソフトウェアは我々の独特な組織構造には馴染まない、というのが日本企業の言い分だった。少なくとも当初、
ERP はこれら供給業者のホームグラウンドであるヨーロッパと米国を中心にマーケティ
ングされていた。それがこれほどに成功したのは、大企業、特に米国の大企業の間で進行していたビジネス・プロセス・リエンジニアリング（BPR）の導入と偶然に一致したからである。経営者が企業再編成の必要性をさほど強く感じていなかった当時の日本では、この神風旋風は起こらなかった。さらに、日本に ERP 供給業者がいなかったこと自体がソフトウェア・メーカーそしてユーザー両面での遅れを示している。
とはいえ一番納得のいく説明は、1980 年代の日本の製造業の成功が「現場主義」
戦略に基づいており、そしてよくあることだが、例えそれでは足りなくなっても過去の勝因を見切る、もしくは改変することに対して腰が重かった、ということである。それは単なる企業全体の効率化と工場最適化のトレードオフという問題ではない。それはシステムレベルで効率化達成に向けて変更を加える一方で、工場レベルでは競争上優位性をもたらす要素については保全するという難題である。
そのためには、一方で工場レベルでの効率・有効性に最も寄与しているもの、それに対し単にユーザーが使い慣れているので変えたくないというだけの処理工程を見分けなくてはならなかった。現行業務プロセスに合ったERPアプリケーションを特注すべきか（そして「現行」通りがもたらす恩恵・利益を損なうリスク）、はたまたアプリケーションにあわせて業務工程を変更すべきか（そしてそのソフトの機能が不完全なせいで効率性

Doshisha Business Case 05-01

3

ナニワハイテク: ERP 実装事例
ロバート・コールが低下するリスク）という二つの問題が生じるのである。この点についてはExhibit2：地域比較データ参照。さらにこれはカスタマイズ決定基準を何とするか、という問題を提起する。新バージョンへのアップデート関連のコストならびにメンテナンス・コストを含む
カスタマイズのコストは非常に高くつくことから、これらの決断は重要な意味合いを持つのである。
「日本の初期 ERP 採択者」が相当数いたにもかかわらず、ERP ベンダーが吹聴するような巨万の富を築いたサクセスストーリーが、日本のビジネス界のメディアで大々的に報道されたことはなく、この事実が日本での ERP 普及の足かせとなった。新しい経営方針導入の迅速な浸透の裏には得てして、個々の企業の成功談があるものとされるからだ。
ERP 実装には強力な経営リーダーシップが必要だといわれているが、日本企業でそのようなリーダーシップを見つけるのは困難なことだと ERP ベンダー達は主張する。

ナニワテックにおける ERP 実装
1998 年 4 月、ナニワテック取締役会は親会社経営陣と緊密な協力体制を持つ IT グループからの重要提案を承認した。社長はこの案を全面的に支持。IT グループはオラク
ル社の E-Business Suite 導入を推奨した。親会社は全社的ライセンスを獲得し、ナニワにも特価で提供できるとのことだった。取締役会への提案は下記 8 項目にのぼった。
１．企業を取り巻く環境
２．ERP パッケージとは
３．ERP パッケージの特徴
４．なぜオラクル E-Business Suite を選ぶのか？
５．オラクル E-Business Suite の機能とビジネス機能との関連
６．オラクル E-Business Suite 導入のキーポイント
７．オラクル E-Business Suite の KFS（成功のためのキーファクター）z

業務プロセスの改革z

顧客にとって価値を生まない付加的な仕事の削減

８．今後の進め方
９．オラクル E-Business Suite 導入提案の検討
各項目詳細については Exhibit3 参照。ナニワ経営陣は、標準的なオープン・イン
ターフェースが欠如した、独自のアーキテクチャを持つ既存のレガシーシステムに閉塞感を募らせていた。各部署は独自のアプリケーション、独自のデータを持っており、主要顧
客とのやりとりの際、異なる課同士でデータをアクセスするのに途方もない時間や労力を必要としていた。ERP システムは、業務全般にわたり即時性・透明性のあるデータが行き来するオープン・ネットワーク、そしてクライアントにとってオープンなインターフェースという明るい材料を持っていた。つまり ERP の主な魅力とは、ビジネス構築に必要な最新のインフラ提供にあった。親会社はかねてから多数のユニット部門を切り離しナニ
ワに移してきた。これが深刻な統合化問題を生み、その結果、統一化に向けた ERP への魅力を高めた。

Doshisha Business Case 05-01

4

ナニワハイテク: ERP 実装事例
ロバート・コール

取締役会への提案は、新インフラ構築や会社規模での統合強化にとどまらなかっ
た。ERP導入は情報技術を戦略目的に利用出来ると強く主張した。これら戦略目的とは、金融決済システム、および製品の製造から顧客発送までの一連の売上予測工程、の双方を含む受注業務の合理化をさす。ERPが、各プロセスの短縮化とそれらの並行作業化により、販売計画から製品配送までの様々な業務プロセスを統合する手段となりうることが期待された。
興味深いことに、取締役会への最初のプレゼンには価格見積が盛り込まれていな
かった。しかし各モジュール取り付け開始前に、実装チームは価格見積表を提示し、経営陣の承認を仰いだ。実装コスト内訳見積りについては Exhibit4 参照。
提案が取締役会で承認されるやいなや、ERP 計画部隊は実装に必要なインフラ構
築にとりかかった。ここでの計画は、まず国内諸工場に照準を合わせ、順に特定モジュー
ル（財務会計、販売、製品管理、在庫管理）の段階的導入を行うことだった。
戦略方針を定め、プロジェクト進捗状況を監視し、緊急の問題や障害に対応し、全てを軌道に乗せるべく、運営委員会－「製造管理標準化委員会」－が各工場に設立された。戦略目標は 7 項目。
１．需要・供給調整および生産計画機能の強化
２．計画生産（ストック生産）から受注生産へ製造システムの移行
３．社内情報システムのシームレス化
４．製造・調達にかかるリードタイムの短縮
５．物流の合理化
６．製品モデルの統一化、デザインの標準化、部品数の削減
７．売掛金回収のスピードアップ
静岡工場の運営委員会メンバー構成は、工場内で最も関連のある部署から部長が 5 名、本社から 3 名、そして生産本部長が 1 名。これはかなり典型的なメンバー構成で、ナニワの他施設でも採択された。
「作業ワーキンググループ」と呼ばれる実装チームも各工場に設置。要となる静岡工場では、ナニワ本社から 4 名、静岡工場から 20 名の計 24 名のメンバーで構成された。
静岡工場のメンバーは主要部署のキーマンたちで、20 名のうち 8 名（製造部門 2 名、生産計画部門 2 名、調達部門 2 名）はまさに実働中核部隊であった。
実装チームに加えて 22 名の IT スタッフがプロジェクト専任プログラマーに任命された。その内訳は静岡工場 10 名、そして親会社の IT スタッフ 12 名である。
親会社派遣の 12名は親会社でのERP実装に携わったスタッフで、当時その努力は完全には実らなかったものの、彼らの知識はナニワでの実装において不可欠な役割を果たした。事実、彼らのおかげでナニワは、ERP実装のためにシステム・インテグレーターを雇うという、日本に典型的な習わしを行わずに済んだのである。ERP実装成功例がほとん
ど見あたらない日本のビジネス環境の中で、比較的初期段階での導入者であるナニワでは、
彼らを教育するという重要な役割を、親会社経営陣が担っていた。ナニワ幹部社員は自分達こそがERP導入の先駆者であると自覚を持っていた。彼らの「先発者」としての役割は、国内の競合企業に対し、戦略上の圧倒的優位を約束するものだった。この開拓的役割はさDoshisha Business Case 05-01

5

ナニワハイテク: ERP 実装事例
ロバート・コール

ることながら、しかし実際のところ、成功のためのキーファクター（KFS）が一体何なのか、実装の開始時点でまだ掴めていないことを、キクチは認識していた。
親会社の IT スタッフに加え、オラクル社員数名もこの実装チームに密接に関わった。ERP パッケージ機能を熟知している彼らは、作業面での重要な知識を提供した。導入された ERP モジュールは、ナニワの経営に必要不可欠な機能をいくつかの重要分野において欠いているという理由で、「標準仕様」（現状のまま）のシステムとして開発するのは難しい、と彼らは説明した。つまり相当のカスタマイズが必要だと。
課題は山積みだった。タイトなスケジュールの中での ERP パッケージ実装だけでも、多くの企業に失敗を招いた主要因だった。加えてナニワは、前述 7 項目の戦略目標に実装を組み込むことを目指していた。さらに、この期に及んで親会社が工場の移転、またそれと並行しナニワテックへのスピンオフなどといった再編を決定したことが、実装プロ
セスをより複雑化した。
保守部品および販売部門における販売モジュール、在庫管理モジュールの導入がまずまずの成功をおさめると、社は 1999 年 1 月までに静岡工場へ ERP を実装することを決定。工場では、同年 10 月「始動」に向け生産計画モジュールを導入するという厳しい
スケジュールが求められた。Exhibit5 は実際の実装成果を示している。経営陣は先手を打ち 1998 年 11 月からプラニングを開始しており、その甲斐あって、1 月にゴーサインが出た時点では「即時フル稼働」ができる状態であった。その準備のほとんどは、既に ERP
実装済みの親会社の現場の情報収集に費やされた。
急遽設置された運営委員会は、前述と同様の主要戦略目標を発表した。取締役会の承認に基づき、全従業員がこの実装に賛成するものとみなされた。7 月には、より多くの経営陣の理解強化のため、管理職クラス（大部分が課長、部長は数名）に対し ERP に関する半日の理論実習が実施された。
作業ワーキング・グループ（実装委員会）もまた急遽設置された。プロジェクト開始を受けて、彼らは即座にプロトタイプ開発および ERP 機能の検討にとりかかった。
これと併せて「試験的会議室(Conference Room Pilot)」も設置された。これは ERP で何が出来るのか、そしてその実現には何が必要なのかをナニワ IT チームに見せるための評価サイトとして作られ、つまり ERP モジュールの妥当性を確認するものである。主要パラ
メータ（操作属性）をいくつか設定し、小規模な試用モデルを実証し、それにより ERP
生産計画モジュールを検証するという基本アプリケーションで、IT チームがパッケージ
機能を確認するためだけに作られたプロトタイプである。
テストサーバー導入にはソフトウェアの環境設定、つまり主要パラメータの初期設定も含まれており、これには IT チームと実装チーム主要幹部らとの緊密な共同作業を要した。連続生産でなく個別生産を選択する、また必要となるセキュリティー・レベルを確定する、といった課題が生じていた。（環境設定とはシステム自体をカスタマイズせずに調整するもので、将来的なアップグレードの妨げにはならない。環境設定については全てオラクル社のようなベンダーにフルサポートされている。）
次の段階は、システム設計（機能プロセスの定義）である。このためにはシステ
ム要件を特定し、ERP対象範囲および開発予定の拡張範囲（増設およびカスタム化を含む）を定める必要があった。この作業に欠かせないのは、生産計画モジュールをどれくらい変更することになるかの見極めである。目標達成の鍵を握る非常に重要なステップだが、Doshisha Business Case 05-01

6

ナニワハイテク: ERP 実装事例
ロバート・コール

これについては既に事前決定が下されていた。オラクル社の製造計画モジュールは幾つかの主要分野で機能不足があり、ある程度の修正（カスタマイズ）およびセットアップ作業が急務だったからである。
システム要件の決定作業は、実装委員会メンバーから必要機能のリストを提出してもらうことから始まった。メンバーは指示を受け、各自ユニット部門に戻り、現場の人員に必要情報を求めた。
メンバーの中には非常に入念にこれらの情報を集めた者たちもいたが、多くは現場で必要なものは既に理解できているとして、単に自らの見解を述べるにとどまった。実装チームリーダーのヨネダ氏は、エンドユーザーに要望書を依頼したところ、彼らの仕事の簡略化を目的とするような結果が返ってきたとの問題点を指摘している。これでは、現場で現行作業プロセスが維持され、せいぜいわずかの「改善」をもたらすだけのために
ERP パッケージをカスタマイズする、ということになってしまう。
要望書が集まり、その中の要望とパッケージソフトのスペックとのギャップを特定すると、次なる仕事は要望事項の適合性評価である。莫大な数のカスタマイズ要望に応えるため、委員会は週会議のほとんどの時間をその対応に費やした。3 月に入ると、彼らは稼動開始までに残っている就業時間を計算し、そこから、プロダクト・サーバー導入やネットワーク構築、クライアント環境、プログラム開発及びテスト、システム構築、デー
タ・アップグレード、そして検証プロセス等の作業に要する時間を差し引いてみた。これは時間厳守の中でどれだけカスタマイズに時間を費やせるかを算出するものだ。彼らは各々のカスタマイズ要望にかかる実装必要時間を計算し、苦渋の決断を行った。
優先順位付けは難航を極めた。カスタマイズ要望の良し悪しを決定する簡便な判断基準などどこにもなかったからである。実装チームは週会議での徹底的な議論の後、本決定を下していった。IT 開発者たちもこれらの審議に情報を提供した。
しばらくして会社は、カスタマイズの合意を得た、一見とるに足らないビジネス
業務が、実は戦略目標達成の大きな障害物となっていることを発見する。これを知り、キクチはこう言った：「私は聖徳太子じゃありません」。また、彼らが行ったカスタマイズ
は、後続のアップグレード・コストを増やし、システム維持にかかる膨大な手間や労働時間も必要とした。経験未熟な彼らにとって過度のカスタマイズは致命的だと悟ったときには、それがどれほど巨大なものとなるのか想像も出来なかった。データ入力とエンドユー
ザー画面については、完全カスタマイズが行われていた。古参の労働者および契約社員、派遣社員同様、彼らはデータ入力を簡略化しなくてはならないと感じていたのだ。
調達部門はカスタマイズ要求を最も強く要求した部署である。この部署は多くの社外ベンダーと取引があり、彼らに全ての変更説明を行うのは大変面倒な作業だと主張していた。ここは「業務の親玉」と自認する部署で、業務の標準化というものは皆無に等しかった。彼らの要求全ては通らなかったものの、かなりのカスタマイズが行われた。明らかにそれは「作業ワーキンググループ」中核メンバーのうち 4 名が調達部門出身だったからである。言い換えれば、標準化によって一番恩恵を受ける部署が、逆にかなり反対したことになる。キクチはこの好ましからざる結果を批判し、必須構成属性を定義する共通言
語なしには大量購入などの潜在的利益保証は厳しくなる、と冷静に言い放った。
ナニワはこれらの経験をふまえ、静岡以降の実装ではカスタマイズを次第に減らしていった。事実彼らは上海新工場で、オラクル社の後続 ERP パッケージソフトの機能

Doshisha Business Case 05-01

7

ナニワハイテク: ERP 実装事例
ロバート・コール改善とその環境設定機能（拡張可能アーキテクチャ）の増強により可能となった基本仕様のアプリケーションを使用した。中国人は管理者・従業員双方とも作業の歴史が浅く、その工程を維持する上での既得権益が生じていなかったことも、基本仕様モデルの導入を後押しした。
ERP パッケージに不可欠なルーチンの導入を拒むもう一つの因子は、社員らが、電話連絡や非公式な会合など、自分では効率的だと思っている処理方法に慣れてしまっていた点である。そのため彼らはデータ入力に必要な時間や所定方法に沿って処理することを煩わしく思い、効率が下がると当初は批判していた。
しかし一方で、ナニワ経営陣が既存のレガシーシステムの完全撤廃を決定したことにより、ナニワでは、他社とは比べものにならないほど実装が容易になっており、結果として新旧システム統合にかかる莫大な時間と資源が不要となった。
次の段階はインターフェースおよび修正デザインの完成である。これはアプリケーションのインストール、修正、そしてモジュールにつなげるアプリケーション・プログ
ラミング・インターフェース（APIs）と呼ばれる標準インターフェースの使用承認を受け必要となるアドオン（カスタマイズ）開発である。
ここに至るまでは常に、これに携わる全ての人々の不満に決着を見るための模索の繰り返しだった。販売部門との間で重要な問題が発生する。ERP が導入されると、販売部門は大量の情報をシステムに入力しなくてはならず、彼らはそれが重荷だと訴える。
もちろん ERP は、そのデータに全社員がアクセスすることを可能にし、可視性とスピードという意味において、企業にとっては大きな利益をもたらす。しかし販売部門は自分の負担しか考えない。彼らには、これをもっと広く企業全体の利益の代償として受け入れてもらわなければならない。当然、彼らに担ってもらう負担にも限界がある。例えばシステ
ムに関する初期のやりとりで、販売部門の社員らは反応速度が遅過ぎるとクレームをつけた。顧客に発送納期を即答しなくてはならないのに、データが出てくるまでパソコンの前で何時間も待つわけにはいかない、と彼らは言う。こういった様々な問題について、チームは幾度となく会議を開き、議論を重ね、システム向上の利点と販売部門側のコストとの折り合いがつくラインを探った。最終的に妥協案が成立した。
これらのカスタマイズが確定し、会社はシステム構築段階に移行する（Exhibit5：
6，8，9，10，11 段階参照）。ここでの使命は、きちんと動くシステムを作ることだ。これには、システム設計完了前に行われるプロトタイプの設定完了を含む。この時点までプ
ロジェクトは予定通り進行していたが、プログラム開発及びテスト、手順およびエンドユーザー・マニュアル作成の段階に入ると、完成予定日が後退しはじめた。遅延の原因は現場作業の不備およびユーザー・マニュアル準備の遅れである。稼動開始 1 ヶ月前、エンドユーザーは 1 日 6 時間、3 日間に渡る新システム研修を受けた。
1999 年 11 月、システム稼動開始。予定の 1 ヶ月遅れではあったが、それでも偉業を達成したといっても過言ではない。多くの企業同様、静岡工場では初期段階で経営成果が落ち込んだが、約 1 ヶ月で以前と同水準に戻った。落ち込み理由の大部分は、ERP 以
前の週ベースから、ERP 導入後の日ベースへの変化による部品選定に起因していた。これに対応するには多くの調整が必要だった。

Doshisha Business Case 05-01

8

ナニワハイテク: ERP 実装事例
ロバート・コール結果
前述した戦略目標の中で優先度の最も高かった課題は、月ベースの「プロダクトアウト」を、週単位の「マーケットイン」情報に基づいた受注生産システムに移行することであった。1999 年 11 月の稼動開始と同時に、週ベース「マーケットイン」製造に切り替えた。これは重要な功績である。
ノーブランド商品については計画製造が十分機能していたが、大企業顧客への特注生産では巨大なリスクを抱えていた。ERP 導入以前、会社は完全計画製造を行っていたが、2003 年末には受注生産 5 割にシフトしている。これは広範囲にわたるビジネスを行った結果がもたらした、特筆すべき変化といえよう。
静岡工場の従業員は週ベース製造への移行により難問に直面していた。彼らは月ベース製造の旧システムが気に入っていたのだ。彼らから見れば、週単位の製造計画は作業効率を損ねるため最善の策ではなかった。材料・部品の仕入が少量単位になり、コストが割高になった。週ベース製造では頻繁な予定変更が必要で、その結果、変更コストも上
昇し、欠陥品率を増加させた。
新システム下で最適化を行うには、一連の組み立てラインからセル生産方式へのシフト、つまりトヨタ式製造システムに移行すべきだと思われた。彼らはまた、業務効率化のため、幾つかの業務を子会社から工場に戻した。これが製造時間を短縮し、欠陥品を減少させた。製造合理化のため、彼らは、部品の統一化や不要なバリエーションの減少（つまり実際の顧客ニーズに基づいたデザインの多様性と、社員のニーズやプロとしての好みを満足させるためのデザインの多様性とを区別すること）をエンジニア達に説得した。
この分野においても彼らは確実な進歩を遂げた。全ては血のにじむような努力の賜物であり、これらの多くは始動後、新 IT 性能を巧みに利用しようと考えるナニワ経営陣のもと達成されたものである。1986 年、社はトヨタシステムに学ぶための委託契約を交わし、現在に至っている。
工場専心型経済に執着する製造部門の社員達は、キクチとそのスタッフが推し進めた方向性にしばしば抵抗を示した。だがキクチの視野はサプライチェーン全体の最適化にある。様々な改変の結果、全社における開発コストは 2000－2003 年に 39％強の削減となった。在庫回転率および資産収益率（ROA）も 1999 から 2002 年の間にそれぞれ 30％、25％改善された。キクチ曰く、これらの改善は静岡工場のみならず、他の国内工場でも同様に見られるERP実装および業務改革の効果である。言い換えれば、部門単体だけでなく全社的な最適化を進める中で、ERPがこれらの改善・向上を可能にする「バックボーン」を作り上げた、とキクチは確信している。ERP実装以前、販売・製造・開発に関する情報は各部門内で保管されており、それぞれ異なるITシステムが使用されていたため、会社単位での集計は数日を要した。現在では企業内のどこからでも同じ情報を瞬時に入手できる。
今、ITは過去 10 年間において生産性に何の役にも立たなかったと公言している専門家た
ちに、キクチはほんの少しの同情も覚えない。彼らは 1990 年代後半の理不尽な期待の犠牲者なのだから。
取り組むべく難問はまだ多い。全ての業務にこの原理を拡張すること、そして製造・販売・マーケティング分野のグローバル・ネットワークの組み込みが重要課題として残っている。販売部門の社員達は、全社規模のトータルな展望には未だ半信半疑である。
彼らは顧客に即時発送できるよう製品をストックしたがるが、これは非常に高くつくやり

Doshisha Business Case 05-01

9

ナニワハイテク: ERP 実装事例
ロバート・コール方だ。この方法では、顧客が 1 週間もしくはそれ以上でも待てる商品と、翌日には欲しいと思っている商品の区別がつかない。販売部門の人間は、製造部門の納期確約を信用していないため、事前に製品を在庫として持とうとする。これらは全て早急に手を打たねばな
らない問題だ。
しかし、さしあたってキクチ氏は、ナニワ社 ERP 実装経験から何を学んだかを考えているところだ。さほど IT を使用せずとも、あるいはカスタムパッケージ構築を選択していたとしても、同じ結果を得られたはずだと豪語する批判者たちに、どう対応しようか悩んでいた。ことに、今度また別の主要子会社で同様の実装イニシアチブを親会社から頼まれた場合、何を同じくして、何を変えたらいいのだろうか、と彼は思いを巡らせている。

Doshisha Business Case 05-01

10

ナニワハイテク: ERP 実装事例
ロバート・コール

Exhibit 1

ＩＴ関連アプリケーション導入率の国際比較
(%)
100

80

米国

ヨーロッパ
60

アジア

40

(NIEs)
20

日本

0
CAD

ERP

SCM

CRM

KM

EDI

（注）: CAD 数値は製造業、SCM 数値は製造、卸売、小売業、その他は全産業を表す
出典: 経済産業省「企業の経営情報戦略に関する国際調査」

Doshisha Business Case 05-01

11

ナニワハイテク: ERP 実装事例
ロバート・コール

Exhibit 2

IT導入と平行に行われる組織改革の国際比較
(%)
80
米国

60

40
ヨーロッパ

日本

20
アジア
(NlEs)

0

組織のスリム化・
フラット化

組織の下位レベルへの機能横断型チームの活用

ITソフト導入に向けた組織変更

権限委譲（注）: 数値は全ての産業を含む
出典: 経済産業省「企業の経営情報戦略に関する国際調査」

Doshisha Business Case 05-01

12

ナニワハイテク: ERP 実装事例
ロバート・コール

Exhibit 3

ナニワハイテクに対する ERP の提案サマリ
1998 年 4 月
情報システム部門提出
1. 企業を取り巻く環境急速に変化するビジネス環境では、我々自身も変化しなければ生き残れない!!!
2. ERP パッケージとは
ERP (Enterprise Resource Planning) とは 、「効果的なマネジメント」の観点からリソースを効果的かつ効率的に利用できるようにまとめて管理を行う手法／コンセプトである。製造から営業までサプライチェーン全体をカバーする新しいビジネス統合システムである。
3. ERP パッケージの特徴①

グローバル・ワールドワイド標準のビジネスプロセス機能を備える。

②

ビジネス統合システム→機能をリアルタイムに統合 → サプライチェーンの強化③

ERP を利用した社内ビジネスプロセスのリエンジニアリング (BPR)④

パラメータ設定による短期での導入・開発↓

将来のビジネス環境の変化に即応可能。オラクルの E-Business Suite は将来、会社が要求し得ることをスケーラブルに実現。
4. なぜオラクル E-Business Suite か？
♦グローバルに事業移管が容易♦

オープン化対応（EDI、EC 対応）♦

既存の 1 部門 1 システム（タコ壷型アプリケーション群島）からの脱却♦

サイトにまたがり区分された情報システム(IS) を統合

Doshisha Business Case 05-01

13

ナニワハイテク: ERP 実装事例
ロバート・コール

5. オラクル E-Business Suite の機能とビジネス機能との関連

受注

回収

計画

完成

生産計画

注文

調達

生産能力
計画

支払

調達依頼

集荷
出荷

所要量
計画

注文
MS/MRP

＊

納品受領
請求
回収

生産

原価計算
検収

在庫管理

支払
オラクルデータベース＊MRP(Material Resources Planning)＊MS(Master Schedule)
6. オラクル E-Business Suite 導入のキーポイント
下の階層の従業員の方向性を設定するトップマネジメントの意識を変える。これにより、何を目指し、目標の達成に何をすべきか、どのようにするのか、いつまでになどを明確化できるようになる。
ビジネスプロセスのリエンジニアリング(BPR)を実現
ERP 採用により、IT をいかに戦略的な経営手段として活用するかを明らかにする。

7. オラクル E-Business Suite の KFS (成功のためのキーファクター)標準のプロセスとシステムを通して全てのシステムを統合することに重点をおく。これにより、（従業員の）意識と組織が改革される。

Doshisha Business Case 05-01

14

ナニワハイテク: ERP 実装事例
ロバート・コール♦

業務プロセスの改革
現状

リニアプロセス

事業方針→販売計画→調達計画→生産計画→流通計画
改革後

コンカレントプロセス（各プロセスの短縮化）→ 販売計画 →事業方針→ 資材計画 → サイクルの短縮→ 生産計画 →→ 物流計画 →♦

顧客にとって価値を生まない仕事の削減①

部門間の調整②

間違えの訂正③

レポート④

在庫の抱え込み

8. 今後の進め方♦♦♦

経営目標の設定①

リードタイムの短縮②

間接部門の人員削減 (例：中間管理職)

完全削減①

既存組織の重複

②

管理のムダ

③

業務のムダ

現状の分析を実施し、将来の「 在るべき姿」を描く

9. オラクル E- Business Suite 導入検討（提案）
生産管理の改革と情報システムの再構築のための 「 プロジェクト編成」♦

プロジェクト編成¾¾

名古屋支社（情報部門）… ワーキンググループ


需給計画、調達、生産から 3 名

本社情報システムから 2 名

静岡工場 … 「 生産管理業務改革ワーキンググループ」を既に設置¾

本社情報システム参加

作業内容 …一連の分析により「 在るべき姿」を策定

Doshisha Business Case 05-01

15

ナニワハイテク: ERP 実装事例
ロバート・コール

♦

生産管理標準化委員会 (ステアリング委員会)¾

メンバー:
生産本部長 (リーダー)
製造部門長
本社情報システム部門長¾

以下の標準化の分析:
ビジネスプロセス
IT システム¾

情報システム化計画の策定期待される結果①

一気通貫の経営を支援
外部の協力会社との密接な情報連携を軸に、資材調達から製品販売まで全てのビ
ジネスを一気通貫に支援②

リアルタイム経営を支援
世界中の生産拠点の状態を把握 （部品在庫, 生産状況, その他.)③

まとまりのない情報システムの統合化

Doshisha Business Case 05-01

16

ナニワハイテク: ERP 実装事例
ロバート・コール

Exhibit 4

ナニワハイテクにおけるERP実装コスト見積り内訳

ハードウェア

ソフトウェア

26%

14%

要員人件費

システムインテグ

20%
レーション40%（注）: 上記見積りは実装チームの主要メンバー及びプロジェクト専属のＩＴ担当者以外の人件費を含まず。

Doshisha Business Case 05-01

17

ナニワハイテク: ERP 実装事例
ロバート・コール

Exhibit 5

ERP 実装スケジュール（結果）

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

プロジェクト開始
サンプル・プロトタイプ完成
ERP 機能調査完了
テストサーバー導入
機能プロセス承認
プロトタイプ設定（セットアップ）完了
インターフェース及び修正デザイン完了
プロダクションサーバー導入
ネットワーク、クライアント環境完成
プログラム開発及びテスト完了
手順マニュアル及びエンドユーザマニュアル完成
インテグレーションテスト完了 最終判断
データ変換完了
稼動開始 Go Live!

Doshisha Business Case 05-01

1999 年 1 月上旬
1999 年 2 月中旬
1999 年 2 月下旬
1999 年 3 月下旬
1999 年 4 月上旬
1999 年 5 月下旬
1999 年 5 月下旬
1999 年 6 月下旬
1999 年 7 月下旬
1999 年 8 月下旬
1999 年 9 月下旬
1999 年 10 月中旬
1999 年 10 月下旬
1999 年 11 月上旬

18