DU300 ASUG Influence Council: Central Master Data Management Enabled by SAP NetWeaver Master Data Management (2h)

TechEd

今回参加したセッションの中で、これが最も収穫だった。
"ASUG Influence Council"というカテゴリから、てっきりASUGメンバーが現在のMDMにない機能、とくに集中マスタ管理に関して不足している部分を挙げ、SAPの開発者に作れ！と直接圧力をかける場を見られるかも、と想像し、もしかしたらDRQ*1を通しやすくするコツが掴めるかも、とちょっと邪な考えで参加。
時間ピッタリに会場に入ったら、壇上にSAPが2人。客席に1人*2。それ以外に参加者が10名くらい。フロアの右半分にディスカッションしやすいように車座になっている。ASUGメンバーがもっとたくさん居て、壇上にもASUGの代表者が陣取っている姿を想像していたので、あてが外れた。「うっ、この輪の中に入るのか」と思うと、ちょっと気後れしたが、何か発言を求められたら日本でよく言われる「集中管理のタイムラグ」「多言語を本当に集中管理シナリオでグローバルマスタ管理者がメンテナンスできるのか？」といった質問をぶつけてみればいいや、と思い返し思い切って前のほうに陣取った。
参加者の会社名を確認できた範囲で記すと、Coca-Cola、ダウ・ケミカル、Intel、ロッキードマーチン、Coors、Kraft Foods、Nikeと誰もがその名前を知っている一流企業がずらり。後から話の中身を総合して考えるに、そういった企業のグローバルマスタの管理プロセスを改革し、実行に移すBPx*3達の修行の場だったのだ。決して開発要望の圧力をかける場などという、SAP開発者とASUGメンバーが丁々発止する場ではなかった。SAP開発者は場から発言が出やすいように話の流れをコントロールする立場に留まり*4、ASUG MDM BPxの面々が自主的に相互理解し、自分の問題を発見・再確認し、ではどうすればよいのかを自ら見つけ出す場だった。SAPの開発者が追加開発をコミットする、などというシーンは見られなかった*5。
参加者の面々は、自社のグローバルマスタ管理のメンテナンスプロセスを直接デザインし、かつ直接実行責任を負っている本人である。彼/彼女らの発言を聞いていると、実に詳細に自社プロセスやそこに潜む問題点を把握していることに驚かされる。したがってファシリテータに促されることなく、自ら能動的に発言し、他のメンバーの発言を積極的に理解しようとする。
日本でこういう会を催しても、なかなか発言が出てこないので「主催者/仕切屋」は苦労する。日本ではこの役割を集団で担うために、責任を負うべき個人はその詳細を知らないことが多い。いや、現場の先人たちが経験とカイゼンで作り上げてきたプロセスの意図を正しく把握している個人が社内に存在しなかったり、仮にいたとしてもビジネスプロセス改革/デザインという重要な仕事に対する責任ある立場に就いていないことのほうが断然多い。
これが今、我彼に「スピードの差」を生じさせている原因の一つなのではないか.....話がいきなり飛躍しているかもしれないが、この2時間でそんな方面を考えていた。会の終了時には、具体的な宿題が出され、4週間後にバーチャルに集まりその結果をまとめていくという合意が出来てしまったのだから。
前置きが非常に長くなった。この会の流れを順に追っていこう。

まずファシリテータから、集中マスタ管理の典型例が３つ示された。

    1. MDM Driven
    2. Application Driven
    3. Process Driven

1.はすべてのマスタをMDMという器で集中管理し他のサーバに配信していく（以下、この役割を「親玉」と呼ぶことにしよう。ここではすなわち「親玉MDM」ということだ）。2.はMDMを親玉として用いず、品目マスタならばCRM、SRMその他のサーバに対してERPが親玉となり、得意先ならばCRM、仕入先ならSRMがそれぞれ親玉となるというモデルだ。3.は1.のモデルにCustom xAppsを載せて、UIやマスタデータ更新依頼のワークフローなどを管理させる形式をとる。
（ここまで書きかけ項目。とりあえずアップロードだけしておき、後に追記・編集を行う予定）

*1:Development Request=機能の開発要望。顧客やコンサルタントはこれをSAPの開発側にぶつける権利を持っている。

*2:おそろいのスタッフ用ポロシャツを着ているのですぐわかる

*3:Business Process eXpertsの略。今回のTechEd06で正式に立ち上がったのがBPx Community。企業内外のビジネスプロセスのデザインに責任をもつビジネス視点でのGeekたちが集う。

*4:こういう役割をファシリテーターfacilitatorとよび、この行為を「ファシリテートする」facilitateと呼ぶとは最近まで知らなかった。日本語訳を見ると「主催者」とか「仕切屋」とかあるが、イメージが異なる気がする。「促し」て会を盛り上げ、迷走しないように「制御する」、重要な二つの役割があるようだ。

*5:考えてみればそれは当たり前の話で、その機能を標準として開発するかどうかは、開発担当者個人が決めるのではなく、SAPとしての明確な方針と戦略の下、何を開発するのかを決めるための社内プロセスが厳然と存在するのだ。ASUGメンバーはそのことをよく理解していると思われる。