SAPの変化を見ると分かってくること
これまで、Whyと上位概念としてのHowを中心に、本当にユーザに役立つシステムを作らなければいけないこと、そのためにはユーザと作り手が一緒になってシステムをデザインするという思考が大事であるというようなこと議論した。
ここからは、どんな構造のシステムを作るのか、それをどんなMethodologyや道具を用いるのかというWhatとHowについて論じていくことにする。
まず、「道具としてのBPMの可能性」の前に、企業情報システムの変遷をみてみる。ここで教科書に書いてあるようなことを言ってもおもしろくないので、世界最大のERPであるSAPの変化の過程（SAPは進化と言っているが）を例に考える。
SAPのERPは現在「mySAP ERP2005」というのが最新バージョンであるが、その前1992年に投入されたSAP R/3というのが有名でこれによって大きく普及した。R/3というのは、メインフレームのシステムであったR/2からクライアント･サーバー型に移行したもので、今までばらばらであった基幹業務システムを統合し、システム間の整合性をとることに威力を発揮した。そしてよく言われたのが、バッチからリアルタイムへと変わるということで、その当時、一度入力するとすっと最後まで行ってしまうから入力するとき怖くて手が震えたといった話をしていたことを思い出した。このリアルタイムということには誤解があってそれについては後で述べる。
この時点でのERPの特徴は、統合化、リアルタイム化、標準化（グローバルスタンダード）であった。しかしながら日本ではこのうちリアルタイム性とグローバルスタンダードは合わないため、メインフレームで統合化されたシステムを持っているところは、それほど魅力があったわけではなかった。
そして、つぎに出てきたmySAP ERPで大きくコンセプトを変えることになる。それは、ESA（Enterprise Service Architecture）と呼ばれる、いわばSOAの概念を採り入れたことだ。そして、ポータル、データ連携、BI、マスタデータ管理などのシステム基盤であるNetWeaverをリリースしたのである。このESAのアーキテクチャは非常に重要でこの理解がないといくら新しいERPを入れても無駄だ。
わが国でもいま少しずつ分かってきていると思うが、おそらく本当にここを理解しいているひとは数少ないのではないでしょうか。だからまだ、アドオンをいっぱいして旧来型の作りにしているプロジェクトも多いかもしれない。どこがどう変わったかを検証すると、ここで議論しようとしているシステム開発の方法の参考になる。というか、結局めざすところは一緒なのだということがわかる。
新バージョンの価値をひと言で言うと「情報を起点としたオペレーションと管理」ということになる。すなわち、情報が業務のアクションを誘導することであり（これが最初に言ったリアルタイムということなのだ）、常に事業の状況を監視し、異常が生じたらワーニングする仕組みなのだ。
そのため必要なことは、シンプルで一貫化された業務プロセスでなくてはならないということと、それが可視化されていることが重要である。従来は、この業務プロセスがすでにSAPにあって、それを使えるかどうかと考えるイメージだったと思う。そして、もし自社のプロセスが合わない場合、２つの誤った方向に走ったわけです。ひとつは、無理やりSAPに合わせて窮屈な思いをする。もう一方は、現状システムを生かそうとしてアドオンの嵐となる。
これが新しいSAPの姿では、標準化された機能を組み合わせてプロセスを自社の要件に合わせて組み上げるイメージです。従って、自社のプロセスと機能（機能とプロセスは明確に分離することが肝要）を特定し、業務プロセスを個性化することができるのです。よく、ERPパッケージは要件定義する必要がないように言う人もいるが、このように要件定義が重要なステップになるのです。
「システムの枠組みにプロセスを合わせる」ことから、「プロセスに必要なシステムを組み合わせる」ことに大きく舵を切ったことをよく認識することが必要です。これって、なんかBPMでしょ。そうなのです。SAPの今の姿はSOA基盤に乗っかったBPMシステムなのです。
SAPという会社はこのパッケージだけに多くの人間を抱え、日夜開発にいそしんでいるわけで、それを考えるとIBMより大きな会社とも言えるし、そのシステム開発のトップランナーがこうした方向性を示していることは特筆すべきであろう。
余談になるが、奥出教授の「デザイン思考の道具箱」によれば、SAPの共同創立者であるハッソ・プラットナーはスタンフォード大学のデザインスクールに3500万ドルもの資金を提供して「デザイン思考」の研究を支援しているのだ。SAPの懐の深さを感じる。