あるホスピタリティ企業は、 ServiceDesk Plus からJira Service Managementへの移行を次のように要約しています。データ移行は2段階に分かれており、いくつかのカスタマイズが必要でした。より困難だったのは、経験豊富な技術者の期待を裏切ることなく、関係者の理解と協力を得ることでした。
このケーススタディでは Help Desk Migration によって企業が移行した内容と、過去のチケット履歴を保持することでチームが新しいプラットフォームへの支持を獲得するのにどのように役立ったかの両方を取り上げています。.
会社がServiceDesk Plusから移行した理由
同社はITサービス提供体制の近代化を図り、統合されたヘルプセンターを構築することに着手した。しかし、既存のチケット管理ソフトウェアでは、チームが構想していたITSMフレームワークに対応できなかった。
ITチームは、新しいシステムに対して以下の要件を掲げていました。
分散型サービスルーティング
統合されたナレッジ記事によるチケットの自動回避
明確なSLA構造
ユーザーとシステム資産に直接リンクされたチケットを含む、完全なコンテキスト
基準の一つは、IT担当者自身から出されたもので、過去のチケットを保管しておくことだった。長年にわたる解決済みの問題は、技術者が頼りにする技術的な背景情報を含んでおり、履歴データがなければレポートを作成することは不可能だった。ITサービスデスクをゼロからやり直すという選択肢はあり得なかった。.
移行範囲：数値で見るデータ
チケット
ユーザー（リクエスト者）
エージェント
企業
Jira Service Management 移行時の課題
難しかったのはチケットの移行作業そのものではなく、チケットの有用性を損なわずに移行することだった。.
-
1
歴史は譲れないものだった。.
技術者はトラブルシューティングと報告のために、クローズされたチケットを必要としていた。チームが過去のデータを失うと、プロジェクトの内部サポートに支障をきたす可能性があった。.
-
2
会話の中にスクリーンショットが埋め込まれていた。.
チケットスレッド内のインライン画像は、デフォルトでは Jira Service Management に引き継がれませんでした。そのため、多くのチケットで修正内容の証拠が失われてしまうことになります。.
-
3
メールの署名がスレッドを乱雑にしていた。.
インライン画像の多くはスクリーンショットではなく、メールの署名に使われていたロゴだった。.
-
4
決議には直接的な行き先がなかった。.
ServiceDesk Plusでは、解決策は作成者と日付が記録された独立したレコードです。Jira Jira Service Management は対応するフィールドがないため、修正内容とその功績が失われる恐れがありました。.
-
5
フィールドが一致しませんでした。.
チームはソースフィールドをターゲットフィールドにマッピングする必要があったが、すべてのフィールドに対応するフィールドが存在するわけではなかった。.
-
6
作業を止めることはできなかった。.
チームが過去のデータを転送している間も、ServiceDesk Plusには新しいチケットが次々と届き続けた。.
-
7
人々は必然的についてくるものだった。.
チームは、経験豊富な技術者の期待を裏切ることなく、新しいプラットフォームに対する関係者の賛同を得る必要があった。.
ServiceDesk Plusと Jira Service Management比較：データマッピング
ServiceDesk Plusと Jira Service Management 同じヘルプデスクデータでも、名前や構造が異なります。以下は、2つのサービスデスク間でレコードがどのように照合されたかを示したものです。（カスタム）とマークされた行は、この移行のために独自に作成したものです。.
| サービスeDesk Plus | Jira Service Management | どのような変化が起こりましたか？ |
|---|---|---|
| リクエスト | チケット | リクエストの種類とステータスは Jira Service Management プロジェクトに存在し、移行前にマッピングされている必要があります。 |
| 依頼者 | 顧客 | 名前、メールアドレス、組織名は変更されます。電話番号と連絡先カスタムフィールドは Jira Service Management ユーザーには不要です。 |
| 部門 | 組織 | 顧客は部門別ではなく組織別にグループ化される |
| 技術者 | エージェント | エージェントはまず Jira Service Management で設定され、複数の技術者が1つのエージェントに割り当てられます。 |
| 会話とメモ | 公私にわたるコメント | コメントには、作成者、プライバシー設定、作成日時が記録されます。 |
| 解決 | 一般からの意見 | Jiraの解決フィールドはドロップダウンリストなので、テキストは元の作成者と日付のカスタムコメントに移動されまし た |
| インライン画像 | 添付ファイル | インライン画像が添付ファイルになりました |
| サポートグループ | タグ（ラベル） | チケットにはグループフィールドがないため、各チケットにグループカスタム用のタグが付けられました。 |
移行はどのようにカスタマイズされたのか
ITチームはまずテストを実施し、その後カスタマイズを依頼しました。サンプルチケットに対して複数の無料デモ移行を実行し、ターゲットプラットフォームでのデータの表示状況を確認しました。
各テストの結果、デフォルト設定では不十分な点が明らかになり、カスタマイズが必要であることが分かりました。そのため、当社の技術エンジニアは、クライアントの実際のデータに基づいて、以下のすべての調整をカスタム作業として構築しました。.
| オプション | それが何をしたか | チームがそれを必要としたのはなぜか |
|---|---|---|
| 添付ファイルにインライン画像を追加 | チケットの会話に埋め込まれた画像を添付ファイルに変換しました。 | そうでなければスクリーンショットは失われていただろう |
| パブリックコメントに関する決議 | 各決議案を公開コメントとして追加し、作成者である技術者と元の提出日をそのまま残した。 | 修正内容はチケットスレッドに記録され、適切なタイミングで適切な技術者に記録されます。 |
| グループごとのタグ | ServiceDesk Plusでグループに基づいて、移行された各チケットにタグを追加しました。 | 元のグループは Jira Service Managementで引き続き表示され、検索可能です。 |
| デルタ移住 | 完全移行後に作成または更新された転送済みチケット | チームは切り替えまでServiceDesk Plusで作業を続け、データに途切れはなかった。 |
Jira Service Management 移行の結果
同社の新しいヘルプセンターは、過去の履歴をそのまま保持した状態で稼働を開始しました。移行は2段階で行われ、まず完全移行、次にその間に作成されたすべてのデータを取得する差分移行が実施されました。.
ホスピタリティ企業からのエキスパートアドバイス
チームが Help Desk Migrationを推奨する理由：
「迅速かつ的確なサポート。ツールは使いやすく、独自の移行スクリプトを作成するよりも安価です。しかもテストは無料です。」
移行を計画しているチームへのヒント：
データ処理はツールに任せましょう
自動化ツールを使えば、データ転送はプロジェクトの中で最も小さな部分となる。成功は、計画、コミュニケーション、そして関係者など、それを取り巻くあらゆる要素にかかっている。.
関係者のバランスを取る
プロジェクトには適切な関係者をバランス良く参加させましょう。新しいプラットフォームへの賛同は必要ですが、従来のチケットシステムに依存している経験豊富な技術者を犠牲にしてはなりません。.
歴史を守ると約束したら、それを守りなさい
過去のチケット情報を保持することは、変更管理の重要な要素でした。これにより、新しいプラットフォームに移行しても、長年にわたる過去のデータが失われることはないということをチームに示すことができました。.
歴史を守り、チームを勝利に導く
このITチームにとって、過去のチケットは単なるデータ以上の意味を持っていた。それらを保管することは技術者への約束であり、その約束を果たすことでチーム全体が新しいプラットフォームを受け入れることができたのだ。.
技術担当者は以前と同じ質問をするでしょう。「古いチケットはどうなるのか？」プロジェクト開始前にその答えを用意しておきましょう。無料のデモ移行を試して、新しいプラットフォームでチームメンバーに自分のチケットを確認させてください。.
