Nieuwe software kiezen: gebruik de juiste argumenten

Er moet wel een correct beeld ontstaan van de punten die de verkoper minder belicht. Worden die punten slechts minder belicht, of zijn het punten waarop het systeem minder presteert? Dat laatste is van belang omdat na ingebruikname van een systeem de initiële voordelen snel ‘gewoon’ worden en dan gaan de mindere punten opvallen. Als deze punten daarna gaan storen wordt het gebruik van het systeem beïnvloed en kunnen zij bijdragen aan een afbreuk van het totale draagvlak. Dan zit je met een systeem dat maar beperkt gebruikt wordt.

Plan van Aanpak
Een pakketkeuze begint bij de interne organisatie. Stel veel vragen, zoals:

• Wat heeft de organisatie nu aan middelen?
• Waar schiet het huidige systeem tekort?
• Welk probleem moet het nieuwe systeem gaan oplossen?
• Kan er gefaseerd geïmplementeerd worden?
• Hoe erg wordt de interne organisatie door de migratie belast?
• Hoeveel budget is voor de vervanging beschikbaar?
• Kan je met jouw organisatie de ‘cloud’ in? En waarom zou je dat doen?

Het is dus van belang om vooraf na te denken over het wat en waarom van het nieuwe systeem. Binnen de eigen organisatie ontstaat dan een duidelijk beeld waar men aan begint en de leveranciers komen beter voorbereid op gesprek. Informatie over het beschikbare budget delen met de leveranciers is zeker aan te raden. Het voorkomt verkeerde verwachtingen en verspilde tijd. De leverancier zal met betere oplossingen kunnen komen als die weet wat het budget is. Partijen die ‘te duur’ zijn haken direct af en dat zorgt voor transparantie gedurende het proces.

Een goed plan van aanpak draagt zeker bij tot een beter project. Vanaf de start word je als kopende partij bestookt met (marketing)kreten zoals ‘360 graden klantbeeld’, ‘keten-integratie’ en ‘integraal inzicht’. Wat dat inhoudt is vaak pas te begrijpen als het complete project is afgerond. Maak daarom vooraf een opgave van wat er na de oplevering daadwerkelijk uit het systeem moet komen qua rapportages en ‘inzichten’. Dit helpt de implementatiepartner of leverancier bij de correcte inrichting van het systeem tijdens de implementatie. Medebepalend voor het resultaat is hoe de migratie van de historische data gaat plaatvinden. Zonder data geen inzicht en geen vergelijkbare rapportages.

Leverancier of partner?
Na de initiële afspraken en globale demo’s is het zaak om te gaan focussen. Met welke leverancier en met welke oplossing heb je de beste match? De bedoeling is dat je een relatie voor meerdere jaren gaat opbouwen met de leverancier. Dan kan die relatie maar beter goed zijn. De leverancier moet dus een partner worden. De angst voor ‘uurtje-factuurtje’ is vaak ingegeven door een ervaring uit het verleden. Als de relatie tussen beide partijen goed is en de leverancier zich een partner voelt, zal die vaak juist niet alles in rekening brengen en meer doen dan gevraagd om de relatie goed te houden. Behandel je jouw leverancier als ‘leverancier’ dan wordt alles facturabel.

Waarop letten?
De belangrijke punten op een rij:

• Continuïteit: Juist in de huidige tijd, waarbij (helaas) veel bedrijven in financiële moeilijkheden komen, is het belangrijk om te toetsen of je leverancier financieel gezond is. Je gaat een relatief grote investering doen en een langdurige relatie aan. Ook de bedrijfsstructuur van de leverancier is belangrijk. Is het een eenmanszaak waarbij de klanten het risico lopen dat het bedrijf stopt of is het een implementatiepartij die zelf geen eigen software maakt? Hoe zit het dan met de relatie tussen die partijen? Als de softwareleverancier besluit dat de implementatiepartner niet voldoende omzet heeft aangebracht kan het zomaar ‘over en uit’ zijn. De klant is dan de dupe. Vraag ernaar en wees kritisch.
   
• Domeinkennis: Heeft de leverancier veel domeinkennis? Dan zal een implementatietraject soepeler verlopen en vaker binnen budget blijven. Een ervaren partij zal de juiste vragen stellen, goede inschattingen maken en daardoor professioneel overkomen. Dat geeft vertrouwen. Je hoeft als klant niet de leverancier op te leiden. Vaak brengt de leverancier nieuwe ideeën en inzichten in, gebaseerd op ‘best practices’ bij soortgelijke bedrijven.
   
• Functionaliteit: Wat biedt het nieuwe software pakket aan functionaliteit? Hoe steekt de user interface in elkaar? Is het pakket gebaseerd op nieuwe technieken of is het een wat ouder platform? Aangezien er meerdere mensen in je organisatie met het nieuwe pakket gaan werken, is het zaak om de wensen en eisen per afdeling in kaart te brengen en te toetsen aan de functionaliteit die het nieuwe pakket biedt. Hierbij is het van belang om in te schatten wat de software in de nabije toekomst moet kunnen brengen. Is het pakket ‘future proof’? Daarnaast is het goed om te weten of er hulp beschikbaar is zodra dat  nodig is. Is er een helpdesk die je vragen begrijpt? Of is er een online toegankelijke helpfunctie? En wat kost die hulp precies?
   
• Koppeling met bestaande software: Deze koppelingen (interfaces) zijn vaak ingewikkeld en perfect werkende en uitvoerig geteste koppelingen zijn niet altijd voorhanden. Hierbij speelt de expertise en flexibiliteit van de leverancier een doorslaggevende rol. Vraag je altijd af of een interface nodig is en wat deze aan het proces toevoegt.
   
• Implementatietijd: Als een leverancier domeinervaring heeft zal de implementatie bij soortgelijke bedrijven sneller gaan. Een ‘generieke’ leverancier zal toch niet alle ‘ins-en-outs’ van uw business kennen en het pakket zal misschien maatwerk nodig hebben. En juist maatwerk wil je zoveel mogelijk beperken. Maatwerk heeft impact op onderhoud en vernieuwing. Standaard software biedt vele voordelen qua investering en onderhoud, terwijl kleine aanpassingen binnen de standaard vaak mogelijk zijn.
   
• Referenties: Check referenties. Op alle niveaus die met het pakket werken. Alleen een CEO of directeur bellen geeft wellicht niet het volledige plaatje. Bel ook met mensen die er vanuit een andere rol mee werken.
   
• Aanschafprijs: Te vaak wordt er alleen op basis van financiële overwegingen een keuze gemaakt. En dan valt het resultaat vaak tegen. Prijs is niet alleen bepalend voor de keuze. Het duurste pakket is niet altijd de beste keuze. Juist een combinatie van factoren zal de uiteindelijke prijs bepalen. Een specialist zal wellicht initieel wat duurder zijn, maar omdat de specialist sneller kan implementeren is hij uiteindelijk goedkoper. En vaak nog beter ook! Koop bewust. 
   
• Kosten: In principe zijn er drie hoofdsoorten kosten:
  1. Licenties voor het gebruik van de software.
  2. Implementatie en migratie Het pakket inrichten zodat je medewerkers er goed mee kunnen werken, interfacing met andere software en migratie van historische data, zodat het nieuwe systeem gevuld is met de juiste klantgegevens en producten. Je kunt uiteraard ook helemaal ‘schoon’ beginnen.
  3. Onderhoud Ook software heeft onderhoud nodig. Denk hierbij aan updates en upgrades, bugfixes en kleine functionele aanpassingen.

Cloud of In house?
Bij een ‘cloud’-oplossing wordt de software door de aanbieder gehost en hebben gebruikers toegang via internet. Bij een ‘in house’-oplossing staat de software op een lokale server die de gebruikers via het bedrijfsnetwerk kunnen benaderen. Een mix van beide is ook mogelijk (hybride oplossing). Bespreek tijdens de inventarisatiefase met de leverancier wat de beste oplossing is.

De kostencomponenten zijn gelijk voor een ‘cloud’-oplossing of een ‘in house’-installatie. Bij ‘cloud’-oplossingen worden vaak maandbedragen berekend en is er sprake van een lage initiële investering, terwijl bij een ‘in house’-installatie de licenties en het onderhoud vaak vooraf betaald moeten worden. De implementatiekosten kunnen verschillen voor ‘cloud’ en ‘in house’. Bij de ‘cloud’ kan vaak gewerkt worden met templates waardoor er zeer efficiënt gewerkt kan worden. De inrichting wordt ‘copy-paste’ overgenomen en aangepast waar nodig. De hardware is tenslotte bekend en eenvoudig toegankelijk voor de leverancier. Een ander verschil kan zitten in de reis- en verblijfkosten voor de consultants die de implementatie uitvoeren. Bij de ‘cloud’ zullen die lager zijn of zelfs geheel wegvallen. Bij de ‘cloud’ moeten er wellicht nog extra hostingkosten betaald worden en moet de internetverbinding misschien aangepast worden. Bij een ‘in house’-installatie moet de hardware voldoen aan de eisen die de leverancier stelt om optimaal functioneren van de installatie te garanderen.  Dit zit bij de ‘cloud’-oplossing normaliter inbegrepen.

Scope?
Je wilt geen verrassingen qua kosten achteraf. Toch komen die vaker voor dan je denkt. Implementatiepartijen die zelf geen eigen software maken maar software van derden implementeren, leven van consultancy. Op zich is dat niet erg, mits er duidelijke afspraken gemaakt zijn, in de vorm van Service Levels Agreements (SLA). Ook de ‘scope’ van het project moet vooraf goed beschreven zijn, zodat duidelijk is welke diensten en functionaliteit de software moet leveren. Het is heel belangrijk om de scope goed in een document vast te leggen, want onduidelijkheid levert vaak achteraf onvrede op. De klant verwacht bepaalde functionaliteit: “Dat is zo standaard, dat doet iedereen, dus het hoort er gewoon in te zitten!”, terwijl het in de scope niet zo duidelijk beschreven is.

Extern Advies
Er komt best veel kijken bij het aanschaffen van een pakket en voor wie dit geen dagelijkse praktijk is, kan een extern advies helemaal geen kwaad. Let wel op wie je om advies vraagt. Helaas zijn er nog steeds advies- en consultancybedrijven die de pakketkeuze vooraf al hebben gemaakt. Dan kun je beter geen adviesbureau inschakelen, want dan is dat weggegooid geld. Een onafhankelijke organisatie of adviseur kijkt naar je bedrijf en processen en vertaalt die naar een plan van eisen. Pas daarna kijkt die naar de juiste oplossing.

(Onvoorziene) kosten achteraf
Als de leverancier geen invloed op de softwareontwikkeling heeft, kan dit leiden tot onvoorziene kosten achteraf. De consultancypartij, die de implementatie doet, heeft weinig tot geen invloed op de ontwikkelingen bij de grote softwareontwikkelaar (Nederland is tenslotte maar een kleine markt voor dit soort grote partijen) en heeft bovendien belang bij nieuwe releases en nieuwe versies. Vaak vergen deze grote releases opnieuw consultancy-inspanningen, die de implementatiepartner wellicht ook niet kan voorzien, maar die wel noodzakelijk zijn omdat oudere releases niet meer ondersteund worden. Als klant kun je geen kant op en moet je wel opnieuw investeren. Voorzien of onvoorzien, het zijn kosten achteraf die je liever niet hebt.
Bij branchespecifieke software, waarbij de software-ontwikkelaar zelf de implementatie doet, zal dit veel minder vaak voorkomen dan bij grote generieke softwareleveranciers. Bij veel branchespecifieke software zijn de updates en upgrades al in de licentie en het onderhoud meegenomen. Dit betekent nauwelijks onvoorziene kosten achteraf.

De praktijk
Een voorbeeld uit de praktijk, gebaseerd op algemeen toegankelijke informatie via internet van een generieke consultancypartij:

“De digitale wereld ontwikkelt zich in rap tempo en pakket xxx ontwikkelt zich hier vanzelfsprekend in mee. Dit heeft periodieke nieuwe releases tot gevolg. De keerzijde hiervan is dat de oudere releases niet langer door xxx worden onderhouden en in de toekomst mogelijk niet langer voldoen aan de eisen die de wetgeving hieraan stelt.”

“De overgang naar xxx2015 is een major release wisseling. Zowel de architectuur als de functionaliteit hebben ingrijpende verbeteringen ondergaan. De gebruikersinterface van xxx heeft in de laatste releases een ware metamorfose ondergaan.”

Wat zijn hiervan de consequenties voor de gebruikers van de oudere releases?
Een upgrade naar de nieuwe versie of release is een schijnbaar ingrijpende stap die een zorgvuldig plan van aanpak verdient. Welke stappen moeten er genomen worden en wat wordt er van de organisatie gevraagd?
Uit bovenstaande kun je opmaken dat een keuze maken niet eenvoudig is en dat additionele consultancy zeker nodig is. Je bent overgeleverd aan de grillen van een zeer grote, vaak internationale partij (xxx) die geen rekening houdt met de wensen en eisen van individuele klanten in een markt die voor dit soort grote ontwikkelaars klein is. Dit leidt tot bijkomende kosten die je bij een branchespecifieke oplossing niet snel zult hebben.
 
Een leverancier van branchespecifieke oplossingen (waarbij de ontwikkelaar zelf de implementatie doet) organiseert elk jaar klantendagen waarop hij luistert naar wat de klanten en gebruikers willen. Ook worden aanpassingen op basis van die input snel gerealiseerd. Je wordt als klant serieus genomen, omdat de ontwikkelaar net zo afhankelijk is van de klant als de klant van de ontwikkelaar. Dat kan bij een generieke implementatiepartij ook zo zijn, maar die heeft vaak geen invloed op het releasebeleid van de grote software-leverancier.

Conclusie
Een goed plan van aanpak is onontbeerlijk en draagt vanaf de start bij aan een goed project. Branchespecifieke softwarepartners kennen de markt, de eigenschappen en de werkwijzen van hun klanten in de sector.

Succes met het kiezen op basis van de juiste argumenten!