Veiledninger

Store innføringer på én dato feiler oftere enn små i rekkefølge. Her er hvordan dere deler opp uten å miste sammenhengen.

Rutingregler avgjør hvem som får hva. Denne veiledningen viser en enkel modell som virker, framfor et regelverk ingen forstår.

Duplikater som følger med inn i et nytt system er langt dyrere å rydde enn å hindre. Denne veiledningen viser grepene som virker.

Et varsel i Teams når en salgsmulighet over en viss verdi opprettes, er en av de flytene som gir merkbar effekt raskest. Her er oppsettet, og hvordan dere unngår at varselet blir støy.

Et CRM-valg binder dere i mange år. Denne veiledningen beskriver en vurdering som lar seg gjennomføre på fire uker og som gir et beslutningsgrunnlag dere kan stå for.

Arbeidsordren er utgangspunktet for alt annet i Field Service. Den kan opprettes manuelt, men i praksis kommer de fleste fra en sak, en avtale om forebyggende vedlikehold eller et salg. Her er den manuelle veien — og hva du bør fylle ut for at planleggingen faktisk skal fungere etterpå.

Miljøstrukturen legges én gang og lever lenge. Her er oppsettet som gir en trygg vei fra endring til drift.

En ryddig produktkatalog gjør tilbud raskere og salgstall sammenlignbare. Denne veiledningen viser strukturen som holder når sortimentet vokser.

Lagring i Dataverse er ikke gratis, og forbruket vokser stille. Her er hva som fyller opp og hva dere gjør med det.

Avtaler som blir liggende er den stilleste kilden til tapt salg. Et enkelt varsel fanger de fleste.

Et pipeline-dashbord skal svare på om dere når målet, og hvor det stopper. Fire visninger holder.

En god gjennomgang tar en time og ender i konkrete handlinger. En dårlig er en opplesning av tall alle har sett.

En importmodell viser gamle tall til noen oppdaterer den. Planlagt oppdatering gjør det automatisk — når forutsetningene er på plass.

Et godt estimat på en oppgave i DevOps krever at flere faktorer vurderes, ikke bare selve utviklingstiden. Bruk denne fremgangsmåten når en ny oppgave opprettes, og involver alltid den som skal utføre arbeidet.

Akseptansetesting er ofte siste kvalitetssjekk før en leveranse godkjennes, der sluttbrukerne selv tester systemet opp mot kundens krav. Bruk denne fremgangsmåten i sluttfasen av en leveranse, eller tidligere i prosjektet for å avdekke risiko underveis.

Bug triage er testleders ansvar: å klassifisere og prioritere feil som meldes inn i et prosjekt, slik at riktig sak blir rettet i riktig rekkefølge. Bruk denne fremgangsmåten når en feil eller et avvik registreres, i pågående så vel som i avsluttede kundeprosjekter.

Retrospektivet finner sted etter sprintgjennomgangen og før neste sprintplanlegging, og er teamets faste anledning til å forbedre måten det jobber på. Bruk denne fremgangsmåten etter hver sprint, og ved prosjektslutt for å samle erfaringer fra hele prosjektet.

Standupen holder prosjektteamet samkjørt gjennom korte, hyppige avstemminger. Bruk denne fremgangsmøten gjennom hele gjennomføringsfasen, normalt ukentlig og daglig i mer intensive perioder.

ProsessPilotene bruker en fast nummerkonvensjon for kunder, prosjekter, ordrer og saker, satt av Dynamics 365. Bruk denne fremgangsmåten når et nytt prosjekt eller en ny ordre skal opprettes, slik at nummerstrukturen blir konsistent på tvers av systemene.

En sprint er en avgrenset tidsperiode med egen leveranseliste, ressursallokering og økonomisk ramme. Bruk denne fremgangsmåten når en ny sprint skal planlegges, både ved prosjektstart og for hver etterfølgende periode.