◆ユーザーの課題◆事務用品最大手のコクヨは，取引先の販売店が発注処理の電子化を望む企業顧客に十分に対応できない問題を抱えていた。顧客から注文を受ける販売店網は業界随一の規模を誇るが，中小企業が大部分を占めるため，各販売店には電子受注システムを独自に開発する体力がなかった。
◆選んだ解決策◆社内ベンチャーのコクヨECプラットフォームが，BizTalk Serverを使った電子受注システムを構築し，ASP（アプリケーション・サービス・プロバイダ）として電子受注代行サービスを提供することにした。顧客との接続部分はコクヨECプラットフォームが個別に作り込む。販売店はシステム開発コストを負担することなく顧客の電子購買化に対応できる。
◆結果と評価◆既に大企業を中心とした10数社の顧客企業からの受注を代行するようになった。注文データは販売店向けの業務システムに直接渡せるフォーマットに自動変換されるため，受注後の処理も大幅に効率化された。
| ||
| ||
|
電子商取引サービスを提供するコクヨECプラットフォーム（KECP）は，事務用品の購買業務を電子化したい顧客企業と，それにこたえる体力のない中小販売店をつなぐ受注代行サービス「StationerHUB（ステーショナー・ハブ）」を提供している。顧客企業が導入した電子購買システムからの注文データを販売店に代わって受け取り，電子的な受注システムを持たない販売店に取り次ぐサービスだ。
販売店が電子化に対応できない
KECPはコクヨの社内ベンチャーとして設立された会社である（2003年4月に「デスカットウェブ」から社名を変更）。コクヨは全国に1万5000～2万店の販売店網を抱える事務用品の国内最大手。電話1本ですぐに商品を納めてくれる販売店網がこれまでコクヨの強さの原動力となっていた。しかし，コンピュータやネットワークの普及で問題も生まれていた。
文房具はおよそすべての企業が購入する商品である。一般的な企業の場合で，従業員1人当たり年間1万円程度の文房具を購入するという。この購入にかかる費用を減らすため，社内に電子購買システムを導入し，ネットワーク経由で販売店への発注処理をしたいと考える企業が増えているのだ。
ところが，システム化の要望にこたえられる販売店は多くない。顧客企業の規模にかかわらず，文房具販売店は中小企業が圧倒的多数を占める。ITスキルも高いとはいえない。「オンライン・ショッピングどころかWebサイトを持っている販売店自体少ない。名刺にメール・アドレスが載っていないこともよくある」（コクヨECプラットフォーム 中村浩延取締役）という。
顧客側には経費節減という動機があるため，電子購買システムの導入は取引する販売店数の絞り込みを伴うことが多い。このときシステム化に対応できない販売店があれば，それだけで整理の対象になってしまう。実際に，ある販売店の顧客から「電子購買システムで発注したい」という要望があっても，全く対応できず，そこで取引が終わってしまったケースもあるという。
受注システムをASP形態で提供
そこでKECPは顧客企業の電子購買システムに直結して注文データを受け取る受注システムを構築し，ASP（アプリケーション・サービス・プロバイダ）形態の販売店支援サービスとして提供することにした（図1[拡大表示]）。既にコクヨ本体は「べんりねっと」「@office」「カウネット」などの電子購買サービスを展開しているが，これらは顧客企業の購買業務を効率化することが主目的であり，顧客企業の電子化に追随したいと考える販売店を支援する内容ではなかったのである。
StationerHUBは顧客企業の電子購買システムと直結しており，文房具の注文データをネットワーク経由で受信している。StationerHUBが受け取った注文データは，各販売店向けに仕分けされて保管される。
一方，販売店はStationerHUB上に用意された専用のWebサイトに定期的にアクセスして，オーダーの有無を確認する（図2[拡大表示]）。新しいオーダーがあれば，販売店はその注文ファイルをダウンロードして，注文内容に従って仕入れを手配する。
ダウンロード以降の手順は，従来から販売店が行ってきた業務と全く同じである。つまり，販売店はWebサイトにアクセスできる環境さえ用意すれば顧客の電子購買化に対応できる。
安さと柔軟性でBizTalkを採用
システム構築に当たっては，いくつか不可欠な要件があった。
まずはコストの問題だ。文房具の取引は発注頻度が高い半面，単価が安い。サービスの利用料金をあまり高く設定できないので，システムを極力安く作る必要がある。現在の料金体系は従量制で，売上高の1パーセントだ。
また，特定の電子購買システムだけを想定した作りにすることもできない。顧客がどのような電子購買システムを導入するかは，販売店に電子購買化の話が持ち込まれるまで分からない。顧客ごとに何らかのカスタマイズが必要になるのは仕方ないが，なるべく簡単に対応できる柔軟性の高いシステムにしたかった。
「当初は『コクヨ』の名前のせいもあってか，ずいぶんと壮大なシステムを提案されたりもした」（中村氏）が，そういったシステムはコスト面で折り合わなかった。最終的にはビジネスの規模に見合ったシステムを提案してきたベイテックシステムズと共同で，マイクロソフトのBizTalk Serverをコアにしたシステムを開発した（図3[拡大表示]）。
BizTalk Serverには，各社各様の電子購買システムに接続するアダプタを比較的容易に開発できる特徴がある。実際にStationerHUBのサービスを開始してみると，接続する電子購買システムの種類は予想以上に多種多様だったが，アダプタの開発に手間取ることはなかった。「接続先は，日本アリバが提供している企業間電子購買ネットワーク『アリバ・サプライヤ・ネットワーク（ASN）』やSAP R/3が多くなると予想していたが，実際には各社独自のシステムをインターネット経由でつなぐケースが多い。導入が先行している直接材（製品の原材料や部品）の電子調達システムを流用しているようだ。意外にもSAP R/3との接続例はまだない」（中村氏）という。
販売店のITスキルに合わせる
販売店に対しては，システム化による業務へのインパクトを極力小さくする工夫を凝らした。
例えば，顧客が検収処理などのために電子的な出荷通知を要求する場合がある。このようなケースでは，コクヨの物流システムからの出荷通知をStationerHUBに戻し，顧客システムの要求するフォーマットに変換して通知することにした。
販売店に渡す注文ファイルの形式も，その後に派生する処理を容易にするため，ひと手間加えた。販売店は商品を出荷する際，コクヨの「@KROS（アットクロス）」と呼ぶシステムを使ってコクヨに商品の仕入れと顧客への配送を同時に指示する。このとき使う@KROSのファイル形式に合わせてフォーマットを変換しているのだ。電子購買システムを導入した顧客企業は，取引する販売店を絞る一方で，1つの販売店に注文する件数が増える。こういう状況で，「販売店が手作業で処理していたら1日仕事になる。しかし，注文ファイルを@KROS形式で提供しているので，10分程度の作業で済むようになる」（中村氏）。
1つのファイルが2つのシステムにまたがって利用されるため，BizTalk Server上でいくつかコード変換処理を実行する必要があった。例えば「地区コード」と呼ぶデータである。これはコクヨが独自に採番した10ケタの数字で，市区町村程度まで特定できる。@KROSを通じてコクヨの物流網に商品を載せるには送り先の地区コードが不可欠になる。このため，顧客からの注文に含まれる郵便番号データを@KROSの地区コードに変換する機能を作り込んだ。
商品コードの変換が必要になることもある。「事前にコクヨの商品コードを提供しているが，どうしても独自のコードを使いたいといわれることがある。その場合はStationerHUBに変換処理を作り込む」（中村氏）。
StationerHUBのサービスが稼働したのは2002年3月。サービス開始から1年半程度で顧客は10数社に増えた。現在も10件程度の商談が進んでいるという。顧客はいずれも「名前を聞けばだれでも知っているクラス」の企業だという。顧客1社当たり1日50～150件程度の注文があり，年間の取引高は少ないところで数千万円，多いところでは2億～3億円に達している。今後は日用雑貨や工具など，似た流通形態を持つ他業種にも展開するという。
