Planlegging av sikre kundevendte digitale arbeidsflyter

Hva det er

En kundevendt arbeidsflyt kan omfatte en portal, en nettjeneste, en mobilopplevelse, backend, API, en betalingsleverandør, en støtteprosess og et administrativt team. Planleggingen bør peke ut brukerroller og tilgangsgrenser; autentisering og gjenoppretting; skjemaer, filer, meldinger, dashbord og status; veier for betaling, abonnement, faktura, tilbakebetaling, oppsigelse og rettigheter; dataeierskap og lagringstid; tredjepartsintegrasjoner; og driftsansvar. Den bør også avgjøre om mobil eller nett er passende, om eksisterende backend og API-er er klare, og hvem som skal eie logging, støtte, endringer og overlevering. Sikkerhetsgjennomgang og programvareleveranse kan ha separate omfang.

Hvem det er for

Denne veiledningen hjelper team som planlegger:

• En kunde- eller partnerportal, en mottaksflyt, et dashbord, en betalingsreise, en overgang fra nett til mobil eller en applansering
• Rollebasert tilgang, gjenoppretting, filer, statusinformasjon, støtte og administrative ansvarsområder
• En produktendring som involverer eksisterende backend, API-er, tredjepartsleverandører, faktureringstilstander eller kundedata
• En klarere grense mellom kartlegging, design, leveranse, herding, gjennomgang og senere driftseierskap

Hva det hjelper med å klarlegge

Planleggingsspørsmålene hjelper med å avdekke:

• Om brukere, roller, tilgangsregler, kontogjenoppretting, dataeierskap og lagringstid er forstått før leveransen starter
• Hvilke skjemaer, filer, meldinger, dashbord, statusvisninger, betalingstilstander og beslutninger om rettigheter som krysser systemgrenser
• Om integrasjoner, backend/API-er, mobilleveranse, lanseringsfase, logging, støtte og eierskap til endringer er klare for et avgrenset neste steg
• Om teamet trenger en portalsprint, en betalingsgjennomgang, en overgang fra nett til mobil, en gjennomgang av lanseringsklarhet, herding av nettstedet eller tidligere kartlegging/produktplan

Hva er inkludert

• En sjekkliste for kjøpere som dekker reiser, roller, tilgang, autentisering, gjenoppretting, skjemaer, filer, meldinger, dashbord, status, betalinger, abonnementer, fakturaer, tilbakebetalinger, oppsigelser, rettigheter, data og integrasjoner
• Planleggingsspørsmål om administrativt eierskap, klarhet i backend/API, mobil kontra nett, lanseringsfase, logging, støtte, endringskontroll og overlevering
• En sammenligning av når Secure Client Portal Sprint, Subscription & Payment Infrastructure Security, Secure Web-to-Mobile Launch, App Launch Readiness og Website Performance & Security Hardening kan være relevante
• En påminnelse om at uklare arbeidsflyter, roller, integrasjoner eller eierskap kan kreve kartlegging eller arbeid med produktplan før leveranse

Hva er ikke inkludert

• Løfte om sikkerhet, regulatorisk egnethet, godkjente betalinger, svindelforebygging, inntekter, godkjenning i appbutikker, vellykket lansering, oppetid, ytelse eller uavbrutt drift
• En påstand om at en portalsprint er en full SaaS-plattform, at en betalingsgjennomgang er PCI-sertifisering eller svindeldrift, eller at mobilleveranse automatisk gjør et produkt klart for lansering
• En antydning om at herding erstatter applikasjonsdesign, lasttesting, hendelseshåndtering eller kontinuerlig drift
• En antakelse om at programvareleveranse, sikkerhetsgjennomgang, godkjenning fra leverandører og løpende eierskap er ett automatisk omfang

Når skal den velges

Bruk denne veiledningen før en kundevendt endring blir en liste over frakoblede funksjoner. Den er nyttig når et team skal avgjøre om det skal bygge en portal, endre tilgang, innføre abonnementer, utvide en nettjeneste til mobil, forberede en applikasjonslansering eller forbedre et nettsted. Hvis den grunnleggende arbeidsflyten, eierskapet, integrasjonene eller brukerrollene fortsatt er uklare, er kartlegging eller arbeid med produktplan som regel mer verdifullt enn tidlig implementering. En avgrenset gjennomgang kan deretter følge når et bestemt sikkerhets- eller driftsspørsmål er klart.

Vår tilnærming

Kartlegg reisen før leveransemetoden velges. Start med brukeren, rollen, tilgangsbeslutningen, dataene brukeren oppgir eller ser, systemet som eier neste tilstand, og teamet som har ansvaret når noe endres. Følg betalingstilstander og rettigheter like nøye som skjermbildene i grensesnittet. Pek deretter ut avhengigheter til leverandører og backend, behov for støtte og logging, begrensninger på mobil, eierskap til lanseringer og krav til overlevering. Dette viser om neste beslutning gjelder portalleveranse, betalingslogikk, arbeid med overgang fra nett til mobil, lanseringsklarhet, herding av nettstedet eller tidligere kartlegging. Det hindrer også at en avgrenset tjeneste forveksles med et ubegrenset ansvar for produkt, drift eller etterlevelse. Et skriftlig kart over arbeidsflyten kan også registrere de normale og de unntaksvise veiene: en ny bruker, en mislykket betaling, en oppsigelse, en tapt konto, en manglende fil, et avbrudd hos en leverandør eller en støtteforespørsel. Det gir produkt-, drifts-, utviklings- og støtteteam et felles sted å avklare eierskap før en kunde blir berørt. Denne klarheten kan redusere omfangsglidning i senere leveransearbeid. Etter hvert som planleggingen utvikler seg, gå tilbake til kartet hver gang en leverandør, betalingsmodell, rolle, tilgangsregel, API, lanseringskanal eller støtteprosess endres. En arbeidsflyt som så enkel ut på et diagram, kan ha viktige unntak i produksjon. Å registrere disse unntakene gjør det lettere å avgjøre om neste omfang er design, leveranse, gjennomgang, herding, testing eller forberedelse av drift. Det hjelper også en kjøper med å be leverandører om riktig dokumentasjon før en beslutning tas. Bruk til slutt kartet til å avgjøre hva som skal måles etter leveransen, og hvem som skal handle på et funn, en mislykket betaling, et støttesignal eller en endringsforespørsel. En overlevering står sterkere når den navngir en eier, et gjennomgangspunkt og en avtalt grense i stedet for bare å liste opp funksjoner.

Ofte stilte spørsmål

Beslektede artikler