問題管理を改善

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などのテーブルに記録されたデジタル上の履歴を使い、すべての問題レコードのライフサイクルを再構成します。これにより、実際のイベントの順序を確認し、引き継ぎが失敗している箇所、承認が滞留している箇所、手戻りが発生している箇所を正確に把握できます。サイクルタイムが長い理由を推測するのではなく、遅延につながる具体的な経路を確認できるため、経験談ではなく客観的な根拠に基づいて改善できます。

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

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

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

見落とされがちですが、プロセスでは回避策を公開するまでの速さも重要です。回避策が特定されてもPBM:Known Errorフォームに記録されなければ、サービスデスクの担当者は繰り返し発生するインシデントに対応し続けることになり、組織全体で作業が無駄になります。プロセスマイニングでは、Workaround IdentifiedからWorkaround Publishedまでの時間を追跡できます。この間隔が長い場合、コミュニケーションに問題があり、インシデント件数に直接影響している可能性があります。このワークフローの特定部分を効率化することで、恒久対策を設計している間も、組織全体で一時的な修正を利用できます。その結果、専門担当者は増え続けるインシデントの対応に追われることなく、根本原因の詳細な分析に集中できます。

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

プロセス改善の最終的な目標は、インシデントがビジネスに与える頻度と影響を減らすことです。プロセスマイニングを利用すれば、問題管理のライフサイクルについて明確な基準値を設定できます。Change Request Initiatedのアクティビティの効果を測定し、合意したサービスレベルの目標内に恒久対策が適用されているかを確認できます。変更を実施した後も、プロセスマイニングが継続的なフィードバックを提供し、改善策が機能しているかをリアルタイムで確認できます。データに基づくこのアプローチにより、透明性と説明責任を重視する文化が育ち、チームは事実に基づいてワークフローを改善できます。時間の経過とともに、こうした成熟度の向上は、繰り返し発生する問題の大幅な減少と、より安定したIT基盤につながります。

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

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

問題管理 根本原因分析 ITサービス管理 サービスデスク ITSM業務 インシデント削減 問題コーディネーター チケット管理 チケット管理 既知のエラー 再発インシデント 回避策 インシデント防止 ITヘルプデスク

よくある問題と課題

影響している課題を特定

担当範囲が不明確であったり、通知の認識が不足していたりするため、多くの問題レコードが未割り当ての状態で数日間とどまります。この遅延により、重大なインシデントが再発するリスクが高まり、重要な根本原因が未解決のまま時間だけが経過するため、IT部門全体の対応力も低下します。

ProcessMindは、BMC Helix ITSMにおけるレコードの記録から最初の割り当てまでの移行時間を可視化します。これにより、担当を引き受けるまで一貫して時間がかかるサポートグループや問題カテゴリを特定し、対象を絞ったリソース調整や、より明確な割り当てルールの導入につなげられます。

問題調査は調査開始の段階に入っても、意味のある進捗更新がないまま長期間とどまることがあります。こうした停滞したレコードは根本原因の恒久的な解決を妨げ、未解決のIT課題のバックログを増加させます。最終的には、サービス停止の増加につながる可能性があります。

調査段階の所要時間を追跡することで、ソリューションはプロセスが停止している箇所を正確に示します。BMC Helix ITSMで通常の解決時間を超えたレコードを明らかにし、調査が陳腐化する前に、問題コーディネーターが介入してリソースを再配分できるようにします。

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

ProcessMindは、回避策の特定からWorkaround Publishedのアクティビティまでの遅延を測定します。この可視性により、一時的な解決策がBMC Helix ITSMを通じて迅速に共有されているかを確認できます。技術チームが最終的な根本原因の解決に集中している間も、進行中の問題の影響を抑えられます。

担当を避けようとしたり、技術的な範囲を誤って解釈したりすることで、問題レコードが異なる技術チーム間を頻繁に行き来することがあります。この循環的な振り分けにより、問題のライフサイクルが大幅に長期化し、根本原因分析の開始も遅れます。その結果、作業が無駄になり、リソースの負担も増加します。

分析エンジンは、割り当てアクティビティの順序をマッピングし、BMC Helix ITSM内の行き来のパターンを明らかにします。レコードを頻繁に別の担当へ振り分けているサポートグループを確認できるため、トレーニングの改善やグループの責任範囲の明確化によって、責任回避の循環を止められます。

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

SLAの期限と実際のプロセスのタイムスタンプを関連付けることで、ProcessMindは違反の原因となっている具体的なアクティビティを特定します。BMC Helix ITSM内でサービスレベルの目標をリアルタイムに監視し、期限を過ぎてサービスの安定性が脅かされる前に、優先度やワークフローを調整できます。

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

Root Cause IdentifiedのアクティビティからChange Request Initiatedのイベントまでの経過時間を分析します。これにより、BMC Helix ITSMにおける問題管理から変更管理への移行で発生する摩擦を明らかにし、不要な管理上の遅延なく恒久対策を進められるようにします。

繁忙期にバックログを減らしてレコードを早くクローズするため、チームが実装後レビューの段階を省略することがあります。この手順がないと、修正が意図どおり機能したかを確認できず、得られた教訓も記録されません。その結果、同様の障害が将来発生する可能性が高まります。

ProcessMindは、クローズされたすべての問題レコードについて、Post-Implementation Review Conductedのアクティビティが実施されたかを追跡します。BMC Helix ITSMの標準プロセスからの逸脱を明らかにし、長期的なサービス改善とコンプライアンス要件に必要な解決手順がすべて実行されるようにします。

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

ProcessMindは、BMC Helix ITSMにおけるResolution Verifiedのアクティビティと最終的なクローズイベントを比較します。確認手順が省略された、または急いで実施されたケースを特定し、問題を正式に解決する前に根本原因が確実に取り除かれるよう、チームの品質管理を支援します。

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

ProcessMindは、Root Cause Category属性が欠落しているレコードや、汎用的な値に設定されているレコードを特定します。BMC Helix ITSM内のこうした不足を明らかにすることで、組織のデータ整合性を高め、ITの不安定さを実際に引き起こしている要因をより正確に把握できるようにします。これにより、より効果的な予防策を立てられます。

特定の専門技術チームに大量の問題が割り当てられると、業務が集中し、大きなバックログや修正の遅延が発生することがあります。この負荷の偏りが単一障害点となり、問題管理プロセス全体を停滞させ、重要なサービスをリスクにさらします。

各サポートグループに割り当てられたアクティブなレコード数を分析することで、ソリューションはリソースのボトルネックを特定します。実際の処理量に基づき、ITマネージャーはBMC Helix ITSM内の重要領域で業務負荷を再配分したり、人員を増強したりできます。

問題管理のライフサイクルが遅いと、同じインシデントがサービスデスクに繰り返し寄せられ、貴重なリソースが定型的な作業に消費されます。この繰り返しにより効率が低下し、チームは戦略的なプロジェクトや、より複雑なトラブルシューティングに集中できなくなります。

ProcessMindは、関連インシデント数と調査・修正段階の所要時間を関連付けます。問題解決の遅れがBMC Helix ITSMのインシデント件数をどのように増加させているかを示し、恒久対策を早めるためのビジネス上の根拠を作成できるようにします。これにより、サービスデスク全体の負担を軽減できます。

一般的な目標

成功の状態を定義

迅速な割り当てにより、重要な問題を適切な専門家がすぐに対応できます。レコードが記録済みの状態にとどまる時間を短縮することで、組織は早期に調査を開始でき、進行中のIT障害がもたらすリスクの時間を抑えられます。その結果、サービス復旧全体の速度が向上します。

ProcessMindは、BMC Helix ITSM内で記録済みから割り当て済みまでの正確な所要時間を特定します。割り当てに平均以上の時間がかかっているカテゴリや優先度を明らかにし、管理者が基準値を設定して対応時間の改善をリアルタイムに監視できるようにします。

問題の根本原因を見つけることは、プロセスの中で最も多くの労力を要する部分です。この段階を短縮すると、恒久対策の開発速度に直接影響し、技術的負債の蓄積を防げます。また、繰り返し発生するインシデントへの対応に追われる技術チームの負担も軽減できます。

プラットフォームはInvestigation Commencedのアクティビティを分析し、根本原因分析に費やされた実作業時間を追跡します。調査が停滞している見えにくいボトルネックを明らかにし、サービスレベルの目標を超える前に、コーディネーターが介入して複雑な問題へリソースを再配分できるようにします。

恒久対策を調査している間にサービスを復旧するには、回避策を迅速に提供することが欠かせません。既知のエラーを早く公開すれば、インシデントの運用上の影響を抑えられます。また、サービスデスクの担当者が一般的な問題に対する解決策をすぐに利用できるため、ユーザー体験とサービスの可用性も向上します。

プロセスマイニングを使うと、最初の問題記録からWorkaround Publishedのアクティビティまでの間隔を可視化できます。このデータから、一時的な対応を最も早く提供しているサポートグループを特定し、その効率的なワークフローをIT組織全体に展開できます。

問題レコードがサポートグループ間を行き来するたびに、時間が失われ、背景情報も分散します。こうした行き来をなくせば、解決までの経路が明確になり、技術スタッフの不満を減らせます。また、適切な専門家がレコードを担当し続けることで、レコードのライフサイクル全体も短縮できます。

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

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

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

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

Root Cause IdentifiedからChange Request Initiatedまでのイベントの順序を分析します。この可視性により、管理上の遅延や承認のボトルネックを明らかにし、チームは変更レコードの作成を自動化できます。これにより、特定から修正までの待機時間を短縮できます。

過去の問題から学ぶことは、継続的なサービス改善に欠かせません。重大な問題についてすべてレビューを完了すれば、教訓を記録でき、同様の問題の再発を防げます。また、ナレッジ共有が進み、IT組織の成熟度も時間とともに高まります。

ProcessMindは、レコードをクローズする前にPost-Implementation Review Conductedのアクティビティが存在するかを監視します。この手順が頻繁に省略されている箇所を特定し、コンプライアンスを徹底するとともに、ナレッジがサービスデスク全体で記録・共有されるようにします。

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

プラットフォームは、Resolution VerifiedからRecord Closedまでのアクティビティの順序を分析します。レコードが早期に終了したケースを明らかにし、品質を優先する運用を徹底できるようにします。すべての修正が有効であることを確認してから、ケースを完了できます。

正確なデータは、効果的な問題管理の基盤です。根本原因カテゴリの品質を高めることで、傾向をより正確に分析し、ITインフラ内の構造的な問題に対処するための技術投資やトレーニングを、より適切に行えます。これにより、長期的な安定性を実現できます。

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

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

ProcessMindは、各担当サポートグループが処理している未解決の問題レコード数を可視化します。業務量が過度に多いチームや処理時間が長いチームを特定し、人員配置、トレーニング、業務負荷の均衡について、データに基づいて判断できます。

問題管理の主な目的は、インシデントの再発を止めることです。再発インシデントの件数を減らすことで、ITサポートのコストを大幅に抑え、ビジネスに不可欠なアプリケーションの可用性を高められます。その結果、ITスタッフは保守ではなくイノベーションに集中できます。

問題レコードと関連インシデント数を関連付け、各問題の実際の影響を測定します。恒久対策の適用後にインシデント件数がどの程度の速さで減少したかを追跡することで、問題管理の取り組みに対する投資対効果を定量化し、最も大きな効果を上げた修正を特定できます。

受け身の問題管理から先回り型の問題管理へ移行することで、ユーザーに影響が及ぶ前に問題へ対処できます。傾向を早期に特定すれば、緊急対応の最中ではなく、計画メンテナンスの中で脆弱性に対処できます。その結果、IT環境全体がより安定します。

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

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

1

データテンプレートを取得

実施内容

Problem InvestigationフォームやKnown Errorフォームなど、BMC Helix Problem Managementの項目向けに設計された標準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

実証された成果

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

組織はProblem Recordを詳細に把握し、根本原因分析を効率化するとともに、全社で繰り返し発生するインシデントの件数を削減できます。これらの結果は、データに基づく分析結果をBMC Helix ITSMのワークフローに適用することで得られる効率向上を示しています。

0 % reduction
根本原因をより迅速に特定

調査サイクル時間を短縮

調査の開始から根本原因の特定までの流れを効率化することで、技術チームは長期化した診断ではなく、恒久対応に集中できます。

0 x fewer moves
記録のたらい回しを削減

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

初期ルーティングのボトルネックを特定することで、問題レコードを適切な専門家へすぐに届け、複数のサポートグループ間での無駄な作業を防ぎます。

+ 0 % improvement
SLA遵守率を向上

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

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

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

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

クローズ前に解決内容を検証することで、根本的な問題が確実に解消されたことを確認できます。これにより、対応済みと思われた問題について調査をやり直す、コストのかかるサイクルを防ぎます。

0 hours saved
回避策の提供を迅速化

修正内容の公開を迅速化

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

実際の改善効果は、プロセスの複雑さとデータの完全性によって異なります。これらの数値は、さまざまなエンタープライズ環境で確認された一般的な成果を示しています。

推奨データ

まずはこれらの基本的な属性とアクティビティから始め、必要に応じて分析範囲を広げてください。
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

属性

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

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

重要な理由

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

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

重要な理由

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

特定のアクティビティが発生した時点のタイムスタンプです。

重要な理由

期間に基づくすべてのKPIを計算し、イベントを時系列に並べるために使用します。

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

重要な理由

組織単位での分析と、チームレベルでのボトルネック検出が可能になります。

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

重要な理由

ビジネス上の重要度別に分析を分け、SLA分析を支えます。

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

重要な理由

個人レベルでのリソース分析と作業量の平準化が可能になります。

問題の根本的な原因を分類したものです。

重要な理由

組織的な問題の傾向分析を可能にし、先回りしたProblem Managementを支えます。

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

重要な理由

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

問題調査を開始した理由です。

重要な理由

受け身の作業と先回りした作業を区別し、成熟度を示す重要な指標になります。

問題を解決しなければならない目標日時です。

重要な理由

すべてのコンプライアンス指標と適時性指標を計算するための基準点です。

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

重要な理由

問題に伴う業務上の影響とユーザーの負担を定量化します。

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

重要な理由

コンプライアンス報告と失敗分析を簡単にします。

アクティビティ

追跡・最適化するプロセスのステップ

システムにProblem Investigationレコードを初めて作成した時点です。PBM:Problem Investigationフォームに新しいエントリが保存された際に、このイベントが明示的に記録されます。

重要な理由

プロセスインスタンスの開始を示します。全体のサイクル時間と初期応答指標を計算するために欠かせません。

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

重要な理由

引き継ぎ、たらい回しの影響、「Mean Time to Initial Assignment」KPIを測定するために重要です。

問題レコードがアクティブな分析段階へ移行したことを示します。「Status」フィールドが「Under Investigation」に変更された時点から推定します。

重要な理由

実際の作業段階の開始を示し、「Investigation Cycle Time」KPIを支えます。

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

重要な理由

「Workaround Publication Lead Time」KPIを支えます。インシデントの影響が軽減されたことを示します。

問題レコードが原因の判明を示す状態へ移行した時点です。「Status」が「Root Cause Identified」に変更された時点から推定します。

重要な理由

「Root Cause Investigation Cycle Time」ダッシュボードにおける重要なマイルストーンです。分析から解決策の策定への移行を示します。

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

重要な理由

「Root Cause to Change Lead Time」KPIの測定と、ProblemプロセスとChangeプロセスの間にあるサイロの特定に重要です。

恒久対応が正常に完了したことを確認した時点です。「Status」が「Solution Implemented」または「Completed」に変更されたことから推定します。

重要な理由

「Problem SLA Adherence Rate」に使用します。技術的な作業が完了したことを確認します。

問題レコードを最終的に管理上クローズすることです。このイベントでプロセスインスタンスが終了します。

重要な理由

標準の終了イベントです。サイクル時間全体の分析と「Incident Linkage Density」の計算に必要です。

解決前に問題レコードを終了することです。ステータスが「Cancelled」または「Rejected」になった時点で記録します。

重要な理由

無駄な作業や正当な重複を特定するために使用します。代替となる終了地点を示します。

よくある質問

よくある質問

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

一意のProblem Record ID、タイムスタンプ、Status ChangeやAssigned Groupなどのアクティビティ説明を含む基本的なイベントログが必要です。通常は、BMC Helixデータベース内のPBM:Problem Investigationテーブルから抽出します。多くのプロセスマイニングツールは、これらのテーブルに直接接続するか、CSVエクスポートをインポートしてプロセスフローをマッピングできます。

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

BMC Helixからのデータ抽出が確立されると、通常2~4週間以内に初期インサイトを生成できます。最初の段階ではシステムへの接続と主要なステータス変更のマッピングを行い、ベースラインモデルを作成します。その後の数週間で分析を精緻化し、記録の再割り当てを減らすなど、具体的な最適化の機会を特定します。

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

プロセスを自動的に修正することはできませんが、目標を達成できなかった記録の正確な経路を示し、SLA違反の根本原因を特定します。コンプライアンスを満たした記録と満たしていない記録を比較し、特定のサポートグループや問題の種類で遅延が起きやすいかを確認できます。これにより、優先度の高い問題を必要な時間内に処理できるよう、対象を絞ったトレーニングやリソースの再配分を行えます。

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

標準レポートを補完し、現在のステータスを静的に切り取ったスナップショットではなく、プロセスを時系列で把握できます。従来のレポートでは未解決の問題数を確認できますが、プロセスマイニングでは問題が時間の経過とともにシステム内をどのように移動したかを確認できます。この詳細な把握は、真のプロセス最適化や、標準のダッシュボードでは見落とされる隠れたボトルネックの特定に必要です。

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

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

無料トライアルを開始

クレジットカードは必要ありません。数分で設定できます。