Datatemplate voor Probleembeheer

BMC Helix ITSM
Datatemplate voor Probleembeheer

Datatemplate voor Probleembeheer

Deze template biedt een structuur voor het analyseren van workflows voor oorzaakanalyses in BMC Helix ITSM. Je vindt erin de benodigde attributen en procesactiviteiten voor een gedetailleerd event log, plus praktische aanwijzingen voor data-extractie. Met deze gids kun je verborgen bottlenecks opsporen en de weg naar een blijvende oplossing van incidenten verkorten.
  • Essentiële datavelden voor oorzaakanalyse
  • Gestandaardiseerde processtappen om bij te houden
  • Specifieke aanwijzingen voor data-extractie uit BMC Helix ITSM

Attributen voor Probleembeheer

Deze tabel bevat de aanbevolen datavelden voor het event log, zodat je de levenscyclus van probleembeheer grondig kunt analyseren.
5 Verplicht 9 Aanbevolen 5 Optioneel
Naam Beschrijving
Activiteit
Activity
De specifieke taak of statuswijziging die heeft plaatsgevonden.
Beschrijving

Dit attribuut staat voor de specifieke stap in het probleembeheerproces, zoals 'Probleemrecord geregistreerd', 'Hoofdoorzaak vastgesteld' of 'Oplossingendatabase bijgewerkt'. In BMC Helix worden deze activiteiten vaak afgeleid uit de statusgeschiedenis, auditlogs of specifieke transactietimestamps in de module Problem Investigation.

Dit attribuut vormt de basis voor procesontdekking. Door de volgorde van activiteiten te analyseren, maakt de process mining-tool een proceskaart die de werkelijke gang van zaken laat zien naast het ontworpen proces. Zo worden lussen, herstelwerk en afwijkingen van de standaardprocedure zichtbaar.

Nauwkeurige activiteitsnamen zijn belangrijk om te begrijpen wat er tijdens het proces daadwerkelijk is gebeurd. Met deze data kun je de tijd tussen specifieke stappen meten, bijvoorbeeld de tijd tussen het vaststellen van de hoofdoorzaak en het starten van een wijzigingsverzoek.

Waarom dit belangrijk is

Dit attribuut bepaalt de knooppunten op de proceskaart en maakt de workflow zichtbaar.

Waar vind je dit?

Afgeleid uit de statusgeschiedenis van PBM:Problem Investigation of PBM:AuditLogSystem

Voorbeelden
Probleemrecord geregistreerdToegewezen aan supportgroepOnderzoek gestartHoofdoorzaak vastgesteld
Probleemrecord
ProblemRecord
De unieke identificatiecode van de case voor het probleemonderzoek.
Beschrijving

Dit attribuut is de centrale identificatiecode van de case binnen het probleembeheerproces. In BMC Helix ITSM is dit meestal het veld 'Problem ID' (bijvoorbeeld PBI00000012345) in het formulier PBM:Problem Investigation. Het koppelt alle gerelateerde activiteiten, van de eerste registratie van het probleem tot de definitieve afsluiting en de evaluatie na invoering.

Bij process mining wordt dit attribuut gebruikt om afzonderlijke gebeurtenissen te groeperen in één procesinstantie. Analisten kunnen zo het volledige verloop van een specifiek probleemonderzoek bekijken. Zonder deze identificatiecode is het niet mogelijk om de reeks acties van verschillende supportgroepen en coördinatoren met elkaar in verband te brengen.

Dit veld is de primaire sleutel van het event log en is nodig voor alle berekeningen per case, zoals de totale doorlooptijd per probleem en het aantal problemen per prioriteitsniveau.

Waarom dit belangrijk is

Deze sleutel is nodig om het procesoverzicht op te bouwen en het verloop van specifieke problemen te volgen.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Problem ID'

Voorbeelden
PBI00000004512PBI00000004513PBI00000004514
Tijdstip van gebeurtenis
EventTime
De timestamp waarop de activiteit plaatsvond.
Beschrijving

Dit attribuut registreert de exacte datum en tijd waarop een activiteit plaatsvond. In BMC Helix ITSM gaat het om velden zoals 'Submit Date' en 'Last Modified Date', of om specifieke timestamps in geschiedenistabellen die bij statuswijzigingen horen.

Bij analyses wordt dit attribuut gebruikt om gebeurtenissen chronologisch te ordenen en tijdsduur te berekenen. Zo kun je de doorlooptijd tussen twee willekeurige processtappen meten, bijvoorbeeld de 'Investigation Cycle Time' of de 'Workaround Publication Lead Time'.

Nauwkeurige timestamps zijn belangrijk om bottlenecks te vinden. Door het tijdsverschil tussen opeenvolgende gebeurtenissen te berekenen, kunnen analisten precies bepalen waar vertraging ontstaat, bijvoorbeeld bij de eerste toewijzing of tijdens de laatste beoordelingsfase.

Waarom dit belangrijk is

Hiermee kun je alle KPI’s op basis van tijdsduur berekenen en gebeurtenissen op volgorde zetten.

Waar vind je dit?

Geschiedenistabellen of auditlogs van PBM:Problem Investigation

Voorbeelden
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
Bronsysteem
SourceSystem
Het systeem waar de data vandaan komt.
Beschrijving

Dit attribuut geeft aan uit welk softwaresysteem de procesdata is gehaald, in dit geval 'BMC Helix ITSM'. Het is vooral belangrijk in omgevingen met meerdere systemen, waar process mining data uit verschillende ITSM-, ontwikkel- of externe leverancierssystemen kan combineren.

Bij analyses dient dit veld als metadatakenmerk om de herkomst van een record te controleren. Als het procesoverzicht data uit BMC Helix voor probleembeheer combineert met data uit een apart systeem voor softwareontwikkeling, zoals Jira, kun je met dit attribuut de analyse uitsplitsen naar bronsysteem.

Het helpt ook bij technische probleemoplossing. Ontstaan er problemen met de datakwaliteit, dan kunnen data-engineers met het bronsysteem de oorzaak terugzoeken tot de specifieke extractieroutine of brondatabase.

Waarom dit belangrijk is

Dit attribuut maakt de herkomst traceerbaar en geeft context, vooral in procesoverzichten met meerdere systemen.

Waar vind je dit?

Vast ingesteld tijdens het extractieproces

Voorbeelden
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
Laatste data-update
LastDataUpdate
De timestamp waarop de data is geëxtraheerd of voor het laatst is bijgewerkt.
Beschrijving

Dit attribuut geeft aan wanneer de data voor het laatst in de process mining-applicatie is geladen. Zo weten analisten hoe actueel de data is die ze bekijken. Meestal wordt dit tijdstip vastgelegd door het extractiescript of de datapipeline.

Dit helpt voorkomen dat beslissingen worden genomen op basis van verouderde data. Als een manager bijvoorbeeld naar 'Open Problem Records' kijkt, maakt het veel uit of de data een uur geleden of een week geleden is bijgewerkt. Dat bepaalt hoe de huidige werkvoorraad moet worden geïnterpreteerd.

Dit attribuut wordt ook gebruikt voor incrementele dataladingen. Door het tijdstip van de laatste update bij te houden, kan het ETL-proces alleen records ophalen die sinds de vorige extractie zijn gewijzigd. Dat verbetert de prestaties en vermindert de belasting van het systeem.

Waarom dit belangrijk is

Zo blijft duidelijk hoe actueel de data is en kun je incrementele dataladingen uitvoeren.

Waar vind je dit?

Systeemtijd op het moment van extractie

Voorbeelden
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
Aanleiding voor onderzoek
InvestigationDriver
De reden waarom het probleemonderzoek is gestart.
Beschrijving

Dit attribuut classificeert de aanleiding voor het probleemrecord, zoals 'Incident Volume', 'Major Incident', 'Vendor Notification' of 'Proactive Trend Analysis'. In BMC Helix is dit het veld 'Investigation Driver'.

Dit attribuut ondersteunt het dashboard 'Proactive Identification Trends'. De organisatie kan ermee meten of er een verschuiving plaatsvindt van incidenten achteraf oplossen naar proactief probleembeheer, waarbij risico’s worden opgespoord voordat ze zich voordoen.

Door processtromen uit te splitsen naar 'Investigation Driver' kunnen verschillen in werkwijze zichtbaar worden. Proactieve problemen blijven bijvoorbeeld mogelijk langer in de wachtrij staan omdat ze geen directe uitval veroorzaken. Problemen die voortkomen uit een groot incident worden juist met spoed behandeld.

Waarom dit belangrijk is

Dit maakt onderscheid tussen reactief en proactief werk, een belangrijke maatstaf voor de volwassenheid van het proces.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Investigation Driver'

Voorbeelden
ReactiefProactiefTerugkerende incidenten
Aantal gerelateerde incidenten
RelatedIncidentCount
Het aantal incidenten dat aan deze probleemregistratie is gekoppeld.
Beschrijving

Dit attribuut geeft de impact van het probleem weer door het aantal gekoppelde incidenten te tellen. In BMC Helix is dit meestal het aantal gerelateerde registraties in het formulier HPD:Help Desk.

Dit attribuut wordt gebruikt voor de KPI ‘Dichtheid van incidentkoppelingen’. Een hoog aantal wijst op een probleem met grote impact dat veel meldingen bij de servicedesk veroorzaakt. Door dit te vergelijken met ‘Prioriteit’ zie je of problemen met veel incidenten ook echt als kritiek worden behandeld.

Het helpt ook om de achterstand te prioriteren. Een probleemregistratie met 500 gekoppelde incidenten verdient waarschijnlijk voorrang boven een probleem met de status ‘Kritiek’ en slechts één gekoppeld incident. Door het eerste probleem op te lossen, komt er immers meer capaciteit vrij bij de servicedesk.

Waarom dit belangrijk is

Dit geeft de operationele impact van het probleem en de hinder voor gebruikers weer.

Waar vind je dit?

Berekend door gerelateerde rijen in HPD:Associations of HPD:Help Desk te tellen

Voorbeelden
15120
Categorie hoofdoorzaak
RootCauseCategory
De classificatie van de onderliggende oorzaak van het probleem.
Beschrijving

Dit attribuut bevat de categorie die is gekozen toen de hoofdoorzaak werd vastgesteld, bijvoorbeeld 'Softwarefout', 'Hardwarestoring' of 'Proceshiaat'. In BMC Helix wordt deze meestal gekozen in de menu’s 'Root Cause' of 'Generic Categorization'.

Dit attribuut is belangrijk voor het overzicht 'Fix Effectiveness and Quality'. De organisatie kan hiermee specifieke soorten hoofdoorzaken vergelijken met herstelwerk of lange onderzoekstijden. Zo kan blijken dat problemen met 'Softwarefout' steeds twee keer zo lang duren om op te lossen als problemen met 'Hardwarestoring'.

Het attribuut wordt ook gebruikt om de 'Root Cause Categorization Rate' te berekenen. Een hoog percentage waarden als 'Unknown' of 'Other' wijst erop dat er mogelijk behoefte is aan betere technische training of meer gedetailleerde categorieën.

Waarom dit belangrijk is

Hiermee kun je trends in structurele problemen analyseren en proactief probleembeheer ondersteunen.

Waar vind je dit?

Formulier PBM:Problem Investigation, velden op het tabblad 'Root Cause' of categorisering

Voorbeelden
SoftwaremoduleNetwerkinfrastructuurMenselijke fout
Is SLA overschreden
IsSLABreached
Een indicator die aangeeft of de toegestane oplostijd is overschreden.
Beschrijving

Dit booleaanse attribuut geeft aan of de probleemregistratie de service level agreement heeft overschreden. De waarde wordt berekend door de timestamp van ‘Oplossing geverifieerd’ te vergelijken met de ‘Uiterste datum SLA’, of rechtstreeks overgenomen uit de SLM-status.

Dit attribuut is belangrijk voor het dashboard ‘SLA-naleving en trends in overschrijdingen’. Het maakt een eenvoudige uitsplitsing van het proces mogelijk: wel of niet volgens de SLA. Zo kun je kenmerken van mislukte processen makkelijk vinden. Zijn bijvoorbeeld bij alle cases met een overschreden SLA dezelfde supportgroep betrokken?

Het is ook een belangrijk filter voor oorzaakanalyses van procesfouten. Analisten kunnen filteren op ‘IsSLABreached = True’ en vervolgens op de proceskaart bekijken waar tijd verloren ging, bijvoorbeeld door lang wachten op goedkeuring van een leverancier.

Waarom dit belangrijk is

Dit maakt rapportages over compliance en analyses van procesfouten eenvoudiger.

Waar vind je dit?

Formulier SLM:Measurement of berekend

Voorbeelden
truefalse
Prioriteit
Priority
De berekende prioriteit van het probleem op basis van impact en urgentie.
Beschrijving

Dit attribuut geeft het prioriteitsniveau van het probleemrecord aan, bijvoorbeeld Kritiek, Hoog, Gemiddeld of Laag. In BMC Helix is dit meestal een berekend veld op basis van de gekozen waarden voor Impact en Urgency.

Bij analyses wordt dit attribuut gebruikt voor het dashboard 'Throughput and Priority Volume'. Organisaties kunnen hiermee controleren of de inzet van medewerkers aansluit op de behoeften van de organisatie. Kritieke problemen zouden bijvoorbeeld sneller moeten worden toegewezen en een kortere totale doorlooptijd moeten hebben dan problemen met een lage prioriteit.

Door op prioriteit te filteren, kun je verbeteringen gericht aanpakken. Een bottleneck in een proces met lage prioriteit is misschien acceptabel, maar dezelfde vertraging bij een kritiek proces vormt een aanzienlijk risico voor de bedrijfscontinuïteit en het behalen van SLA’s.

Waarom dit belangrijk is

Hiermee kun je analyses uitsplitsen naar belang voor de bedrijfsvoering en SLA’s analyseren.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Priority'

Voorbeelden
KritiekHoogGemiddeldLaag
Probleemcoördinator
ProblemCoordinator
De medewerker die is aangewezen om het onderzoek te coördineren.
Beschrijving

Dit attribuut vermeldt wie verantwoordelijk is voor het probleemrecord. In BMC Helix ITSM is dit het veld 'Problem Coordinator'. Deze persoon is verantwoordelijk voor het verloop van het probleem, ook als taken aan anderen worden gedelegeerd.

Dit attribuut ondersteunt het dashboard 'Support Group Workload Distribution'. Managers kunnen ermee zien of bepaalde medewerkers te veel onderzoeken behandelen terwijl anderen nog capaciteit hebben. Ook kun je prestaties per medewerker analyseren en vaststellen waar extra training nodig is of wie goed presteert.

Bij process mining is dit een attribuut van de medewerker die het werk uitvoert. Je ziet hoe het werk tussen medewerkers wordt overgedragen en kunt ontdekken of het proces te sterk afhankelijk is van één specifieke expert.

Waarom dit belangrijk is

Hiermee kun je de werkverdeling en werkdruk per medewerker analyseren.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Problem Coordinator'

Voorbeelden
John DoeJane SmithSysteembeheerder
Service-CI
ServiceCI
De belangrijkste bedrijfsservice of het configuratie-item waarop het probleem invloed heeft.
Beschrijving

Dit attribuut geeft aan welke Service Configuration Item (CI) bij het probleem hoort, zoals 'E-mailservice', 'SAP ERP' of 'wifi-netwerk'. In BMC Helix is dit vaak het veld 'Service+' of de primaire CI-relatie.

Bij analyses kun je probleemrecords hiermee uitsplitsen naar product of service. Zo ziet de IT-leiding welke services het kwetsbaarst zijn en de meeste probleemonderzoeken opleveren. Dit voegt een productdimensie toe aan het dashboard 'Throughput and Priority Volume'.

Door dit attribuut te vergelijken met 'Investigation Cycle Time' kun je zien of complexe services, zoals een centraal banksysteem, van nature langer onderzoek vergen dan standaardservices, zoals printen.

Waarom dit belangrijk is

Dit attribuut koppelt de procesprestaties aan specifieke producten of services van de organisatie.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'ServiceCI' of 'CI Name'

Voorbeelden
E-mailserviceSalarissysteemBedrijfs-VPN
Supportgroep
SupportGroup
Het technische team dat op dit moment aan het probleemonderzoek is toegewezen.
Beschrijving

Dit attribuut geeft aan welke supportgroep, bijvoorbeeld 'Server Admin' of 'Database Support', verantwoordelijk was voor het probleemrecord toen de gebeurtenis plaatsvond. In BMC Helix is dit het veld 'Assigned Group'.

Dit attribuut is belangrijk voor de dashboards 'Support Group Workload Distribution' en 'Support Group Reassignment Analysis'. Analisten kunnen de proceskaart per team uitsplitsen en zien welke groepen het meeste werk behandelen en waar bottlenecks in het onderzoek ontstaan.

Door overdrachten tussen supportgroepen te analyseren, kun je heen-en-weerbewegingen opsporen waarbij een ticket zonder oplossing tussen teams blijft gaan. Dat wijst vaak op onduidelijke verantwoordelijkheden of gebrekkig kennisbeheer binnen de organisatie.

Waarom dit belangrijk is

Hiermee kun je de organisatie analyseren en bottlenecks op teamniveau opsporen.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Assigned Group'

Voorbeelden
Servicedesk niveau 1Backoffice-ondersteuningNetwerkbeheer
Uiterste datum SLA
SLADueDate
De datum en tijd waarop het probleem uiterlijk moet zijn opgelost.
Beschrijving

Dit attribuut bevat de deadline voor het oplossen van het probleem, op basis van de service level agreement. In BMC Helix is dit vaak de ‘Target Resolution Date’ of een berekend timestamp voor een SLA-mijlpaal.

Dit attribuut vormt de basis voor het dashboard ‘SLA-naleving en trends in overschrijdingen’. Door deze timestamp te vergelijken met de timestamp van de activiteit ‘Oplossing geverifieerd’, berekent het systeem of de SLA is gehaald of overschreden.

Met deze datum in beeld zien analisten hoeveel tijd het team overhoudt. Worden problemen dagen van tevoren opgelost, of is het team telkens pas enkele minuten voor het verstrijken van de deadline klaar? Dit inzicht helpt bij capaciteitsplanning.

Waarom dit belangrijk is

Dit is het referentiepunt voor alle metingen van compliance en tijdigheid.

Waar vind je dit?

PBM: formulier Problem Investigation, veld ‘Target Resolution Date’

Voorbeelden
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
Aantal herindelingen
ReassignmentCount
Het aantal keer dat de supportgroep is gewijzigd.
Beschrijving

Dit attribuut telt hoe vaak de activiteit ‘Toegewezen aan supportgroep’ voorkomt voor één case. Het geeft rechtstreeks aan hoeveel wrijving er in het proces zit en hoe efficiënt de routering verloopt.

Dit attribuut wordt weergegeven in de grafiek ‘Analyse van herindelingen tussen supportgroepen’. Een hoog aantal, oftewel heen-en-weer sturen, wijst erop dat de eerste triage niet goed gaat of dat niemand duidelijk eigenaar is van complexe problemen. Het is een vroege aanwijzing voor langere doorlooptijden.

Managers gebruiken dit om te bepalen waar training nodig is. Als de servicedesk problemen met ‘Database’ steeds eerst naar ‘Netwerk’ stuurt en ‘Netwerk’ ze vervolgens terugstuurt, loopt het aantal herindelingen op. Dat maakt duidelijk dat betere scripts voor de eerste diagnose nodig zijn.

Waarom dit belangrijk is

Dit brengt verspilling, wrijving en onduidelijk eigenaarschap in het proces aan het licht.

Waar vind je dit?

Berekend op basis van de activiteitengeschiedenis

Voorbeelden
015
ID van gerelateerde wijzigingsaanvraag
RelatedChangeRequestId
De identificatiecode van de wijzigingsaanvraag die is gestart om het probleem op te lossen.
Beschrijving

Dit attribuut bevat de ID van de wijzigingsaanvraag, bijvoorbeeld CRQ0000..., die aan de probleemregistratie is gekoppeld. Het markeert de overgang van onderzoek naar de uitvoering van een permanente oplossing.

Dit attribuut is nodig voor de KPI ‘Doorlooptijd van oorzaak tot wijziging’. Hiermee kan process mining meten hoeveel tijd er zit tussen het vinden van de oorzaak en de start van het wijzigingsproces. Dit is een veelvoorkomend overdrachtsmoment waarop de voortgang stokt.

Ook helpt het om te controleren of het proces volledig is. Een probleemregistratie met de status ‘Voltooid’ die wordt gesloten zonder gekoppelde wijzigingsaanvraag of tijdelijke oplossing, kan erop wijzen dat het proces niet is gevolgd: de oorzaak is gevonden, maar nooit daadwerkelijk verholpen.

Waarom dit belangrijk is

Hiermee wordt het probleembeheerproces gekoppeld aan het verandermanagementproces.

Waar vind je dit?

PBM: tabblad Investigation Associations of Relationship

Voorbeelden
CRQ00000021345CRQ00000021346
Onderzoeksdoorlooptijd
InvestigationCycleTime
De tijd vanaf de start van het onderzoek tot het vaststellen van de oorzaak.
Beschrijving

Dit berekende duurattribuut meet de tijd tussen de activiteit ‘Onderzoek gestart’ en de activiteit ‘Oorzaak vastgesteld’. Het geeft de tijd weer waarin het probleembeheerproces daadwerkelijk waarde toevoegt.

Deze metriek wordt gebruikt in het dashboard ‘Doorlooptijd van oorzaakanalyse’. Managers zien hiermee hoe complex de technische problemen zijn en hoe efficiënt de onderzoeksteams werken. Afwijkingen kunnen iets zeggen over de aanpak: een uitzonderlijk korte doorlooptijd kan wijzen op giswerk, terwijl een zeer lange doorlooptijd kan betekenen dat het onderzoek is vastgelopen.

Door deze metriek te vergelijken tussen ‘Supportgroepen’ en ‘Prioriteiten’ kan de organisatie bepalen welke teams betere hulpmiddelen, training of ondersteuning van leveranciers nodig hebben om problemen sneller te diagnosticeren.

Waarom dit belangrijk is

Dit is de belangrijkste efficiëntiemeting voor de technische onderzoeksfase.

Waar vind je dit?

Berekend op basis van activiteitstimestamps

Voorbeelden
4500000120000
Regio
Region
De geografische regio die bij het probleem hoort.
Beschrijving

Dit attribuut geeft aan op welke geografische locatie het probleem is ontstaan of wordt behandeld, bijvoorbeeld Noord-Amerika of EMEA. In BMC Helix vind je deze informatie vaak in de velden ‘Regio’ of ‘Locatie’ bij de aanvrager of het getroffen bedrijfsmiddel.

Bij analyses kun je hiermee gegevens per regio uitsplitsen. Zo zie je of in bepaalde regio’s meer problemen voorkomen of problemen langer duren. Dat kan wijzen op verschillen in de bezetting van supportteams of de kwaliteit van de infrastructuur.

Voor internationale organisaties helpt dit om de dienstverlening overal op hetzelfde niveau te houden. Duurt de ‘Onderzoeksdoorlooptijd’ in ‘APAC’ twee keer zo lang als in ‘NAM’? Dan is het zinvol om te kijken naar de inzet van middelen of de naleving van processen in die regio.

Waarom dit belangrijk is

Hiermee kun je de procesprestaties per regio vergelijken.

Waar vind je dit?

PBM: formulier Problem Investigation, veld ‘Regio’

Voorbeelden
Amerika’sEMEAAPAC
Status tijdelijke oplossing
WorkaroundStatus
Geeft aan of er een geldige tijdelijke oplossing is gevonden en gepubliceerd.
Beschrijving

Dit attribuut houdt de status van de tijdelijke oplossing bij. Het kan een eenvoudige ja/nee-waarde zijn (‘Has Workaround’) of een status als tekst. In BMC Helix wordt dit vaak afgeleid uit de aanwezigheid van tekst in het veld ‘Workaround’ of uit een specifieke statusindicator.

Dit attribuut is belangrijk voor het dashboard ‘Prestaties bij publicatie van tijdelijke oplossingen’. Het laat zien hoe goed het team de impact beperkt terwijl het de oorzaak onderzoekt. In een procesweergave met het filter ‘Geen tijdelijke oplossing’ zie je cases waarin de organisatie tijdens het onderzoek de volle impact ondervindt.

Het helpt ook bij kwaliteitscontroles. Een probleemregistratie sluiten zonder permanente oplossing (wijzigingsaanvraag) én zonder tijdelijke oplossing is doorgaans een procesfout die nader onderzoek vraagt.

Waarom dit belangrijk is

Dit meet hoe goed de impact tijdens het onderzoek wordt beperkt.

Waar vind je dit?

PBM: formulier Problem Investigation, controle op inhoud van het veld ‘Workaround’

Voorbeelden
ActiefGeenBuiten gebruik
Verplicht Aanbevolen Optioneel

Activiteiten voor Probleembeheer

Dit zijn de belangrijkste processtappen en statuswijzigingen om bij te houden. Zo krijg je volledig zicht op de onderzoeks- en oplossingsfasen.
9 Aanbevolen 4 Optioneel
Activiteit Beschrijving
Hoofdoorzaak vastgesteld
Het moment waarop de status van het probleemrecord aangeeft dat de oorzaak bekend is. Dit wordt afgeleid uit een wijziging van Status naar 'Root Cause Identified'.
Waarom dit belangrijk is

Een belangrijk moment voor het dashboard 'Root Cause Investigation Cycle Time'. Dit markeert de overgang van analyse naar het uitwerken van een oplossing.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Status' = 'Root Cause Identified'.

Vastleggen

Vergelijk het statusveld om de overgang naar Root Cause Identified vast te stellen

Gebeurtenistype inferred
Onderzoek gestart
De overgang van het probleemrecord naar een actieve analysefase. Dit wordt afgeleid uit een wijziging van het veld Status naar 'Under Investigation'.
Waarom dit belangrijk is

Dit markeert het begin van het daadwerkelijke werk en ondersteunt de KPI 'Investigation Cycle Time'.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Status' = 'Under Investigation'.

Vastleggen

Vergelijk het statusveld om de overgang naar Under Investigation vast te stellen

Gebeurtenistype inferred
Oplossing gecontroleerd
Het moment waarop is bevestigd dat de permanente oplossing werkt. Dit wordt afgeleid uit een wijziging van Status naar 'Solution Implemented' of 'Completed'.
Waarom dit belangrijk is

Wordt gebruikt voor 'Problem SLA Adherence Rate'. Bevestigt dat het technische werk is afgerond.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Status' = 'Solution Implemented' of 'Completed'.

Vastleggen

Vergelijk het statusveld om de overgang naar Solution Implemented vast te stellen

Gebeurtenistype inferred
Probleemrecord geannuleerd
Een probleemrecord beëindigen voordat het is opgelost. Vastgelegd wanneer de status 'Cancelled' of 'Rejected' wordt.
Waarom dit belangrijk is

Spoor onnodig werk of terechte duplicaten op. Dit is een alternatieve eindstatus.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Status' = 'Cancelled' of 'Rejected'.

Vastleggen

Vergelijk het statusveld om de overgang naar Cancelled vast te stellen

Gebeurtenistype inferred
Probleemrecord geregistreerd
Het moment waarop een Problem Investigation-record voor het eerst in het systeem wordt aangemaakt. Deze gebeurtenis wordt vastgelegd wanneer een nieuwe invoer wordt opgeslagen in het formulier PBM:Problem Investigation.
Waarom dit belangrijk is

Dit markeert het begin van de procesinstantie. Nodig om de totale doorlooptijden en de eerste responstijden te berekenen.

Waar vind je dit?

Formulier PBM:Problem Investigation, timestamp van 'Submit Date' of registratielog van de aanmaak met 'Status' = 'Draft'.

Vastleggen

Geregistreerd wanneer een PBM:Problem Investigation-record wordt aangemaakt

Gebeurtenistype explicit
Probleemrecord gesloten
De definitieve administratieve afsluiting van het probleemrecord. Deze gebeurtenis beëindigt de procesinstantie.
Waarom dit belangrijk is

De standaardgebeurtenis aan het einde van het proces. Nodig voor een volledige analyse van de doorlooptijd en de berekening van 'Incident Linkage Density'.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Status' = 'Closed'.

Vastleggen

Vergelijk het statusveld om de overgang naar Closed vast te stellen

Gebeurtenistype inferred
Tijdelijke oplossing vastgelegd
Tekst invoeren in of wijzigen van het veld Workaround van het probleemrecord. Deze gebeurtenis geeft aan dat een tijdelijke oplossing is gedocumenteerd.
Waarom dit belangrijk is

Ondersteunt de KPI 'Workaround Publication Lead Time' en geeft aan dat de impact van het incident wordt beperkt.

Waar vind je dit?

Formulier PBM:Problem Investigation, wijzigingen in het tekstveld 'Workaround'.

Vastleggen

Controleer of het veld 'Workaround' is bijgewerkt met een waarde

Gebeurtenistype inferred
Toegewezen aan supportgroep
De toewijzing van het probleemrecord aan een specifiek technisch team. Vastgelegd door wijzigingen in het veld 'Assigned Group' te volgen.
Waarom dit belangrijk is

Nodig om overdrachten, heen-en-weerbewegingen en de KPI 'Mean Time to Initial Assignment' te meten.

Waar vind je dit?

Formulier PBM:Problem Investigation, wijzigingsgeschiedenis van het veld 'Assigned Group' of auditlog.

Vastleggen

Vergelijk het veld 'Assigned Group' voor en na de wijziging

Gebeurtenistype inferred
Wijzigingsverzoek gestart
Een Infrastructure Change Request koppelen aan het probleemonderzoek. Dit markeert het begin van de invoeringsfase.
Waarom dit belangrijk is

Nodig voor de KPI 'Root Cause to Change Lead Time' en om silo’s tussen Problem Management en Change Management op te sporen.

Waar vind je dit?

Tabel PBM:Investigation_Associations of invulling van het veld 'Infrastructure Change ID'.

Vastleggen

Geregistreerd wanneer een koppeling wordt aangemaakt in PBM:Investigation_Associations

Gebeurtenistype explicit
Bekende fout aangemaakt
Een Known Error-record aanmaken dat is gekoppeld aan het probleemonderzoek. Dit is een gebeurtenis waarbij een gerelateerd record wordt aangemaakt.
Waarom dit belangrijk is

Dit geeft aan dat het probleem formeel is vastgelegd voor bredere communicatie en opvolging op de lange termijn.

Waar vind je dit?

Een record aanmaken in PBM:Known Error dat is gekoppeld aan het PBM:Problem Investigation-ID.

Vastleggen

Geregistreerd wanneer een PBM:Known Error-record wordt aangemaakt

Gebeurtenistype explicit
Coördinator opnieuw toegewezen
Een wijziging van de Problem Coordinator binnen een supportgroep. Vastgelegd door het veld 'Problem Coordinator' te volgen.
Waarom dit belangrijk is

Helpt bij het analyseren van de werkverdeling en bottlenecks rond individuele medewerkers.

Waar vind je dit?

Formulier PBM:Problem Investigation, wijzigingsgeschiedenis van het veld 'Problem Coordinator'.

Vastleggen

Vergelijk het veld 'Problem Coordinator' voor en na de wijziging

Gebeurtenistype inferred
Evaluatie na invoering uitgevoerd
De PIR-fase is afgerond. Dit wordt vastgelegd wanneer de status verandert vanuit een PIR-status of wanneer een gekoppelde PIR Task wordt gesloten.
Waarom dit belangrijk is

Ondersteunt rechtstreeks 'Post Implementation Review Compliance' en kwaliteitsaudits van processen.

Waar vind je dit?

Formulier PBM:Problem Investigation, specifieke markering 'PIR Required' of afronding van een gekoppelde Task van het type 'PIR'.

Vastleggen

Afgeleid uit de afronding van de PIR-status of het sluiten van een PIR Task

Gebeurtenistype inferred
Oplossingendatabase bijgewerkt
De status van het record verandert in 'Solution Database'. Dit geeft aan dat een permanente oplossing is voorgesteld of vastgesteld.
Waarom dit belangrijk is

Volgt de voortgang van het uitwerken van een oplossing voordat deze wordt ingevoerd.

Waar vind je dit?

Formulier PBM:Problem Investigation, veld 'Status' = 'Solution Database'.

Vastleggen

Vergelijk het statusveld om de overgang naar Solution Database vast te stellen

Gebeurtenistype inferred
Aanbevolen Optioneel

Extractiegidsen

Zo haal je data over probleembeheer uit BMC Helix ITSM

Klaar om aan de slag te gaan?

Verbeter de stabiliteit van je dienstverlening door deze template vandaag nog toe te passen op BMC Helix ITSM-data. Heb je vragen over de inrichting, dan helpt ons team je graag verder.

Pak bottlenecks in Probleembeheer vandaag aan

Verkort doorlooptijden met 30% en verbeter de stabiliteit van de dienstverlening.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten ingesteld.