Tidsplan for implementering: Gantt-diagram til ERP-, CRM- og softwareudrulning

Lav en implementeringstidsplan som Gantt-diagram: designgodkendelse, konfiguration, datamigrering, integrationer, test, oplæring, overgang og hypercare, med en parathedsgennemgang som port til go-live.

En udrulning af forretningssoftware har én dato, alle husker: go-live. Et Gantt-diagram viser, hvad der skal være på plads inden da, og hvilke spor der kan køre parallelt, indtil det er.

Kort fortalt

  • Brug en milepæl til designgodkendelsen og en milepæl til parathedsgennemgangen før go-live.
  • Lad sporene for konfiguration, data og integrationer køre parallelt mellem de to porte.
  • Brug afhængigheder fra start til start med en forsinkelse til arbejde, der kan begynde, før forgængeren er færdig.
  • Lad go-live afhænge af parathedsgennemgangen, så overgangen ikke kan planlægges før beslutningen.
  • Tag hypercare og overdragelse med, så planen slutter, når support overtager, ikke ved go-live.

Hvad en implementeringstidsplan skal vise

Udrulninger af ERP, CRM og andre forretningssystemer består af nogle få spor, der for det meste kører parallelt: konfiguration af systemet, forberedelse og migrering af data, opbygning af integrationer og forberedelse af mennesker. De mødes kun på bestemte punkter som test og beslutningen om go-live. En god tidsplan gør de møder synlige, for det er der, et forsinket spor forsinker alt andet.

Den struktur, der virker, er en kort række af porte. Krav fører til et godkendt design, som frigiver sporene for konfiguration, data og integrationer. Deres resultat mødes i systemintegrationstest, derefter brugeraccepttest og en parathedsgennemgang før go-live. Derefter kommer overgangen, den endelige datamigrering og en periode med hypercare. Godkendelsen af designet og parathedsgennemgangen er milepæle uden længde: de er beslutninger, ikke arbejde, og diagrammet skal vise, hvem der venter på dem.

Ikke alle spor behøver vente på, at det foregående er færdigt. Prøvemigreringer af data kan starte, når konfigurationen er halvt færdig, og undervisningsmateriale kan skrives, mens systemet stadig konfigureres. Afhængigheder fra start til start med en forsinkelse udtrykker præcis det. De forkorter planen ærligt, så længe du angiver forsinkelsen i selve afhængigheden i stedet for stiltiende at lade bjælker overlappe.

Eksemplet nedenfor er en komplet implementeringsplan med seksten opgaver. Åbn regnearkspanelet for at se afhængighederne, herunder forbindelserne fra start til start.

En systemimplementeringsplan fra projektstart til overdragelse

Seksten opgaver og tre milepæle. Åbn regnearkspanelet for at se afhængighederne bag hvert trin.

  1. Projektstart, krav og designporten

    "Projektstart" tager 2 arbejdsdage og "Krav og fit-gap-analyse" 10. "Løsningsdesign godkendt" har længden 0, så den er en milepæl, og konfigurationen, datamappingen og udviklingen af integrationer venter alle på den.

  2. Parallelle spor ind i testen

    "Systemkonfiguration" tager 20 dage, "Datamapping og datarensning" 12 og "Udvikling af integrationer" 18. "Prøvemigrering af data" starter 10 dage efter, at konfigurationen starter, og "Systemintegrationstest" venter på konfigurationen, prøvemigreringen og integrationerne, før "Brugeraccepttest" følger.

  3. Oplæringen overlapper opbygning og test

    "Undervisningsmateriale" er forbundet fra start til start med konfigurationen med en forsinkelse på 5 dage. "Slutbrugeroplæring" venter på materialet og starter 3 dage efter, at "Brugeraccepttest" starter. "Go-live-parathedsgennemgang" er en milepæl, der venter på både test og oplæring.

  4. Overgang, hypercare og overdragelse

    "Endelig datamigrering" (3 dage) og "Overgang og go-live" (2 dage) kan ikke starte før parathedsgennemgangen. "Hypercare" løber i 15 dage, og "Overdragelse til support" er en milepæl, der afslutter planen.

Sådan fungerer det

  1. Start med portene, ikke opgaverne

    Beslut, hvor projektet kræver en beslutning: designgodkendelse og parathedsgennemgang før go-live er de sædvanlige to. Tilføj dem som opgaver med varigheden 0, så tegnes de som milepæle.

  2. Tilføj arbejdet mellem portene

    List krav før den første port. Mellem portene lister du konfiguration, datamapping, integrationer, undervisningsmateriale og testfaserne, hver med en estimeret længde i arbejdsdage.

  3. Forbind sporene

    I Afhænger af peger du konfiguration, data og integrationer på designgodkendelsen. Peg systemintegrationstesten på alle tre, så det længste spor vises som det, der sætter datoen.

  4. Lad arbejde overlappe, hvor det reelt overlapper

    Brug SS og en forsinkelse til arbejde, der kan starte tidligt, for eksempel 4SS+10 for en opgave, der starter 10 arbejdsdage efter, at opgave 4 starter. Tjek hver enkelt med den, der ejer arbejdet.

  5. Tilføj overgangen og opfølgningen

    Lad den endelige datamigrering og go-live afhænge af parathedsgennemgangen, og tilføj derefter hypercare og en milepæl for overdragelse. Planen er færdig, når support ejer systemet, ikke når det går i drift.

  6. Tænd for den kritiske vej, og del den

    Vis, Kritisk vej fremhæver den kæde, der sætter datoen for overdragelsen. Del diagrammet som link, eller eksportér en PDF til styregruppen.

Faldgruber du skal undgå

  • At behandle datamigrering som én opgave

    En prøvemigrering finder problemer, som den endelige ikke må støde på. Tegn begge, og lad den endelige afhænge af parathedsgennemgangen.

  • At lægge oplæringen til sidst

    Oplæring, der begynder efter testen, levner ikke tid til at rette det, brugerne finder. Lad den overlappe med en forbindelse fra start til start som i eksemplet, og lad go-live-beslutningen afhænge af den.

  • At overlade go-live-datoen til tilfældighederne

    Er go-live fastlagt af en kontrakt eller et regnskabsårs udgang, så fastlås kun den start og se på den markerede konflikt. Fastlåser du alle opgaver, skjuler det det egentlige problem.

  • At forvente følgning af ressourcer eller omkostninger

    QueryChart registrerer, hvem der ejer en opgave, men advarer ikke om overbelastning, følger ikke omkostninger og sammenligner ikke med en baseline. Hold budget og kapacitet i de værktøjer, der håndterer dem.

Planlæg din udrulning

Åbn implementeringsplanen som dit eget diagram, udskift opgaverne med dine egne, og del tidsplanen med din styregruppe.

Planlæg din udrulning

Relaterede guides

Ofte stillede spørgsmål

Egner det sig til ERP- og CRM-projekter?

Ja. Strukturen er den samme for ethvert forretningssystem: design, konfiguration, data, integrationer, test, oplæring og overgang. Udskift eksemplets opgavenavne med dine egne.

Hvordan viser jeg, at to opgaver kan overlappe?

Brug en afhængighed fra start til start med en forsinkelse i Afhænger af, for eksempel 4SS+10. Opgaven starter 10 arbejdsdage efter, at opgave 4 starter, uanset om opgave 4 er færdig.

Kan jeg gruppere opgaver efter arbejdsspor?

Ja. Giv opgaver en gruppe, så tegnes de som bånd med en sammenfattende bjælke, og konfiguration, data og oplæring kan hver være et bånd.

Kan jeg vise, hvem der er ansvarlig?

Ja, ved at tilføje personer til hver opgave. Diagrammet kontrollerer ikke arbejdsbelastning og løser ikke kollisioner.

Kan jeg importere fra Microsoft Project?

Nej. Microsoft Project-filer understøttes ikke. Du kan kopiere rækker fra et regneark og indsætte dem i regnearket.

Skabelonen bag denne guide

Gantt-diagram til implementeringsplan for systemudrulning — Redigerbart Gantt-diagram til implementeringsplan: krav, konfiguration, datamigrering, integration, test, oplæring, overgang og hypercare med afhængigheder og milepæle. Ret en varighed, og datoerne følger med.

Gantt-diagram for implementeringsplan: Planlæg → Konfigurér → Migrér og integrér → Test og oplær → Go-live
Tidsplan for implementering: Gantt-diagram til ERP-, CRM- og softwareudrulning