Applicatiestrategieën

Logo CORA.png

Inleiding

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.
Let op: deze pagina bevat de tekst zoals die integraal in CORA 3.0 is opgenomen. Nieuwe inzichten en ontwikkelingen zoals cloudoplossingen zijn hierin nog niet verwerkt.

Op de thema pagina CORA applicatielaag en services is meer uitleg te vinden die tot nieuwe applicatiestrategieën leiden die op deze themapagina nog niet zijn verwerkt
.


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.


Figuur 1: Spectrum van dynamiek en aspecten van applicaties


Welke applicatiestrategieën zijn er?

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:

  1. What is the enterprise’s desired operating model - oftewel: wat is de benodigde inrichting en werking van de woningcorporatie?
  2. How will IT support the desired operating model? - oftewel: hoe ondersteunt IT-inzet deze inrichting en werking van de woningcorporatie?


Figuur 2: Operationele modellen


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).


Figuur 3: Belangrijkste applicatiestrategieën


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:

  1. 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.
  2. 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.
  3. 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.
  4. 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?

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.


Figuur 4: Strategieën beoordeeld op verschillende aspecten


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

Best of breed met ESB.PNG


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

Dominant pakket met satelliet systemen en ESB.PNG


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

ERP pakket.PNG


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

Best of breed met point to point koppelingen.PNG


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?

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


Voorbeeld 1: Online dienstverlening

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:

Figuur 5: Voorbeeld applicatielandschap casus online dienstverlening


Voorbeeld 2: Kernregistraties

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:


Figuur 6: Voorbeeld applicatielandschap casus kernregistraties


Voorbeeld 3: Nieuwe dienst

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:

Figuur 7: Voorbeeld applicatielandschap casus nieuwe dienst

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

Het thema Applicatiestrategieën 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ën:

Een procesketen is een samenwerking van meerdere organisaties/organisatieonderdelen met elk een eigen verantwoordelijkheid die de levering van een of meer samenhangende diensten aan een klant realiseert. (BusinessInteraction) Procesketen Een dienst is een afgebakende prestatie die voorziet in een specifieke behoefte van een klant behorende bij het af te nemen/afgenomen product. (BusinessService) Dienst Een applicatieservice (vrij vertaald gebruikersfunctie) is functionaliteit die een applicatie biedt ter ondersteuning van een werkproces en bedient hiermee een bedrijfsfunctie. (ApplicationService) Applicatieservice Een bedrijfsobjecten-domein is een logisch samenhangende groepering van bedrijfsobjecten. (Grouping) Bedrijfsobjecten-domein Een bedrijfsobject is een al dan niet tastbaar concept waarvan informatie wordt vastgelegd en verwerkt. (BusinessObject) Bedrijfsobject Een doelgroep is een verzameling van bij elkaar horende afnemende rollen. (Grouping) Doelgroep Een afnemende rol is de hoedanigheid waarin c.q. verantwoordelijkheid waarmee een persoon of organisatie een product afneemt. (BusinessRole) Afnemende rol Een bedrijfsfunctie is een coherente verzameling competenties gericht op het leveren van een of meerdere bedrijfsservices. (BusinessFunction) Bedrijfsfunctie Een zaaktype is een generieke omschrijving van zaken van hetzelfde type. (BusinessObject) Zaaktype Een begrip is een binnen de reikwijdte van de architectuur relevante term met een definitie of omschrijving. (BusinessObject) Begrip Een werkproces is een geordende reeks processtappen die onder verantwoordelijkheid van een enkele bedrijfsfunctie uitgevoerd wordt en die als afgebakend onderdeel van een bedrijfsproces de levering van een deeldienst realiseert. (BusinessProcess) Werkproces Een processtap is een geordende reeks handelingen die onder verantwoordelijkheid van een enkele uitvoerende rol aaneengesloten uitgevoerd wordt en die een afgebakende bijdrage levert aan de uitvoering van een werkproces. (BusinessProcess) Processtap Een handeling is een enkelvoudige toewijsbare activiteit die bijdraagt aan de uitvoering van een processtap. (BusinessProcess) Handeling Een uitvoerende rol is de hoedanigheid waarin c.q. verantwoordelijkheid waarmee een persoon, afdeling of organisatie een toegewezen taak uitvoert. (BusinessRole) Uitvoerende rol Een kanaal is de wijze waarop een bedrijfsservice beschikbaar is voor afnemers. (BusinessInterface) Kanaal Een actor is een persoon of organisatie die in een of meerdere rollen kan acteren. (BusinessActor) Actor Een gebeurtenis is een toestandsverandering binnen de organisatie of in de buitenwereld die een bedrijfsproces doet starten of die uit een bedrijfsproces voortkomt. (BusinessEvent) Gebeurtenis Een koppelvlak (VERA) is een aansluiting met een exacte specificatie via welke applicaties gegevens met elkaar kunnen uitwisselen. (ApplicationInterface) Koppelvlak (VERA) Een prestatie-indicator is een meetbare vertaling van een veelal niet direct meetbare businessdoelstelling. (Value) Prestatie-indicator Een kengetal is een getal dat is uitgedrukt in geld- of in fysieke eenheden en dat de toestand van of de ontwikkeling op een bepaald beleidsterrein weergeeft. (Value) Kengetal Een principe is een richtinggevende uitspraak waar een organisatie zich aan kan verbinden, gericht op het bereiken van een doel op langere termijn. (Principle) Principe Een doelstelling is een richtinggevende uitspraak in termen van een gewenste situatie voor de organisatie en/of voor haar klanten. (Goal) Doelstelling Een sectordoelstelling is een doelstelling die breed voor de gehele sector geldt. (Driver) Sectordoelstelling Een kritieke succesfactor is datgene dat bepalend is voor het welslagen van een bepaalde ambitie. (Requirement) Kritieke succesfactor Een procesindicator is een prestatie-indicator die gekoppeld is aan een bedrijfsproces. (Value) Proces-indicator Een resultaatindicator is een prestatie-indicator die gekoppeld is aan een dienst. (Value) Resultaat-indicator Een bedrijfsservice is een afgebakende prestatie die geleverd wordt als onderdeel van een dienst aan een klant. (BusinessService) Bedrijfsservice Een product is een verzameling van diensten die onder bepaalde leveringsvoorwaarden in zijn geheel wordt aangeboden aan klanten. (Product) Product Een bedrijfsproces is een geordende reeks werkprocessen die onder verantwoordelijkheid van één organisatie wordt uitgevoerd met als doel een dienst te leveren aan een afnemer en die wordt gestart door een specifieke gebeurtenis. (BusinessProcess) Bedrijfsproces Een hoofdbedrijfsfunctie is een coherente verzameling competenties gericht op het leveren van een of meerdere diensten. (BusinessFunction) Hoofd-bedrijfsfunctie Assessment Risico BusinessService Deelbedrijfsservice Een gegevensobjecten-domein is een logisch samenhangende groepering van gegevensobjecten. (Grouping) Gegevensobjecten-domein Een gegevensobject is een logische verzameling van gegevens die van vitaal belang zijn voor een bedrijf. (DataObject) Gegevensobject (VERA) Een leverende rol is de hoedanigheid waarin c.q. verantwoordelijkheid waarmee een externe organisatie een door de interne organisatie af te nemen dienst levert. (BusinessRole) Leverende rol AggregationRelationship bestaat uit AggregationRelationship groepeert ServingRelationship bedient AccessRelationship W TriggeringRelationship veroorzaakt AggregationRelationship Clustert Kan verantwoordelijk zijn voor een verzameling van bedrijfsservices (RealizationRelationship) Verantwoordelijk voor AccessRelationship RW RealizationRelationship realiseert AggregationRelationship bestaat uit AggregationRelationship bestaat uit RealizationRelationship realiseert ServingRelationship bedient ServingRelationship bedient AssignmentRelationship voert uit AssignmentRelationship ondersteunt TriggeringRelationship bedient AssignmentRelationship vervult AssignmentRelationship vervult TriggeringRelationship initieert AssociationRelationship gekoppeld aan AccessRelationship W AggregationRelationship is opgebouwd uit AssociationRelationship heeft betrekking op InfluenceRelationship draagt bij aan RealizationRelationship realiseert SpecializationRelationship is een AssociationRelationship gekoppeld aan SpecializationRelationship is een AssociationRelationship gekoppeld aan AggregationRelationship groepeert AggregationRelationship groepeert ServingRelationship bedient TriggeringRelationship veroorzaakt AggregationRelationship bestaat uit RealizationRelationship realiseert RealizationRelationship verantwoordelijk voor CompositionRelationship Onderdeel van AggregationRelationship clustert AssociationRelationship gekoppeld aan RealizationRelationship realiseert AssociationRelationship gekoppeld aan AssociationRelationship gekoppeld aan AssociationRelationship gekoppeld aan Deze svg is op 12-09-2020 06:19:09 CEST gegenereerd door ' . SCAM_PRODUCT_NAME . ' ' . SCAM_COPYRIGHT_STATEMENT . '. ArchiMedes 12-09-2020 06:19:09 CEST


Originele kleuren
Vanuit CORA 3
   
   
   
   
Rollenmodel
   
   
Dienstenmodel
   
   
Productenmodel
   
   
Producten en diensten model
   
   
CORA producten en dienstenmodel
   
   
Informatiefunctiemodel
   
   
Applicatiemodel
   
   
CORA processjabloon
   
   
Applicatielaag en services
   
   
Bedrijfsfunctiemodel
   
   
Organisatie
   
   
Werkprocesmodel
   
   
Informatiemodel
   
   
Gegevenshuishouding
   
   
CORA procesmodel
   
   
Sturingsmodel
   
   
Bedrijfsprocesmodel
   
   
Bedrijfsservicesmodel
   
   
Status
   
   
Prestatiemeting
   
   
Zaakgericht werken
   
   
ArchiMate basiskleuren
   
   
   
   



Logo CORA.png