SAPのテンプレートについて、第一回では概要に触れました。

今回はテンプレートを採用することによって導入ユーザ側にどのようなメリットとデメリットがあるか、解説したいと思います。

採用するメリット

まずは、前回も触れましたが、なんといっても自由度が高すぎるSAPのコンフィグレーションを簡素化できることです。

SAPは自由度が高い半面、オーバースペックという表現をすることもでき、「この業務は、大して管理要件が無いのに設定箇所が多い」なんて場合には自由度の高さなんて邪魔なだけだったりもします。

元々SAPには代表的な業務が入力可能な設定がなされているのですが、少々潔癖とでも言いましょうか、多くの場合、特に日本の実務にはフィットしません。

それ自体が良いことなのか悪いことなのかは別として、より実務に近い事前設定を活用できることはポイントです。
また、これも前回触れたことですが、「よくあるアドオン」が予め提供されることは作業工数の削減に大きく寄与します。

業務で使用するレポートなどは標準機能で賄えることも多くありますが、特に請求書や出荷依頼書などのフォームについては、SAP標準を使用している会社は殆どなく、新たに開発することが多いように思います。

これらについて、各社ごとの要件にて修正するにせよ、元ネタの有無によって開発工数が大きく違い、新規開発する場合と比べると、導入費用の開発部分は安上がりになる所見です。

最後に重要なトピックとして、テンプレートの販売元ベンダーは様々な会社への売り込みのため、導入事例を増やしたいと考えているのが常です。

ユーザ側としては、そういったベンダーの思惑も逆手に取ることができるという側面もあります。

採用するデメリット

さて、とはいっても、良いことばかりではありません。

まず、事前に用意された設定を活用できることの裏返しとして、自由度の高さというSAPの良さをスポイルしてしまうという点です。

同様に、大抵のテンプレートには「そのテンプレートが推すセールスポイント」がありますが、それがSAP標準の振る舞いやコンセプトにとって邪魔になるという場合もあります。

また、そのテンプレートの仕様というのは大抵がブラックボックスになってしまい、キャリアを積んだSAPエンジニアでも対応が難しくなってしまうこともあります。

その結果として、本来はSAPベンダーなんて選びたい放題であるはずのなのに、テンプレートの販売元のベンダーにロックインされてしまい、下手をすると足元を見られてしまうなんてこともあります。

特にSAPを捨てる日が来た際のデータ移行などでは間違いなく、他社との経営統合によるシステムの再編などの際は、間違いなく邪魔になります。

しかし、だからといって「一旦導入したテンプレートを取り外す」という選択肢は現実的ではなく、標準機能に従って再導入しかありません。

ですが、このご時世、そんなことに予算が降りる会社は無いでしょう。

最後に

こういった書き方をしてしまうと、SAPテンプレートのネガティブキャンペーンのように捉えられてしまうかもしれません。

もちろん、テンプレート＝悪、だなんてことはありません。
うまく活用することで発揮するメリットは多くあります。

ただ、SAPは一昔前ほどではないにせよ、相変わらずイニシャルもランニングもコストが高いシステムです。

そういった背景がある中、少しでもコストを抑えようと思ったとき、上記に挙げたようなデメリットを負ってまで採用するか？ということは、充分に考えなければならないのです。