案件

顧客業種：某小売り業 導入規模：大規模

OTRS導入の背景

お客様のシステム保守インシデント管理においては、従来エクセルを利用していた。エクセルは柔軟な入力、運用に併せたフォーマットの変更が効くため、当初は使い勝手が良かったのだが、インシデント数の蓄積により、1000件を越えたあたりからエクセルによる弊害が出始めシステム化の要望が挙っていた。さらに、ECサイトオープンを控え、インシデントの大幅な増加が予想され、システム化が喫緊の課題となり、商用インシデント管理製品と比較検討の末、ライセンス費用の掛からないオープンソースシステムの導入を決めた。

導入の範囲

お客様の要望では、構成管理、変更管理を含めたITIL化、さらに基盤システム運用のオープンソース化など要望が挙ったが、ECシステムオープンのスケジュールと併せて検討の結果、まずインシデント管理のシステム化のみにターゲットを絞って導入することとなった。インシデント管理のみとはいえ、問い合わせ元（顧客）が複数エリア存在し、システム保守の担当者（一次、二次担当）も10チーム程度存在する大規模システムであり、登場人物が複数社にまたがることからかなりの困難が想定された。当社事例においても最大級の案件である。

 

構築フェーズ

要件定義・設計

OTRS導入の肝となるのは、お客様の登場人物の役割把握、業務フローの把握、インシデント管理における管理項目の意図を把握することである。今回は特にシステムを利用する登場人物が複数チーム、複数社にまたがり、要件定義により多くの時間を割くこととなった。既存のエクセルを洗い出したところ、インシデント管理における項目が30項目以上におよびエクセルの自由度（自由に項目を追加しやすい）における弊害が発生していた。エクセル同様の使い勝手の継続を要望されるお客様担当者と、OTRS運用による、より項目の整理されたインシデント運用との間には当初大きなギャップがあり、一部ワークフローの見直しも含め、改善が必要となった。

ここでの肝は、現在の項目をOTRS上ではどのように集約するかである点と、各項目の入力形態を”ドロップダウン”、”テキスト入力”、”エリアテキスト”、”自動入力”などいずれを採用するかの確定も協議を要する部分となった。理由としては、従来の管理表であるエクセルはその自由度ゆえに、法則性から逸脱した入力形態を行っていたからである点と、それに慣れたユーザーがその自由度を求めていたからである。

また、OTRS導入において、キューをどれに対して割り当てるのか、一次担当、二次担当が複数に渡る場合、グループ、ロールの設計をどのようにするのかが、非常に重要である。今回は最も緊急課題であった、システムサポート部門におけるエクセル管理のみをOTRS化ターゲットとし、これをキューとして割り当てる設計を行った。またお客様のワークフローから、一次担当、二次担当の大枠に「グループ」定義、各チーム別に「ロール」定義を割り当て、所有権の移譲を持って、エスカレーションという設計にした。

導入〜テストフェーズ

導入自体は、要件定義、設計フェーズに比べると、比較的容易なフェーズである。OTRSの各種設定項目を設定し、バックアップスクリプトを用意し、障害への耐用性を高めた導入を行う。また今回の基盤環境はクラウド上に構築し、OA端末のある社内とVPNにて接続を行う基盤設計となっていた。

運用フェーズ

顧客向け WebUIを用いる顧客担当チーム、担当者向けUIを用いるインシデント管理者（インシデント管理者）および、一次対応・二次対応を行う各担当チーム、OTRS基本的な運用を行うOTRS管理者向けのレクチャー、それぞれ３タイプ別のレクチャー会を実施した。