Brukerstøtte: pågående produksjonsløsningsstøtte

Delene nedenfor omhandler formelle og uformelle metoder for å støtte brukere av Microsoft Power Platform-løsninger, for eksempel apper, flyter og chatroboter.

Dette diagrammet viser et vanlig rammeverk for støtte og gradering som brukes av organisasjoner:

Type	Beskrivelse
	Selvbetjeningsstøtte (intern) skjer når en utvikler støtter sin egen løsning. Brukere av løsningen vet at de kan kontakte utvikleren for å få støtte, og det er ofte ingen synlighet for IT eller teamet på nivået av eller typen støtte som utvikleren gir.
	Støtte med hjelp fra teamet (intern) skjer når teammedlemmer lærer av hverandre når de utvikler Power Platform-løsninger. Teammedlemmer blir medeiere av teamets apper, flyter og chatroboter. Medeiere kan støtte brukerspørringer og utføre små feilrettinger og endringer. Selv om støtte med hjelp fra teamet noen ganger forekommer uformelt, er det en god idé å formalisere denne prosessen etter hvert som innføringen og veksten øker.
	Hjelpegruppestøtte (intern) håndterer formelle støtteproblemer og -forespørsler. Hjelpegruppen kan hjelpe deg med ulike spørsmål, for eksempel hvordan du får tilgang til en app på en mobilenhet, eller hvordan du ber om tilgang til en datakilde på en serverdel. De omdirigerer løsningsrelaterte spørsmål til kanalen som støtter løsningen.
	Dedikert Power Platform-støtte (intern) omfatter håndtering av komplekse problemer som eskaleres av hjelpegruppen. Dette teamet tar seg av kritiske programmer, og de kan distribuere feilrettinger.
	Partnerstøtte (ekstern) kan komplettere det interne støttetilbudet og enten støtte kritiske programmer eller arbeide med bestemte avdelinger for å støtte appene deres. Finn ut mer: Få eksperthjelp fra Power Apps-partnere
	Kundestøtte fra Microsoft (ekstern) kan brukes til å registrere tekniske problemer knyttet til plattformen. Ulike tjenester for teknisk støtte og veiledning er tilgjengelig, avhengig av kundestøtteplanen du har. Finn ut mer: Kundestøtte for Microsoft Power Platform

Avhengig av størrelsen på organisasjonen og eksisterende leveringsmåter for lavkode- og prokodeteknologi, kan du velge ulike måter å formalisere kundestøtten på. Hvis du stort sett bruker en desentralisert tilnærmingsmåte til innføring av Power Platform, har du autonome team over hele organisasjonen som leverer og styrer Power Platform-løsninger. Med denne modellen kan kundestøtte også delegeres, og støtte med hjelp fra team kan være den mest relevante tjenesten for brukere og utviklere.

Hvis du stort sett bruker en sentralisert tilnærmingsmåte til innføring av Power Platform, har du sentrale team med produkteiere som eier lavkodeleveringen av avdelingsløsninger fra de ulike forretningsenhetene i organisasjonen. Med denne modellen blir støtten også sentralisert, og et sentralt kundestøtteteam tar seg av spørringer og spørsmål.

I de fleste organisasjoner er det best med en blanding av leveringsmodeller – selv om desentraliserte team støtter løsninger for utviklerne, kan det hende at en hjelpegruppe og et sentralt kundestøtteteam fortsatt er nødvendig med hensyn til tekniske problemer, brukerspørringer og kundestøtte på første nivå.

Definere programnivåer

Når du definerer kundestøtteprosessen og videresendingsbanen, er det viktig å kategorisere løsninger som er bygd basert på kritikalitet. Dette gjør at du kan bruke prosesser som sikrer at kritiske programmer har de nødvendige beskyttelsessperrene rundt seg og samtidig ikke undertrykker innovasjon i produktivitetsscenarioer.

Egenskaper og prosesser	Produktivitet	Viktig	Kritisk
Brukseksempel	Individuelle brukstilfeller for produktivitet og små team der eksisterende data kan brukes.	Enkle forretningsprogrammer eller teaminitiativer. Små, frittstående samarbeidsprosesser.	Komplekse forretningsprogrammer, initiativer som dekker hele bedriften, eller forretningskritiske arbeidsbelastninger med betydelig virksomhetsinnvirkning under nedetid.
Kompleksitet	Enkle prosesser.	Middels kompleksitet.	Høy kompleksitet.
Brukerbase	Liten brukerbase – enkeltbrukere, direkte kolleger eller lite team.	Begrenset til forretningsenhet.	Stor brukerbase eller bruk over hele bedriften.
Livssyklus for utvikling	Høyt gjentakelsesnivå.	Vanligvis mindre enn tre måneder å utvikle.	Lengre utviklingssyklus.
Innvirkning	Lav virksomhetsinnvirkning.	Viktig, men ikke forretningskritisk (middels innvirkning).	Høy virksomhetsinnvirkning.
ALM	ALM kreves ikke.	ALM kreves – og kan oppnås via manuell import/eksport av løsning.	Robust ALM-prosess kreves – ALM oppnås ved hjelp av Azure DevOps- eller GitHub-datasamlebånd.
Miljøstrategi	Løsningen er innebygd i det standard produktivitetsmiljøet eller i et delt produktivitetsmiljø.	Dedikert utviklingsmiljø og delte test- og produksjonsmiljøer (delt med andre løsninger, for eksempel løsninger for spesifikke forretningsenheter). Miljøer administreres av forretningsenheten (desentralisert) eller av sentral IT (sentralisert).	Dedikerte miljøer for utvikling/testing/produksjon. Miljøer administreres av sentral IT.
Utviklertillatelser	Utviklere har sikkerhetsrollen Miljøoppretter i miljøene.	Utviklere har sikkerhetsrollen Miljøoppretter eller Systemtilpasser i utviklingsmiljøet, men bare sikkerhetsrollen Sluttbruker i test- og produksjonsmiljøer. Løsninger kan eies av en tjenestekonto eller miljøadministrator i test og produksjon.	Utviklere har sikkerhetsrollen Miljøoppretter eller Systemtilpasser i utviklingsmiljøet, men bare brukersikkerhetsrollen i test- og produksjonsmiljøer. Løsningsdistribusjon skjer automatisk, og løsninger eies av en tjenestekontohaver i test og produksjon.
IT-medvirkning	Reaktiv styring – IT har oversikt over løsninger som bygges, og overvåker bruk.	IT-tilslutning på løsnings- eller brukernivå. Utviklere kommer med løsningsdetaljer, for eksempel mulige løsninger og datakilder som brukes.	Produksjonsmiljøet administreres av IT.
Støttemodell	Selvstøttet.	Støttet med hjelp fra teamet.	Formell støtte.

Når du definerer støttemodellene, bør du også tenke på en graderingsbane – en løsning trenger kanskje bare støtte på produktivitetsnivå til å begynne med, men kan vokse i funksjonalitet eller brukerbase slik at den trenger støtte på viktig-nivået. Definer hvordan utviklere kan be om mer formell støtte og overføre en løsning til støttede miljøer.

Hver av de ulike typene brukerstøtte nevnt ovenfor, er beskrevet nærmere i denne artikkelen.

Utviklerstøtte (selvstøtte)

Utviklerstøtte henviser til tilfeller der utviklere støtter sine egne apper og flyter som de har bygd for seg selv, teamet eller kollegene sine. Dette betyr at de svarer på spørringer fra brukere, retter feil og foretar endringsforespørsler. Dette er en uformell støttemetode. Brukere vet ofte hvem utvikleren er, og kontakter vedkommende direkte.

Viktig

Som en del av innføringen av nye utviklere må du passe på at der er klar over støtte-, graderings- og videresendingsbanene. Utviklere som blir overveldet med å støtte forretningsviktige løsninger de har utviklet, kan ikke lenger innovere og utvikle nye løsninger. Definer tydelig hvordan utviklere kan gradere løsningene til neste kundestøttenivå og hvordan dette ser ut.

Sammen med denne proaktive måten å fortelle utviklere om prosesser på, må du også sørge for at du har reaktiv styring på plass for å identifisere løsninger som deles og brukes mye og kan være viktige for virksomheten, og ta kontakt med utviklerne for å sikre at disse løsningene har de nødvendige beskyttelsessperrene rundt seg. Bruk analyse på leiernivå til å finne ut mer om programbruken, eksporter telemetrien til din egen datalagringskonto for å bygge din egen forbedrede rapportering, eller bruk startpakken for CoE som utgangspunkt.

Støtte med hjelp fra teamet

Støtte med hjelp fra teamet henviser til tilfeller der teammedlemmer blir medeiere av apper og flyter som er bygd for eller brukes av teamet, og hjelper til med å støtte løsningene i det daglige arbeidet. Dette betyr at de svarer på spørringer fra brukere, retter feil og foretar endringsforespørsler. Utviklere som viser seg å være mestere, har en tendens til å ta på seg denne uformelle støtterollen frivillig fordi de ønsker å hjelpe.

Selv om dette ofte er en uformell prosess i begynnelsen, er det mange organisasjoner som formaliserer støtte med hjelp fra teamet for å skalere arbeidet med Power Platform. Dette betyr at forretningsenheter eier de dedikerte miljøene sine, tar på seg rollen Miljøadministrator og støtter løsningene i disse miljøene. I større organisasjoner kan dedikerte Power Platform-team per forretningsenhet ta på seg denne rollen.

Hjelpegruppestøtte

Hjelpegruppen drives som en delt tjeneste av IT-avdelingen.

Hjelpegruppen kan gjøre følgende:

• Støtte tekniske problemer som ikke kan løses uten at IT involveres, for eksempel problemer med Power Platform-tjenesten som krever at en administrator registrerer en støtteforespørsel i administrasjonssenteret for Power Platform.
• Svare på spørsmål som er knyttet til sluttbrukere og styring, for eksempel hvordan du ber om tilgang til programmer eller hvor du finner programmer.
• Rute problemer med kritiske apper til riktig kundestøtteteam.

Dedikert støtteteam for Power Platform

Etter hvert som innføringen øker og utviklere utvikler flere forretningsviktige og -kritiske løsninger, får du kanskje behov for et dedikert støtteteam for Power Platform.

Dette teamet bør bestå av tekniske eksperter på Power Platform som kan støtte komplekse problemer. Dette teamet bør bare involveres i støtteprosessen gjennom en definert bane via en støtteforespørsel.

Dette teamet støtter forretningskritiske Power Platform-løsninger som rulles ut til dedikerte miljøer som støttes sentralt.

Hvis organisasjonsstrukturen er desentralisert, kan du vurdere å formalisere støtten med hjelp fra teamet for å innrette den etter de lokale områdene eller forretningsenhetene, og slik at det sentrale støtteteamet for Power Platform bare hjelper til med komplekse spørringer eller sentrale konfigurasjoner, for eksempel policyer for hindring av datatap.

Noen kunder velger å utkontraktere dette støttenivået til en partner.

Det kan være vanskelig å få alle forespørsler til utelukkende å følge en videresendingsbane fra hjelpegruppen siden disse tekniske ekspertene på Power Platform ofte er velkjente for forretningsbrukerne. Dette teamet bør alltid be brukerne om å sende inn en hjelpegruppeforespørsel for å gjøre dem vant til å gå via riktige kanaler. Dermed forbedres også datakvaliteten ved analyse av hjelpegruppeforespørsler.

Partnerstøtte

Mange kunder velger å samarbeide med partnere om Power Platform-innføring, inkludert kundestøtte. Dette kan omfatte utviklingshjelp for utviklere, hjelp med å opprette et CoE og prosedyrer for teknisk støtte og teknisk kundestøtte døgnet rundt for kritiske apper.

Kundestøtte fra Microsoft

Kundestøtte fra Microsoft brukes til å registrere tekniske problemer knyttet til plattformen. Ulike tjenester for teknisk støtte og veiledning er tilgjengelig, avhengig av kundestøtteplanen du har.

Tips

Før du registrerer en kundestøtteforespørsel, bør du også se Power Apps-støtte, Power Automate-støtte og Power Virtual Agents-støtte når det gjelder problemer av høy prioritet som hovedsakelig påvirker alle kunder.

Vurderinger og viktige tiltak

Dette er vurderinger du kan gjøre og viktige tiltak du kan iverksette for å forbedre egne løsninger og løsninger støttet med hjelp fra team:

• Gi utviklerne anerkjennelse og oppmuntring.
• Sørg for at utviklerne er klar over graderingsprosesser, slik at de kan gradere løsningene til mer formelle støttekanaler.
• Gi utviklerne kontortid, mentormuligheter og opplæringsøkter, slik at de kan fortsette å øke kompetansen.
• Sørg for videresendingsbaner for utviklere som står fast, slik at de kan kontakte tekniske eksperter på Power Platform.
• Opprett malkomponenter som utviklere skal tar med i appene, for eksempel et skjema brukerne kan bruke til å kontakte hjelpegruppen.
• Evaluer formalisering av støtte med hjelp fra teamet basert på arbeidsbelastning og antall løsninger som trenger støtte i et bestemt forretningsområde.

Dette er vurderinger du kan gjøre og viktige tiltak du kan iverksette for å forbedre den interne hjelpegruppestøtten:

• Fastslå det innledende omfanget av Power Platform-emner hjelpegruppen skal behandle.
• Vurder beredskapsnivået til hjelpegruppen for å håndtere støtte.
• Sørg for mer opplæring for ansatte i hjelpegruppen basert på mangler i beredskapen.
• Finn ut hvor videresendingsbanen går for forespørsler som hjelpegruppen ikke kan håndtere direkte.
• Oppdater kunnskapsbasen til hjelpegruppen for kjente Power Platform-emner. Sørg for at noen får ansvaret for regelmessig oppdatering av kunnskapsbasen for å gjenspeile nye og forbedrede funksjoner over tid. Hold deg oppdatert ved å abonnere på RSS-feedene for Power Apps-bloggen, Power Automate-bloggen og Power Virtual Agents-bloggen.
• Sørg for å ha et godt system for problemsporing på plass. Det er ofte et system for støtteforespørsler som kan brukes til å administrere prioritetsnivåer.
• Finn ut om noen kommer til å ta hånd om problemer knyttet til Power Platform. Du må gjøre klart om det kan forventes støtte døgnet rundt eller ikke.
• Finn ut hvilke serviceavtaler som finnes, og sørg for å meddele forventningene til svar og løsning klart og tydelig.
• Vær forberedt på å løse bestemte vanlige problemer raskt. En forespørsel om bruk av en ny kobling bør for eksempel håndteres raskt. Treg reaksjon på støtteforespørsler kan føre til at brukere finner midlertidige løsninger.
• Sørg for at hjelpegruppen har en sikkerhetsrolle som gjør at de kan registrere støtteforespørsler hos Microsoft. Avgjør om hjelpegruppen eller det dedikerte støtteteamet skal sortere disse problemene.

Dette er vurderinger du kan gjøre og viktige tiltak du kan iverksette for å forbedre den interne, dedikerte støtten for Power Platform:

• Definer klart og tydelig hvor ansvaret til hjelpegruppen slutter og ansvaret til den dedikerte støtten begynner.
• Sørg for at det dedikerte støtteteamet for Power Platform har en direkte videresendingsbane til globale administratorer for Microsoft 365 og Azure. Dette er avgjørende når det oppstår en utbredt problem utover Power Platform. Slike problemer kan være knyttet til brukerkontoer og -tillatelser, nettverkskonfigurasjon eller datakilder som brukes i Power Platform-løsninger.
• Opprett en tilbakemeldingssløyfe fra det dedikerte støtteteamet tilbake til hjelpegruppen, slik at IT-kunnskapsbasen kan oppdateres. Målet er at den primære hjelpegruppen hele tiden skal bli bedre til å håndtere flere problemer i fremtiden.
• Opprett en tilbakemeldingssløyfe fra hjelpegruppen til det dedikerte støtteteamet. Når støttepersonell oppdager overflødighet eller ineffektivitet, kan de meddele denne informasjonen til det dedikerte støtteteamet, som kan velge å endre og forbedre interne prosesser. Eksempel: Hvis hjelpegruppen er opptatt med å opprette og konfigurere nye Power Platform-miljøer for utviklere, kan det dedikerte teamet vurdere automatisering av denne prosessen ved å bruke komponenter for behandling av miljøforespørsler i startpakken for CoE.
• Opprett en videresendingsbane fra enkeltpersoner og team som støtter løsningene sine, til det dedikerte støtteteamet, slik at de unngår å bli stående fast hvis de får problemer de ikke kan løse selv.
• Opprett en overføringsbane fra enkeltpersoner og team som støtter løsningene sine, til det dedikerte støtteteamet, slik at kritiske programmer kan overføres.
• Velg den generelle strategien for overføring av løsninger til det dedikerte teamet. Etter hvert som antallet viktige og kritiske løsninger øker, kommer du for eksempel til å øke bemanningen i det dedikerte støtteteamet, eller lar du forretningsenheter bemanne støtteteamene for områdene sine?