社内購買申請システムを更改、ECサイトのような使い勝手を実現したファイザー
ファイザー Pfizer は、世界最大級の製薬会社のひとつである。2013年度の売上は515億ドル（約5.1兆円）、従業員約77,000人。長らく業界トップの座に君臨してきたが、主力薬の特許切れ等もあってここ2年で売上を1兆円ほど減らしており、2013年度の製薬会社売上高ランキングではJ&J、ノバルティス、ロシュに次ぐ第4位。それでも国内首位の武田薬品工業の3倍以上ある巨大企業である。
研究開発型企業の例にもれず、ファイザーもIT投資による社員の生産性向上には積極的である。SAP ERPについても長年のユーザーであるが、アリバの購買ソリューションも2000年から利用している。
そのファイザーは2013年、あらたに「アリバ購買コンテンツ」（APC：Ariba Procurement Contents）モジュールを導入した。これはアリバの主要機能の一つで、カタログと呼ばれる商品データベースを社内の（イントラネット内の）購買ポータルに表示して、社員に発注させることができる仕組みである。
↓ 下はSAP社内で使われているAPC画面のイメージ。「PC周辺機器」の商品データを表示させてみた。
一般的なショッピングサイトと同じようなUIから発注できるため、社員からするとなじみやすく使いやすい。キーワード検索や比較、並列表示などECサイトでおなじみの機能も備えている。
一方、購買部門から見ると、「パンチアウト・カタログ」（サプライヤ側が提供しメンテナンスしている商品データベース）と、「自社独自カタログ」（ユーザー企業側がメンテナンスしている商品データベース）の両方を扱うことができ、商品データや価格に更新が入れば即座に更新され、さらに自社で設定した購買ポリシーが自動的に適用されるためポリシー遵守率が高まるなど、大きなメリットがある。
■アリバ購買コンテンツ（APC）についてはこちら。
http://www.ariba.co.jp/buy/procurement-content.htm
-----
このアリバ購買コンテンツの導入プロジェクトにつき、同社のリック・レイカー氏（Global Procurement Systems & Tools Lead）がAriba Live 2014のセッションでプレゼンしてくれている。導入プロジェクトの実情、とくに「テストができる状態になるまでの早さ」が印象的なので紹介しよう。
（Slideshareによるプレゼン資料とYoutubeによる音声はあるが、顔写真などはない。なおこのセッションはHP社とファイザー社のジョイント講演で、前半がHP、ファイザーはp20から／Youtubeでは29分38秒付近から。）
■Ariba Procurement Content Hybrid Lessons Learned
http://www.slideshare.net/Ariba/ariba-procurement-hybrid-lessons-learned
（Slideshare。p20から）
■Ariba Procurement Content Hybrid Lessons Learned
https://www.youtube.com/watch?v=O1FpDpaAAWg&t=29m38s
（29分38秒付近から）
-----------------------------------
私のセッションでは、昨年（2013年）行ったアリバ購買コンテンツ、APCの導入プロジェクトの経験を共有します。今日ここにいらっしゃる皆さんにもAPCをぜひ導入いただきたいと思っています。アリバからキックバックがもらえるわけじゃないですが(笑)、同志が増えるのはわれわれにとってもよいことですから。
ファイザーはアリバ・バイヤー（購買システム）のヘビーユーザーで、長年アリバを利用してきました。前年にはe購買（eSourcing： 条件にあうサプライヤを探すための、オンライン入札モジュール）を導入し、非常にスムーズにいきましたので、続いてAPCの導入を決めるのは難しい決断ではありませんでした。
アリバの「導入フレームワーク」についても触れます。アリバは経験豊富なコンサルタントを多く抱えていますが、プロジェクトの進め方についてもフレームワーク化されており、とても手慣れていた印象です。
-----
現在、ファイザーでは40ヵ国でAPCを利用しています。自社独自カタログは150、パンチアウト・カタログが204あり、パンチアウトの比率がかなり高いほうだと思います。
下記のグラフは9月30日に稼働して以来取り扱った購買の数を表しています。ひと月あたり1万～1.5万件、累計7.8万件のオーダーを処理しており、スケーラビリティには問題ないと言ってよいでしょう。
よく言われる話ですが、「ビッグバン（全社一括）導入ではいつ開始に踏み切れるか分からない、でもフェーズ分けアプローチではいつ完了できるか分からない」(笑)。結局ファイザーでは、ビッグバン導入を選択しました。
導入スケジュールは、当初は6か月の予定でしたが、途中で少し伸ばしたので、8か月くらいになりました。2013年2月～9月です。
キックオフの後、一番重要なのは「サイト設定＆インテグレーション」、つまりサプライヤが提供するパンチアウト・カタログがファイザー環境で動くするようにする部分です。先ほど申し上げたように、パンチアウト・カタログを204も使っていますからね、それなりの時間がかかるのです。
サイト設定と「テスト」はほぼセットです。設定、テスト、設定、テスト、、、という日々が続きました。4万人ものユーザーが日々接するサイトになるわけですから、リリース初日の段階で、われわれの期待値通りのクオリティになっている必要があると考えました。「ご不満の点は後から改善します」ではダメ。使い勝手が悪ければユーザーにすぐ嫌われてしまい、それをリカバリーするチャンスは二度と来ませんから。
※筆者コメント： キックオフのあと、すぐに「設定→テスト」のフェーズが始まっていることに注意。クラウドなので当然といえば当然だが、いわゆる「システム開発」のようなフェーズはそもそも存在せず、すぐにテストに入っている。
さて、アリバのデプロイメント・フレームワークに沿って解説していきましょう。他社でのケースと必ずしも同一ではないかもしれませんが、これがファイザーで実施したものです。
フレームワークは6つのフェーズに分かれています。
■1. プロジェクト・マネジメント
このフェーズの目的：プロジェクトのスコープについて合意し、スケジュールを引き、適切なリソースがアサインされていることを確認する。
主なアクション 担当 お客様側のプロマネをアサインする お客様 アリバ側のプロマネをアサインする アリバ プロジェクト計画をドラフトする アリバ
主な成果物 担当 プロジェクト計画のドラフト アリバ クラウド側のサイトを準備 アリバ
■2. キックオフ
このフェーズの目的：プロジェクトチームとともに、スコープとスケジュールを精査し、各チームメンバーの役割と責任を明確にし、またお客様にシステム概要を紹介する。
主なアクション 担当 プロジェクトのスコープ、リソース、スケジュールの整合が取れていることを確認する 両社 クラウド側機能のデモ アリバ お客様社内での必要リソースを確保する お客様 プロジェクト計画をレビューする 両社 キックオフの開催 アリバ
主な成果物 担当 キックオフで使うプレゼンテーション アリバ プロジェクト計画書 最終版 アリバ 課題管理表 アリバ
キックオフの段階で行う重要なステップは、両社のプロジェクトメンバーの「役割と責任」(Role & Responsibility) に関する明確な合意です。
アリバはプロジェクトに必要となるメンバーとそれぞれの「役割と責任」を明確・詳細に記述したフレームワークを持っています。それがファイザー側の流儀と100％適合していたわけではありませんが、少なくともこの記述に従って事前に合意をとっておくことで抜け漏れはなくなります。今回われわれのプロジェクトが非常にスムーズに行った理由のひとつはこれだったと思います。
顧客側メンバーとしては、プロジェクトマネージャー、業務リーダー、サプライヤ担当リーダー、ITリーダー、トレーニングリーダー、業務プロセス専門家、サポート担当窓口、など7人くらいの役割が定義されていますが、私の部下は7人もいませんので(笑)、専任者は1人だけで、あとは兼務メンバーで乗り切りました。でも役割と責任が明確になっていれば、社内から引っ張るときもやりやすいですよね。こういう期待値をこなせる人を、と。
専任者にはプロジェクトマネージャー、業務リーダー、サプライヤ担当リーダーの3役をこなしてもらいましたが、彼女は立派にやりとげてくれました。
トレーニングについては社内トレーニング専門部署から兼務で出してもらいましたが、実のところこのツールは直観的に分かりやすいので、トレーニングはあまり必要ではなかったです。われわれはアマゾンなどWeb上でモノを買うというアクションにもう慣れていますからね、何をしなければいけないか、はだいたい想像がついているわけです。
ITリーダーは、もちろん多数のITチームに支えられていますが、もし必要なときには「一人だけの首を締めればよい」ようにしておいたほうが良い(笑)。
そして、15人ものテスト要員。これは広範囲に集めました。購買カテゴリ担当者、アナリスト、エンドユーザー、領域ごとの専門家、ITなど、しかもできるだけ”声の大きい”メンツを集め、新システムに文句を言いたいなら今の段階で言ってくれ、と頼みました。
15人もの人数をある程度拘束するわけですから「何をやってるんだ」と文句が来たりしましたが、押し切りました。なぜか？4万人のエンドユーザーに相対する前に、彼らに徹底的に触ってもらい、いい点も悪い点も洗い出しておきたかったのです。いいところをできるだけピックアップして、ポジティブなコミュニケーションができるように準備していく一方、問題点については一つずつチェックし、直せるものなら本番稼働前に直し、直せない場合でも「それについては認識しています、以下のように対応する方向です」と答えられるようにしておくのです。
■3.設定
このフェーズの目的：クラウド上にお客様用のカタログサイトを設定する。お客様独自カタログのマスターデータをアップロードする。アリバe購買システムとAPC（パンチアウトカタログ）との接続をテストする。次のテストフェーズに備えて準備する。
主なアクション 担当 マスターデータ・リファレンスデータを抽出し、アップロードする お客様 業務プロセスのデザインとレビューを行うワークショップを実施
－カタログを承認するルールを定義する
－カタログのフィルタを定義する
－ユーザープロファイルの承認ルールを定義するアリバ 承認ルールとカタログフィルタを設定する アリバ オンプレミスの購買システムとのインテグレーションを行う お客様
主な成果物 担当 アリバ・サプライヤ・ネットワーク経由で接続されているサプライヤ一覧 アリバ サプライヤに対して発行されている電子カタログの諸元 アリバ サプライヤに対する電子カタログ管理のトレーニング アリバ サプライヤから受領したカタログ・コンテンツ アリバ パンチアウト・カタログの接続テスト アリバ 顧客独自カタログのアップロード アリバ 商品と価格の確認をお客様とともに実施 アリバ
このフェーズは、「やるべきことをたんたんとこなしていく」ところです。サプライヤのいくつかは、パンチアウト接続が初めてで、一発では接続できず、アリバとともに一社ずつ解決していく必要がありました。しかし一度済んでしまえばあとは同じですから、もしみなさんがこれらのサプライヤと接続するときは楽ですよ、もう接続は済んでますから(笑)。
■4.テスト
このフェーズの目的：システムのバージョン1が稼働し、プロジェクトは佳境にさしかかります。すべての設定と接続は完了しており、テストと確認の準備ができています。主なステークホルダーにソリューションを評価いただき、もし本番稼働までに対応すべき課題があれば洗い出すことを目的としています。
主なアクション 担当 システムテストを実施する お客様 ユーザー受入テストを実施する お客様 課題を管理し解決していく アリバ テストにて問題があればトラブルシュートする 両社
主な成果物 担当 システムテスト確認書 お客様 ユーザー受入テスト確認書 お客様 テスト課題ログ 両社
テストにはもっとも多くの時間をかけましたし、このソリューションに関してもっとも多くのことを学んだのも、テストのフェーズでした。
それから... 人は「自分のプロジェクト」のことは悪く言わない、ということも(笑)。自分が関わっていないプロジェクトならいろいろと文句を言う人でも、プロジェクトチームの一員に引き込んでしまえば、もう味方です(笑)。
■5. トレーニング＆コミュニケーション
このフェーズの目的：エンドユーザーにこのクラウドソリューションがスムーズに受け入れられるよう、効果的なトレーニング＆コミュニケーション戦略を策定します。
主なアクション 担当 エンドユーザー向けコミュニケーション戦略を策定 お客様 エンドユーザー向けコミュニケーションを実施 お客様 エンドユーザー向けトレーニングマニュアルを作成 お客様 エンドユーザー向けトレーニングを実施 お客様 （必要な場合）チェンジマネジメント戦略を策定 お客様
主な成果物 担当 コミュニケーション戦略 お客様 トレーニング計画書 お客様 チェンジマネジメント戦略 お客様
このフェーズも非常にうまく行きましたが、そもそもトレーニングはあまり必要ありませんでした。
なお、アクションと成果物の担当がすべて「お客様」である点にも注意してください。つまりこの部分はすべてわれわれユーザー側が責任を持つパートなのです。スタッフィングの際にはこの点は注意を。
ユーザーへのコミュニケーションは重要です。APCを初めて見る4万人の社員に、そのメリットを上手に伝えて利用を開始させるには、最初が肝心です。
しかし過去20年、私が手掛けたすべてのプロジェクトでは、コミュニケーション・プランがきちんと準備されたことはなかったです(笑)。6か月も8か月もハードワークを重ね、稼働のめどがたってからやっと考えはじめたものの、時間切れ...でした。
それが、このプロジェクトでは初めて、コミュニケーション・プランを、プロジェクト初日から考えていました。本番稼働を○月○日と仮置きし、ではいつ、誰に、どんな通知を出すのかをプランしてくれ、と指示しました。もちろん、チームからは文句を言われました。どんなツールなのか、見たことも使ったこともないのに、そんな計画作れない、と。まあ初期の段階では中身はなくてよいから、いつまでに何をと大枠だけ作って計画的に進めてくれ、と指示しました。
コミュニケーションの主軸としては、イントラネットに「アリバ・ニュース」サイトを設けて、リリース日や機能概要、紹介プレゼン、スクリーンショットなどを載せていきました。
ファイザーでは一斉配信メールは誰も読まないので(笑)、メールには細かいことは書かず、「○月○日にこんなのが来ます！」とだけ送って、あとは興味があればリンク先のアリバ・ニュースに誘導する、といった形でやりました。
■6. 本番稼働とまとめ
このフェーズの目的：システムを本番稼働、業務を運用／サポートへ移管、プロジェクト完了を確認
主なアクション 担当 カットオーバーに必要な切替等を行う お客様 製品サポートへ移管 アリバ エンドユーザーへ本番稼働を報告 お客様 サプライヤへ本番稼働を伝達 アリバ プロジェクト報告書をお客様とともにレビュー アリバ プロジェクト完了報告書にサインをいただく アリバ
主な成果物 担当 本番稼働チェックリスト アリバ プロジェクト完了確認 お客様 プロジェクト報告書 アリバ
最後の重要なステップは、社内のシステム運用・サポートグループへの移管です。彼らからすれば、これとて「面倒をみている数あるシステムのひとつ」にすぎません。われわれ導入チームの業務知識も、経験も、文脈も、熱意も、何も知らない人たちに引き継ぐのですから、それらを少しでもいかにして伝えるか、に気を使うべきだと思います。
それでは、プロジェクトのまとめです。うまく行ったと言ってよいでしょう。
- 8か月プロジェクト。
- 2013年9月に稼働。
- 354カタログ、40ヵ国。
- すでに7.8万件のオーダーを処理。
- 重大な課題や大きなギャップは一切なし。
-----------------------------------
ファイザーのように、必要な備品を社員が自分で発注できる、いわゆる「購買申請システム」を備える企業が増えてきている。これには大きく4つの背景がある。
1. 購買に伴う手間（社員の時間コスト）の削減。
読者のみなさんもよくご存じのとおり、企業がモノを買うのは、非常に手間がかかる。
①まず買う予算を確保するために、上長や購買部門に承認を取る（ワークフローを回す）、
②できるだけ安く、しかししっかりしたサプライヤから買うために、適切なサプライヤを探す（ソーシング）、
③見積書受領、価格交渉、発注、請求書受領、支払処理、など一連のペーパーワークを行う、
など、これらひとつひとつに手間が取られる。購買申請システムは、これらをできるだけシステム化・自動化することで、社員の時間コストを省く。
2. 購買コンプライアンスの徹底によるコスト削減。
承認権限や指定サプライヤからの購入、処理ルールなどさまざまな「購買ポリシー」を定めている企業は多いが、それを社員が遵守するとは限らない。購買ポリシーを購買申請システムに組み込むことによってコンプライアンスを高め、たとえば指定サプライヤとの間で締結した割引価格を確実に利用することで、コスト削減を進める。
3. 一元化による購買状況の見える化。
間接材やサービス購買は各部門が部門ごとの予算で個別に買うことが多いため、企業として全社を俯瞰した状況把握や管理、改善はしにくい。購買システムを一元化すればこれがすべて把握でき、見える化→分析→さらなる改善につながる。
4. ERPなどバックエンドシステムとの連携。
購買に伴って発生する買掛金や支払は、ERPなどバックエンドシステム側で処理することになる。購買システムとバックエンドが連携すればすべて自動処理で流れてくれる。
購買システムでやっかいなのは、商品データベースのメンテナンスだ。モノの値段や在庫状況は常に変わるからだ。その点、上記ファイザー事例でもしばしば出てきた「パンチアウト・カタログ」の場合は、そのメンテナンスをサプライヤ側が行うため、バイヤー企業側は手間がかからない。
そしてAPCを使うことで、ユーザーはほとんどトレーニングなしに、購買申請システムを使っていくことができる。Amazonや楽天などコンシューマ向けのECサイトにはもう慣れているからだ。
-----
ファイザーの「40か国」には日本も含まれており、先ごろロールアウトが完了しているとのこと。機会があれば、その使用感や効果についても取材してまたお伝えしてみたい。
※本稿は公開情報をもとに筆者が構成したものであり、ファイザー社のレビューを受けたものではありません。
【参考リンク】
■Ariba Procurement Content Hybrid Lessons Learned
http://www.slideshare.net/Ariba/ariba-procurement-hybrid-lessons-learned
（Slideshare。p20から）■Ariba Procurement Content Hybrid Lessons Learned
https://www.youtube.com/watch?v=O1FpDpaAAWg&t=29m38s
（29分38秒付近から）