Loading
Probleembeheer identificeert de hoofdoorzaak en elimineert terugkerende problemen

Probleembeheer identificeert de hoofdoorzaak en elimineert terugkerende problemen

Help een probleemmanager terugkerende incidenten te koppelen aan een probleem, de hoofdoorzaak te identificeren, herstel te coördineren en te controleren of herhaling of impact afneemt.

Gebruikscase in een oogopslag

Persoon: Een probleemmanager die verantwoordelijk is voor het identificeren van systemische oorzaken, het coördineren van onderzoek en het voorkomen van terugkerende serviceonderbrekingen

Klus te klaren: Terugkerende incidenten koppelen aan één probleemrecord, de hoofdoorzaak vaststellen en documenteren, en een permanente oplossing of een expliciete risicobeslissing stimuleren

Uitgangspunt: Incidenthistorie, servicegegevens of operationele trends geven aan dat dezelfde of gerelateerde onderbreking terugkeert

Geslaagd resultaat: Het probleem heeft een ondersteunde analyse van de hoofdoorzaak, gerelateerde incidenten en herstelrecords zijn traceerbaar, betroffen gebruikers hebben goedgekeurde richtlijnen en uit gegevens na wijziging blijkt dat herhaling of impact is afgenomen.

Gebruik dit scenario om te bepalen of een terugkerend probleem wordt begrepen en gecontroleerd. Gebruik de gerelateerde Help-onderwerpen voor stappen om records te maken en te koppelen, probleemanalyse bij te werken, een oplossing te documenteren, een veranderingsverzoek te maken, risico te accepteren, een probleem opnieuw te openen en te sluiten.

Een patroon detecteren dat het onderzoeken waard is

Begin met bewijs van een gedeelde onderliggende aandoening in plaats van alleen het aantal incidenten. Vergelijk symptomen, fouthandtekeningen, betroffen services en configuratie-items (CI's), timing, recente wijzigingen, gebruikerspopulaties, oplossingen en herhaling na serviceherstel. Soortgelijke bewoordingen kunnen verschillende oorzaken beschrijven, terwijl incidenten met verschillende bewoordingen uit dezelfde fout kunnen voortvloeien.

Bewijs Vraag over probleemmanager Beslissing die het ondersteunt
Terugkering Welke incidenten herhalen zich nadat de service is hersteld? Open een formeel probleem of ga door met incidentbewaking.
Gemeenschappelijk toepassingsgebied Welke service, CI, versie, locatie of gebruikersgroep wordt gedeeld? Definieer het bereik van het onderzoek en de betrokken gebruikers.
Bedrijfseffect Hoe vaak doet het probleem zich voor en welke onderbreking veroorzaakt het? Stel de impact, urgentie, prioriteit en het niveau van onderzoek in.
Bestaande records Is een open probleem, bekende fout, artikel of wijziging al bezig met het patroon? Koppel bestaand werk en werk het bij in plaats van het te dupliceren.
Huidige besturingselementen Welke oplossingen herstellen de service en waar mislukken ze? Bescherm gebruikers terwijl permanent herstel wordt onderzocht.
Gereedheid voor onderzoek Zijn logboeken, tijdlijnen, wijzigingen, eigendom en technische expertise beschikbaar? Wijs een eigenaar toe en plan het onderzoek.

Gebruik probleemdashboards om trends, open werk, SLA-inbreuken (Service Level Agreement), niet-toegewezen records, oplossingstijd en oplossingscodepatronen te vinden. Behandel dashboardgegevens als een onderzoekslead in plaats van te bewijzen dat incidenten een gemeenschappelijke oorzaak hebben. Zie Probleembeheerdashboard voor IT-services voor details over dashboardmeetgegevens.

Het probleem vaststellen zonder herstel te vertragen

Incidentbeheer herstelt de service voor elke actieve onderbreking. Probleembeheer onderzoekt en verwijdert de systemische oorzaak. Houd die uitkomsten gescheiden: een incident kan worden opgelost via een tijdelijke oplossing terwijl het gerelateerde probleem open blijft, en een probleem mag niet alleen worden gesloten omdat het laatste incident geen gevolgen meer heeft voor gebruikers.

Maak of selecteer één probleem dat de terugkerende voorwaarde binnen het juiste bereik beschrijft. Bevestig het onderwerp, de beschrijving, de categorie, de subcategorie, de betroffen services en CI's, de impact, urgentie, prioriteit, eigenaar en onderzoeksstatus. Koppel de ondersteunende incidenten aan andere relevante problemen, veranderingsverzoeken, releases of Knowledge artikelen zodat onderzoekers bewijs van toeval kunnen onderscheiden.

Maak niet één probleem voor elk incident of één breed probleem voor niet-gerelateerde mislukkingen. Gebruik koppelingen zoals Veroorzaakt door en Soortgelijke alleen wanneer het beschikbare bewijs de relatie ondersteunt.

Als de proactieve actie Soortgelijke problemen koppelen is ingeschakeld, kan deze automatisch probleemrecords koppelen op basis van semantische gelijksoortigheid. Een soortgelijke koppeling brengt geen relatie Veroorzaakt door tot stand. Controleer automatisch gekoppelde problemen voordat u ze gebruikt als bewijs van een gedeelde hoofdoorzaak.

Als u records handmatig wilt koppelen, opent u het probleem. Klik op het tabblad Koppelingen op Koppelen en selecteer vervolgens een recordtype en relatietype, zoals Veroorzaakt door of Vergelijkbaar. Als u een koppeling verwijdert, wordt de gekoppelde record niet verwijderd. Oplossen staat los van koppelen en kan meerdere gerelateerde records sluiten. Controleer daarom de geselecteerde records voordat u op Oplossen klikt.

Zie Problemen voor IT-services beheren voor stappen om problemen te maken en te koppelen, problemen op te lossen, risico's te accepteren en problemen opnieuw te openen. Zie Incidenten beheren voor IT-services als u rechtstreeks vanuit een incident een probleem wilt maken.

De hoofdoorzaak onderzoeken en vaststellen

Stel een testbare verklaring samen op basis van incidenttijdlijnen, logboeken, telemetrie, configuratie- en activumgegevens, recente wijzigingen, bekende fouten, Knowledge artikelen en expertise op het gebied van onderwerpen. Reproduceer de fout veilig wanneer mogelijk. Vergelijk betroffen en niet-beïnvloede omstandigheden, betwist concurrerende verklaringen en leg vast welk bewijs elke hypothese bevestigt of afwijst.

Documenteer de causale keten in plaats van het symptoom te herhalen. Leg uit wat de mislukte voorwaarde is, waarom deze de waargenomen impact heeft veroorzaakt, wat het betrof en onder welke omstandigheden het probleem zich opnieuw kan voordoen. Vermeld de records of tests die de conclusie ondersteunen. Markeer onopgeloste aannames en wijs vervolgwerk toe in plaats van gevolgtrekkingen als feit te presenteren.

Houd de geconfigureerde mijlpaal voor de hoofdoorzaak bij zonder afbreuk te doen aan de onderzoekskwaliteit. De standaard Problem SLA houdt de voltooiingstijd van de rootoorzaak bij voor problemen met kritieke en hoge prioriteit, maar het beleid van uw organisatie kan verschillen. Het voltooien van de mijlpaal bewijst niet dat de analyse correct is. Zie SLA-beleid voor probleem voor IT-services.

Impact verminderen met een tijdelijke oplossing of bekende fout

Wanneer een veilige tijdelijke methode onderbrekingen vermindert, documenteert u de toepasbaarheid, vereisten, stappen, beperkingen, risico's en verificatieresultaten ervan in de tijdelijke oplossingsinformatie van het probleem. Maak de begeleiding beschikbaar voor incidentuitvoerders zodat ze de service consistent kunnen herstellen terwijl de permanente oplossing in behandeling is.

Maak of werk een Knowledge artikel bij over een bekende fout wanneer een bevestigde hoofdoorzaak en een herbruikbare oplossing beschikbaar moeten zijn buiten de probleemrecord. Verwijder recordspecifieke en gevoelige details, routeer het artikel door het geconfigureerde beoordelingsproces en controleer of de beoogde ondersteuningsdoelgroep het kan vinden. Een tussenoplossing controleert symptomen of gevolgen; het neemt de onderliggende oorzaak niet weg.

Als er geen veilige oplossing is, vermeldt u dat expliciet en versterkt u de bewaking, escalatie, communicatie en herstelvoorbereiding. Gebruik een Knowledge artikel om een geverifieerde tijdelijke oplossing beschikbaar te maken voor de beoogde doelgroep. Zie Belangrijkste werkstromen in IT-services.

De oorzaak elimineren door gecontroleerde verandering

Nadat voldoende bewijs de hoofdoorzaak en de oplossing ondersteunt, maakt en koppelt u een veranderingsverzoek vanuit het probleem. Neem het betrokken bereik, causaal bewijs, voorgestelde oplossing, implementatievereisten, testplan, terugdraaibenadering, planningsbeperkingen en verificatiecriteria op. Houd het probleem open terwijl de wijziging doorgaat door middel van risicobeoordeling, goedkeuring, planning, implementatie en verificatie.

De uitkomst van de wijziging moet de causale claim testen. Bevestig dat de beoogde voorwaarde is gewijzigd zoals bedoeld, dat de servicetoestand acceptabel is gebleven, dat terugdraaien niet nodig was of succesvol was, en dat er geen materiële bijwerkingen zijn opgetreden. Een met succes geïmplementeerde wijziging is niet voldoende als de terugkerende fout aanhoudt.

Wanneer een permanente oplossing niet haalbaar is, gebruikt u Risico accepteren alleen nadat de juiste belanghebbenden de resterende impact, waarschijnlijkheid, huidige controles, eigendom en beoordelingsvoorwaarden hebben begrepen. Noteer de rechtvaardiging en de voorwaarden die bewaking of heropening activeren. Risicoacceptatie is een geregeerde beslissing, geen vervanging van onvolledige analyse. Zie Problemen voor IT-services beheren voor stappen voor veranderingsverzoeken en risicoacceptatie.

Terugkeringsvermindering controleren en sluiten

Observeer de service gedurende een periode en volume die passen bij het oorspronkelijke terugkeringspatroon. Vergelijk de frequentie van incidenten vóór en na het verhelpen, betroffen gebruikers of transacties, foutpercentages, downtime, gebruik van tijdelijke oplossingen, ondersteuningsinspanning en uitkomsten op serviceniveau. Houd rekening met seizoensgebondenheid, verkeer, releases en rapportagewijzigingen voordat u verbetering toekent aan de oplossing.

Sluit het probleem alleen wanneer de record de ondersteunde hoofdoorzaak, oplossingsgegevens, gekoppelde incidenten en oplossingen, verificatiebewijs, resterend risico en herbruikbare Knowledge bevat. Los gerelateerde koppelingen op volgens het proces van uw organisatie, met behoud van hun historie. Open het probleem opnieuw wanneer het probleem opnieuw optreedt, de causale verklaring wordt weerlegd of nieuw bewijs de vereiste actie wijzigt.

Probleembeheer is succesvol wanneer een geverifieerde oplossing of expliciete risicobeslissing resulteert in een traceerbare vermindering van herhaling of impact. Het sluiten van een probleem, het publiceren van een artikel of het voltooien van een wijziging alleen betekent niet dat het terugkerende probleem is opgelost.

Gebruik AI als assistentie, niet als bewijs

Indien geconfigureerd, kan Einstein een probleem opstellen op basis van een incident en kunnen Agentforce acties problemen samenvatten, kenmerken controleren, gerelateerde records vinden, oplossingen voorstellen en samenvattingen van hoofdoorzaken of oplossingen opstellen. Controleer gegenereerde velden en koppelingen voordat u ze opslaat of ernaar handelt.

Gegenereerde samenvattingen en voorgestelde correcties zijn geen geverifieerd hoofdoorzaakbewijs. Bevestig elke materiële claim tegen logboeken, records, tests, vertrouwde Knowledge bronnen en onderwerpexperts. Behoud het onderscheid tussen een semantische overeenkomst, een plausibele hypothese en een aangetoonde oorzaak. Zie Automatisch problemen maken op basis van incidenten met Einstein, AI-acties voor probleembeheer en proactieve acties voor IT-problemen.

Bevestigen dat Probleembeheer gereed is

Voordat u dit proces breder implementeert, controleert u of Probleembeheer en de bijbehorende veldvalidaties, prioriteitsmatrix, recordlay-outs, koppelingen, dashboards en SLA's uw proces ondersteunen. Controleer ook of de vereiste componenten Knowledge, Change Management en Configuration Management Database (CMDB) zijn geconfigureerd. Einstein, Agentforce en proactieve acties zijn optionele mogelijkheden die afzonderlijke set-up en machtigingen vereisen.

Wijs de juiste groep machtigingensets voor Probleembeheer of Probleemvervuller toe. Wijs ook de vereiste machtigingen toe om risico te accepteren, problemen opnieuw te openen, incidenten, veranderingsverzoeken en releases te koppelen aan problemen, en koppelingen op te lossen. Zie Probleembeheer instellen voor IT-services en Probleembeheermachtigingensets voor IT-services.

Valideer de configuratie voordat u deze breder implementeert. Controleer of een geautoriseerde gebruiker probleemrecords en -dashboards kan vinden, analyse- en oplossingsvelden kan inspecteren en gerelateerde incidenten en andere koppelingen kan weergeven. Controleer of het juiste veranderingsverzoek en de juiste risicoacties beschikbaar zijn voor de status van de record, samen met geconfigureerde Knowledge en AI-assistentie. Sluit bij het testen elke stroom voor maken, bewerken, vragenlijsten, genereren, goedkeuren of sluiten af zonder wijzigingen op te slaan.

 
Wordt geladen
Salesforce Help | Article