Datatemplate voor Probleembeheer
Datatemplate voor Probleembeheer
- Essentiële datavelden voor oorzaakanalyse
- Gestandaardiseerde processtappen om bij te houden
- Specifieke aanwijzingen voor data-extractie uit BMC Helix ITSM
Attributen voor Probleembeheer
| 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
|
|||
Activiteiten voor Probleembeheer
| 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
|
|||
Extractiegidsen
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.
Geen creditcard nodig. Binnen enkele minuten ingesteld.