Leveringsmodeller
Avhengig av størrelsen på organisasjonen din kan det være lurt å formalisere Microsoft Power Platform-innføringen ved å implementere en strukturert organisasjonsmodell. Du bør vurdere følgende måter å strukturere teamet på og bestemme deg for hva som passer best til situasjonen og organisasjonen.
Microsoft Power Platform har fire leverings modeller, men hver av disse er bare en mental modell – alle organisasjoner har en variasjon av flere modeller langs denne continuum. Selv om du for eksempel velger en sentralisert modell der alle kravene kommer inn i et sentralt leveringsteam, vil du fremdeles ha offentlige utviklere til å oppdage plattformen og utvikle apper for teamene sine. Så du har elementer av matrise eller BizDevOps uansett.
Disse modellene kan hjelpe deg med å vurdere hva den gjeldende modellen for programvarelevering er, og hvordan Microsoft Power Platform kan overlappe i den, eller hvordan den gjeldende modellen kan utvikles slik at den håndterer den hurtige utviklingsfunksjonen som aktiveres av Microsoft Power Platform.
Sentralisert
I denne modellen oppretter du sentrale grupper av produkteiere som eier lavkode-leveringen av avdelingsløsninger fra organisasjonens forretningsenheter. Profesjonelle utviklere som eier kode – første løsninger vil arbeide sammen med virksomheten for å levere i en delt modell. Bedriftsarkitekter skal eie det midterste laget og tjenestene, og sikre at data er tilgjengelige for opprettere. Sentral IT skal eie lisensieringen og systemene som alle driver på.
Ved hjelp av denne modellen oppretter du et sentralt team som kan utvikle apper basert på organisatoriske prioriteter. Ettersom de ville ha grunnleggende ekspertise i Power Apps, inkluderer teamet ditt medlemmer som spesialiserer seg i bestemte deler av Microsoft Power Platform, for eksempel Power Automate, Power BI og Power Apps component framework, eller så kan de spesialisere seg i tredjeparts integrering og kunstig intelligens. Denne modellen er en effektiv måte å drive endringer på i hele organisasjonen, og er den beste måten å levere alle typer programmer på.
Her er en digital orientering fra Schlumberger som viser at denne typen modell har vokst gjennom både desentraliserte og matriserte modeller. Finn ut mer om hvordan Schlumberger tar i bruk Microsoft Power Platform: Produktiv appoppretter skaper lavkode-revolusjon hos Schlumberger
| Type programlevering | Type leveringsmodell | Byggetid for programmet | Livstid for programmet | Eksempler | IT-engasjement |
|---|---|---|---|---|---|
| Selvbetjening | Alle | 1-2 uker | 6-12 måneder | Små, avdelings- eller LOB-løsninger. | Desentralisert IT |
| Små team | Matrisert/sentralisert | 3-6 måneder | 6-24 måneder | Små arbeidsgrupper som arbeider med middels løsninger eller løsninger med flere avdelinger. | Desentralisert IT |
| Flere avdelinger eller store forretningsløsninger | Matrisert/sentralisert | 3-6 måneder | 6-24 måneder | Store grupperte team som arbeider med å levere middels og stor løsninger eller løsninger internt i avdeling. | Sentralisert IT |
| Produktlevering i stor skala | Sentralisert | 1-2 år | 5-7 år | Store produktleveranser på tvers av virksomheter med en blanding av løsninger med lite kode og kode først Power Apps-løsninger sammen med leverandør- og førstepartsløsninger. | Sentralisert IT |
| Leverandørlevering fra stor bedrift | Sentralisert | 7 år | 10-15 år | Omliggende strategi for et tredjeparts system av oppførings- og støtterammeverk. For eksempel SAP-implementering med en blanding av kode for lite kode og kode først-løsninger i Power Apps og andre Microsoft- og tredjeparts integreringer. | Sentralisert IT |
Desentralisert
I denne modellen kan du opprette flere team på tvers av organisasjonen som er nær den daglige administrasjonen av ulike team. De får ressurser til å levere apper konsekvent innenfor organisasjonens retningslinjer. Hvert team kan kjøre frittstående, og de kan dele og vokse i celler. Med denne modellen må imidlertid fremdeles en sentralisert ledelse bruke et høyt nivå av digitale beskyttelsessperrer for for å sikre bedriftens overholdelse. Disse kan omfatte ting som styring av hindring av tap av data (DLP), koblingsbehandling og lisensbehandling for å sikre at brukere og utviklere trygt kan bygge og lansere løsninger med minimal innblanding fra IT, samtidig som selskapets data er sikre og samsvarer med forskriftene. Dette er et bra alternativ for selvbetjening.
Matrise
Med denne modellen blander du det beste av desentralisert og sentralisert. Du har en sentralisert gruppe med kvalifiserte og sertifiserte Microsoft Power Platform-spesialister. Du vil ha ledere innen endring, design, levering og arkitektur, i tillegg til spesialiserte instruktører for å lære opp lokale team på tvers av organisasjonen. Lokale team som består av offentlige utviklere, er koblet sammen med eksperter fra den sentraliserte strukturen for å sikre at det ikke er noe som går tapt i forbindelse mellom personene som utfører daglige jobber, og bruker appene som bygges. Med denne modellen kan du skalere til flere tusen personer som arbeider med opprettelse av apper.
Dette teamet bør også vurdere et å ta i bruk et Center of Excellence for å administrere deres dataeiendom og distribuere løsninger med retningslinjer for alle. Dette fungerer bra for selvbetjening og små team for å levere alternativer raskt med lite IT-engasjement.
BizDevOps
Hurtig utvikling av apper kan bare skje i den hastigheten som operasjoner, for eksempel IT, kan støtte apper som opprettes. BizDevOps er en helhetlig relasjon mellom appoppretter og operasjoner som arbeider i en solid løkke. For at dette skal fungere må alle team ha en klar visjon om den digitale kulturen som organisasjonen beveger seg mot. For å få maksimal verdi fra apper som opprettes, trenger de pålitelig støtte, styring og vedlikehold. Etter hvert som teknologien utvikler seg, må det gjøres oppdateringer på appene for å holde dem oppdatert. Ikke bare å være klar over endring, men å ha en plan for å behandle den, er en nøkkel til vellykkede apper.