2015年9月7日

【ＲＦＰコンサルタントの日常】

～社内ＳＬＡの重要性～

友人と話している中で、興味深い話を聞いた。彼は中小企業のITマネージャーである。結論的には社内SLAに取り組んだ話となるが、取り組むきっかけが予想外のものであったので紹介したい。なお、SLAとは「どこまでサービスの品質保証をするか」を定めた合意文書のことである。

１ きっかけは部下の一言

ある日の残業時間。古い工数管理システムがダウンしたことがわかった。残念ながら、数ヶ月に１度ダウンするシステムである。すぐに関連ユーザーに連絡し、手慣れた方法でシステムを再開させた。念のため、ダウンした原因を確かめるよう新任の部下に指示したところ、

「これって今日やる必要ありますか？」

唐突に質問を受けた。

２ 過剰なサービス

確かに、その通りである。彼は反射的に原因究明を指示してしまったが、原因究明は明日でも良い。しかも社内に残っているのは工数管理システムと無関係のユーザーのみである。苦笑いしながら、「今日やると原因究明が楽になるよ」と部下に告げた。

彼は考えた。そもそも、このシステムに関するサービスが過剰であったかもしれない。これが、決算期での経理システムであったら何がなんでも対応しただろう。しかし、ダウンした時点では誰も使っていない工数管理システムである。ダウンを知ってしまい、回復させた以上、原因究明したい思いはあるが、そのために部下に１時間のコストを支払うことになる。

３ 今後、社内ＳＬＡが重要になる

情報システム部門において、部門自体のサービス時間をユーザーに示している会社はある。また、具体的に示さなくても暗黙的な了解を得ている場合もある。「19時以降は誰も席にいない」といった方法で。

しかし、システムごとにサービス時間をユーザーに示している会社は少ない。システムが内製でないのであれば、ベンダーとSLAを取り交わす場合が多いであろう。しかしそれはあくまで、情シスとベンダー間のものだ。ユーザーからの問い合わせ窓口は情シスである。ユーザーはベンダーとSLAなど知ったことではない。

ポイントは社内SLAにある。システムやサービスごとのサービスレベルを定義し、何らかの方法で知らせることである。方法は様々である。

≫ 正当法でいくのであれば、システム利用部門長と交渉する。

≫ ドライに「～時までしか対応しません」と利用部門に知らせる。

≫ あるいは、既成事実をつくる。「～時以降は対応しない」ことで暗黙的に利用部門に理解させる。

利用部門に納得してもらえない場合もあろう。しかし、定義したサービスレベルは無駄にならないと筆者は思う。定義したサービスレベルは一種の行動指針として情シスに浸透する。浸透することで過剰業務の抑制となり、人的コストの削減になる。

社内SLAは情シスを改善する切り口の一つとなる。それが友人との会合での結論であった。

2015年9月