稼動後運用体制を頭に入れてベンダー選定せよ

運用体制といっても、システム運用管理だけではありません。より重要なことは、エンドユーザ支援体制で、いわゆるヘルプデスクです。また、システムのアップグレード、拡張、システムの評価、ビジネスに対する影響の評価などがあります。

既に、情報システム部内で、ヘルプデスク機能が設置されている企業は、扱うアプリが増えるだけですからまだ良いとしても、ヘルプデスク機能がない企業は、開発プロジェクトと同時並行で、人材を育てなければなりません。

システム運用管理も、ヘルプデスクもアウトソースしてしまうとしても、出来上がったアプリを稼動後すぐに万全な体制でヘルプデスクを機能させることは出来ません。

社内であれ、社外であれ、その機能を知る期間が必要になります。

アウトソースする場合は、ベンダーが受け皿となってくれるかどうかも確かめておかなければなりません。ダメであれば、別途、探す必要が出てきます。

社内で構築する場合は、人事異動や組織変更が伴いますから、十分な予備期間が必要となります。

プロジェクトチームがそのままヘルプデスクに移行したら良いではないか、と言われるかもしれませんが、そうは行きません。開発者とヘルプデスクでは、必要なスキルが異なります。ヘルプデスクに異動させられた開発者は、一種、左遷させられたような印象を持つのではないでしょうか。

ある医薬品メーカでは、稼動後運用を自社で行なうことを決定しました。導入プロジェクト期間中に人材を異動させ、十分なトレーニングを実施することになりました。

実際には、テストが始まる1ヶ月前ぐらいに、プロジェクトチームにフルタイムで参加し、機能を習得することになりました。そして、テストが始まると、不具合のハンドリング、修正履歴管理などを担当してもらいました。

OJTでヘルプデスク機能を体験してもらったわけです。

さらに、エンドユーザ教育の講師も担当してもらいました。これは、非常に効果が高かったです。エンドユーザにしてみれば、問い合わせをする担当者の顔がわかり、さらに、教えてもらった経験があるので、対応もスムーズに行きました。

あるブロードバンド機器メーカーは、基幹システムのヘルプデスクをあるベンダーにアウトソースしていました。新たに導入したシステムのヘルプデスクもそのベンダーにアウトソースすることにしました。

ところが、そのベンダーには、新たに導入したアプリの知識がありません。急遽担当者をアプリのトレーニングに出席させ、機能を学ばせました。

案の定、ヘルプデスクとしては機能できません。当然です。トレーニングに出たからと言ってすぐには出来ません。問題をアプリベンダーに投げて、回答を待つということが長く続きました。

これでは、エンドユーザに回答を返す時間がかかってしまいます。そのうち、ヘルプデスクへの問い合わせ件数も激減しました。

むっ！うまく稼動し始めたのか？

そうではありませんでした。エンドユーザがそのアプリを使用しなくなったためでした。これでは、何のための導入か分かりません。アプリベンダーとしては、頭の痛い事態になってしまいました。