Fujitsu The Possibilities are Infinite

オンメモリ・データベース活用し
大規模バッチ処理と応答を高速化



サークルKサンクス様 導入事例


サークルKサンクスは、2006年9月からLinux搭載サーバ「PRIMEQUEST」による新情報系システムを稼働させる。組織別/業務別に構成されていたデータベース/データマートを一元化すると同時に、Webアプリケーションを用いたモバイル利用を可能にする。大規模なバッチ処理を高速化するために、全データをメモリに展開するオンメモリ・データベースを使う点が特長。ストレージ・オン・デマンドも用いて今後3年間で約30%のシステム開発・運用費用の削減を目指す

[ 2006年10月3日掲載 ]

入力フォーム 本事例に関するお問い合わせ


 導入の背景・システム概要 |  次ページ  導入の経緯・将来の展望 |


 導入の背景 |  システム概要 

導入の背景

全国に約6300店を展開しているコンビニエンス・ストア大手のサークルKサンクス(写真)。2004年9月にサークルKとサンクスの2社が合併した際に統合した情報系システムを見直し、2006年9月に新しい商品情報(POS情報)システムの全面稼働を始める。従来の多数存在していたデータベース群を一元化して再構築。運用コストの低減と情報提供のスピードアップを図る。

コンビニエンス・ストアでは、POSシステムを通じて、すべての売上データが基幹系システムに集められる。これは販売管理や会計処理などの基幹業務に使われるものだ。

一方で、同じ売上データから、天候と売れ行きの関係、イベントとの関係など、さまざまな仮説に基づいて販売動向を分析し、適切な新規商品を企画・開発したり、商品構成を店舗へ提案していくといった作業が必要となる。このためのデータを加工したり、さまざまな視点に基づく分析データを提示することが、今回の新しい商品情報システムの重要な役割である。

役割違う2種類のユーザーが利用

渡部正則
業務統括本部
システム本部
システム開発部
店舗システムマネージャー

商品情報システムのユーザーは2種類に大別できる。加盟店の経営を指導するスーパーバイザー(SV)と、サークルKサンクス全体の商品仕入れや新商品開発を担うマーチャンダイザ(MD)である。

SVは1人で7~8店舗を担当する。加盟店の売り上げを向上させるために、発注の指導や商品の陳列・販促の提案などを行う。「SVにとって必要な情報のパターンはある程度決まっています。しかし参照すべきデータは大量です。個々の店舗の問題点を見つけるためには、周囲の店舗の状況や、商品の売上状況など、さまざまな情報が必要となります。もちろんシステムのレスポンスの高速性も重要となります」(業務統括本部システム本部システム開発部店舗システムマネージャーの渡部正則氏、写真)。

一方、MDは売れるアイテムを探し出して店舗に推奨し、また新たに商品を開発することが仕事である。それには顧客の目線に立ち、過去のデータをさまざまな角度から分析して販売動向を予測する必要がある。分析した結果に基づいて、店舗のストア・コンピュータを通じて推奨商品の情報を配信する。「従来から多面的に分析した情報を提供してきましたが、MDのニーズは幅広く、これまで以上に柔軟性が求められるようになってきました」(業務統括本部システム本部システム開発部情報システムマネージャーの板倉千穂氏、写真)。


板倉千穂
業務統括本部
システム本部
システム開発部
情報システムマネージャー

こうした販売支援情報を作り出すため、従来のシステムは、(1) 全POSデータを格納する「セントラルDWH(データ・ウエアハウス)サーバ」、(2) 商品情報と営業情報を格納したデータベースである「商品・営業情報サーバ」、(3) 営業情報と一部POSの情報を格納した「新本部情報サーバ」、(4) 定型的な情報分析ではなく、より高度な多角的分析を行うための「マイニング・サーバ」-という4種類のサーバから構成されていた。

だが、従来のシステムには2つの大きな課題があった。

1つはユーザー・インターフェースを司るクライアント・アプリケーションがVisual Basicによって作られていること。これらは16ビット・アプリケーションとして作られていたため、Windows 95 / 98 / Meといったサポート期限切れのOSを使い続けていた。またMDにとっては、固定的な画面しか使えず、より多種類の分析ができないといった問題があった。

もう1つがデータベースの一元化である。従来システムの4種類のサーバには多数のデータベース/データマート(データ・ウエアハウスのサブセット)が分散していた。それによって起こっていた問題が、サーバ間でのデータ重複や処理結果の不整合である。「システムの開発時期によって、同じ項目名でも算出基準が異なり、結果、違う数値となる問題もありました。合併前のそれぞれのシステムが存続していたことも影響しています。また、業務別にサーバを構成していたため、データの分散は避けられない面がありました。そこでデータを一元化し、数値を統一する必要があると考えました」(板倉氏)。


システム概要

新しいシステムの構成

システム構成図

拡大イメージ

運用時には、SVやMDからのリクエストをWebアプリケーション・サーバが受け取り、フロントDB/バッチ・サーバとセントラルDWHサーバに振り分けて処理する。夜間にはフロントDB/バッチ・サーバがすべてのPOSデータを処理し、データマートを作成する


【導入事例(PDF版)印刷用】

【お問い合わせ】

本事例中に記載の肩書きや数値、固有名詞等は掲載日現在のものであり、このページの閲覧時には変更されている可能性があることをご了承ください。