統合って？　SAPのこと

前回お話したSAPについてもう少し書こうと思います。

SAP社は今でこそインメモリーデータベースのHANAや様々な製品群を販売していますが、僕がSAPの日本法人に入ったころは、R/3と言うソフトウェアのみでした。（現在のS/4 HANA、SAP ERPがそれに該当）

今でも「SAP」とか「SAP経験がある」と言った場合、R/3なりSAP ERPの経験があると言う意味で捉えられることが多いです。

僕がSAPと言っている場合もこのR/3とその後継の製品の話と思ってください。

さて、このSAPの製品のことをERPソフトとか業務用統合パッケージと言ったりします。

今回は、「統合」の部分について説明しようと思います。

業務用のシステムは、分野ごとに違うシステムが動いていることが多くありました。（今でもですが）

例えば、会計のシステムと販売のシステムが別とか、販売と生産のシステムが違うなどです。そして、業務が動いていない夜中などにこれらのデータをまとめて他のシステムの送るようにしています。（例えば、売上のデータを販売のシステムから会計のシステムに送るなど）

このような状態だと大きく二つの問題が発生します。

一つ目はリアルタイム性がなくなることです。例えば、会計と販売が分かれている場合、会計側で日時で決算データを確認すると言ったことができません。販売と在庫のシステムが分かれていると売ったはいいけど実は欠品でしたと言うようなことが起きてしまいます。（さすがにこのようなマズい仕組みのところは減ってはいますが、今でもネットショップなどで注文したはいいけど実は欠品でしかも入荷の予定もないなんて言うところがあったりします）

二つ目は、同じデータを二重・三重で保持しなくてはならなくなることです。例えば、売上というデータを会計・販売のシステムが分かれていると二重に保持することになります。同じ意味を持つデータを重複して持つとデータのずれが生じたり、同じ値にきちんとメンテナンスするのに余計な手間が掛かってしまいます。さらに厄介なことに同じ名称で管理している項目がシステムごとに意味が違うと言う事態も起きえます。例えば、売上の意味がシステムAでは税込みでシステムBでは税抜きみたいなことです。

これらの問題を解決するために複数の業務を統合して管理できるようにしようというコンセプトで作られたのがSAPのR/3と言う製品でした。ちなみにR/3のRはリアルタイムのRです。

このように説明すると簡単そうに聞こえますが、複数の業務を統合して一つのソフトウェアで管理できるようにするには高度のデータベース設計や業務の理解が必要です。

SAPの創業者は1970年代からそれらを地道に続けてきて、R/3と言う製品に仕上げました。

実はSAPと競合するソフトウェアはいくつかあります。ただ、このあたりのところをトコトン突き詰めて作られた製品は少ない印象を持っています。元々、複数のシステムだったものを見た目上は統合しているようにしていて中身は実は重複データの問題が解消できていないソフトウェアもあったりします。

SAPにはユーザインターフェイスが使いずらいとか問題点はあるにせよ長年使われ続けているのは、このベーシックな部分がしっかりしているからだと個人的には考えています。