Checklist overname software

altijd handig

Geschreven door: op
Van leverancier wisselen is altijd een vreemd moment. Je bent de relatie aangegaan met als doel een succesvolle partnership. Overstappen voelt als een nederlaag. Toch ben je overtuigd dat het moet. Maar hoe doe je dat eigenlijk...?

De markt is constant in beweging. Klanten veranderen, maar leveranciers ook. Dan komt er een moment dat deze niet meer met elkaar matchen en ontstaat er een breuk. Soms vanuit de fouten van de leverancier, soms vanuit een andere verwachting vanuit de klant. Het is niet altijd iemand's schuld. Wel levert het vaak een ongemakkelijke situatie op.

Maar hoe gaat dat precies, wisselen van softwareleverancier? Welke gegevens en deliverables zijn er eigenlijk? Dit is iets waar je nieuwe leverancier je bij moet helpen. Bij voorkeur koppel je de oude en nieuwe leverancier aan elkaar en regelen zij dit onderling. Vaak is dit mogelijk en werkt de oude leverancier goed mee. Mocht dit niet het geval zijn en is de breuk dusdanig groot, dan zul je dit via correspondentie moeten regelen. Hoe dan ook heb je een checklist nodig.

Algemene informatie omgevingen

De eerste batch met gegevens die je nodig hebt richten zich op de bestaande omgevingen. Via welke URL's is de website of applicatie te benaderen? Hoe kom ik op de servers en waar staat de database? Indien de hosting bij dezelfde leverancier blijft heb je al deze gegevens nodig. Stap je ook over naar een andere hostingpartij dan kun je de servergegevens laten voor wat het is. De omgeving wordt daar opnieuw opgezet.

De volgende informatie kun je aanvragen:

  • Gegevens en URL’s Website(s)
  • Gegevens en URL’s Module(s)
  • Gegevens en URL’s Applicatie(s)
  • Gegevens en credentials CMS of Backoffice
  • Gegevens en credentials Acceptatie Server
  • Credentials Acceptatie Database
  • Gegevens en credentials Productie Server
  • Credentials Productie Database

Deliverables

Er is meer dan alleen de broncode. Om de website of applicatie ook bij de nieuwe leverancier duidelijk te krijgen zijn de documenten hoe de code tot stand is gekomen net zo belangrijk. Hoe moet de functionaliteit werken, hoe kan deze getest worden en kunnen nieuwe knoppen eenvoudig via het design worden gemaakt? In de meest ideale situatie vind er ook nog een persoonlijke overdracht tussen de twee partijen plaats. Het is gebruikelijk dat de oude leverancier voor de gehele overdracht een vergoeding vraagt. Dit is vaak tussen de 4 en 8 uur.

De volgende bestanden en documenten kun je aanvragen:

  • Project met broncode
  • Modules derde partijen
  • Modules custom gemaakt
  • Artwork (Photoshop, Illustrator)
  • Documentatie (FO, TO, Wireframes)
  • Documentatie (Testscripts)
  • Overdrachtsdocument
  • Overdracht Licenties

De spullen zijn binnen...

...maar niet compleet. Hoewel iedere leverancier een bepaalde standaard aanhoudt zijn niet altijd alle deliverables aanwezig. Gebrek aan tijd of geld zijn vaak de oorzaak. Dan moet er geïnventariseerd worden wat de mogelijke risico's zijn van het ontbreken hiervan.

Aan de hand van de aangeleverde spullen wordt een nieuwe ontwikkelomgeving opgezet om te kijken of alles werkt. De code wordt ook geanalyseerd op mogelijke knelpunten welke bij de eerste meeting naar voren worden gebracht. Van ontwikkelstraat tot productieserver (live) wordt de code geheel opnieuw uitgerold. Als dit succesvol is kan de overdracht technisch als afgerond worden beschouwd.

Een nieuwe start

De techniek is er klaar voor, het is nu tijd om de nieuwe relatie te starten. Gebruik een kick-off om de overdracht te bespreken en een nieuwe strategie en roadmap uit te stippelen. Richt je niet op de gedane zaken welke niet goed zijn; je weet niet welke oorzaak hier achter zat. Focus je voornamelijk op de punten waar jij als nieuwe leverancier een goede bijdrage kan leveren.

De overdracht is afgerond en er wacht een nieuwe klant. Een mooi moment om vooruit te kijken.

Checklist overname software Aantal keer bekeken: 3.300