【製造業の基幹システム #8 ERP導入会社の選択】

私はERPを扱うSI会社からERPの経験を開始し、複数のERP開発元に属して現在に至ります。その中で数多くのERP導入会社やコンサルタントに接してきました。ERPはセミオーダーのスーツみたいなものですから、最後の仕上げをする会社（人）によって出来あがりは大きく異なります。

また、その会社（人）の優劣ではなく、自社（自分）にとって最適な会社（人）を選択することが非常に重要になります。

 

スーツに例えると、

・自分の好みをくみ取ってくれ、自分に合った色や形を提案してくれる会社（人）

・自分の色や形に対するこだわりを忠実に再現してくれる会社（人）

・縫製技術に優れている会社（人）

・安く仕上げてくれる会社（人）

・早く仕上げてくれる会社（人）

・話が面白い会社（人）

などの会社（人）がいます。全てが満たされるような会社（人）はいません。なぜならば1番目と2番目の項目は相反する項目だったりするからです。

そこで必要であるのは、「自分にこだわりがあるかどうか？」です。

あなた

「来月妹の結婚式がある。くたびれたスーツしか持ってないからボーナスも出たことだしスーツを新調するかな」

と思ったとしましょう。いきなり紳士服の○○に行きますか？デパートの紳士服売り場に行きますか？それともインターネットで情報収集しますか？

人によってそれぞれかと思います。

スーツにこだわりが有る人であれば、自分の思い描くスーツを仕立ててくれる店に目星がついているか、もしくは下調べをするでしょう。

スーツにこだわりが無い人であれば、とりあえず店に行って店員のお勧めを直ぐに購入するかもしれません。

どちらも正解です。

不正解は、スーツにこだわりがあるにも関わらず下調べもせず飛び込みで店に入って、馴れ馴れしい店員に安っぽい生地やボタンを薦められ「私が欲しいのはこんなスーツじゃないのになぁ・・・」と思いつつ買ってしまうか、もしくは店を出て時間を無駄にすることです。

その逆も不正解ですね。こだわりがないのにサッサと買わずに店員とのムダ話で時間を無駄にすることです。こだわりがある人が行くような店では無い限り、店員は売り手の論理で薦めているだけだと言うことに気付くべきです。

ERPの導入会社やコンサルタントも同様です。何でもいいから早く安く仕上げたいのか、こだわりを持ってERPを導入したいのかにより相談、委託する会社（人）は異なります。

また、セミオーダーのスーツでもERPでも「安価」「高価」には必ず理由があることを肝に銘じておく必要があります。

【製造業の基幹システム #7 計画系システム】

私は製造業向けERPに関連する仕事に従事していますが、一般論としてERPは業務管理系のシステムであり、いわゆる「計画系」と呼ばれるシステムは別途構築する場合も多いかと思います。

狭義での「計画」機能はEnterprise Resource Planningという名の通り、ERP本体で需給計画や資源計画機能などを有しているかと思いますが、一般消費財の需要計画や複雑なグローバルサプライチェーン計画、計画の策定と評価や分析などには、各々の計画専用のシステムを活用することにより、より最適な「計画」を自動的に立案することも進んでいるかと思います。

・生産計画（APS、Planning、Scheduling）

・プロジェクト計画

・配送（配車）計画

・購買（調達）計画

・（最適）在庫計画

・販売（需要）計画

・人員（配員）計画

・設備投資計画

・・・まだまだ沢山の○○計画がありますね。 

また、これらの計画機能をERP本体に有していたとしても、あえてERP外で計画した方が良い場合もあるかと思います。

例えば、

・複雑なシミュレーションを繰り返す為、ERP全体のパフォーマンスに影響を及ぼす

・商流や生産に直接関係しない人員計画

・ERPで詳細定義をすると山のように会計仕訳を生成する

のような場合、計画機能はERPの外で処理した方がよいかもしれません。

要するに、ERPの導入にあたっては、

・ERPにはより確定に近い状況のデータを処理する（現場を混乱させない）

・ERPには在庫、会計に関わるデータを処理する（ムダなデータを蔓延させない）

・ERPは幹の業務プロセスを管理する（枝葉をキレイに剪定する）

という基本指針が必要です。

ひと昔前は、これらの計画系アプリケーションとERPとの連携がネックとなっていたりしましたが、昨今ではアプリケーション連携技術も急速に発展、標準化されてきました。また、様々なアプリケーションをひとつのアプリケーションの様に「見せる」技術も発展し、「色々なアプリケーションを使い分けるのも面倒くさいなぁ」ということは減っているかと思います。

また、製造業向けERPに関しては、ERPで莫大な部品のMRPを回すと処理時間がかかるので、MRPだけ外出しのオン・メモリ高速MRPで処理するようなことも盛んに行われていました。これも昨今のオン・メモリDBの発展などによりERP自体が高速化していますので、単に高速化だけを実現するアプリケーションは衰退していくでしょう。

そのようなシステム的な制約よりも業務的な役割分担によりERPと計画系アプリケーションとの分担を決定することが多くなってきたからこそ、各計画系アプリケーションの本質を見極める必要性が高くなってきました。「早い/遅い」「出来る/出来ない」よりも「本質的にどちらで処理すべきか？」ということです。

すなわち、ERPを「精度が高い業務データを矛盾、重複なく流す」ことに徹し、それ以外の「流れない（行き先が無い）データ」「グルグル回っているだけのデータ」「ある時点のみをとらえたデータ」はERP外で管理すべき、だと私は思います。

【LNよもやま話 #13 MIRACLEから歴史が始まるLN技術】

LN関係者で、「MIRACLE」を知っている方は少ないのではないでしょうか。TritonやTrimcs、BMCSなどはこのブログにも書きましたが、MIRACLEについては未だどこにも書き起こしたことがありません。個人的には、このMIRACLE（Machine Independent Risc Architecture Computer Language Environment）が無ければ現在のLNは無かったと思っています。 

ERPが普及した現在においても、グローバルで生産管理分野をERPで統一、統制している組立製造業は多くありません。それはなぜでしょう？

装置産業、プロセス製造業と比較すると、組立製造業の工場は、小規模であり、新設/移転が多く、製品/生産設備は一定ではありません。20年前と同じ場所で、同じ設備で、同じ部品を使って同じ製品を作っている組立製造業は亀の子たわし・・・他に何かありました？

そのような様々な環境変化に追従する必要があり、グローバルでシステム統一、統制することが一番難しいのが、組立製造業の生産管理システムだと思います（←人事給与や税金系などの国ごとに規制・法令対応が必要なシステムはさておき）。

さて、ここで「MIRACLE」の登場です。LN生みの親であるBaan社はハードウェアやOSに依存しないアプリケーションを作ることを第一義に掲げ、各社UNIX上で動作する開発環境を作りました（※）。これが「MIRACLE（Machine Independent Risc Architecture Computer Language Environment）」です。開発言語は「Baan 4GL」というC言語を発展させた独自言語です。データオリエンテッドな開発ツールで、データ構造を定義することにより、画面、帳票、グラフなどのプログラムを自動生成します。同時期にも様々な開発ツール（言語）がありましたが、その中でもMIRACLEのシステム開発生産性は非常に高いものでした。

（※）オランダで業務コンサルタントをしていた創業者Jan Baan（ヤン・バーン）は、渡米した際に黎明期のUNIXに触れ「これからはオープンシステムの時代が来る」と、一気にソフトウェアベンダーへかじ取りしました。

その後、Baan社がERP第一弾のTRITONをリリースした時、既にMIRACLEはバージョン4.3でした。LN関係者はピンときますね？

それゆえに、LN（業務系機能）はEnterprise Server（システム基盤）と各々のバージョンが違うのです。LNの最新バージョンは10.3ですが、システム内部のバージョンはLN :B61a9、Enterprise Server:7.6a9です。わかり易く言うと、6.1と7.6です。

ちょっと話が散漫になりましたね。

この、MIRACLE改めTriton Tools改めBaan Tools改めLN Tools改め、LN Enterprise Serverの仕組みにより、5ユーザー（小さなWindowsサーバー）から数万ユーザー（UNIXハイエンドサーバー）までのスケーラビリティがあり、小さな町工場から巨大な工場までを、ひとつのERPでカバーできるのです。

【LNよもやま話 #12 Porting Setって何よ？】

このブログは「Porting Set」という検索キーワードで訪問されている件数が多いので、今回は「Porting Set」特集です。

「LNバカ（Baanバカ）」の私は「Porting Set」って一般用語だと思っていましたが、「Porting Set」で検索するとLN関係、Baan関係ばかりヒットします。

LNのPorting Setの「Porting」も基本的には一般IT用語の「ポーティング」と同義です。すなわち「移植するためのセット」です。LNはWindows、UNIX（IBM-AIX、HP-US、Oracle-Solaris）、Linux（SUSE、Red Hat）で動作します。かつては、Tru64 UNIXやAS/400、OS/390、Z/OS、DYNIX_PTX、ReliantUNIX（SINIX）、IRIXなどでも動作しました。また、データベースとしてはOracle DB、SQL Server、Informix、DB2が使用できます。かつてはSybaseやBisam（Baan社製DB）なども使用できました。これらのOS/DBの組合せごとにLNを動作させる仕組みが「PortingSet」です。

これらのOSおよびDBに依存する機能（コンパイラ、帳票出力制御、SQL、など）のみをLN本体から切り離して独立させていますので、OS/DBの組合せごとにPortingSetは存在します。また、OS/DBのバージョンごとにもPrtingSetが存在します。

・・・ということは、、、賢いあなたは気付きましたね？

・UNIXで動作しているLNをWindowsへ移植する

・Windows 2003で動作しているLNをWindows2008環境へ移植する

・Oracleを使っているLNをSQL Serverへ替える

ということが、PortingSetの入れ替えだけで行うことが出来ます。

・・・もっと賢い方は、こういう疑問をもったかもしれません。

・古いバージョンのLN（Baan、Triton）も最新のOS/DBで動くのだろうか？

正解です。なんと1996年にリリースされたTriton3.1bがHP-UX 11i v3とOracle11gR2で動作します。実際に某日本のお客様において、15年以上前のバージョンが数度のハードウェア（OS/DB）の変更を経て使用されています。

世の中に蔓延している「ERPって入れる時も大変だけど、バージョンアップも大変だよね」という都市伝説に対して、LNは「じゃあ、ERPをバージョンアップしなければいいじゃん」と言えるのです。

次号では「MIRACLE（Machine Independent Risc Architecture Computer Language Environment）から歴史が始まるLN技術のマニアックな話」を書こうかと。。。この号の続編になります。

【LNよもやま話 #11 1カ月でBaanを稼働した事例】

プロジェクト・キックオフから約１カ月で本番稼働した事例は日本ではもちろん、海外でも稀有な事例だと思います。このプロジェクトに最初から本番稼働まで関わっていた生き証人として、本番稼働までの過程をご参考までに記録に残したいと思います。

＜プロジェクト概要＞

・海外に本社を持つ、オフィス用品Web通販の会社
・本社では既にBaanを使っていた。既使用の倉庫管理パッケージやWebポータル（自前開発）を日本でも利用。
・4月頭からBaan導入プロジェクト開始、GWに営業（本番稼働）開始。
・社外のコールセンターを利用。
・Webポータルから入ってくる顧客登録情報、注文情報をBaanに取り込み、Baanから物流委託業者の倉庫管理システムへ出荷指示を行う。
・商品仕入は海外からの輸入もあったが、大半は国内仕入（文具中心）
・海外本社への連結のため、（基本的には）本社指定の勘定科目を使用した会計管理

＜3月＞

お客様来社し「GW明けに商売を開始したいので1カ月でシステムを立ち上げて欲しい」と依頼受ける。
早速、海外のデータセンタへ日本法人用のBaanインストールを実施。

＜4月1週目：プロジェクト・キックオフ＆初期設定＞

常駐メンバーはY氏（会計業務担当）、S氏（販売物流、仕入業務担当）＆私（雑役夫）。
監査法人からも一人常駐し、内部統制などの仕組みを一緒に構築。
新規設立法人でもあり、FIT&GAP分析をやっている時間もないので、デモ環境をそのまま使う感じでパラメータ設定、主要マスタのコード設計＆設定を終える。

＜4月2週目：ビジネスプロセスの設計＆検証＞

綿密に業務設計する時間もお客様の工数も無いので、どんどん進めて、一通りの業務がBaanで動くように完成。
倉庫管理システムとの連携を開発開始。米国のパートナーが開発したBaan自動化ツールを利用して開発（外部開発会社へ委託）。いやあ、これはヒヤヒヤもんでした。
お客様専任メンバーにて品目マスタ（当初は約4,000品目で営業開始）の整備を開始。一日中Excelにデータを打ち込んでBaanに取り込む作業を本番稼働まで繰返し。
実はこの時点で海外本社（日本向けBaan本番機）と日本オフィスの回線が通じてなく、Baanの導入作業は持ち込んだデモ環境（ノートPC）で行っていました。本番稼働まであと2週間なのに。。。

＜4月3週目：システムテスト＆操作マニュアル作成＞

登録された品目を使って一通りの業務をお客様と検証＆トレーニング＆その場で操作マニュアル作成。
海外本社の日本向けBaan本番環境とようやく回線がつながるも日本オフィスからFTP出来ず。Hotmailに移行データや設定情報を添付して、海外のターミナルサーバーに接続し、HotmailからダウンロードしたデータをBaanにインポートし・・・ドタバタですね。

＜4月4週目：統合テスト＆エンドユーザトレーニング＞

BaanとWebポータルや出来あがってきたWMS連携をつかってWMSと連携させて動かしてみた。Webポータル開発はお客様海外本社の方。。。文字化け。。。
同フロアにあるコールセンターまでLANケーブルを数十メートル引いてオペレータにBaanの操作教育。
5月の営業開始に合わせ販促グッズのロゴ入りティッシュをBaanで発注してみる・・・「Webサイトオープン記念！！！ティッシュ5箱パックプレゼント。在庫2,000パック限り」・・・2,000パック発注したはずが10,000パック（50,000個！！！）届き、倉庫に入らない。。。

＜5月１週目：本番稼働＞

日本でのWebサイトを正式オープンし、「初日で数万オーダーとか来たらどーするぅ？」みたいに緊張していたら・・・GWなので注文はぽつぽつでした。

＜5月2週目＞

本番運用支援をしつつ、Baanプロジェクト側メンバーは積み残しの開発作業（月次帳票関連など）を粛々とこなす。

＜5月3週目＞

Baanプロジェクト側メンバーは積み残しの開発作業（月次帳票関連など）を粛々とこなす。

＜5月4週目＞

お客様へ色々引き継ぐ。5月末を持って本番稼働支援も終了。若干の追加開発を残して常駐解除。怒涛の2カ月間でした。

1歩でも後戻りしたら本番開始には間に合わないという中、プロジェクト開始時にイメージした運用、設定、開発を仕様書も何も無く（書いている暇がない）、ワーーーーーーーーーーーっと実現したという感じです。今だと内部統制上問題あるかもしれませんね。

【LNよもやま話 #10 パートナー】

私は様々な局面で「LNを導入するパートナーってどこがあるの？」と尋ねられます。インフォアの公式ホームページ（日本）には、諸事情によりパートナー企業一覧は記載されていません。US本社のホームページ（http://www.infor.com）にはパートナー検索機能があり、世界中の「LN」パートナーを検索することが出来ます。「LN」「Japan」で検索しても、これも諸事情により日本におけるLNパートナーは表示されませんが、それでも世界中の約100カ国をカバーするLNパートナー網があることが分かります。

1997年刊行「SAP革命」（日本能率協会マネジメントセンター刊）には、当時のバーンジャパンのパートナーが日立製作所他、十数社記載されています。
これらが日本における初期のBaanパートナーになります。実際には、これらの会社の下で多くの会社がBaanの開発などに関わっていました。

現時点では「Infor LN」というのが、製品の正式名称なのですが、かつては様々な製品名の変遷がありますので、「Infor LN パートナー」などのキーワードでWEB検索した場合、旧製品名で紹介されているパートナーが検索されない場合があります。
では「Baan パートナー」で検索すると、検索結果の上位はタイのホテルや賃貸マンション、レストランばかりになってしまいます。これは、「Baan」はタイ語で「家」のことだからです。
また「Baan ERP パートナー」で検索すると、現在はInfor LN関連ビジネスを行っていない会社の情報も沢山表示されてしまいます。

これは、現在に至るまで製品名称を数度にわたり変更した弊害かもしれません。ここでもう一度製品名の変遷をまとめます。
2012年以降：　Infor LN
2011-2012年：　Infor10 ERP Enterprise (LN)
2006-2010年：　Infor ERP LN
2004-2006年：　SSA ERP LN
2003-2004年：　SSA Baan ERP
2000-2003年：　Baan ERP（一時期「iBaan ERP」、）
1996-2000年：　BaanIV
1990-1996年：　Triton（日本では「TRIMCS」）

特に近年において、数度の製品名称を行っていますので各パートナーの製品紹介でも旧名称のままになっているものもあります。製品名称が変わっても、基本的なアーキテクチャやコンセプトなどは一貫していますので、もし旧名称で記載されている会社のホームページがあった場合でも、「Infor LN」のことを指していると思って頂いて間違いないかと思います。

また、各パートナーや、Baan社、SSA社でInfor LN（Baan）を経験した後に独立起業された方も多くいらっしゃいます。ERP導入前の前捌きやPMO、アドバイザーとして公正中立な個人コンサルタントをご活用されるもよろしいのではないでしょうか。

※1997年刊行「SAP革命」の表紙に載っている８つのERP（８社のERP開発元）のうち４つが今となってはインフォア社の製品です。インフォア社はどこまでERPを買収し続けるのでしょうか。

【製造業の基幹システム #6 製造業のグローバル・システムの変遷】

ここ数年の製造業の基幹システムの新規実装および見直しの話（私の本業）は、海外拠点の話が非常に多くなってきています。もちろん業種業界によっては随分と前から海外に製造拠点、販売拠点、サービス拠点を設け、とっくの昔に海外売上の方が国内よりも多い企業というのはあったと思いますが、多くの企業においては（どちらかと言うと）海外拠点の基幹システムは（日本から見て）ほったらかしになっていたのではないでしょうか？

 

＜1980年代～90年代前半＞

製造業の海外製造拠点は、自動車関連などに限定され国内向けはともかく、海外市場向け製品も国内で生産し輸出するという形態が主であった。また、海外製造拠点の基幹システムについても、システムらしいシステムは無く、紙、電話、FAX（テレックス）などが主な情報伝達、情報蓄積手段だった。図面、保存帳票などはマイクロフィルムも活用。

 

＜1990年代後半＞

多くの業種で製造拠点の海外進出が進み、海外拠点の情報システムも、アプリケーションやネットワークの発達に伴い、基幹業務のシステム化が推進された。

まだ、グローバルでの情報一元管理や活用を行うには、システムインフラ（ハードウェア、ネットワーク）の性能（費用）がネックになり、拠点ごとにバラバラのシステムやExcelによるローカル管理になっている製造業も多かった。

 

＜2000年～2008年＞

中堅規模の製造業でも、海外に生産拠点を設立したり、海外メーカーと協業、買収したり、グローバル・サプライチェーンの裾野が広がっていった。基幹システムにおいてもシステム・インフラの急速な発展により、グローバル最適化を基本にしたシステム構想を立案し、実現していった。コンサルティングファームやSIerは様々なグローバル・システム展開の方法論、手法、サービスメニューなどを開発したが、「ひとつのERPで統一」という手法が多かった。

 

＜2008年～2010年＞

「ひとつのERPで全世界統一」という手法に対して、コスト、スピード、リスクなどの観点から別の手法を模索するようになった。設備投資の落ち込みはシステム投資にも波及し、その観点からも最小コストで自社に最適な基幹システム構築を模索していた。例えば2tier ERPやベストオブブリード、ハブ＆スポークなど。

海外販社の基幹システムをクラウドで行う会社も出てきたが、海外生産拠点の基幹システムをクラウド化する事例はほとんどない。

 

＜2011年以降＞

データ保有コストが下がったことによるビッグデータの活用やオン・メモリシステムの台頭、クラウドサービスの拡大、ソーシャル・ネットーワークの法人利用など、様々なITシステムの新テーマが出てきた。これは従来のシステム・インフラである基幹業務システムの業務機能的な成熟により、情報システム業界から仕掛けた面もある。

製造業の基幹システムにおいては、拠点進出時にその拠点の将来構想に応じて適切なERPパッケージを利用すること（「ExcelやAccessでローカル管理」をしない）が常識となり、その上で基幹システムに様々な付加価値を求めている。

 

と、ここまで一般論的なことを書きましたが、要するに「10年前の常識は通用しない」ということです。私がERPに関わりはじめた90年台半ばには製造業側にもシステム屋にも「生産システムについて一家言あり」という人が沢山いました。以前の投稿でも書きましたが会計システムは答えがあるが生産システムには答えがありません。10年前までは「こういうおっちゃんがERP導入の障壁になるんだよな～」と生意気なことを思っていましたが、今は「こういうおっちゃんが居なくなったから日本の製造業（生産分野）におけるERP導入が進まないんだよな～」と思います。特に、伝統と歴史ある企業では、現在の生産システムのコンセプトや工場の文化について「俺が全く新しい仕組みを作ってやる！！！」という人をほとんど見なくなってしまいました。そういう時代の流れも日本の製造業の凋落に関連しているというのは言い過ぎでしょうか。

 

次回は、MRPやAPS、SCM、そしてS&OPなど計画系システムの話を書いてみようと思います。

【LNよもやま話 #9 導入テンプレート】

LN最新版には、Content Pack（※）という業務フロー（システムフロー）のひな型をオプションで提供していますが、これは「LNの莫大な機能を漏れなく使う」ために有用なものです。

（※）以前はEBM（Enterprise Business Model：Baan5.0c～LN 10.2.0）、HLM（Hybrid Logistics Model：Baan5.0b）、Reference Model（BaanIV）と呼ばれていました。名称は変わっていても基本的なコンセプトは同一です。

実際のERPの実装においては、LNの機能だけで隅から隅までカバーできる訳ではないので、他のアプリケーションと連携したり、LNの開発ツールを使ってアドオン開発したりします。

よっぽどの変人ではない限りは「毎度毎度同じ機能を開発するよりは、前回作った方ものを流用したほうが楽ちん」と考えますし、「一度作った仕組みを上手く商品化できないか？」と考える人もいるか思います。

そのような理由で、いくつかのパートナーがBaanを「安く、早く、確実に」導入するためのテンプレートを開発しました。代表的なテンプレートをご紹介します。

※このブログは宣伝目的ではないのであえて社名は伏せます。また、ここで紹介したテンプレートは過去に作成されたものであり、現時点での適用を保証するものではありません。個人的な思い出話として捉えて下さい。

＜＜A社のテンプレート「飛龍」（BaanIV短期導入テンプレート）＞＞

A社は、古くからのBaanユーザーであり自社導入事例をベースにした導入パートナーでもあります。自社拠点へのBaanIV導入成功事例をベースに「これ、他にも売れるんじゃないの？？？」というA社側の思いと、当時のバーン日本法人の戦略が一致し「飛龍」という中国っぽい（？）名称で売り出しました。

まずは中国の日系法人へ売りだそうと「中国Baan事例巡りツアー」をやったり、真っ赤な（中国っぽい）販促グッズを作ったり色々やりかけたところでSAAS騒動が・・・。

A社はLNの導入パートナーであり、色々なお客様のプロジェクトに参画しています。今でも、A社のLN導入にはDNAとしての「テンプレート指向」があります。

＜＜B社のテンプレート（Baan5導入方法論＆アドオンパック）＞＞

B社もA社と同様に古くからのBaanユーザーでありパートナーです。B社はエンタープライズアプリケーションに非常に力を入れ、「B社と言えばBaan、Baanと言えばB社」と言われていました。

1990年代、B社はBaanをなめ尽くすように研究していました。前回ご紹介したBaan導入方法論「Target Enterprise」や前述のContent Pack（以前は「EBM」「Reference Model」）についても、マニュアルがぼろぼろになるまで、しかも相当な人数で根ほり葉ほり研究していました。

そしてBaan5ベースのテンプレート（生産形態別業務・システムフロー＆アドオンパック）を完成させました。私は実物を見たことがあるのですが、マニュアルだけでも超大作です。

LNは、単なる業務プログラムの集合体ではなく、コンセプトや方法論に基づいたERPですので上手く導入するパートナー様がいるからこそ、本来の価値が生きてきます。

私も時々「究極のテンプレート」を作ってみようかという衝動にかられます。1人で作ると100年かかるかもしれませんが。

【LNよもやま話 #8 導入方法論】

今回のよもやま話には私見が沢山入ります。

1998年頃、バーン社には「Target Enterprise」という導入方法論がありました。これは、日本語訳され、パートナー向けに販売もしていました。確かCD1枚＋マニュアル数百ページでウン万円でした。

これは、ERP導入プロジェクトのコンフィグレーションツール（日程、体制、成果物サンプル、など）を中心に、導入前の作業、導入後の作業までカバーされたBaanコンサルタント必携のツールでした。現インフォア社のように複数のERPを持っていませんでしたので、「これを使えばBaanの導入がバッチリOK！」というものでした。

ところが、その後バーン社は様々な製品を買収し、導入プロジェクト計画も複雑になり、前述の「Target Enterprise」では対応できなくなってきました。それで、Baan5.0cがリリースされた時、Target Enterpriseも新版が出ました。この版では、CRMやSCM製品との組合せで導入した時のプロジェクト計画自動作成もカバーされていました。誰も日本語訳してくれないので、個人的に日本語訳しました。世界中で「Target Enterprise phase 3 日本語版」を持っているのは私だけかもしれません。

なぜ、私がせこせこと翻訳したかというと「使えるツール」だったからです。現インフォアのように思想が違う複数のERPがある訳ではなかったので、あくまでも「Baanおよびそのオプション」を導入する為の詳細なプロジェクトタスクや、注意・留意事項がズバリ使えるかたちで生成されました。

もちろん、プロジェクト毎に色々と調整・修正することは必要ですが、根底に「Baan DNA」がしっかりと埋め込まれたプロジェクト計画が作成されました。

現インフォアのように「思想（DNA）が異なるERP」を複数持っている会社の場合、全製品共通の詳細な導入方法論を確立するのは困難であり、各製品が持っているメリットを殺してしまい、かえって悪影響を及ぼしてしまうかもしれません。LNとSyteLineでは、導入タスクもプロジェクト体制も、お客様との役割分担も異なるはずですし、異なるからこそ各製品が持つ特長も生きるような導入ができるはずです。

LNの世界一の製造業向け機能を十分に生かすような導入ができるような（Target Enterpriseのような）導入方法論を確立しないといけないなぁ、と思う今日この頃です。

次回は、【LNよもやま話　#9　導入テンプレート（仮題）】をお伝えしたいと思います。パートナー様が作成した導入方法論＆アドオンパックをご紹介したいと思います。

【製造業の基幹システム #5 インド人技術者】

はじめにお断りしておきますが、以下の文章は決してインドの方を誹謗中傷するものではございません。素直で単純な「純日本人」から見たインドの印象と捉えて頂ければ幸いです。

10年程前まではERP実装の仕事をしていましたので、様々なパートナー企業の方々と寝食を共にしました。その中でも思い出深いのは某インド系の会社との共同プロジェクトです。

ERPを導入するスコープは会計、生産、購買、販売、在庫、原価・・・という「基幹系業務」と呼ばれるほとんどの業務領域を日本の全生産拠点、全営業拠点、全物流拠点、そして海外の主要な生産拠点、販売拠点へビッグバンで導入するというものです。

主に開発や海外拠点導入などをインド系の会社へ委託していました。以前にもベトナムの日系企業へのERP導入をシンガポール人と一緒にやったり、ドイツ系やスイス系、シンガポール系（華僑）企業の日本法人へのERP導入を現地の方と実施したりしていましたが、色々な意味でインド系の方が一番印象に残っています。

＜プロジェクトのはじめに＞

プロジェクトの最早期にインド人2人を連れて、お客様の工場を訪問しました。夜に歓迎会を開いて頂いたのですが、某地方都市のカラオケ屋で「ボリウッド」の世界を堪能させて頂きました。音楽が聞こえると踊らずにはいられないようです。首を左右にクネクネする、あの踊りです。

＜工場での食事＞

2人のうち一人はベジタリアンでした。地方都市の工場の昼食は社員食堂以外の選択肢はありません。最初のうちはカレーの肉を除けて食べたり、うどんの麺だけすすっていたり（スープも魚介なのでダメ）しましたが、面倒になったのか朝の通勤時に食パンを一斤買って食パンばかり食べていました。

＜インド人の女性＞

さて、本社のプロジェクトルームに戻り沢山のインド人に囲まれて仕事をしていたのですが、一人のインド人女性は毎朝パソコンの横に生のニンジンを数本並べ仕事中にポリポリ食べていました。皮をむかずにそのまま食べるのですが、さすがにヘタは食べずに残していました。ヘタを毎日捨てるという習慣がないのか、次第にヘタの山が机の上に積み上がり・・・ヘタの山を見た日本人は「これ、なーに？」という感じで不思議がっていました。

＜インド人のプライド＞

日本のIT技術者は3Kとか5Kとか言われたりしますが、インドにおけるIT技術者の社会的地位は高く、とても仕事に誇りを持っている裏返しとして、とてもプライドが高いのです。お客様は日本人ですので、いつものIT技術者のつもりでインド人技術者と会話すると、彼らはカチーンときて巻き舌でまくし立てたりします。どこかの話で「国際会議において、インド人に黙らせることと、日本人に喋らせることほど難しいことはない」（出典不明）というのを聞いたことがありますが、まさにこの状態になります。インド人を激怒させた同僚の代わりに私が詫び状を書いたことも有りました。

＜上下関係の厳しさ＞

「ボスには絶対言わないで！！」とインド人コンサルタントに半泣きで言われたことが何回かありました。ある時、ご尊父がお亡くなりになられたインド人にも「ボスには絶対言わないで！！」と言われました。「仕事に身が入らないだろ？」とプロジェクトを外されるのを恐れていたからです。

＜９９×９９＞

「インド人は９９×９９の掛け算を暗記している」という都市伝説があります。プロジェクト中締めの飲み会で「この都市伝説って本当？」って聞いてみました。その人は「うーん、昔は覚えていたけど忘れた。１９×１９までなら今でも覚えている」と言っていました。インドでも地方によって９９×９９まで覚えたり１９×１９までだったり、まちまちのようです。

＜言語＞

インドの紙幣をご覧になったことがありますか？インドには多数の言語があるため紙幣には10以上の言語でずらーっと表記されています。日本にも方言がありますが、インドでは言語ごとに文字そのものが異なるので、このような表記になるのです。なので、様々な地方出身から集まったプロジェクトのインド人達はインド人同士でも英語でないと話が通じません。同じ言語を話す人同士は、その言語で会話したりしていましたが、その言語が理解できないインド人は仲間外れのようになっていました。

＜インド人のプライド２＞

さて、プロジェクトも終盤になりお客様へ色々と引き継いでいると、猛烈な剣幕でインド人に怒られました。「システム開発の引き継ぎをお客様にするな！」と。インド人にしてみればシステム開発をお客様ができる訳ないし、お客様自身が開発すると我々の仕事が無くなってしまう、と。気にせずにお客様へ引き継ぎましたけど。

次回は、製造業のグローバル化についての考え方の変遷の話を書いてみようと思います。