Automatiser livssyklus for serviceordre og SLA-styring med Power Platform

Power Platform kan brukes til å bygge en løsning som automatiserer ende-til-ende-livssyklusen for serviceordrer. Denne tilnærmingen effektiviserer oppretting av serviceordreforespørsler, administrerer godkjenningsarbeidsflyter på tvers av flere faser, håndhever SLA-basert livssyklusadministrasjon og håndterer avslutningsprosesser. Det gir også et sentralisert system for juridiske og kontraherende team for å administrere serviceordrekontrakter og tilknyttede signerte dokumenter.

Tips

Denne artikkelen inneholder et eksempelscenario og en generalisert eksempelarkitektur for å illustrere hvordan du utformer en løsning som automatiserer tjenesteforespørselslivssykluser, godkjenninger, SLA-styring og avslutning ved hjelp av Power Apps, Power Automate, Dataverse og Microsoft 365.

Arkitekturdiagram

Diagram for Power Platform-arkitektur som viser brukere, sikkerhet, datavers, modelldrevet brukergrensesnitt for apper, Power Automate og Microsoft 365 integrations.

Workflow

Arbeidsflyten består av tre hovedprosesser: arbeidsflyt for serviceordre, arbeidsflyt for serviceavtale og arbeidsflyt for avslutning. Hver arbeidsflyt har ulike faser og godkjenningsprosesser.

Arbeidsflyt for serviceordre

En bruker starter forespørselsprosessen for serviceordren ved å fylle ut et skjema i den modelldrevne appen. Andre brukere, for eksempel den kommersielle ansvarlige gruppebrukeren og den primære ansvarlige brukeren, er involvert i godkjenningsprosessen på ulike stadier.

Arbeidsflyten er som følger:

  1. Brukeren får tilgang til hjemmesiden, som er en egendefinert side som er innebygd i den modelldrevne appen. Den egendefinerte siden har hurtigkoblinger til:

    • Få tilgang til eksisterende serviceordre, serviceavtale (serviceavtale) eller avslutningsforespørsler
    • Opprett ny forespørsel om serviceordre, serviceavtale eller oppsigelse
    • Vis tilordnede oppgaver
    • Administrator-knappen synlig for administratorgruppemedlemmer
  2. Brukeren velger Ny serviceordre fra hjemmesiden. Et nytt serviceordreskjema vises med faner for å angi serviceordredetaljer. Brukeren kan legge ved dokumenter i den nylig opprettede serviceordren ved hjelp av det innebygde SharePoint delnettalternativet.

  3. Hvis du vil opprette serviceordreforespørselen, velger brukeren den egendefinerte knappen Send forespørsel øverst på siden. Følgende handlinger finner sted:

    1. En ny serviceordre opprettes med en ny serviceordre-ID.

    2. Statusen for forespørselen oppdateres til forespurt serviceordre.

    3. En ny oppgave opprettes i oppgavetabellen og tilordnes til eierteamet for den kommersielle ansvarlige gruppen.

    4. Brukeren kan ikke lenger redigere forespørselen.

    5. Forretningsprosessflyten oppdateres til neste fase.

    Når brukeren velger den egendefinerte knappen, kjøres et skript for å oppdatere forespørselsstatusen og utløse en Power Automate flyt som utfører alle de foregående handlingene. Skriptet i det modelldrevne appskjemaet kontrollerer forespørselsstatusen og den tilordnede brukeren. Feltene blir skrivebeskyttet for alle unntatt den kommersielt ansvarlige gruppen. Denne betingelsen gjelder for alle de egendefinerte knappene som er tilgjengelige i de ulike fasene.

Den kommersielle ansvarlige brukeren tilordner eller avviser forespørselen på følgende måte:

  1. Den kommersielle ansvarlige brukeren logger på og velger den tilordnede oppgaven under Min oppgave.

  2. Den kommersielle ansvarlige brukeren gjennomgår forespørselen og godkjenner eller avviser forespørselen ved å velge den tilsvarende egendefinerte knappen:

    • Tilordne hovedansvarlig
    • Avvis forespørsel
  3. Ved avslag avvises forespørselen, og et varsel sendes til tjenesteordreforføreren.

  4. Når brukeren velger Tilordne primæransvarlig, flyttes forespørselen til neste fase.

    1. Forespørselsstatusen oppdateres til Venter på pr-godkjenning.

    2. Fasen for forretningsprosessflyten oppdateres.

    3. En ny oppgave opprettes for den primære ansvarlige brukeren. Den forrige oppgaven som er tilordnet den kommersielle ansvarlige brukeren, er fullført.

    4. Et varsel sendes til den primære ansvarlige brukeren.

Den primære ansvarlige brukeren godkjenner, avviser eller ber om endringer på følgende måte:

  1. Den primære ansvarlige brukeren logger på og velger den tilordnede oppgaven under Min oppgave.

  2. Den primære ansvarlige brukeren velger å godkjenne, avvise eller sende for endringer. Disse egendefinerte knappene er bare synlige for brukeren som er tilordnet pr til forespørselen når forespørselen har statusen Venter på PR-godkjenning.

    • Godkjenn:

      1. Forespørselsstatusen er merket som godkjent. Denne statusendringen implementeres gjennom et egendefinert skript skrevet på en egendefinert knapp.

      2. Et varsel sendes til den kommersielle ansvarlige gruppen og serviceordreforespørselen.

      3. Forespørselsstatusen oppdateres til ventende sluttsigneringsprosess.

      4. En oppgave tilordnes den kommersielle ansvarlige gruppen.

      5. Forretningsprosessflyten oppdateres til neste fase.

      6. Den primære ansvarlige brukerens oppgave er fullført.

    • Avvis:

      1. Forespørselen er merket som avvist.

      2. Forretningsprosessen oppdateres til Avvist-fasen.

      3. Et varsel sendes til serviceordreforespørselen og den kommersielle ansvarlige gruppen.

    • Send til endring:

      1. Forespørselen sendes tilbake til serviceordreforespørselen for endringer.

      2. Forespørselsstatusen oppdateres til serviceordreforespørselen pågår .

      3. Forretningsprosessflyten oppdateres til startfasen.

      4. Et e-postvarsel sendes til serviceordreforespørselen med en kobling til serviceordreforespørselen.

    Når den primære ansvarlige brukeren avviser eller godkjenner forespørselen, eksporteres og lagres et PDF-dokument i serviceordren SharePoint library. PDF-filen genereres ved hjelp av dokumentmalfunksjonen i Dataverse, der brukeren oppretter malen i Word ved hjelp av XML-enhetsattributter. En Power Automate flyt kaller PDF-dokumentmal-API-en for å generere PDF-versjonen og eksporterer alle dataene i tjenesteforespørselen. Dokumentmal-ID-en og serviceordren Global unik identifikator (GUID) sendes til Power Automate flyt.

I den siste signeringsfasen signerer den kommersielle ansvarlige brukeren dokumentet og fullfører forespørselen. Brukeren kan bare se fanene som er relatert til dokumentsigneringsprosessen. Alle andre faner er skjult. Denne funksjonaliteten implementeres ved hjelp av XRM API og JavaScript i skjemaet.

  1. På den første fanen ser den kommersielle ansvarlige brukeren knappen Last opp signert dokument .

  2. Når brukeren velger knappen, uthever appen den neste fanen, som inneholder SharePoint dokumentundernett og PDF-dokumentet som ble generert i forrige trinn.

  3. Den kommersielle ansvarlige brukeren laster ned PDF-dokumentet, signerer det manuelt og laster det opp i dokumentbibliotekfanen.

  4. En egendefinert knapp for fullføringsprosess øverst blir tilgjengelig.

  5. Når den kommersielle ansvarlige brukeren velger knappen, blir forespørselen skrivebeskyttet.

  6. Når forespørselen er fullført, sendes et varsel til brukeren, den kommersielle ansvarlige gruppen og den primære ansvarlige brukeren. En Power Automate-flyt markerer forretningsprosessflyten og oppgaven som er tildelt som fullført.

SLA-arbeidsflyt

Arbeidsflyten for serviceavtale (SLA) startes etter at serviceordreforespørselen er godkjent. Serviceavtaleforespørselen har en lignende arbeidsflyt som serviceordreforespørselen, med godkjenningsfaser og oppgavetilordninger.

Serviceavtalen er gyldig i 18 måneder som standard, og en serverdel Power Automate jobb kjører daglig for å se etter utløpsdato for serviceavtale. Når utløpsdatoen for serviceavtalen samsvarer med gjeldende dato, markerer jobben serviceavtalen og den tilknyttede serviceordren som avsluttet, og oppdaterer tilsvarende e-postvarsler og forretningsprosessflytfaser for begge enhetene.

Hvis du vil starte SLA-arbeidsflyten, velger brukeren Opprett ny SLA-forespørsel for å åpne et nytt SLA-skjema . I dette skjemaet kan brukeren bare velge en fullført serviceordreforespørsel som de selv opprettet.

Avslutningsarbeidsflyt

Når en serviceordre og SLA-forespørsel krever eksplisitt avslutning, opprettes en avslutningsforespørsel. Avslutningsforespørselen bruker en lignende arbeidsflyt for å få godkjenning fra den kommersielle ansvarlige gruppen og den primære ansvarlige brukeren.

En bruker kan bare heve forespørselen om oppsigelse for en serviceavtale eller tjenesteordre som de godkjente og opprettet.

Når avslutningsdatoen er nådd for eventuelle godkjente oppsigelsesforespørsler, kjører en serverdel Power Automate flyt daglig for å sjekke og:

  • Hvis forespørselen er for en serviceavtale, må du avslutte serviceavtalen som er knyttet til avslutningsforespørselen.

  • Hvis forespørselen er for en serviceordre, avslutter du alle SLAene som er knyttet til serviceordren, og avslutter serviceordren.

Brukstilfelledetaljer

Denne delen oppsummerer forretningskonteksten og målene som formet serviceordreløsningen, inkludert beslutningen om å flytte til Power Platform.

Forretningskontekst

Dette initiativet begynte da en organisasjon satte i gang med å flytte administrasjonsprosessen for serviceordrer fra en Angular–Camunda-plattform til Microsoft Power Platform.

Den eldre løsningen, bygget på Angular, Camunda Workflow Engine og PostgreSQL, pådro seg høye lisensieringskostnader, krevde et dedikert teknisk team for endringsforespørsler og erfarne lange behandlingstider for selv mindre forbedringer. Kompleksiteten i løsningen og vedlikeholdskostnadene fikk organisasjonen til å forfølge et moderne, kostnadseffektivt og enkelt vedlikeholdsalternativ.

Målsettinger og drivere

Viktige drivere for den nye løsningen:

  • Dra nytte av eksisterende Power Platform-lisenser og infrastruktur for å eliminere ekstra lisensieringskostnader.

  • Reduser avhengigheten av spesialisert teknisk støtte, noe som reduserer driftskostnadene.

  • Effektiviser endringsbehandling ved hjelp av funksjoner med lav kode og minimering av egendefinert utvikling.

  • Lever en mager, vedlikeholdbar Power Platform-løsning innen én måned, og møte kundens aggressive tidslinje.

  • Sikre sømløs overføring av eksisterende prosess og underliggende data.

  • Forbedre brukeropplevelsen med et interaktivt, intuitivt grensesnitt.

Komponenter

Teamet utformet og implementerte en Power Apps modelldrevet app, støttet av viktige out-of-the-box (OOTB)-funksjoner for å holde tilpasningen minimal mens den oppfyller alle funksjonelle krav.

Brukergrensesnitt

Modelldrevet app fungerer som det primære brukergrensesnittet for brukere.

Egendefinerte sider moderniserer brukeropplevelsen ved å sikre interaktiv virkemåte for brukergrensesnittet og minimal endring for sluttbrukere når programmet overføres fra den eksisterende plattformen.

Kommandolinjetilpasninger administrerer forretningsregler og godkjenningsprosess gjennom ulike faser.

Forretningsprosessflyter (BPF) hjelper brukere med å visualisere den eksisterende fasen.

PDF-generering

Det forrige systemets PDF-eksportfunksjonalitet var svært kompleks og krevde hyppig teknisk inngripen for selv mindre maloppdateringer.

Den nye løsningen bruker:

  • OOTB-enhetsdokumentmaler for Word/PDF-generering.

  • Administratorkontrollerte malendringer, som eliminerer avhengighet av tekniske team.

Denne tilnærmingen reduserer behandlingstiden betydelig og fjerner behovet for utviklingsdrevne maloppdateringer.

Arbeidsflyter og godkjenninger

Forretningsprosessflyter orkestrerer forespørselsruting , godkjenninger og sporing av flere trinn.

Power Automate flyter utføre ulike handlinger ved fullføring av hvert godkjenningstrinn, for eksempel sende varsler til Outlook og Teams, tilordne oppgaver og generere en automatisk PDF-fil i sluttfasen.

Livssyklus og avslutningsadministrasjon

Power Automate-flyter kjører daglig for å se etter serviceavtaler og serviceordrer som avslutter den dagen.

Aktivitetspåminnelser

Power Automate-flyter sender påminnelser til brukere som oppgavene tildeles når forfallsdatoen har passert.

Datakilde

Datavers for å administrere og lagre programdataene og vedlikeholde loggen for overvåkingsloggen.

SharePoint som dokumentrepositorium og for versjonskontroll av dokumenter.

Rapportering

Power Apps modell-drevne applikasjoner har innebygd rapportering og viser diagrammer som gir innsikt i applikasjonsdata.

Vurderinger

Disse hensynene tar i bruk prinsippene i Power Platform Well-Architected, et sett med veiledende prinsipper som forbedrer kvaliteten på en arbeidsbelastning. Finn ut mer i Microsoft Power Platform Well-Architected.

Pålitelighet

  • Etablere klare forventninger til:

    • Responstid
    • Tidslinjer for godkjenning
    • Daglige jobbvinduer (SLA-utløp, avslutningsjobb)
  • Implementere oppgavebasert robusthet. Hvis for eksempel et Power Automate trinn mislykkes:

    • Behold oppgaven i Dataverse til den relaterte handlingen er fullført.

    • La brukere prøve innsending eller godkjenning på nytt når som helst.

    • Oppdater forespørselsstatusen bare etter at alle trinnene i arbeidsflyten kjøres.

    • Vis feilen i forretningsprosessflyten hvis en faseoppdatering mislykkes.

  • Håndtere daglige jobbfeil med logikk på nytt og hente data basert på dynamiske filtre.

  • Bruk kortvarige, tilstandsløse brukerhandlinger for å redusere sjansen for fastlåste arbeidsflyter.

  • Bruk logging for å holde forespørselsdata pålitelige og støtte sporbarhet.

Security

  • Kontroller tilgangen til den modelldrevne appen ved hjelp av Microsoft Entra ID sikkerhetsgrupper tilordnet til dataverse eierteam.

  • Definer sikkerhetsroller for kommersielle ansvarlige, primære ansvarlige, anmodere og administratorer for å sikre datatilgang.

  • Inviter gjestebrukere til å Microsoft Entra ID etter organisasjonspolicyer, og legg dem til i sikkerhetsgruppen bare etter godkjenning. Bruk samme sikkerhetsgruppe for godkjente eksterne brukere.

  • Bruk datavers sikkerhet på feltnivå og radnivå.

  • Gi SharePoint tillatelser gjennom innebygd integrasjon med dataverse og modelldrevne programmer.

  • Distribuer programmet i et administrert miljø , og definer en bestemt datapolicy for det.

  • Bruk datavers overvåkingslogging til å oppdage dataavvik.

  • Gjør dataene skrivebeskyttet etter at forespørselen har nådd et bestemt stadium.

  • Implementere en arkivpolicy for å sikre at administratorer har full kontroll over arkiverte data, og brukere kan bare få tilgang til PDF-dokumentene som genereres for hver forespørsel.

Driftskvalitet

  • Definer en miljøstrategi for å sikre driftskvalitet. Konfigurer utviklings-, test- og produksjonsmiljøer, og konfigurer dem som administrerte miljøer der det er aktuelt.

  • Implementere en løsningsstrategi:

    • Bruk en uadministrert løsning i utviklingsmiljøet og en administrert løsning i andre miljøer.

    • Utform løsningssegmentering for segmentkomponenter, prosesser og kjernekomponenter.

  • Implementere kodegjennomganger før du flytter fra utviklingsmiljøet.

  • Bygg en modelldrevet app på konstruksjoner med lav kode for raskere forbedringer og feilrettinger.

Ytelseseffektivitet

  • Identifiser mønstre for transaksjonsvolum fra gamle programmer, og bli enige med bedriften om volumdataene som samles inn.

  • Deleger langvarige aktiviteter, for eksempel utløp av serviceavtale og avslutningskjøring, til planlagte flyter som ikke avhenger av brukersamhandling.

  • Bruk satsvise API-er for masseoperasjoner for crud for å unngå begrensningsgrenser.

Opplevelsesoptimalisering

  • Opprett en egendefinert side for å forbedre målsiden.

  • Send velformaterte e-postmeldinger slik at brukerne enkelt kan identifisere dem.

  • Inkluder dype koblinger i e-postmeldinger, slik at brukerne kan gå direkte til forespørsler.

  • Send regelmessige påminnelser for å hjelpe brukere med å fullføre oppgaver i tide.

  • Legg til hurtigkoblinger i Mine oppgaver og administrasjonsinndelinger.

  • Legg til egendefinerte knapper som brukere kan velge for å identifisere handlinger som skal utføres.

  • Varsle brukere om vellykket eller mislykket etter hvert knappevalg.

  • Skjul unødvendige data når forespørsler kommer til et bestemt stadium.

  • Arkiver data slik at brukere bare ser aktive elementer.

Bidragsytere

Microsoft vedlikeholder denne artikkelen. Følgende bidragsytere skrev denne artikkelen.

Hovedforfattere: