Click here to visit our sponsor


----------------------------------------------------------------------

(情報システムにおけるサービスレベルについて)

----------------------------------------------------------------------

----------------------------------------------------------------------
(設問ア)
----------------------------------------------------------------------
1.情報システムのサービス概要と基準値
----------------------------------------------------------------------
1.1.A社情報システムのサービスレベル
----
 A社は東日本を中心に100店舗を展開するスーパー
である。各店舗には、本部システムの端末に加え、
POSレジ・発注用のEOS・EOB端末が配置されて
いる。これら販は本部システムの、販売管理・受発注管
理と連動しており、販売管理・受発注管理の主な機能は
以下の通りである。
 a.POS商品マスタの更新
 b.売上データの集計
 c.発注データの集計
 勿論、集計されたデータは会計システムと連動し、集
計された発注データは仕入先にも送信されている。
----
1.2.重要と考えたサービスレベルの項目と基準値
----
 A社では、以下の項目をサービスの品質を測る重要項
目として管理している。

 a.オンライン稼動時間帯
 前述の通り、販売管理・受発注管理はPOSの商品マ
スタを更新し、発注データを受けつけるものであり、オ
ンラインの稼動が不可欠である。システムが使用できな
い場合は、店舗の営業に直接影響を与えるため、A社で
は重要な管理項目とされている。尚、基準値としては、
7時−深夜1時とされている。

 b.バッチ稼動時間帯
 オンライン停止後のバッチ処理にて、発注データを集
計し仕入先に送信している。もし、バッチ処理が遅延し
た場合、時間によっては希望日に商品が入荷されない可
能性もある。また前日のバッチ処理の遅延が翌日のオン
ライン開始に直接影響を与える。従って、基準値は深夜
2時−5時とされている。

----------------------------------------------------------------------
(設問イ)
----------------------------------------------------------------------
2.サービスレベルを維持するための方策
----------------------------------------------------------------------
2.1.継続的なサービス状況の監視
----
 前述の基準値について、私は以下の視点で監視を続け
ている。

 a.オンライン稼動時間帯
 前述のバッチ処理の遅延、ソフトエウェア・ハードウ
ェア障害により基準値を満たせていない日は無いか。

 b.バッチ稼動時間帯
 小売業のデータは週末に集中するため、前週・前年同
時期とくらべ、処理時間・データ量が著しく増えている
日は無いか。

 いずれも、サービスレベルを満たせない可能性を早期
に発見する事を目的としており、システムのログから情
報を収集している。
----
3.1.適切なキャパシティプランニング
----
 A社では、毎年10〜20店舗を出店しており、これ
は全体の10〜20%に相当するものである。当然、処
理対象のデータ量も増える。従って、私は先の基準値の
監視に加え、CPU・ディスク・メモリ等の使用率につ
いても監視を行い、必要の都度ハードウェアの追加を行
っている。

----------------------------------------------------------------------
3.サービスレベルを維持するための工夫
----------------------------------------------------------------------
3.1.サービスレベルに関するユーザとの合意
----
 前述の基準値はあくまでも基準値であり、必ずしも
365日満足しなければならないものでは無い。

 具体的には、年末・年始の稼働日や、新規出店の際の
特殊な業務オペレーションに対応するための、オンライ
ン稼働時間の延長を要請される場合がある。

 一方、システム側としては、データベースの構造変更
を伴う中規模なシステム改造を本番化する際には、オン
ラインの稼働時間を短縮する場合もある。

 重要な事は、これらについて事前にユーザとの合意を
得ている事にあると考える。従って私は、ユーザの代表
責任者を交えた会議を毎月行っており、そこで基準値の
達成状況に対する実績報告や、翌月の特別対応について
確認を行っている。勿論、事前の合意無しに基準値を満
たせなかった場合には、ここで厳しく追及される事とな
る。
----
3.2.システム構成上の工夫
----
 キャパシティプランニングに基づき、必要なハードウ
ェアの増強を行っている事は既に述べた。具体的には、
DBサーバについては、2002年6月の本番稼動時に
は2台のサーバで構成していたが、現在は3台となって
おり、年内にはもう1台の追加が予定されている。これ
は、システム設計時に拡張性のある構成を選択している
事により実現されている。具体的には、複数のサーバか
ら構成されるDBを、アプリケーションからは透過的に
1台に見せる、DBMSのオプションを適用している。


----------------------------------------------------------------------
(設問ウ)
----------------------------------------------------------------------
4.サービスレベル維持方策の評価と課題
----------------------------------------------------------------------
4.1.基準値の達成状況とユーザの評価
----
 前述の施策により、基準値の達成率は99.8%とな
っている。尚、この数字からは事前に合意のとれた特別
対応は除外している。残りの2%については、年末・年
始のバッチ処理において、時間が延長したものでありキ
ャパシティプランニングが甘かったを言わざるを得ない。

 但し、この達成率はA社からは高い評価を頂いている
ものであり、私の施策が奏効していると判断する。
----
4.2.今後の課題
----
 中規模のシステム改造を本番化する際には、オンライ
ン稼動時間・バッチ処理時間帯の変更を御願いしており、
これがA社の満足度を下げる要因となっている。

 現在、システム切り替え手順、システム構成を見直す
ことにより、基準値を満足しつつ切り替える方法が無い
か、検討を進めているところである。





[ 戻る ]