Een nieuw IT systeem kies je niet zomaar. Dat doe je omdat je iets wilt bereiken. Lagere kosten voor je bedrijf, meer verkoopkansen om op te volgen, beter inzicht in je processen waardoor je de kwaliteit aan je klanten beter kunt leveren die je nodig vindt en waar nodig op tijd nog kunt bijsturen. Een IT systeem is altijd slechts een deel van de oplossing. Je klanten en je medewerkers helpen hun doelen te bereiken met een nieuw systeem betekent vaak ook trainen, instructie en hulp organiseren voor als het even moeilijk is.
De belangrijkste vragen om te beantwoorden luiden:
1. Waarom hebben we een nieuw IT systeem nodig? (#why)
Als je deze vraag goed beantwoordt sluit je aan op het doel en de strategie van je bedrijf. Sluit het daar niet op aan, dan valt het te heroverwegen of je een nieuw IT systeem nodig hebt!
2. Wat zijn de belangrijkste verwachtingen en uitgangspunten? (# key believes and prerequisites)
De antwoorden op deze vragen zijn de ankerpunten voor de rest van het traject. Een mooi voorbeeld van een klantverwachting: “We zijn een klein flexibel en pragmatisch bedrijf; het mag geen monsterproject worden”. De klant geeft in dit voorbeeld aan dat de oplossing zo simpel mogelijk moet zijn; liever minder functionaliteit dan meer. Ook legt de klant de koppeling met het karakter van het eigen bedrijf, namelijk klein, flexibel en pragmatisch. Dat is een prima vertrekpunt voor latere discussies als je uit allerlei soms heel gedetailleerde voorstellen kiest wat voor jouw bedrijf het beste past.
3. Hoe past een nieuw systeem?
Bedoeld is hier hoe past een systeem in de gewenste setting van (nieuwe) systemen. IT architecten noemen dit de doelarchitectuur. Daarbij is het van belang om te weten in hoeverre data uitgewisseld gaat worden tussen systemen. Vroeger werden daar ingewikkelde interfaces voor gemaakt. Tegenwoordig gaat integratie met andere systemen meestal met API’s. API staat voor Application Programming Interface.
Een API (Application Programming Interface) is een soort digitale stekkerdoos die externe diensten of ontwikkelaars gecontroleerde toegang kan verschaffen tot interne diensten, algoritmes, devices of informatiebronnen. Het aanbieden van een API maakt een algoritme, dienst, devices of data ‘programmable’. Kijk ook op deze video voor een snel begrip: What is an API?
4. Wat moet het nieuwe systeem kunnen?
Dit raakt de essentie van de baten van invoering van zo’n systeem. Het vereist dat je de antwoorden begrijpt op de vragen: Welke business modellen (#business models) zijn van belang? En wat zijn de belangrijkste aandachtsgebieden per business model?
Hieruit blijkt al gauw of je een heel specifiek systeem nodig hebt, dat maatwerk biedt (#customizations) of dat je met slim configureren van een systeem aan je specifieke wensen kunt voldoen (#configurations).
Vervolgens breng je de beoogde doelprocessen (#blue print processes) in kaart en geef je dus antwoord op de vraag:
5. Wat zijn de blauwdruk processen?
Het is verstandig deze in concept uit te werken en vervolgens goed te toetsen bij je belanghebbenden (#stakeholders).
Ga in dit stadium wel voor de hoofdlijn, want bij het invoeren van moderne systemen is het beter om zoveel mogelijk de door het systeem al ondersteunde processen te hanteren, dan om maatwerkprocessen te laten bouwen.Je hebt nu de business modellen met de specifieke aandachtsgebieden en de blauwdruk processen in kaart. Nu is het belangrijk de specifieke wensen voor het systeem goed te inventariseren en vast te stellen. Dat doe je door antwoord te geven op de vraag:
6. Wat zijn de specifieke eisen waaraan invoering/gebruik van het systeem moet voldoen? (#agile #user stories)
Deze vragen kun je het beste beantwoorden in een workshop setting waarbij iedere belanghebbende meedoet of iemand zijn belang laat vertegenwoordigen. Bij voorkeur houd je het aantal deelnemers onder de twaalf zodat ieders inbreng goed meegenomen kan worden. Zonodig kun je natuurlijk meer workshops plannen als je toch meer deelnemers mee wilt nemen in het vaststellen van de eisen.Vervolgens helpt het in de voorbereiding als je al weet welke rollen straks met het nieuwe systeem gaan werken. Als je die rollen hebt kun je vervolgens in brainstorms per rol vaststellen wat die dan nodig heeft van het nieuwe systeem. Je maakt dan zogenaamde gebruikersverhalen (#user stories). De vorm van zo’n gebruikersverhaal bestaat uit:
- de rol
- wat diegene vanuit zijn rol wil
- waarom diegene dat wil
- eventueel hoe te toetsen valt dat is voldaan aan de wensen
Bij die workshop doorloop je eerst weer het doel (#why) en de resultaten naar dat doel tot nu toe. Je toetst daarbij of je de business modellen en/of blauwdruk processen toch nog kunt verbeteren.
Terwijl je dit allemaal in kaart brengt stel je ook een lijst op van software die mogelijk voldoet en je maakt per software leverancier een lijstje van een aantal mogelijke implementatiepartners.
Je geeft daarmee antwoord op de vragen:
7. Welke software kan waarschijnlijk voldoen aan mijn verwachtingen?
Maak een lijstje van mogelijke software. Soms is het aan te raden eerst een langere lijst te maken. Vervolgens kun je met belanghebbenden op voorhand verkennen op welke criteria ze goed of minder goed scoren en zo snel en pragmatisch tot een short list te komen. In andere gevallen is een uitgebreider proces te overwegen. Maak het alleen niet te complex!
8. Welke implementatiepartner kan mij het beste helpen bij het invoeren van het nieuwe systeem?
Om de vragen 8 en 9 goed te beantwoorden helpt het om de belangrijkste business processen uit te werken in zogenaamde use cases. Aan de potentiële implementatiepartners vraag je om aan de hand van de door jou gedefinieerde use cases een demonstratie voor te bereiden. Zo’n use case kun je hoog over maken en daarmee veel vrijheid geven aan de leveranciers om nader in te vullen. Je kunt ze ook gedetailleerd voorschrijven zoals je later nodig hebt voor het testen van je systeem. Ik geef altijd de voorkeur aan een behoorlijke vrijheidsgraad voor de leverancier, omdat je dan als klant meerdere creatieve oplossingen terugkrijgt. Daar kun je je voordeel mee doen door te vragen naar het waarom van specifiek hun oplossingsrichting. Bovendien kun je daarmee de andere leveranciers challengen door te vragen waarom ze het niet op een andere nu specifiek te duiden manier hebben opgelost. Niet zelden leer je hier veel van, zowel over de techniek, de oplossingsrichtingen die mogelijk zijn, maar ook de creativiteit en kunde van de leverancier!
Bij het beoordelen van de stukken, presentaties en demonstratie van de use cases is het van belang om op deze op verschillende aspecten te beoordelen en daarna tot een totaalafweging te komen.
Belangrijke aspecten zijn meestal: Business Processen (match met de blue print processen), gebruik door eindgebruikers, IT Architectuur & Infrastructuur, IT Architectuur & Applicaties, Inkoop/procurement (inkoopvoorwaarden, kun je beter voorschrijven dan overnemen van een leverancier), veranderingsaanpak (scope definitie, changes, governance, gevraagde en geleverde deskundigheid, werkwijze, etc) en natuurlijk Finance (business case, kostprijzen, uurtarieven,, etc). Het werkt prettig als iedere stakeholder één of meerdere aspecten beoordeelt en daarover na elke sessie een beoordeling geeft zowel in een rapportcijfer als met een onderbouwing daarvan.
Als je hebt gekozen voor een oplossing en een implementatiepartner ga je de contracteringsfase in en daarna de implementatiefase.
9. Heb ik een onafhankelijk programma- of projectmanager nodig?
Een systeem werkend krijgen lukt bijna altijd wel. Het accepteren van een systeem door alle gebruikers is nog wel wat anders!
Alleen steunen op de implementatiepartner is bijna altijd onverstandig. Deze heeft nu eenmaal andere belangen dan jij. Hoe agile ze ook werken! Als je zelf de deskundigheid en de beschikbaarheid hebt om je verandering te begeleiden, dan heeft dat altijd de voorkeur. Heb je die kennis en beschikbaarheid niet of onvoldoende voorhanden? Kies dan een onafhankelijke partner om jou te helpen bij het voorbereiden en doorvoeren van de verandering. Change-Partners.nl is onafhankelijk en helpt jou graag de regie te behouden!
Wil je meer weten hoe Change-Partners.nl jou kan helpen bij een voorbereiding en selectie van een nieuw systeem?
Neem vrijblijvend contact op via marcel.otto@change-partners.nl of tom.oudman@change-partners.nl. Je kunt ons natuurlijk ook gewoon bellen op +31 (0)6 5341 7930 of +31 (0)6 5315 9732.
Wil je voorbeelden van templates voor de documenten die wij vaak gebruiken bij voorbereidingen en selecties van systemen? Stuur ons een mailtje waarin je aangeeft wat je nodig hebt en we sturen het je graag toe!
Comments are closed.