【LNよもやま話 #19 MRP】

今回は「MRP」の話です。MRPとは、Materials Requirements PlanningもしくはManufacturing Resource Planning（MRP II）とかの略です。MRPについて簡単に言うと、
いつ？何を？どれだけ？
買ったり作ったりすればよいのかコンピュータに計算させよう、ということです。
例えば、貴社にて10機種のパソコンを製造していたとします。パソコンの中には沢山の電子部品が入っています。それらの電子部品がパソコンの販売計画に基づいて計算された生産計画に合わせ用意されている必要があります。パソコンに組み込む電子部品がいつ必要なのか？そのためには、いつ部品を発注する必要があるのか？を計算させる仕組みがMRPです。
しかし、世の中は単純ではありません。
パソコンの組立に2日間必要である場合、パソコンの組立前に全部品を揃えると部品在庫を最長2日間抱えることになってしまいます。それならば組立工程ごとに部品を納入させればよいかと思うと、部品業者からの納入は1回/週だったりします。さあ、どうしましょう？
モデルAの売れ行きが絶好調で生産量を増加させたいがモデルBは生産量を減らしたい。しかし、とうの昔に各々のモデルの部品は発注済みである。さあ、どうしましょう？
部品の製造業者が突然倒産した？さあ、どうしましょう？
前工程と後工程で工場が違う？さあ、どうしましょう？
生産の為の所要量計算だけでなく、サービスパーツの需要予測も必要。さあ、どうしましょう？
新製品の発売日が迫っているのに最終仕様が決まってなくて最終組立できません。さあ、どうしましょう？
設計変更で新部品を組み込むことになりましたが、旧部品の在庫がたんまりあります。さあ、どうしましょう？
これらの様々な要因を解決するための設定は、あなたが今使用しているMRPで可能ですか？

LNのMRPでは上記のような例外、ただし製造業にとっては日常的に発生すること（←何か表現が変ですね）に対し、様々な機能を有しています。それは、LNが「複雑な製品と複雑なサプライチェーンをもつグローバル製造業」に育てられてきた結果です。

ボーイング社の工場の脇に、日本から空輸された主翼が雨ざらしで山積みされていたらシャレになりません。ちなみにボーイング社は純粋なMRPではなく、LNのAssembly Planning & Controlという仕組みを使って高度な生産計画＆管理をしています。この話は機会があれば。

そもそも御社では部品表や生産工程がデータ化されていない？まずは、そこから始めましょう。

（追記）

あるWebサイトに「MRPは中小企業を中心に普及してきた」という記述がありました。本当ですかね？

【LNよもやま話 #18 BaanIVとLNの違いって何？】

Infor LNの前身のひとつが1996年にリリースされたBaanIVですが、現時点でもBaanIVを使っている企業は数多くあります。なぜ、そんな昔のERPが今でも使用出来る理由については【LNよもやま話　#12　Porting Setって何よ？】をご覧頂くとして、BaanIVからLNへアップグレードについてご相談頂くこともあります。今後もBaanIVは最新プラットフォーム上で動作し続けるので、アップグレードする理由が無ければ無理やりアップグレードする必要はありません。

もちろん、BaanIVからBaan5、そしてLNになる過程で数多くの業務機能、技術機能が追加、改善されています。もし、下記のような「BaanIVでは出来なかったことがLNでは出来ること」に大きなメリットを感じるBaanIVユーザーはLNへのアップグレードを検討してみては如何でしょうか？

＜BaanIVとLNの主要な相違点＞

・各種オーダの桁数が6桁から9桁になった

・各種オーダに日付だけでなく時間（時分秒）を持つようになった

・品目桁数が16桁から38桁になった

・カスタマイズ工順、カスタマイズBOMが標準工順、標準BOMと同一テーブルになった

・PRP、DRP、MRP機能が、ひとつの処理にまとめられ、1回で全てを実行できるようになった

・販売、購買などの全ての入出庫処理がひとつの機能にまとめられた

・販売、購買などの全ての請求処理がひとつにまとめられた

・製造、プロジェクトなどの全ての時間会計処理がひとつにまとめられた

・顧客、仕入先マスタがひとつのマスタにまとめられた

・販売、購買オーダステップに「自動実行」フラグが付いた

・ロットとシリアルを並行で持てるようになった（どちらでもトレース可能）

・会計ディメンションが最大12種類になった

・サービス管理機能の大幅な機能拡張

・UIがWebブラウザになった（BWのインストール不要）

・画面表示項目の選択や見出しの変更が使用している画面から出来るようになった

・データの条件により（例：納期遅れ）データの表示色を変更できるようになった

・ユニコードの採用によりひとつのインスタンスで多言語を取り扱えるようになった

・各種名称を多言語で持てるようになった

・Excelへのデータエクスポート、Excelからのデータインポートが画面からボタンひとつで可能

・ライセンス管理の仕組みがERPから独立した（複数ERP環境をまとめて管理可能）

ここに挙げた以外にも数多くの機能追加、改善がありますが、コンセプトとしての違いもあります。BaanIVが開発された当時のコンセプトは、「製造業のためのERP」でしたが、世間一般的には「工場のためのERP」と理解されることもありました。現在の製造業においてはグローバル分業化が進み、かつグローバル統制管理が要求され、より一層の変化対応力も要求されます。これらの要求に応えるためのERPとして「真のグローバル製造業のためのERP」というコンセプト（単に工場の業務管理システムではない）で更なる進化を続けているのがInfor LNです。

ちょっと表現が大袈裟ですかね？

【LNよもやま話 #17 MANMAN、MKって聞いたことありますか？】

いきなりですが、貴社、もしくは貴社の関係する製造業で「MANMAN」「MK」というアプリケーションを聞いたことはありませんか？

もし、使っている、使っていたという話を聞いたことがあるのであれば、次の質問です。

実は、「MANMAN」「MK」もInfor LNの傍流であるということをご存知ですか？

 

Infor LNの源流をたどれば、オランダのBaan社（英Invensys社に買収後、米SSA社に買収。現Infor社SSA社をまるごと買収）にて開発された製造業向けERPであることは以前にも書きました。

1980年代から90年代にかけて、オランダの小さなソフトウェアベンダーであった旧Baan社は開発したアプリケーションを世界に拡販するために、そのソフトウェアをいくつかの会社へOEM供給しました。OEM先はHP社であり、ASK社などです。

HP社にOEM供給されたERPは「MANMAN/HP」と呼ばれました。またASK社にOEM供給したERPは「MANMAN/X」と呼ばれました。本家のBaan社では「BMCS」「TRITON」と呼んでいたころの話です。

OEM先では、MANMANに独自の改造、追加を加え、（当時のBaan社とは比べ物にならない）広い自社グローバル・ネットワークを使って世界中の製造業へ「MANMAN」を販売しました。

その後、ASK社は米CA社に買収され「MK（Manufacturing Knowledge）」というビジネスユニットとなり、「MANMAN/X」も「MK」に改名されました。

もちろん、OEM供給された「MANMAN」「MK」も、現Infor LNと同様の技術基盤（※）を持っていますので、長年にわたり製造業の基幹システムとして使われていました。

（※）お暇があれば、LNよもやま話　#12、#13をご参照下さい。

 

その後、CA社のビジネスユニット「MK」は、製造業向け以外のアプリケーションも取り扱う「interBiz」というビジネスユニットに統合されました。

ここで、Infor社マニアの方は気付いたかもしれません。Infor社が買収した、旧SSA社は2002年（2003年にBaan社を買収する前！）に、CA社から「interBiz」を買収しています。

うーん、ややこしい話ですね。

簡単に言うと、1992年に旧Baan社から旧ASK社へ旅立ったアプリケーションが世界中をぐるりと回って、結局は現Infor社が所有しているという話です。

 

もし、貴社、もしくは貴社の関係する製造業で「『MANMAN』『MK』を20年使っているのだけれど、そろそろ次期ERPを検討しようと考えている」というような話を耳にされたら、是非Infor LNを第一候補に推薦して下さい。次の20年、もしくはそれ以上の年月をInfor LNで管理することが出来るはずです。

【LNよもやま話 #16 個別受注生産製造業】

久しぶりにInfor LNに関する話を書きたいと思います。

さて様々な業種、業界、業態の業務システムで一番導入難易度が高いシステムは何でしょう？

天気予報システム？しかしながらInfor LNには天気予報機能はありません。Infor LNが市場としているのは「組立製造業」です。部品や原材料を組立、加工して製品をつくる製造業です。

さて、「組立製造業」といっても様々な業種、業界、業態がありますが、単純に下記の4つに分類してみます。

・見込生産型（市場の需要を予測して、標準製品を生産する）

・受注生産型（注文を請けて、標準製品を生産する）

・受注組立型（注文時に標準オプションを選択させ、顧客仕様製品を生産する）

・個別受注生産型（個々の注文毎に新規設計し、顧客仕様製品を生産する）

ひとつの製品でも、製品を構成するユニット、コンポーネントは見込生産している標準品かもしれません。また、受注組立型で選択するオプション仕様は全て標準品で構成されると考えます。

例えば、東京都庁の建物は個別受注生産ですが、ほとんどの建売住宅は見込生産型、ハウスメーカーによる多くの注文住宅は個別受注生産のように見えて実は受注組立型です。

 

もちろん、これら4分類の中で一番ヤヤコシイ仕組みは「個別受注生産型」の製造業ということが出来ます。

納期とコストを最も小さくして市場競争力を高めるためには、出来るだけ標準化、共通化し、出来るだけ受注組立型に近付けることが必要ですが、様々な理由によってどうしても個別設計が必要な場合があります。

なので、

・営業部門と設計部門のシームレスな連携（見積仕様）

・営業部門と調達部門のシームレスな連携（先行調達）

・設計部門と生産部門のシームレスな連携（製品仕様）

・設計部門とサービス部門のシームレスな連携（品質情報）

・案件単位に様々な原価を管理する仕組み

などの部門をまたがった業務連携が非常に重要です。

おや、ここで気付きましたね？まさにERPの真骨頂です。

どんなに大量の製品を製造していても、単純な製品を見込生産する仕組みは単純なシステムで実現出来ますが、個別受注生産製造業のシステムは上記4分類全ての製造業が必要とする業務管理機能をシームレスに連携するシステムが必要です。

Infor LNが航空防衛業界や産業機械製造業などに広く普及しているのは、このような理由によります。

単純な「生産管理ソフト」を導入しただけでは、個別受注生産型の製造業の効率化には程遠いことを分かって頂けたでしょうか？

【LNよもやま話 #15 見た目と操作性】

現在は「Infor LN」と呼ばれているERPですが、このERPは20年以上前に誕生してから数度の名称変更を経て現在に至っています。その間に業務機能的な機能拡張と合わせ、技術的な進歩も続けています。

そこで、今回は「見た目と操作性」に絞って、その変遷を振り返ってみたいと思います。

１．Triton（～1990年代半ば。日本国内ではTRIMCS）

基本的にはUNIXサーバー上で動作していたので、VT端末もしくは端末エミュレータを介して操作。当然キャラクターベースのユーザーインタフェース（CUI）。グラフ表示は「*」の数で表現していました。メニューには数字が並び「1. マスタ　2. 販売物流 3. 製造」という感じです。操作性も汎用機のそれと近く、汎用機から移行しても違和感は少なかったかと思います。

２．BaanIV（1990年代半ば～2000年頃）

Windows95の出現により、企業のコンピュータ端末として急速にWindowsPCが普及しました。BaanIVには「BW（Baan Windows）」というクライアントソフトウェアが付属し、BWを介してERPを操作していました。出現当時、他のERPは、前述のCUIベースの操作画面が多かったなかで、「グレーのウィンドウ上でアイコンをクリック、グラフやチャートも表示」というグラフィカルベースのユーザインタフェース（GUI）は画期的でした。マウスに馴染んでいないご年配の方は、マウス操作に四苦八苦していましたが、学生時代からPCに慣れ親しんでいる世代には当然の操作性でした。

なお、そのような「マウス嫌い」の方向けにCUI（「BA（Baan ASCII）」インタフェース）でも操作できるようになっていました。

３．Baan5（1990年代後半～2000年代半ば）

「一人に一台のPC」という時代に突入し、マウス嫌いを公言するような人も少なくなり、前述のBW（Baan Windows）でのGUI操作が基本になりました。ショートカットキーをWindowsOSと統一し、ERP上のデータを「Ctrl+c」でコピーし、Excelに「Ctrl+v」で貼りつけるような操作も可能になりました。

また、インターネット（Webブラウザ）の普及により、Baan5にもWebブラウザベースのユーザインタフェース（「BI（Baan Internet）」）が出現しましたが、当時の技術レベル（ハード、ネットワーク）では、とてもレスポンスが悪く、本番運用で使用された例は少なかったかと思います。

４．LN（2000年代半ば～）

インターネット（Webブラウザ）技術の発展にともない、LNのユーザインタフェースもjavaをベースにしたWeb UI（WebTop）になりました。適切なWebサーバーを使用し、適切なチューニングをしていれば、C/S方式とのレスポンスの差はほとんどなくなりました。

また、先ごろ（javaではなく）HTML5をベースにした、新しいデザインのWeb UI（「LN UI」と言います）も発表されました。これによりクライアントPCへのjavaのインストールを不要とし、各種ブラウザ、OS、デバイスへの幅広い適用が可能になりました。

Infor LNは、「製造業の基幹業務システム」という地味なシステムですが、その時々のテクノロジーを取り入れて「いかにユーザーフレンドリーに操作性を向上できるか？」という視点でも成長を続けています。

【LNよもやま話 #14 結局○○○と何が違うの？】

今までInfor LNが最も多く競合になるのは大手グローバルERPです。LNにお声がかかるような「生産管理機能を含む組立製造業のERP案件」の場合、どちらのERPもRFPに記述されているような業務要件については、ほとんどの機能を持っているので992点v.s. 989点の闘いのような感じです。で、結局LNと○○○って何が違うのよ？LNって○○○をコピーして作ったERPなの（笑）？と聞かれることもあります。

そこで、Infor LNと○○○の違いについての問答を書いてみました。

【注１：「○○○」は特定のERPを指すものではありません。】

【注２：私は○○○について詳しい訳ではないので嘘八百かもしれません！！！】

 

１．一言で違いを説明して欲しい

「Infor LNは製造業向けERPで、○○○は業種を問わないERPです。」

 

２．業務的な側面で違いを説明して欲しい

「○○○は、生産管理機能がついた会計管理システムです。Infor LNは会計管理機能がついた生産管理システムです」

 

３．○○○も多くの製造業で使われているよね？

「Infor LNが導入されている製造業の100%は生産管理機能を使用していますが、○○○が導入されている製造業の半分も生産管理機能を使用していません」

 

４．費用的な側面で違いを説明して欲しい

「初期費用は変わりません。ただし、運用維持費用は圧倒的に安価ですので長期間使えば使うほどお得です。」

 

５．すでに○○○を会計や購買業務で使っているんだけど

「では、Infor LNを○○○に連携しましょう。○○○を他の会計システムに連携することはあり得ませんが、Infor LNは他のシステムとの連携は自由自在です。」

 

６．○○○が大企業に入っている事例は良くきくけど、Infor LNは聞かないよね？

「ボーイング社など部品点数が多くてグローバルサプライチェーンが複雑な製造業は○○○ではなくInfor LNを選択しています」

【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を買収し続けるのでしょうか。

【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　導入テンプレート（仮題）】をお伝えしたいと思います。パートナー様が作成した導入方法論＆アドオンパックをご紹介したいと思います。

【LNよもやま話 #7 そう言えば昔はこういうのがあったっけ？】

今回は（今回も？）役に立たない話です。

旧バーン社は現インフォア社と同様「製品を買収して連携する＋α」という道を突っ走っていました。買収した製品群の一部は今でも残っていて、インフォア社の製品ラインの一部になっています。

＜＜Open World＞＞

簡単に言うと、現インフォア社の「ION」みたいなものです。複数製品を連携したり、ワークフローしたり、イベントマネジメントしたりダッシュボードしたりする製品です。2000年頃、Baan5.0cのリリースと共に発表されました。現在も「Integration for LN」という名でLNとの連携機能（LNとMS Word/Excelとの連携など）として生き残っています。

＜＜Scheduler、Planner＞＞

Schedulerは、元をたどればカナダのBarcrain社のMoopiというスケジューラです。Plannerはボーイング社やフレクトロニクス社にも採用されているグローバルサプライチェーン計画システムです。各々国内にも導入事例があります。現インフォアにおいてはプロセス製造業向けなどのSCM、S&OP系ソリューションも取り揃えています。

＜＜iBaan PLM＞＞

PLM8と名前を変え現在はInfor PLM Discreteと言います。元はBAIN（BA Intelligence Networks）社（後にc-Arkと社名変更）のMANTA PDMという製品で、世界で初めてのVisual PDMという売り文句でした。2012年、インフォアはこのPLMを全面的にWEBアプリ化して生まれ変わりました。

＜＜CAPS＞＞

現インフォア社においてはSCE（Supply Chain Execution）の一部機能（TMS）として生き残っています。バーン社がCAPS logistics社を買収し、その後SSA社に売り飛ばしてしまいましたが、SSA社がバーン社を買収し、インフォアがSSA社を買収し・・・結局は現インフォアの製品として生き残っています。

＜＜bisam/btam＞＞

かつてのバーン社はデータベースも作っていました。ただしBaan専用データベースです。バカ高い市販DBを買わなくてもBaanが使える、というものでしたが、餅は餅屋ということで2000年位にやめました。軽くて早かったんですけどね。

＜＜DDC（Distributed Data Collection ）＞＞

簡単に言うと、バーコード連携機能です。入出庫や棚卸、製造実績登録などの機能をハンディターミナルで行う為の機能です。VT端末用の画面やプログラムを提供していました。LNになったとたんに無くなりました。

今はInfor Warehouse Mibolity（旧Infor10 Barcode、BridgeLogix）によって、このような機能を実現します。

そんなこんなで、様々な企業や製品を買収していたバーン社でしたが、実はWeb会議のWebEX（現在はCiscoの持ち物）や、SAP社ポータル製品のTopTierは、かつてバーン社の持ち物でした（正確にはバーン社創業者の個人会社のもの）。TopTierは「Baan Data Navigator」と呼んでいました、とさ。

次回は、【LNよもやま話　#8　導入方法論（仮題）】をお伝えしたいと思います。役に立たない話が続きます。