Applicatiestrategie
Inleiding[bewerken | brontekst bewerken]
Een woningcorporatie is geen statische organisatie, maar een organisatie waarbinnen een dynamiek bestaat. Zo zijn niet alle processen even stabiel als gevolg van:
- Externe invloeden (bijvoorbeeld veranderende wetgeving);
- De behoefte om te optimaliseren (bijvoorbeeld kosten verlagen, doorlooptijd verkorten);
- De behoefte om te specialiseren;
- De wens om te innoveren.
Deze verschillen uiten zich in de bedrijfsinrichting van de woningcorporatie. Niet voor alle processen kunnen dezelfde eisen aan de bedrijfsinrichting gesteld worden. Er moeten afgeleid van de bedrijfsstrategie en afhankelijk van bovengenoemde dynamiek keuzes gemaakt worden over hoe de bedrijfsinrichting eruit komt te zien. Als gevolg hiervan worden er ook verschillende eisen gesteld aan de informatievoorziening. Deze zal in staat moeten zijn zowel dynamische als minder dynamische processen te ondersteunen en hierbij betrouwbare informatie moeten leveren. Het sturen van de informatievoorziening zodat deze hiertoe ook in staat is, is onderdeel van een BIP-traject.
Voor kleinere woningcorporaties lijkt bovenstaande niet direct van toepassing. Een kleinere woningcorporatie kent minder (complexe) processen en heeft over het algemeen een meer eenvoudige automatiseringsbehoefte. Kleinere woningcorporaties hebben hierdoor over het algemeen voldoende aan minder pakketten om de administratie in te voeren. Ook de risico’s bij het min of meer handmatig uitvoeren van processen m.b.v. bijvoorbeeld Excel is door de beperkte schaal minder groot. Wordt dit risico te groot dan kan er eenvoudig een nieuw pakket aangeschaft worden.
Maar ook bij kleinere woningcorporaties komt er door groei op den duur een omslagpunt in de complexiteit en is IT geen middel meer maar een belemmering. Om dit te herkennen en op de toekomst voorbereid te zijn is het ook voor kleinere woningcorporaties goed om kennis te nemen van de vraagstelling en beoordelingscriteria bij de keuze van een applicatiestrategie.
Wat betekent die dynamiek? De informatievoorziening van de woningcorporatie wordt gerealiseerd door applicaties. Omdat er door de hierboven aangegeven dynamiek verschillende eisen gesteld worden aan de informatievoorziening binnen de woningcorporatie worden applicaties verschillend ingezet. Het inzetten van applicaties gaat verder dan alleen het voeren van de bedrijfsadministratie. Het omvat alle activiteiten waar we ter ondersteuning informatiefunctionaliteit voor inzetten, denk bijvoorbeeld aan applicaties voor klantondersteuning, managementinformatie of om informatie als product aan een klant aan te bieden. Omdat applicaties zo verschillend ingezet kunnen worden is het belangrijk na te denken over een applicatiestrategie.
Er bestaan dus per definitie verschillende categorieën applicaties binnen de woningcorporatie. Aan de ene kant van het spectrum vinden we applicaties die snel geïmplementeerd zijn om te experimenteren, om op korte termijn aan nieuwe eisen te kunnen voldoen of om snel een gewijzigd proces door te kunnen voeren (bijvoorbeeld SMS-diensten voor huurders of ad-hoc stuurinformatie). Aan de andere kant van het spectrum vinden we applicaties die gekenmerkt worden door de stabiliteit van de processen die ze ondersteunen of doordat deze processen gemeengoed zijn (bijvoorbeeld HRM en inkoop). In figuur 1 zijn voor applicaties een aantal karakteristieke verschillen in dit spectrum uiteengezet.
Over het algemeen zal een woningcorporatie bijna altijd een bestaande applicatie willen kopen, in plaats van het zelf te ontwikkelen. Soms is echter de conclusie na een zogenaamde ‘make-buy analyse’ dat er geen applicaties zijn die voldoende aansluiten bij de eisen. In dat geval is maatwerk de enige oplossing. Maatwerkoplossingen vinden we in figuur 1 typisch terug in de bovenkant van het spectrum, waar wordt geëxperimenteerd, innovaties plaatsvinden, onderscheidende processen ondersteund moeten worden, en/of processen nog niet volledig gestabiliseerd zijn of gemeengoed zijn geworden.
Gedurende het bestaan van een applicatie kan deze van boven naar beneden zakken in het spectrum. Dit betekent dat het proces dat de applicatie ondersteunt, stabiliseert, minder onderscheidend is en / of gemeengoed is geworden. De functionaliteit voor dit proces zal dan niet langer in een maatwerk, Excel, of aparte applicatie zitten maar eerder opgenomen zijn in een ERP-suite.
Welke applicatiestrategieën zijn er?[bewerken | brontekst bewerken]
Om de applicatiestrategieën te introduceren is het nodig eerst iets over de mogelijke operationele modellen van een woningcorporatie uit te leggen. De applicatiestrategieën hebben hiermee namelijk een directe link. Met een operationeel model beschrijft een woningcorporatie in welke mate zij streeft naar bedrijfsprocesintegratie en –standaardisatie. Ross, Weil, en Robertson komen met deze aspecten tot onderstaande vier operationele modellen (Ref. 13). De vragen om deze aspecten te kunnen plaatsen in één van die operationeel modellen zijn:
- What is the enterprise’s desired operating model - oftewel: wat is de benodigde inrichting en werking van de woningcorporatie?
- How will IT support the desired operating model? - oftewel: hoe ondersteunt IT-inzet deze inrichting en werking van de woningcorporatie?
In een fusie zal een woningcorporatie zich hoogstwaarschijnlijk in het kwadrant ‘diversificatie’ bevinden. De te fuseren onderdelen doen dezelfde dingen, maar elk op hun eigen en verschillende manier, wat neerkomt op een lage mate van standaardisatie en een lage mate van integratie. Dit is waarschijnlijk niet waar de fusie woningcorporatie wil zijn, de wens kan bijvoorbeeld zijn om te streven naar unificatie.
Van de operationele modellen naar applicatiestrategieën kunnen we de assen uit figuur 2 op de volgende manier vertalen. De as van de processtandaardisatie vertaalt zich in de keuze om pakketminimalisatie toe te passen (hoge mate van standaardisatie) of voor functionele aansluiting op de wensen (lage mate van standaardisatie). De as van de procesintegratie vertaalt zich in de keuze voor een manier van koppelen waarbij functionaliteit eenvoudig geïntegreerd kunnen worden (in dit stuk verder een ‘losse koppeling’ genoemd). Of een manier van koppelen waardoor de functionaliteiten minder vanzelfsprekend geïntegreerd kunnen worden (in dit stuk verder een ‘harde koppeling’ genoemd).
Dit levert grofweg de vier applicatiestrategieën uit figuur 9.3 op die voor woningcorporaties interessant zijn. Op details kunnen de verschillende strategieën nog van elkaar verschillen, maar voor dit overzicht is bovenstaand onderscheid voldoende. Met de klok mee in het schema:
- Best-of-breed met ESB - In deze strategie is het streven naar een optimale functionele aansluiting van de applicaties op de processen. Hierbij wordt er per definitie voor elke informatiefunctie opnieuw bepaald welk pakket in de markt hier het meest geschikt voor is. In de praktijk wordt bij de uiteindelijke beslissing wel vaak gekeken naar wat er al in huis is. In deze strategie zijn de pakketten los aan elkaar gekoppeld met behulp van een Enterprise Service Bus (ESB). Een ESB kan het best ingericht worden in een service georiënteerde architectuur (SOA) stijl conform de bijbehorende ontwerp principes. Op een ESB bieden pakketten services aan die de functionaliteit(en) van het pakket ontsluit(en). Dit kunnen eenvoudige raadpleeg-acties zijn (bijvoorbeeld ‘lees huurder’) of complexere acties die een proces starten (bijvoorbeeld ‘verwerk huuropzegging’). Deze services, overeen¬komend met CORA informatiefuncties, zijn over het algemeen afgebakend op de informatiedomeinen en zijn herbruikbaar voor andere pakketten.
- Dominant pakket satelliet systemen en ESB - In deze strategie is het doel pakket minimalisatie. Dit wordt bereikt door de informatiefuncties aan een dominant pakket toe te wijzen, bijvoorbeeld het ERP-pakket. Uitzondering is wanneer de functionele aansluiting te beperkt is, het dominante pakket het niet ondersteunt of de informatiefunctie onderscheidend / strategisch is. Dan wordt er een apart pakket ingezet. Ook in deze strategie zijn de applicaties los aan elkaar gekoppeld met een ESB.
- ERP-pakket - In deze strategie is het doel ook pakketminimalisatie door alle informatiefuncties aan het ERP-pakket toe te wijzen. Alleen voor een aantal zeer specialistische functies waar het ERP-pakket niet in voorziet zijn specialistische pakketten ingezet. In deze strategie is het ERP-pakket hard gekoppeld aan de andere pakketten. Een harde koppeling maakt gebruik van de interne structuur en werking van pakketten om deze aan elkaar te koppelen. Hierdoor kan een interne wijziging van een pakket (bijvoorbeeld in het datamodel) ertoe leiden dat de koppeling ook wijzigt.
- Best-of-breed met point-to-point koppelingen - In deze strategie is het doel om een optimale functionele aansluiting te bereiken. Hiervoor worden de informatiefuncties geconsolideerd in een aantal pakketten. Deze pakketten worden hard aan elkaar gekoppeld met point-to-point koppelingen om informatie waar nodig uit te wisselen.
Waarop bepaal ik een passende applicatiestrategie?[bewerken | brontekst bewerken]
Zoals aan het begin al aangegeven is het zo dat niet voor elk organisatieonderdeel dezelfde strategie geldt. Maar wat zijn nu de aspecten die in een keuze voor een (deel)strategie meegenomen kunnen worden?
Deze keuze of weging van de aspecten is geen autonome keuze van de woningcorporatie, zij is ook gebonden door de omgeving of context van de woningcorporatie. Zij wordt bijvoorbeeld beïnvloed door het huidige applicatielandschap, politiek (wet- en regelgeving), economie, techniek, enz. Het komen tot een goede applicatiestrategie is dus een hele opgave! Wanneer een keuze gemaakt is betekent dit niet dat de praktijk hierop aansluit. Er zal sprake zijn van een verandering. Deze verandering kan gestuurd worden met een traject van informatieplanning.
De zes belangrijkste aspecten worden hieronder opgesomd. Er is bewust voor gekozen om de kosten buiten beschouwing te laten. Reden hiervoor is dat een applicatiestrategie allereerst moet aansluiten bij de bedrijfsstrategie en daarom vooral draait om de aansluiting van het applicatielandschap op de beweging en het lange termijn doel van de woningcorporatie. Bovendien is het lastig om te bepalen hoe je in een eenvoudig model de kosten meeneemt en vooral welke kosten erin betrokken worden.
- Onafhankelijkheid van leveranciers – wie is er in control over de IT? U of de leverancier(s)? Ligt de bedrijfsproces- en integratiekennis bij de pakketleverancier, in-house (of een aparte partner) of is die verspreid over een groot aantal leveranciers? Een lage score (hoge leveranciersafhankelijkheid) op dit aspect kan tegen de woningcorporatie gaan werken. Een leverancier heeft dan in een bepaalde mate een lock-in die hen de vrijheid geeft om bijvoorbeeld de tarieven sterk te verhogen. Daarnaast bepaalt de leverancier in plaats van de markt welke wijzigingen in het pakket doorgevoerd worden. Aan de andere kant kunnen er, bijvoorbeeld na een fusie, ook teveel leveranciers bestaan. Hierbij is het vaak wenselijk om juist met minder leveranciers te eindigen.
- Aansluiting op processen – werken de medewerkers zoals het pakket voorschrijft of werkt het pakket zoals de mensen voorschrijven? Een slechte aansluiting op de processen zorgt ervoor dat de voor de woningcorporatie ideale processen niet op die manier uitgevoerd kunnen worden. De samenhang tussen de processen zal beperkter zijn. Procesoptimalisaties kunnen zeker in combinatie met een lage aanpasbaarheid, moeilijk doorgevoerd worden. Daarnaast kan een slechte aansluiting op processen een lagere arbeidssatisfactie geven.
- Aanpasbaarheid – in hoeverre kunnen processen eenvoudig veranderd worden? Wat is de flexibiliteit van de applicatiestrategie om met wijzigingen om te kunnen gaan? Ook time-to-market is een aspect van de aanpasbaarheid. Hoe groot is de impact van een wijziging? Blijft die beperkt tot het aan te passen pakket of rimpelt deze door het hele landschap heen? Een lage score op dit aspect geeft dat er een starheid ontstaat. Het veranderen van een werkwijze of deelprocessen uitbesteden kan dan alleen met de grootst mogelijke inspanning. Een lage score geeft dat IT een beperkende factor wordt voor het in kunnen spelen op veranderingen.
- Functionele scheiding – Hoe groot is de kans dat in het applicatielandschap dezelfde functionaliteit meerdere malen voorkomt? Een grotere kans op functionele overlap betekent dat twee afdelingen hetzelfde doen in twee verschillende applicaties. Met alle gevolgen voor de samenwerking tussen de afdelingen en herbruikbaarheid van gegevens. Een keuze om functionele overlap te beperken, betekent niet automatisch dat het vanaf dat moment ook niet meer voorkomt. Hier kan actief op gestuurd worden om de huidige overlap te verminderen, maar de woningcorporatie heeft er niet altijd invloed op. Er kan bijvoorbeeld overlap ontstaan doordat een nieuwe versie van een applicatie een functionaliteit introduceert die al op een andere plaats in het landschap was opgenomen. Daarnaast kan er sprake zijn van grote overlap vanwege de geschiedenis van de woningcorporatie. In dat geval zal er applicatie rationalisatie plaats moeten vinden.
- Beheersbaarheid – in hoeverre levert de strategie een beheersbaar applicatielandschap? Invloed hierop heeft niet alleen de complexiteit, maar bijvoorbeeld ook of extra integratie leidt tot een grote toename van complexiteit en extra inspanning voor beheer. Lage beheersbaarheid geeft een ‘kaartenhuisgevoel’. Er is alleen overzicht op onderdelen en bij de eerste de beste verandering storten aanpalende applicaties en informatie functies onverwacht in.
- Eenvoud integratie – Hoe eenvoudig is de integratie tussen applicaties onderling en met ketenpartijen? Moet er veel geïntegreerd worden? Is er sprake van complexe integratie waarbij hetzelfde gegeven twee kanten op geïntegreerd moet worden?
In het onderstaand model zijn de vier strategieën uitgezet op de zes beoordelingsaspecten. Een hogere score op een aspect (verder van het midden) is beter. Afhankelijk van de situatie van de woningcorporatie (context, omgeving), kan het belang van aspecten meer of minder zwaar meewegen. Het gaat hierbij om het maken van keuzes, vaak over keuzes die het minste pijn doen. In de voorbeelden 'Online dienstverlening', 'Kernregistraties' en 'Nieuwe dienst' (onderaan deze pagina) is dit onder andere uitgewerkt.
Vervolgens wordt per strategie toegelicht waarop ze zijn beoordeeld. De belangrijkste argumenten om een strategie voor een bepaald aspect te scoren zijn hierbij in de vorm van korte statements opgenomen.
Best-of-breed met ESB[bewerken | brontekst bewerken]
Grootste valkuil van deze strategie is dat er relatief eenvoudig functionele overlap geïntroduceerd kan worden waardoor het overzicht verdwijnt en de complexiteit erg snel toe kan nemen.
Dominant pakket met satelliet systemen en ESB[bewerken | brontekst bewerken]
Bij deze strategie is een belangrijke afweging hoe ‘slecht’ de aansluiting van het dominante pakket moet zijn, voordat er een ander pakket wordt ingezet. Wanneer de grens bijvoorbeeld wordt gelegd bij het ondersteunen van 20% van de functionele eisen, verschilt deze strategie niet veel van de ERP-pakketstrategie.
ERP-Pakket[bewerken | brontekst bewerken]
Het grootste risico bij deze strategie is de afhankelijkheid van de leverancier. Wanneer de leverancier niet kan of wil leveren is er geen alternatief. Bedrijfsprocessen kunnen dan niet optimaal worden ingericht omdat de woningcorporatie te afhankelijk is van het aanbod van functionaliteiten in het ERP-pakket. Een hieraan gerelateerd risico is dat er eerder maatwerk wordt gerealiseerd (schermen, eigen registraties of Excel-applicaties) om de ontbrekende functionaliteit in te vullen.
Best-of-breed met point-to-point koppelingen[bewerken | brontekst bewerken]
Door de inzet van harde koppelingen (en de daarbij horende wederzijdse kennis van de interne werking) leidt een applicatiewijziging op de ene applicatie tot impact op de andere applicatie. Vervolgens kan dit op eenzelfde manier weer impact hebben op applicaties die hieraan gekoppeld zijn. Door de grotere kans op dubbeling van functionaliteit in dit scenario kunnen de koppelingen ook eerder complex zijn.
Hoe kan ik applicatiestrategieën toepassen?[bewerken | brontekst bewerken]
Zoals uit het voorgaande blijkt is het kiezen van een applicatiestrategie niet eenvoudig. Vanwege de dynamiek in sommige processen en de verschillende eisen die dit aan de applicaties stelt is er geen sprake van een ‘one-size-fits-all’. Op hoofdlijnen zal er wel een keuze gemaakt moeten worden voor een strategie. Maar er zal ook voor de belangrijkste procesgebieden gekeken moeten worden hoe deze zich ontwikkelen, hoe snel ze zullen veranderen en wat dit betekent voor de samenhang met de andere procesgebieden. In deze afweging zal altijd rekening gehouden moeten worden met het kunnen reageren op invloeden van buitenaf, bijvoorbeeld overname van leveranciers onderling, fusies van woningcorporaties, ontwikkelingen op de markt, enz. Afhankelijk hiervan kunnen er voor bepaalde procesgebieden andere eisen en strategieën gelden (denk ook aan het spectrum wat geschetst is in figuur 1). Na verloop van tijd zullen hierdoor hoogstwaarschijnlijk meerdere strategieën te herkennen zijn. Om dit te illustreren worden hier drie casussen uitgewerkt.
Enkele voorbeelden[bewerken | brontekst bewerken]
Voorbeeld 1: Online dienstverlening[bewerken | brontekst bewerken]
Een woningcorporatie wil graag gaan innoveren op het gebied van online dienstverlening. Er moeten snel bestaande en nieuwe diensten via het internet ontsloten kunnen worden en huurders moet de gelegenheid gegeven worden om zaken zelf uit te zoeken en minder afhankelijk te zijn van de openingstijden van de woningcorporatie.
Voor deze casus kunnen we het volgende principe definiëren: Processen en gegevens worden ook online ontsloten om selfservice voor de klant mogelijk te maken. Dit impliceert dat:
- Gegevens op orde moeten zijn omdat deze ook voor de klant zichtbaar worden;
- Kernsystemen ontsluitbaar moeten zijn naar het online kanaal.
De applicatie die voor deze casus benodigd is zit aan de bovenkant van het spectrum uit figuur 1. De belangrijkste aspecten zijn dan ook ‘aanpasbaarheid’ en ‘aansluiting op processen’. De woningcorporatie wil snel diensten kunnen ontsluiten en de oplossing moet werken zoals de woningcorporatie (of eigenlijk de huurder) wenst te werken. De te verwachten applicatiestrategie neigt hier naar een oplossing die in een specialistisch pakket gerealiseerd wordt. Maar dat betekent dat we met integratie te maken hebben. Daarom moet onze gewenste strategie ook goed scoren op ‘eenvoud integratie’. De meest voor de hand liggende keuze lijkt te zijn om op zoek te gaan naar een losse applicatie die in staat is om via een ESB geïntegreerd te worden. De vraag of deze binnen een best-of-breed aangesloten moet worden of als pakket naast een dominant pakket hangt af van (eerdere) keuzes met betrekking tot bijvoorbeeld backofficeprocessen en de bij het principe genoemde implicaties.
Een voorbeeld applicatielandschap voor deze casus zou er dan als volgt uit zien:
Voorbeeld 2: Kernregistraties[bewerken | brontekst bewerken]
Een corporatie wil de kwaliteit van de belangrijkste gegevensregistraties verhogen. Hierbij wenst zij gebruik te maken van voorhanden zijnde basisregistraties van de overheid.
Voor deze casus kunnen we het volgende principe definiëren: De bedrijfsvoering en informatiehuishouding sluiten aan op (relevante) overheidsbrede basisregistraties (CORA principe 5). Dit impliceert dat:
- In de processen van de woningcorporaties rekening gehouden moet worden met de processen van de basisregistraties. Bijvoorbeeld dat een verblijfsobject al bij het verlenen van de vergunning in de BAG wordt opgenomen.
- De applicaties van de woningcorporatie moeten in staat zijn om (onderdelen van) de gegevensverzameling extern te betrekken.
In dit scenario is aanpasbaarheid minder belangrijk. Het beheren van de kernregistraties is een proces waarvan te verwachten valt dat het niet regelmatig zal veranderen. De benodigde applicatie zit dus meer aan de onderkant van het spectrum uit figuur 1. De verwachting is wel dat de gegevens uit de kernregistraties naar ketenpartners gecommuniceerd moeten worden. Ze zullen in ieder geval extern (bij de overheid) betrokken moeten worden. Een goede score op de integratie is daarom wenselijk. Vanwege de stabiliteit (en het belang) van de kernregistraties is het geen probleem om een bepaalde leveranciersafhankelijkheid te hebben. De keuze valt dan al snel op de ERP-pakketstrategie of de strategie met het dominante pakket en de satellietsystemen.
Een voorbeeld applicatielandschap voor deze casus zou er dan als volgt uit zien:
Voorbeeld 3: Nieuwe dienst[bewerken | brontekst bewerken]
Een corporatie wil graag iets gaan doen op het gebied van leefbaarheid omdat dit goed aansluit bij de maatschappelijke doelstellingen maar het is een dienst die nog niet veel andere corporaties aanbieden. De authentieke bron voor de meeste gegevens is het ERP pakket waarin de huurder-, vastgoed- en financiële administratie is opgenomen en de corporatie wil de nieuwe leefbaarheidsdienst ook in het ERP pakket onderbrengen. De leverancier van dit pakket heeft echter pas over een jaar weer een grote release met nieuwe functionaliteit gepland staan.
Voor deze casus kunnen we het volgende principe definiëren: Strategische en gespecialiseerde diensten kunnen relatief snel op de markt gebracht worden. Dit impliceert dat:
- Het aanpassen van bestaande processen en introductie van nieuwe processen eenvoudig moet kunnen;
- Bestaande gegevensverzamelingen snel voor nieuwe doeleinden ingezet kunnen worden.
In deze casus is de voorkeursoplossing (het ERP-pakket) niet op korte termijn mogelijk. De woningcorporatie kan wachten met de nieuwe dienst tot de leverancier het in het pakket heeft geïntroduceerd of een specialistisch pakket voor de nieuwe dienst aanschaffen (of eventueel als maatwerk laten maken). Vanwege het gestelde principe wordt er niet gewacht maar een nieuw pakket geïntroduceerd. Dit doet de woningcorporatie wel vanuit de gedachte dat het specialistische pakket na verloop van tijd geconsolideerd moet worden naar het ERP-pakket. In dat geval is het belangrijk om een eenvoudige integratie te hebben met een losse koppeling tussen het specialistische leefbaarheidspakket en de andere pakketten. Bij de consolidatie naar het ERP-pakket kan de impact van deze wijziging (de consolidatie) dan beperkt blijven. De keuze voor de strategie zit daarom in de hoek van de best-of-breed strategie met ESB vanwege de optimale functionele aansluiting en de losse koppelingen.
Een voorbeeld applicatielandschap zou er dan initieel als volgt uit zien:
Wanneer de functionaliteit in de nieuwe release van het ERP-pakket is opgenomen kan de specialistische applicatie geconsolideerd worden en zal deze weer kunnen verdwijnen uit het landschap. De leefbaarheidsservice wordt vanaf dat moment aangeboden door het ERP-pakket.
In Kennismodel[bewerken | brontekst bewerken]
Het thema Applicatiestrategie CORA 3 past binnen de metastructuur van de CORA als weergegeven in onderstaande figuur, waarbij in het kennismodel alleen de concepten zijn ingekleurd die relevant zijn voor het thema Applicatiestrategie CORA 3:
