Eerste selectie

Voor elke taak die we ons maar kunnen voorstellen, of het nu om instant messaging of e-commerce gaat, bestaan er talloze digitale oplossingen, misschien wel honderden of duizenden.

Het is onmogelijk om al deze oplossingen te kennen. We zullen er van uit moeten gaan dat degene die goed zijn, ondertussen wel redelijk bekend zijn. Een eerste selectiestap kan er daarom in bestaan om de juiste zoektermen in een zoekmachine op het web in te typen.

Daarna maken we een lijstje met de resultaten die uit die zoektocht komen, na een controle dat het wel degelijk om oplossingen gaat voor de gegeven taak.

Trechter van honderden oplossingen tot de beste keuze

In die trechter gebeuren de volgende stappen:

• Bovenaan staan de vele oplossingen die de gegeven taak kunnen oplossen.
• We kennen niet al deze oplossingen, maar onze zoektocht levert de bekendste op.
• We selecteren hieruit de oplossingen die aan onze basiscriteria voor digitale oplossingen voor een zelfdragende samenleving voldoen.
• We selecteren hieruit de oplossingen die aan extra analytische criteria voldoen
• Uit deze ondertussen sterk uitgedunde selectie kiezen we na een strenge analyse en vergelijking de beste kandidaat.

Uiteindelijk komen we zo van misschien honderden oplossingen tot één oplossing die op dit moment de beste keuze is voor de gegeven taak.

In de rest van deze pagina leggen we de verschillende stappen in de trechter uit.

Selectie volgens basiscriteria

Om onze visie op een zelfdragende samenleving voor elkaar te krijgen in onze regio, moeten de digitale oplossingen die we gebruiken aan een aantal basiscriteria voldoen. Een oplossing die niet voldoet aan een van deze criteria, valt af omdat we hiermee onze visie niet kunnen realiseren.

• We moeten de infrastructuur zelf kunnen beheren, zodat we niet afhangen van een systeem buiten onze regio.
• We moeten de software zelf kunnen aanpassen (opensource), zodat we niet afhangen van de maker van de software.
• De infrastructuur is gedecentraliseerd, zodat communicatie en andere digitale diensten als één systeem uitvalt niet verstoord wordt.
• We moeten met andere zelfdragende regio’s kunnen communiceren op een gestandaardiseerde manier (federation).

Voor elke oplossing die we overwegen te gebruiken, moeten we dus kritisch kijken of ze aan al deze criteria voldoet.

Selectie volgens extra analytische criteria

De vorige stap levert ons in principe geschikte oplossingen die onze visie uitdragen. Maar tussen theorie en praktijk liggen nog wat barrières.

Daarom voeren we op de geselecteerde oplossingen nog een evaluatie uit volgens extra analytische criteria. Daarmee kunnen we op een objectieve manier een rangorde in de oplossingen opstellen.

Die criteria zijn:

1            Reputatie

Hoeveel verwijzingen vind je naar de oplossing in (gespecialiseerde) pers en op websites. Zijn de makers van de oplossing actief op sociale netwerken en wordt de oplossing daar vaak vermeld? Zijn die vermeldingen en interacties positief of negatief?

Vermeldt de website klantenreferenties? Zijn het er veel, komen er regelmatig nieuwe bij, en gaat het om belangrijke bedrijven of organisaties? En hoe groot is de lijst met partners en integratoren op de website? Zijn dat grotere of kleinere bedrijven? Het antwoord op al deze vragen geeft je wat zekerheid over de betrouwbaarheid van de oplossing op langere termijn.

2            Dynamiek van de community

Een van onze basiscriteria is dat we niet willen afhangen van de maker van software, en daarom kiezen we voor opensourcesoftware. Maar zelfs bij opensourcesoftware kan het gebeuren dat de maker de enige integrator is of bijna alle ontwikkelaars tewerkstelt. In dat geval hangen we nog altijd van de goede wil van de maker af.

Daarom verwachten we van een oplossing een bloeiende, dynamische community. Worden gebruikers, externe ontwikkelaars en integratoren betrokken bij belangrijke beslissingen over de oplossing? Is die ontwikkeling publiek te volgen in coderepository’s, op forums en mailing lists en op chatkanalen? Zie je daar activiteit van externen? Het antwoord op deze vragen leert je hoe veerkrachtig de community is als de maker ooit beslissingen neemt die tegen de verwachtingen van de community ingaat.

3            Technische kwaliteiten

Software ontwikkelen is een vak apart, en de kwaliteit van oplossingen kan enorm variëren. Het spreekt voor zich dat we niet willen gebruikmaken van broze, onveilige en moeilijk te onderhouden oplossingen. Gebruikt de oplossing bestaande industriestandaarden en is het ontwikkeld met behulp van gekende frameworks en best practices? Is er voldoende aandacht voor veiligheid?

Ook modulariteit is een belangrijke technische kwaliteit. Is de functionaliteit onderverdeeld in afzonderlijke modules, die onafhankelijk van elkaar te upgraden zijn? En is de oplossing eenvoudig aan te leren? Tot slot zijn ook de prestaties niet onbelangrijk.

4            Functionaliteit

Voor elk type oplossing hebben de gebruikers specifieke verwachtingen. Zo verwacht je van een e-commerce-oplossing integratie met betaalproviders, voorraadbeheersystemen en boekhouding, maar ook een zoekfunctie voor bezoekers van de webwinkel. We moeten dan ook evalueren of de oplossing functioneel biedt wat we verwachten van dit soort oplossingen.

5            Uitbreidbaarheid

Vaak volstaat het niet om een standaardoplossing met zijn standaardinstellingen te gebruiken. Elke organisatie heeft wel haar eigen specifieke vereisten op het gebied van functionaliteit. De vraag is dus of de oplossing uitbreidbaar genoeg is om aan die specifieke vereisten te voldoen.

Uitbreidbaarheid is in het ideale geval zowel intern als extern mogelijk. Interne uitbreidbaarheid wil zeggen dat je gemakkelijk de interne datastructuren kunt aanpassen, de gebruikersinterface of zelfs de code zelf. Externe uitbreidbaarheid wil zeggen dat er voldoende programmeerinterfaces zijn om de oplossing uit te breiden met plug-ins en te laten communiceren met andere oplossingen.

6            Regionale beschikbaarheid

Sommige oplossingen hebben wel een bloeiende community met meerdere integratoren, maar zijn in onze regio niet populair. Dat maakt het wat lastiger om dan regionale dienstverleners te vinden. Daardoor word je weer te afhankelijk van buitenlandse aanbieders, wat in de weg staat van onze visie op een zelfdragende samenleving. Stel daarom ook altijd de vraag: vind je in onze regio gemakkelijk dienstverleners, integratoren en/of ontwikkelaars om je met de oplossing te helpen?

Selectie na vergelijking

Als we de oplossingen dan een score geven op deze analytische criteria, kunnen we dit grafisch als volgt weergeven:

Na een vergelijking komen we zo tot een gegronde keuze voor een oplossing in de gegeven categorie, met mogelijk ook andere interessante alternatieven die in specifieke niches misschien beter zijn dan de eerste keuze.

Belangrijk om te vermelden is dat een evaluatie volgens deze criteria en dus ook een keuze voor een oplossing altijd een momentopname is. Het is aan te raden om elke twee tot drie jaar een nieuwe evaluatie uit te voeren, vanaf het begin van de trechter tot een uiteindelijke keuze.

Speciale aandacht voor het open-coremodel

In het criterium van de dynamiek van de community gaven we al aan dat het belangrijk is dat de ontwikkeling van de oplossing niet uitsluitend mag afhangen van de makers van de oplossing. In het ideale geval draagt de community ook bij aan de ontwikkeling.

Als het om opensourcesoftware gaat die voornamelijk door één bedrijf wordt ontwikkeld, is er speciale aandacht nodig voor het businessmodel van de makers. Sommigen gebruiken een open-coremodel. Daarbij bestaat er een opensourceversie van de software (vaak Community Edition genoemd) met basisfunctionaliteit, naast een propriëtaire versie met extra functionaliteit (vaak Enterprise Edition genoemd).

Zo heeft de bedrijfssoftware Odoo een opensourceversie, mede ondersteund door de Odoo Community Association (OCA). Hiervoor zag je een voorstelling van hoe deze oplossing op onze zes criteria scoorde. Het bedrijf achter Odoo hanteert een open-coremodel en biedt ook een Enterprise-versie aan. We dienen elke paar jaar te herevalueren of de community rond de opensource Odoo-versie nog dynamisch genoeg is om de meest geschikte keuze voor bedrijfssoftware te zijn.

Het risico bestaat dat het bedrijf Odoo ooit zozeer de nadruk legt op de Enterprise-versie dat het minder investeert in de ontwikkeling van de opensourceversie of in die versie veel beperkingen oplegt. Op dat moment kom je na je evaluatie mogelijk tot het besluit dat andere bedrijfssoftware een betere keuze is.