いまさらながら:パッケージで統一!は、是か非か その2

前回は、やったほうがいいんじゃね?ネタでしたが、今回は、やらないほうがいいんじゃね?ネタでございます。

統一の定義・・・同一インスタンスか複数インスタンス同一パッケージか

ちょっとこの話を考えるときに、「統一」ってやつにも、程度があるなあ、ということに思い至り、最初に少々書いてみようかと。ひとつのインスタンスで全部やってしまおう、というお話と、複数のインスタンスを立ち上げて運用するんだけれど、その中身は同一パッケージ、というお話がございまして、同一インスタンスで全部運用する、ってのが成り立つかどうかから、行ってみようかなあ、と思います、はい。


同一インスタンスで運用しよう!というのは、会社がひとつなら、まあ当たり前のことですが、じゃあ、海外子会社も一緒のインスタンスで運用しよう、というお話が、成り立つかどうか。
前述したように、業務のサービス化ができる分野では、会社が違っても同じシステムに対してオペレーションできたほうがいいね〜というのは、間違いないと思うんですよ。
しかしながら、大胆に時差がある地域を含めて同一インスタンスにしてしまうと、バッチ処理の時間がなくなってしまう。最悪それは大丈夫だとしても、システム変更するときの、移送ウインドウがなくなる、もしくはすごく小さくなってしまう。これは痛いなあ、と、思うわけです。


ですんで、海外子会社がヨーロッパとか、アフリカ、アメリカとか、豪快に時差があるところは、同一パッケージであっても、別インスタンスにするのが吉。業務としても、サービス化をいくらしたって、夜中に通常業務をするわけにはいかないですから、そのほうが素直だし。同一パッケージにしておけば、マネージャが見慣れた数字で管理できますよ〜というメリットもそのままでございます。
逆に、時差がない地域なら、同一インスタンスでがんばる、は、ありでしょうね。

複数インスタンスにしてみても

とはいうものの、複数インスタンスにしたときに、伝票構成にかかわるカスタマイズや、アドオンを各インスタンス別々にしてしまうと、それはすでに、「統一」の観点ではなくなる感じ。インスタンスは別々でも、資源は統一にしておかないと、メンテナンスの手間や、テストパターンの増加など、マイナスの要素が多い。
ですんで、資源は、全インスタンス共通にするのがいいんだろうな、と、思います。

その前提で考えると、もし、パッケージで全業務を統一したとすると、そのシステムは、各国の事情をすべて包含した、最大公約数的なシステムにならざるを得ない。それはそれで、ムチャムチャ巨大なシステムなわけで、メンテナンスコストが大きくなる、というか、あっという間にメンテナンス不能の状態になるのでは、と、予想されるわけで。
実際、もう10年近く前になりますが、某ERPパッケージベンダーが、全世界全業務統一インスタンス!!という荒業を、自社でやったらしいという話を聞きましたが、やっぱりやめたそうです。でかくなりすぎて、無理無理って話で。

となると、物事の流れとしては、全社共通で使う部分、つまり、サービス化の恩恵が大きいところや、定型的なバックエンドの仕組みは、全社資源として、時差を考慮した複数インスタンス構成にしておき、各国個別の事情の部分は、別のシステムを各国ごとに立てるのがいいんじゃね?という話になりますね。

具体的に、どこを外だしにするべきか

なんだか、ここまでのの結論は、すごく一般的なセールストークに落ち着いてしまった感じ。


けど、真面目にそうだと思うんですよ。
情報システム部から見れば、同一パッケージを使うメリットは、バラバラのときに比べて、同じスキルセットの人の中で融通が利くから、運用コストがさがる、ということ。ところが、いくら同じSAPだからって、たとえば、中国の商慣習なんてわかりゃしない。日本の本社の統一パッケージシステムにビルドインするっつったって、SAPスキルとしてはOKだとしても、業務前提がわからないわけだから、メンテナンスしようもないわけで、「同じスキルセットの人の中で融通が利く」という前提が崩れている。それなら、その部分だけ中国で作ってもらって、共通部分とIFしてもらおうかな〜っていう流れになり、ついでに、その中国で作ってもらう開発予算も、中国内から融通してもらって、金の出所とシステムサービスを対比させよう、という発想に落ち着きますよ。


となると、どこまでが統一システムの範囲で、どこからが各国固有なのか、ということになるわけで。各国固有のところ、その最大の部分は、やっぱり、販売側かな、と、思います。


受注までのプロセスは、やっぱり圧倒的に違うし、仮にそのプロセスがシステム構築の対象外だったとしても、国が違えば、収益性分析にまわす分析軸も違ってくるのが当然でしょうねえ。そうなると、これを共通化しちゃうと、分析軸、分析値の最大公約数を共通システム側にもたなければいけなくなる。いや、こりゃつらい。
さらに、受注でのネックは、価格決定だったりする。商売が違えば、価格決定のキーも変わってくるわけですが、それが最大公約数として設定することになると、それだけで大変な労力になりますわね。あら大変。


ということで、共通にしないほうがいいのは販売側。それに伴う、国ごと販売分析の分野も、各国ごとのほうがいい感んじゃないでしょうかね。

もうひとつの「最大公約数」・・・いろいろな商売をやっている場合

もうひとつ、統一しないほうがいいんじゃない?というケースは、グループ会社がいろいろな商売をいろいろな規模でやっている場合。


実は、こっそり前回、ERPだけで全部の業務はOKか、という話のなかに、「主力の商売ってのはひとつで、商売の形態がいくつもあるわけではない、という状態なら」という文言を入れていたりするんですよ。グループ会社が、いろいろな商売をやっている、という状況だと、統一ってやらないほうがいいかな〜と、私も思います。


やっぱり、統一しようと思うと、販売系のお話がネックになってきますね、こちらも。理由は各国共通にしない理由とまったく一緒。
製造から購買のところも、ちょっと考えないといけないでしょうね。こちらは、業務の違い自体は、会社ごとの設定ってやつで、機能的には吸収できそうかな〜と思うんですが、グループ会社ってのは、企業規模がさまざまであることが当然多い。小さい規模の会社に、軍艦みたいなSAP ERPを入れて、ライセンス料がペイするか、というと、全然ダメなわけですよ。商売が違うから、複数国パターンみたいに、複数会社でセンター化ってのも難しいわけで。


逆に、会計系は、グループ会社内で資金の融通をしてみたり、というオペレーションを考えると、サービス化ができる部分なので、パッケージで統一っていうのはアリでしょう。


結論。いろいろな商売をグループ会社でやっている場合、会計系はグループ会社共通で同一パッケージを同一インスタンスで運用するのがよさそう。そうなると、複数会社を同一インスタンスで運用できる、大規模ERPが微妙に有利。ロジ系は、そのグループ会社の規模を考えつつ、適切なパッケージで構築というのが最適ですね、きっと。


以上でございます〜