COTS tips / lessons learned

.. tips voor goed gebruik van COTS applicaties

Het grote voordeel van COTS (Common/Commercial-Off-The-Shelf) applicaties is de beperking van de complexiteit en daarmee ‘het gedoe’. Het is feitelijk het statement “Gij zult geen software ontwikkelen” zoals dit bij ‘ In-House applicaties’ gebeurd. Zowel vernieuwing, aanpassingen als het draaiend houden van de appplicatie wordt eenvoudiger. Hergebruik van kennis en bestaande wielen wordt geïnstitutionaliseerd. Dit geldt voor allerlei aspecten zoals de UI, opleiding, stabiliteit, compliance, aanpasbaarheid en … Best-practices.

Integratie wordt vaak gegarandeerd. Interconnectivity met andere platformen en onderliggende database en hardware componenten wordt veelal gegradeerd, sterker in het geval van SAAS verdwijnen dit soort aspecten totaal van de radar.

Met het niet zelf bouwen moeten een ander soort keuzes gemaakt worden. Bij zelf software maken worden de eisen en wensen gerealiseerd, COTS is zo rijk dat er juist een beperkende keuze moet worden gemaakt. “Alles kan in pakket X, maar wat willen we eigenlijk … (minimaal, ooit, nooit). Daarnaast zullen de organisatie en de processen meer rekening moeten houden met het tool i.p.v. Vice versa zoals dit voorheen het geval was.

Mijn tips zijn gerelateerd aan bovenstaande voordelen, verder enkele aanvullingen o.b.v. mijn ervaringen met COTS applicaties op het vlak van SOx controls, ARBO, Service Management, Monitoring en Grootboek

Hanteer een groeimodel voor de uitrol / implementatie. Een big bang benadering werkt niet en is te riskant. Groei zal langs meerdere asssen moeten plaatsvinden: leren, functionaliteit, klanten, processen. de weg der geleidelijkheid leidt tot resultaat.
Maak vooral gebruik van bestaande wielen. Beperk zaken die een eventuele upgrade in de weg kunnen staan.
Hanteer de laatste software versie of zorg voor een laatse versie -X beleid
Beperk het aantal omgevingen. Een productie en een speel/uitprobeer/Sandboxomgeving zijn vereist. Andere omgevingen moeten een duidelijk nut hebben of een bepaald risico afdekken. Aspecten van belang zijn vooral data gerelateerd: databeschikbaarheid, privacy, opbouwsnelheid, grote en omvang.
Beperk jezelf in wat je gebruikt. De functionaliteit is dusdanig rijk en de mogelijkheden zijn ‘onbeperkt’, keuze en beperking zijn essentieel. Genoeg is genoeg, streef naar het optimale (goed genoeg) niet naar het maximale. Werk met timeboxes…
Laat ook het aantal licencies groeien met het gebruik. Daarmee hou je voor de leverancier een incentive om “mee te blijven denken”. De leverancier heeft hiermee een belang in de groei waardoor hij bij de les blijft.
Maak op hoofdlijnen helder wie wat doet. Zowel binnen de organisatie als met de leverancier.
Maak helder waar de grenzen liggen van configureren > customizen > aanpassen. Laat vrij > beperk / restricties > verbied maar ook documenteer / registreer> beslis o.b.v. BC > beleg bij vendor.
Maak het tool leidend in beslissingen…
Stel een aantal principles op ten aanzien van gebruik, aanpasbaarheid, inrichting
Organiseer experimenten met functionaliteit in níeuwe releases.
Maak het simpel, ….en houdt het simpel. Maak vooral gebruik van door de vendor beproefde technieken voor Connectivity, releasemanagement..
Maak gebruik van installatierequirements en voorschriften van de vendor en maak daarmee interne guidelines secundair.
Doe een voor- selectie op basis van magic quadrant en/of interviews van Peers.
Selectie

maak gebruik van een aantal onderscheidende usecases
laat de leveranciers een wedstrijdje houden, evalueer via vooraf vastgestelde criteria
doe de beoordeling met een zo breed mogelijke doorsnede van de organisatie en eventuele stakeholders
Maak een top 3 en laat de uiteindelijke keuze op het juiste niveau / gremium bekrachtigen
Indien gewenst kan met een pilot / PoC gestart worden om de laatste tegenstanders de wind uit de zeilen te nemen
Na de pilot kan plateugericht uitgerold worden ….

Zorg voor een roadmap. Hoewel basis functionaliteit snel beschikbaar kan zijn en gebruikt kan worden is het zaak behoeftes een plek in de tijd te geven. Het is zaak om in tranches / plateaus te denken. Realisatie – verificatie – implementatie cycli kunnen per kwartaal gerealiseerd worden.