問題管理の改善

BMC Helix ITSMを最適化する6つのステップ
問題管理の改善
問題管理
BMC Helix ITSM

プロセスを選択

接続済みのワークスペースで作業を続けるには、プロセスを選択してください。

BMC Helix ITSMの問題管理を最適化

ProcessMindは、サービス効率に影響する見えにくいボトルネックやプロセス上の滞りを明らかにします。手作業や引き継ぎによって調査が遅れている箇所を、簡単に可視化できます。こうした状況を把握することで、ワークフローを見直し、繰り返し発生する運用上の問題の根本原因を取り除けます。

事前設定済みのデータテンプレートをダウンロードし、よくある課題に取り組んで、効率化の目標を達成しましょう。6段階の改善計画に沿って進め、データテンプレートガイドを参考に、業務を改善してください。

詳細を表示

問題管理を改善する戦略的価値

効率的な問題管理は、安定したIT環境を支える基盤です。インシデント管理がサービスの迅速な復旧を目指すのに対し、問題管理では、サービス中断の根本原因を取り除きます。このプロセスが最適化されていないと、ITチームは同じ問題への対応を繰り返すことになり、事後対応に追われます。その結果、運用コストが増加し、ユーザー満足度が低下するだけでなく、技術スタッフにも不要な負担がかかります。BMC Helix ITSMで問題管理を改善すれば、事後対応から予防的な取り組みへと移行し、ビジネスサービス全体の信頼性を高められます。最終的には、サービス停止による大きな損失から組織を守ることにつながります。

BMC Helix ITSMのデータを具体的な改善案につなげる

BMC Helix ITSMの標準レポートでは、未解決の問題数や解決までの平均時間など、データの静的な状況を確認できます。しかし、こうした指標だけでは、特定の調査がなぜ停滞しているのかまでは分かりません。プロセスマイニングでは、PBM:Problem InvestigationやPBM:Known Errorなどのテーブルに記録されたデジタル上の履歴を使い、問題レコードのライフサイクル全体を再構成します。実際のイベントの順序を可視化することで、引き継ぎが滞る箇所、承認に時間がかかる箇所、手戻りが発生する箇所を特定できます。サイクルタイムが長い理由を推測するのではなく、遅延につながる具体的な経路を確認できるため、経験談ではなく客観的なデータに基づいて改善できます。

根本原因分析における構造的な非効率を特定する

問題管理で大きな課題となるのが、問題の特定から調査開始までの移行です。多くの組織では、レコードが記録済みまたは割り当て済みの状態のまま数日間とどまり、専門担当者が着手しないことがあります。プロセスマイニングを使えば、こうした見えにくいボトルネックを特定できます。特定のサポートグループに業務が集中して滞留が生じている場合や、問題を根本原因分析に進める基準が明確でない場合も把握できます。「調査開始」から「根本原因の特定」までのアクティビティの流れを分析すれば、技術チームに必要な情報が届いているか、診断ではなく事務作業に時間を取られていないかを確認できます。このサイクルタイムを短縮することが、IT環境全体の安定性を高める最も迅速な方法です。

回避策と既知エラーの効果を高める

見過ごされがちですが、回避策を公開するまでの速さも、プロセスの重要な要素です。回避策が見つかってもPBM:Known Errorフォームに記録されなければ、サービスデスクの担当者は繰り返し発生するインシデントへの対応に苦慮し、組織全体で作業が無駄になります。プロセスマイニングでは、「回避策の特定」から「回避策の公開」までにかかる時間を追跡できます。この間隔が長い場合、情報共有に問題があり、インシデント件数に直接影響している可能性があります。このワークフローの該当箇所を効率化すれば、恒久対策の開発中も組織全体で暫定的な解決策を利用できます。その間、専門担当者は増え続けるインシデントへの対応に追われることなく、詳細な分析に取り組めます。

成果を測定し、プロセスの成熟度を高める

プロセス改善の最終的な目標は、インシデントの発生頻度とビジネスへの影響を抑えることです。プロセスマイニングを使えば、問題管理のライフサイクルに明確なベースラインを設定できます。「変更リクエストの開始」に関するアクティビティの効果を測定し、合意したサービスレベル目標の範囲内で恒久対策が適用されているかを確認できます。変更を実施した後も、プロセスマイニングによる継続的なフィードバックで、改善の効果をリアルタイムに把握できます。データに基づく取り組みは透明性と説明責任を高め、事実に基づいてワークフローを改善できる環境づくりにつながります。こうした取り組みを重ねることで、再発する問題が大幅に減り、ITインフラの回復力も高まります。

プロセス主導の改善を始める

問題管理を改善するために、ITSMスイート全体を刷新する必要はありません。まずは現在の状態を把握することから始められます。BMC Helix ITSMのデータに分析手法を適用し、優先度の高い特定のサービスや、頻繁に発生する問題のカテゴリに絞って取り組むこともできます。ボトルネックを見つけて解消するにつれて、インシデント件数が減り、チームにはより複雑な構造上の課題に取り組む余力が生まれます。このガイドと付属のテンプレートを使って、より安定し、効率的で、予防を重視したITサービス環境づくりを始めてください。

問題管理 根本原因分析 ITサービス管理 サービスデスク ITSM運用 インシデント削減 問題コーディネーター チケット管理システム チケット管理 既知のエラー 繰り返し発生するインシデント 回避策 インシデント予防 ITヘルプデスク

よくある問題と課題

影響している課題を特定

担当範囲が不明確だったり、通知を見落としたりするため、多くの問題レコードが未割り当てのまま数日間放置されています。対応が遅れると、重大なインシデントが再発するリスクが高まります。また、根本的な問題が未解決のまま時間が経過し、IT部門全体の対応力も低下します。

ProcessMindは、BMC Helix ITSMでレコードが記録されてから最初に割り当てられるまでの時間を可視化します。担当の引き受けが常に遅れているサポートグループや問題カテゴリを特定できるため、リソースの調整や割り当てルールの明確化につなげられます。

問題の調査が「調査開始」の段階に入った後、進捗が更新されないまま長期間とどまることがあります。レコードが停滞すると、根本的な問題を恒久的に解決できず、未解決のIT課題が積み上がり、やがてサービス停止につながります。

調査段階にかかった時間を追跡することで、プロセスがどこで止まっているかを明らかにします。BMC Helix ITSMで一般的な解決時間を超えたレコードを特定できるため、問題管理の担当者は調査が長期化して意味を失う前に介入し、リソースを再配分できます。

回避策が見つかっても、ナレッジ管理システムに速やかに公開されなければ、サービスデスクの担当者はインシデントを迅速に解決できません。暫定的な解決策が共有されないと、関連するインシデントの平均修復時間が長くなり、恒久対策の開発中にユーザーの不満も高まります。

ProcessMindは、回避策の特定から「回避策の公開」アクティビティまでの時間を測定します。状況を可視化することで、BMC Helix ITSMを通じて暫定的な解決策を迅速に共有し、技術チームが根本原因への恒久対策に取り組む間も、問題の影響を抑えられます。

担当を避けようとしたり、技術的な対応範囲を誤解したりして、問題レコードが複数の技術チーム間を何度も行き来することがあります。こうした循環的な割り当てによって問題のライフサイクルが大幅に長引き、根本原因の分析開始も遅れます。その結果、作業が無駄になり、担当者の負担も増します。

分析機能は、割り当てアクティビティの順序をマッピングし、BMC Helix ITSM内でレコードが行き来するパターンを明らかにします。レコードを頻繁に別のグループへ回しているサポートグループを確認できるため、担当者への研修やグループの役割の明確化を通じて、責任の押し付け合いを防げます。

調査や修正の段階に潜む非効率が原因で、優先度の高い問題がサービスレベル目標を達成できないことがあります。期限を守れないとITサービスの安定性が損なわれ、重要なインフラが合意した期間を超えて不安定な状態にある場合、社内の対立やビジネス上の信頼低下につながるおそれがあります。

SLAの期限と実際のプロセスのタイムスタンプを照合し、違反の原因となっているアクティビティを特定します。BMC Helix ITSMでサービスレベル目標の達成状況をリアルタイムに確認できるため、期限を過ぎてサービスの安定性が損なわれる前に、優先順位やワークフローを調整できます。

根本原因が特定されても、恒久対策を適用するための変更リクエストが開始されるまでに、大幅な遅れが生じることがあります。技術的な解決策が分かっていても、実施段階が事務手続きで停滞していると、組織はインシデントの再発リスクにさらされます。

「根本原因の特定」アクティビティから「変更リクエストの開始」イベントまでの経過時間を分析します。これにより、BMC Helix ITSMで問題管理から変更管理へ移行する際の障害が明らかになり、不要な事務処理による遅れを抑えて恒久対策を進められます。

繁忙期には、レコードを早くクローズして滞留を減らすため、実施後レビューを省略するチームがあります。この手順を省くと、対策が意図したとおりに機能したかを確認できず、得られた教訓も記録されません。その結果、同様の問題が再発するおそれがあります。

ProcessMindは、クローズ済みのすべての問題レコードについて、「実施後レビューの実施」アクティビティへの適合状況を追跡します。BMC Helix ITSMの標準プロセスからの逸脱を明らかにし、長期的なサービス改善とコンプライアンス要件のために、必要な解決手順がすべて実施されるよう支援します。

ビジネス部門や技術責任者が解決を確認する前に、問題レコードがクローズされることがあります。その後、同じ問題が再発し、レコードを再オープンしたり新たに作成したりする必要が生じるため、レポートや指標の正確性が損なわれます。

BMC Helix ITSMで「解決の確認」アクティビティと最終クローズイベントを比較します。確認手順が省略されたり、十分な確認を行わずに進められたりしたケースを特定できるため、品質管理を徹底し、問題を正式に解決する前に根本原因が取り除かれていることを確認できます。

技術者が問題の根本原因を正しく分類できていないと、長期的な傾向やインフラの構造的な弱点を特定できません。データが不足していると、インフラ投資や安定性向上に必要なプロセス変更について、管理者が十分な情報に基づいて判断できなくなります。

根本原因カテゴリの属性が未入力、または汎用的な値に設定されているレコードを特定します。BMC Helix ITSMでこうした不足を明らかにすることで、組織のデータ品質を高め、ITの不安定さを実際に引き起こしている要因を把握しやすくします。その結果、より効果的な予防策を検討できます。

専門性の高い技術チームに問題の割り当てが集中すると、滞留が増え、修正も遅れます。業務量の偏りによって単一障害点が生まれ、問題管理プロセス全体が停滞し、重要なサービスがリスクにさらされます。

各サポートグループに割り当てられた対応中のレコード数を分析し、リソースのボトルネックを特定します。実際の処理量に基づいて、BMC Helix ITSMの重要な領域で業務量を再配分したり、要員を増やしたりできます。

問題管理のライフサイクルが長引くと、同じインシデントがサービスデスクに繰り返し寄せられ、反復作業に貴重なリソースが費やされます。この繰り返しによって業務効率が低下し、チームが戦略的なプロジェクトや複雑なトラブルシューティングに取り組む時間も減ります。

関連するインシデント数と、調査および修正の段階にかかった時間を照合します。問題の解決が遅れることでBMC Helix ITSMのインシデント件数がどのように増えるかを示し、恒久対策を早めるための根拠を提示します。これにより、サービスデスク全体の負担軽減につなげられます。

一般的な目標

成功の基準を定義

問題を適切な専門家にすぐに割り当てれば、重要な問題に迅速に対応できます。レコードが記録済みの状態にとどまる時間を短縮することで、調査を早く始められ、ITサービスの中断が続くリスクを抑えられます。これにより、サービス復旧全体のスピードも高まります。

BMC Helix ITSMで「記録済み」から「割り当て済み」までにかかった時間を正確に特定します。割り当てに平均以上の時間がかかっているカテゴリや優先度を明らかにできるため、管理者は基準を設定し、対応時間の改善状況をリアルタイムに確認できます。

問題の根本原因を突き止める作業は、プロセスの中でも特に多くの労力を要します。この段階を短縮すれば、恒久対策の開発を早め、技術的負債の蓄積を防げます。また、再発するインシデントへの対応に追われる技術チームの負担も軽減できます。

プラットフォームは「調査開始」アクティビティを分析し、根本原因分析に実際に費やした時間を追跡します。調査が停滞する見えにくいボトルネックを明らかにするため、問題管理の担当者はサービスレベル目標を超える前に介入し、複雑な問題へリソースを再配分できます。

恒久対策を検討している間にサービスを復旧させるには、回避策を速やかに提示することが欠かせません。既知エラーを迅速に公開すれば、インシデントの業務への影響を抑えられます。また、サービスデスクの担当者がよくある問題にすぐ対応できるようになり、ユーザー体験とサービスの可用性も向上します。

プロセスマイニングを使って、問題の初回記録から「回避策の公開」アクティビティまでの時間を可視化できます。暫定的な対応を最も速く提示しているサポートグループを特定し、その効率的なワークフローをIT組織全体に広げるために役立ちます。

問題レコードがサポートグループ間を行き来するたびに、時間が失われ、対応の背景に関する情報も薄れていきます。こうした行き来をなくし、適切な専門家が一貫して対応すれば、技術スタッフの負担を減らし、レコードのライフサイクル全体を短縮できます。

BMC Helix ITSMで、異なるサポートグループ間のレコードの流れをマッピングします。よくあるループや頻繁な再割り当てを特定することで、知識不足が生じている箇所や初期の振り分けを改善すべき箇所を把握し、最初から適切なチームにレコードが届くようにできます。

優先度の高い問題についてサービスレベル合意を守ることは、事業継続性の維持に欠かせません。コンプライアンスを一貫して守ることで、ビジネス部門との信頼関係を築き、影響の大きい問題に必要な緊急対応を確実に行えます。その結果、重要なサービスの停止時間を短縮できます。

プラットフォームは、すべての問題レコードについてSLA期限の属性と実際の完了時刻を照合します。期限が近づいているレコードを早期に知らせるため、問題管理の担当者は業務の優先順位を調整し、重要なサービスで高いコンプライアンス水準を維持できます。

根本原因が特定されたら、正式な変更リクエストへスムーズに移行する必要があります。この引き継ぎを早めることで、恒久対策をできるだけ早く本番環境に適用し、IT環境のリスクを取り除けます。また、解決策の提案段階にとどまる時間も短縮できます。

「根本原因の特定」から「変更リクエストの開始」までのイベントの順序を分析します。事務処理の遅れや承認のボトルネックを明らかにできるため、チームは変更レコードの作成を自動化し、問題の特定から対処までの待ち時間を短縮できます。

過去の問題から学ぶことは、サービスを継続的に改善するうえで欠かせません。重大な問題ごとにレビューを完了すれば、教訓が記録され、同様の問題の再発を防げます。また、知識共有が進み、IT組織の成熟度も高まります。

ProcessMindは、レコードをクローズする前に「実施後レビューの実施」アクティビティが行われたかを確認します。この手順が頻繁に省略されている箇所を特定できるため、コンプライアンスを徹底し、得られた知識をサービスデスク全体で記録・共有できます。

修正を確認せずに問題レコードをクローズすると、同じ問題が再発することがあります。正式な確認手順を設ければ、根本原因が確実に取り除かれたことを確認でき、将来のインシデント件数を減らし、ビジネス全体のサービス安定性を守れます。

「解決の確認」から「レコードのクローズ」までのアクティビティの順序を分析し、レコードが早期にクローズされたケースを明らかにします。このデータを使って品質を優先する対応を徹底し、案件を完了する前に修正の効果を確認できます。

正確なデータは、効果的な問題管理の基盤です。根本原因カテゴリの品質を高めれば、傾向をより正確に分析し、ITインフラの構造的な問題に対処するための技術投資や研修を的確に行えます。こうした取り組みが、長期的な安定性につながります。

プラットフォームは、数千件のレコードに含まれる根本原因カテゴリの属性を分析し、値の不整合や汎用カテゴリの過剰使用を特定します。この情報をもとに、管理者はデータ入力基準を見直し、BMC Helix ITSM環境でのレポートの信頼性を高められます。

技術チーム間で業務量を調整すれば、特定のグループがボトルネックになるのを防げます。適切にリソースを配分することで、カテゴリを問わずすべての問題に必要な対応を行い、ライフサイクル全体を一貫した予測可能なペースで進められます。

ProcessMindでは、割り当て先のサポートグループごとに、未解決の問題レコード数を確認できます。業務量が著しく多いチームや処理時間が長いチームを特定し、要員配置、研修、業務量の調整についてデータに基づいて判断できます。

問題管理の主な目的は、インシデントの再発を防ぐことです。再発するインシデントを減らせば、ITサポートのコストを大幅に抑え、ビジネスに欠かせないアプリケーションの可用性を高められます。その結果、ITスタッフは保守作業ではなく、イノベーションに取り組めるようになります。

問題レコードと関連するインシデント数を照合し、それぞれの問題が実際に及ぼす影響を測定します。恒久対策の適用後にインシデント件数がどれだけ早く減るかを追跡することで、問題管理の取り組みに対する投資効果を数値で示し、特に効果の大きかった対策を特定できます。

問題管理を事後対応型から予防型に切り替えることで、ユーザーに影響が及ぶ前に問題を防げます。傾向を早期に把握すれば、緊急対応ではなく、計画的な保守の中で脆弱性に対処できます。その結果、IT環境の安定性が高まります。

ProcessMindは、インシデントの集中発生から問題レコードの作成までにかかった時間を分析します。こうしたパターンを監視することで、問題の調査を早めに開始できる機会を特定できます。チームの対応を問題発生後の対処から予防へと移し、ビジネスへの影響を抑えられます。

問題管理を改善する6つのステップ

1

データテンプレートを入手する

実施内容

問題調査フォームや既知エラーフォームなど、BMC Helixの問題管理項目に合わせて作成された標準Excelテンプレートを入手します。

重要な理由

あらかじめ用意された構成を使うことで、ライフサイクルデータを分析モデルに正確に合わせられ、診断に役立つ情報をより早く得られます。

期待される結果

ITSMデータのマッピングにすぐ使えるテンプレート。

プロセスのインサイト

Helixの問題管理プロセスに潜むボトルネックを発見

ProcessMindを使うと、BMC Helix ITSMのデータを詳しく確認し、調査が滞る箇所や恒久対策を早める方法を把握できます。
  • 調査サイクルのすべての手順を可視化
  • 担当割り当てが遅れる原因を特定
  • 回避策の文書化にかかる時間を短縮
  • 対策がインシデント件数に与える影響を測定
Discover your actual process flow
Discover your actual process flow
Identify bottlenecks and delays
Identify bottlenecks and delays
Analyze process variants
Analyze process variants
Design your optimized process
Design your optimized process

実証された成果

問題解決における測定可能な効果

組織は問題レコードを詳しく把握し、根本原因の分析を効率化するとともに、企業全体で繰り返し発生するインシデントを減らせます。これらの結果は、データに基づくインサイトをBMC Helix ITSMのワークフローに取り入れることで得られる効率向上を示しています。

0 % reduction
根本原因の迅速な特定

調査サイクルタイムの短縮

調査開始から根本原因の特定までの流れを効率化することで、技術チームは長引く診断ではなく、恒久的な修正に注力できます。

0 x fewer moves
問題レコードのたらい回しを削減

サポート担当の再割り当てを削減

初期の振り分けにおけるボトルネックを特定すれば、問題レコードを適切な専門家にすぐに割り当てられます。複数のサポートグループ間で作業が重複するのを防ぎます。

+ 0 % improvement
SLA遵守率の向上

コンプライアンス遵守率の向上

滞留している問題レコードをリアルタイムで把握できるため、SLA目標の未達前に管理者が対応できます。これにより、組織へのサービス提供を安定させます。

0 % less rework
解決後の手戻りを削減

再オープンする問題ケースを削減

クローズ前に解決内容を検証することで、根本的な問題が確実に修正されたことを確認できます。修正後に調査をやり直すコストのかかる事態を防ぎます。

0 hours saved
回避策の迅速な提供

修正内容の早期公開

一時的な回避策を早期に公開することで、長期的な解決策の開発中に、継続中のインシデントがエンドユーザーに与える影響を大幅に抑えられます。

実際の改善効果は、プロセスの複雑さやデータの整合性によって異なります。ここに示す数値は、さまざまな企業環境で一般的に確認された成果です。

推奨データ

まずは、分析に欠かせない属性とアクティビティから始め、必要に応じて対象を広げてください。
イベントログを初めて作成する方はこちら: プロセスマイニング用イベントログの作成方法.

属性

分析に必要な主要データ項目

問題調査ケースを一意に識別するIDです。

重要な理由

プロセスのビューを作成し、個々の問題のライフサイクルを追跡するために必要な基本のキーです。

実行された特定のタスク、または発生したステータス変更イベントです。

重要な理由

プロセスマップのノードを定義し、ワークフローを可視化できます。

特定のアクティビティが発生した時刻です。

重要な理由

所要時間に基づくすべてのKPIの算出と、イベントの順序付けに役立ちます。

問題調査を現在担当している技術チームです。

重要な理由

組織単位の分析や、チームレベルでのボトルネックの特定に役立ちます。

影響度と緊急度に基づいて算出された問題の優先度です。

重要な理由

業務上の重要度に応じて分析対象を分け、SLA分析に役立てられます。

調査の調整を担当する個人ユーザーです。

重要な理由

個人単位のリソース分析と作業負荷の調整に役立ちます。

問題の根本原因の分類です。

重要な理由

システム上の問題の傾向分析や、予防的な問題管理に役立ちます。

影響を受けた主要な業務サービスまたは構成アイテムです。

重要な理由

プロセスのパフォーマンスを特定の業務製品やサービスに関連付けられます。

問題調査が開始された理由です。

重要な理由

事後対応型と予防型の作業を区別でき、プロセスの成熟度を測る重要な指標になります。

問題を解決する期限となる日時です。

重要な理由

コンプライアンスと期限遵守に関するすべての指標を算出する基準です。

この問題レコードに関連付けられたインシデントの件数です。

重要な理由

問題が業務に与える影響と、ユーザーへの負担を数値で把握できます。

問題の解決に許容時間を超えたかを示すフラグです。

重要な理由

コンプライアンスの報告と問題分析を簡潔に行えます。

アクティビティ

追跡・改善するプロセスのステップ

システムで問題調査レコードを新規作成することです。PBM:Problem Investigationフォームに新しいレコードを保存した際に、このイベントが明示的に記録されます。

重要な理由

プロセスインスタンスの開始を示します。全体のサイクルタイムや初期応答指標の算出に欠かせません。

問題レコードを特定の技術チームに割り当てることです。「Assigned Group」フィールドの変更を監視して記録します。

重要な理由

引き継ぎやたらい回しの状況、「初回割り当てまでの平均時間」KPIの測定に欠かせません。

問題レコードがアクティブな分析段階に移行することです。「Status」フィールドが「Under Investigation」に変わった時点で推定します。

重要な理由

実作業の開始を示し、「調査サイクルタイム」KPIの測定に役立ちます。

問題レコードの「Workaround」フィールドにテキストを入力または更新することです。一時的な解決策が文書化されたことを示します。

重要な理由

「回避策の公開リードタイム」KPIの測定に役立ち、インシデントの影響を軽減したことを示します。

問題レコードが、原因が判明したことを示す状態に移行した時点です。「Status」が「Root Cause Identified」に変わった時点で推定します。

重要な理由

「根本原因調査サイクルタイム」ダッシュボードの重要なマイルストーンです。分析から解決策の検討への移行を示します。

Infrastructure Change RequestをProblem Investigationに関連付けることです。実装段階の開始を示します。

重要な理由

「根本原因特定から変更までのリードタイム」KPIの測定や、問題管理と変更管理のプロセス間にある分断の特定に欠かせません。

恒久的な修正が成功したと確認された時点です。「Status」が「Solution Implemented」または「Completed」に変わったことから推定します。

重要な理由

「問題のSLA遵守率」の算出に使用します。技術的な作業が完了したことを確認できます。

問題レコードの最終的な事務処理上のクローズです。このイベントでプロセスインスタンスが終了します。

重要な理由

標準の終了イベントです。サイクルタイム全体の分析と「インシデント関連付け密度」の算出に必要です。

解決前に問題レコードが終了したことです。「Status」が「Cancelled」または「Rejected」になった際に記録されます。

重要な理由

無駄な作業や妥当な重複を特定します。通常とは異なる終了地点を示します。

よくある質問

よくある質問

プロセスマイニングでは、問題レコードがたどるすべての経路を可視化できるため、想定された流れではなく実際の流れを把握できます。過去のイベントログを分析すると、レコードがサポートグループ間を行き来している箇所や、保留状態のまま停滞している箇所を特定できます。こうした状況を明らかにすることで、チームは構造的な非効率を解消し、影響の大きい根本原因分析に集中できます。

一意の問題レコードID、タイムスタンプ、「ステータス変更」や「割り当て先グループ」などのアクティビティの説明を含む基本的なイベントログが必要です。通常、この情報はBMC Helixデータベース内のPBM:Problem Investigationテーブルから抽出します。多くのプロセスマイニングツールでは、これらのテーブルに直接接続するか、CSV形式でエクスポートしたデータを取り込んでプロセスの流れをマッピングできます。

ベンダーからの情報や他部門からのフィードバックを待つなど、調査が停滞している段階を明らかにします。各段階の移行にかかった時間を数値で把握することで、管理者は調査を遅らせているリソース不足や文書化の不備を特定できます。データに基づいて分析することで、遅延が実際に発生している箇所を、経験談ではなく事実に基づいて把握できます。

BMC Helixからデータを抽出する環境が整っていれば、通常2~4週間で最初のインサイトを得られます。最初の段階では、システムに接続し、主なステータス変更をマッピングしてベースラインモデルを作成します。その後の数週間で分析を調整し、レコードの再割り当てを減らすなど、具体的な改善の機会を特定します。

プロセスマイニングは、タイムスタンプの欠落や分類の誤りなど、データ品質の問題を特定するのに役立ちます。データの品質が低いと一部のインサイトが得にくくなる場合がありますが、可視化によって、サポート担当者がプロセスの手順を省略した箇所や誤って入力した箇所が明らかになることがあります。今後のレポートの正確性を高めるため、こうしたデータの不足を解消することが最初の改善目標の1つになります。

プロセスを代わりに修正することはできませんが、目標を達成できなかったレコードの経路を正確に示し、SLA違反の根本原因を特定できます。目標を達成したレコードと達成できなかったレコードを比較し、遅延が特定のサポートグループや問題の種類に偏っているかを確認できます。その結果、優先度の高い問題を所定の期間内に処理できるよう、対象を絞った研修やリソースの再配分を行えます。

問題管理モジュールから変更管理モジュールへの引き継ぎを追跡し、大幅な遅延がないかを確認します。この移行を可視化することで、根本原因の特定後すぐに変更要求が作成されているか、事務処理のループで滞留しているかを把握できます。問題の特定から恒久的な修正の実施まで、ライフサイクル全体の効率化に役立ちます。

標準レポートを補完し、現在の状況を示す静的なスナップショットだけでなく、プロセスを長期的な視点で確認できます。従来のレポートで未解決の問題の件数がわかるのに対し、プロセスマイニングでは、問題が時間の経過とともにシステム内をどのように進んだかを確認できます。プロセスを適切に改善し、標準のダッシュボードでは見つけにくい潜在的なボトルネックを特定するには、こうした詳細な分析が必要です。

問題管理のボトルネックを今すぐ解消

サイクルタイムを30%短縮し、サービスの安定性を高めます。

無料トライアルを開始しましょう。

クレジットカード不要。数分で設定できます。