Woningcorporaties kunnen hulp gebruiken bij de selectie van it-systemen voor hun organisatie. Ze komen er vaak later in een traject achter dat bepaalde functionaliteit toch niet zo goed werkt als verwacht of dat de integratie niet soepel verloopt. Tijdens het selectieproces is hier dan vaak te weinig aandacht voor geweest. Ik wil hier verandering in brengen en geef daarom tips als leidraad bij een pakketselectie.
1. Houd rekening met de eigen organisatie. Corporaties houden vaak onvoldoende rekening met de eigen organisatie: wat voor product kunnen wij aan? Het is zaak om na te gaan of het pakket past binnen het proces en bij de beheerorganisatie. Ook de vraag of er voldoende kennis binnen de organisatie aanwezig is om het pakket te laten draaien is van belang.
2. Let niet alleen op functionaliteit. Vaak wordt met name gekeken of een pakket functioneel is, of sterker nog, of het er goed uitziet. Vragen zoals of het pakket veilig en robuust is en of het kan koppelen met de omgeving blijven vaak onderbelicht, maar zijn wel heel essentieel.
3. Bekijk procesondersteuning in een breder geheel. Beveiliging wordt meestal pas in een later stadium dan tijdens de pakketselectie bekeken en aan de toepasbaarheid binnen een volledig proces wordt nog weleens voorbij gegaan. De beoogde procesverbetering wordt daardoor vaak niet gerealiseerd. Corporaties moeten procesondersteuning dan ook in het geheel bekijken, in relatie tot andere pakketten die ze hebben draaien.
4. Voorkom maatwerk. Voorkom bij een pakketselectie dat er teveel maatwerk aan te pas gaat komen. Het moet geen doel op zich zijn om het pakket volledig te willen customizen tot het precies past bij jouw situatie. Pas de eigen organisatie ook aan naar het pakket en zoek zo naar een balans die het meeste voordeel biedt. Spreek bij maatwerk ook altijd duidelijk met de leverancier af wie voor de eventuele bijkomende onderhoudskosten opdraait. Uitbreidings- en onderhoudskosten leiden vaak tot onaangename financiële verrassingen.
5. Zorg voor veilige koppelingen. De beveiliging van een geïsoleerd pakket is veelal goed geregeld. Pakketten integreren echter steeds meer met andere systemen. Dan is het met name de vraag of de koppelingen wel veilig zijn, bijvoorbeeld een koppeling naar een ketenpartner, maar ook koppelingen met bepaalde portalen die aan een pakket zijn verbonden. Zodra functionaliteit via het internet beschikbaar wordt gesteld, zal moeten worden voldaan aan de zogenaamde OWASP-criteria.
6. Betrek de business en it. Een pakketselectie wordt vaak vanuit één bepaalde afdeling geïnitieerd. Daarbij wordt vaak vergeten om na te gaan of bepaalde functionaliteit al via een andere applicatie wordt aangeboden. Het gevolg kan zijn dat twee keer dezelfde functionaliteit binnen een applicatielandschap beschikbaar komt. Betrek daarom op tijd zowel de business als de it-afdeling in het selectietraject, zodat de input vanuit beide afdelingen komt.
7. Maak duidelijke afspraken met de leverancier. Sla’s moeten vooraf duidelijk worden gecommuniceerd. Het maakt veel uit of een pakket 24/7 beschikbaar moet zijn, of dat dit alleen tijdens kantoortijden het geval is. Initieel wordt deze overweging vaak niet meegenomen. Als deze later alsnog ter sprake komt, vallen de kosten vaak behoorlijk hoog uit en is het traject zo vergevorderd dat het ook geen optie meer is ermee te stoppen. Hoe eerder dit soort zaken op tafel liggen, des te kleiner het risico op allerlei kosten achteraf.
Redeneren vanuit functionaliteit
Veel woningcorporaties denken wel dat ze voldoen aan deze richtlijnen, maar realiseren toch te weinig effect, omdat ze onvoldoende kritisch zijn op de antwoorden van hun leverancier. Ik heb vaak te maken met de integratie van pakketten en ik zie daarbij geregeld dat er onvoldoende naar de technische kwaliteitsaspecten wordt gekeken. Corporaties redeneren vaak erg vanuit functionaliteit, waarbij zij voor het gemak kiezen voor een leverancier die hen eerder pakketten heeft geleverd, ongeacht of dit de beste optie is. Hierdoor worden woningcorporaties verderop in het traject vaak geconfronteerd met het feit dat een pakket toch niet zo goed werkt als verwacht, of dat de integratie niet soepel verloopt. Daarom is het van groot belang dat hier tijdens de selectie voldoende aandacht aan wordt besteed.
Raimond Brookman, principal architect bij Info Support
Beste Raimond,
Dank voor je artikel. Je haalt hele goede en relevante punten aan. Ik moet wel aangeven dat de aangehaalde punten ook binnen andere branches gebruikt kunnen worden.
De uitdaging die woningcorporaties hebben is dat ze niet eenvoudig van het ene pakket naar een ander pakket kunnen overstappen, vanwege de specifieke functionaliteiten die vereist zijn, zoals het kunnen administreren van VHE, objecten, technische eenheden, administratieve eenheden en het uitvoeren van service processen, onderhoudsprocessen etc. Het migreren van de gegevens van het ene pakket naar het ander pakket is ook niet even gedaan. Dus de keuze wordt dan vaak gemaakt om door te gaan met dezelfde leverancier en waar nodig aanpassingen door te voeren. Ook de schaal grootte van de woningcorporatie speelt een grote rol in de pakketkeuze.
Marianne,
No offense, maar wat maakt dat het uitvoeren van processen een corporatie meer dan andere organisaties belemmert in het overstappen naar een ander pakket? Dat zo’n overstap niet perse makkelijk is bestrijd ik niet, maar met het juiste (generieke) perspectief zijn processen en (nieuwe) tool op elkaar af te stemmen.
Beste Michiel,
Dank voor je reactie.
In mijn reactie geef ik niet aan dat het overstappen naar een andere pakket bij woningcorporaties meer is dan bij andere organisaties. Ik geef alleen aan wat de uitdagingen zijn en waarom er ‘eenvoudig’ weer wordt gekozen voor dezelfde leverancier, zoals in het artikel is aangehaald.
Waar een wil is, is zeker een weg, maar de wil moet er ook zijn. En die is er niet altijd, ongeacht type organisatie.
De helft van de genoemde punten zijn de functionele attributen, de andere helft de non-functionele die inderdaad nog weleens vergeten worden. De vraag is of er ook gekeken wordt naar onderliggende platform zoals database en eventuele framewerken. Opmerkelijk vaak blijken onder de motorkap nog weleens oplossingen gebruikt te worden die al lang niet meer ondersteund zijn door de leverancier. Dat levert niet alleen problemen op met het onderhoud maar vaak ook de prestaties omdat mogelijkheden van code (32-bits) en hardware (64-bits) uit de pas gaan lopen. Misschien handig om dus ook te selecteren op efficiëntie.
Betreffende efficiëntie ben ik aangaande punt 6 benieuwd vanuit welk perspectief een eventuele rationalisatie gedaan gaat worden. Een dubbele functionaliteit kan namelijk positieve effecten hebben op de non-functionele attributen doordat je niet afhankelijk bent van één ingang. Gelijk daarmee trek ik punt 4 in twijfel omdat dit meestal het commerciële gebrul is van pakket leveranciers die hun niche proberen op te rekken, we hebben een hamer en dus is alles een spijker. Verder is dit – zoals Michiel al zegt – niet specifiek gebonden aan een sector, veel organisaties hebben pakketten die vanuit een eenzijdig perspectief zijn geselecteerd.
Even voor de duidelijkheid, de IT-afdeling wordt door veel organisaties als duur en lastig ervaren en wordt er meestal pas bij geroepen als er problemen zijn. Betreffende de goede beveiliging kan ik melden dat vaak het pleisters plakken al lastig is en dan zal ik het nog maar niet hebben over de weerstand die er vanuit de leveranciers is om het middelenbeslag te verbeteren. Zie ook:
https://www.computable.nl/artikel/opinie/infrastructuur/4619191/2379248/oud-maar-nog-niet-vervangen.html
Ewout, bij punt 6 gaat het er vooral om dat er bewuste keuzes gemaakt worden rondom dubbele functionaliteit en dan ook vooraf. Soms vanwege niet-functionele eisen het inderdaad zinvol zijn om dubbeling in functionaliteit te hebben. Maar mijn constatering is dat het vaak niet bewust gebeurt. De ene afdeling selecteert los van andere afdelingen een tool voor ondersteuning van “hun” probleem en later in het traject blijkt dan soortgelijke functionaliteit al in huis te zijn, als een aparte applicatie of als optionele module in een pakket die wellicht nog niet in gebruik genomen is.
Mbt punt 4: ik zie maar al te vaak dat een organisatie (ook buiten woningcorporaties) aan de ene kant een standaard pakket willen (vanuit kostenbeheersing), maar aan de andere kant toch dit pakket helemaal willen aanpassen aan hun eigen “unieke” situatie. Zolang dit binnen de inrichtingsparameters past is dat ook prima. Echt zo gauw dit maatwerk gaat vergen moet je je afvragen of de organisatie dan wel een handig proces gebruikt, aangezien het pakket gericht is op hoe de meeste organisaties in een branche werken.
Marianne, het klopt dat veel punten ook buiten woningcorporaties valide zijn. Ik zie bij woningcorporaties wel veel meer de neiging om bij vertrouwde dingen te blijven en de tendens om veel verantwoordelijkheid bij de leverancier neer te leggen. Dit omdat corporaties veelal geen eigen ontwikkeling doen en IT liever zoveel mogelijk uitbesteden. Echter dan ontstaat te meer het risico dat er te weinig aandacht is voor de genoemde punten omdat er te veel vertrouwen bij de leveranciers gelegd wordt en dat die “onderling wel zorgen dat het allemaal goed werkt”.
Juist in een situatie met veel uitbesteding zul je zelf grip moeten houden op integratie en op de selectiecriteria van pakketten, zowel functioneel als niet-functioneel.
@Raimond
Betreffende functionaliteiten en standaards zijn er meerdere manieren om zoiets bassaals als e-mail te implementeren. Keuze tussen SMTP, POP3 en IMAP heeft niet alleen impact op de middelen maar ook de poorten. Hetzelfde geldt voor databases waar je niet alleen voor verschillende toegang kunt kiezen maar ook waar je de business logic legt. De standaard pakketten leggen laatste nog weleens in de code waardoor de integratie dus moeilijk wordt, maatwerk wordt je dus vaak opgelegd door de leverancier.
In de praktijk zie je dan ook vaak dat er een pakket gekozen wordt die voor uitdagingen zorgt bij IT zoals dat een andere smaak database ook een andere back-up agent nodig heeft bijvoorbeeld. En dan zal ik het maar niet hebben over problemen in de prestatie als normalisatie van database niet gedaan kan worden waardoor er steeds meer resources nodig zijn. Ik betwijfel of er voldoende onder de motorkap gekeken wordt, men schaft nog weleens een dieselmotor aan en tankt vervolgens benzine.