HORA (Hoger Onderwijs Referentie Architectuur) is een verzameling van instrumenten voor het inrichten van de organisatie en informatiehuishouding van Nederlandse instellingen voor Hoger Onderwijs. De HORA is een referentie-architectuur; een generieke architectuur die van toepassing is op meerdere organisaties. (...) Ze beschrijft een HO-instelling op een niveau waarop het onafhankelijk is van instellingsspecifieke keuzes. Ze kan door HO-instellingen gebruikt worden als spiegel voor de eigen organisatie-inrichting en informatiehuishouding. De focus van de HORA ligt op informatievoorziening; het geheel van mensen, middelen en maatregelen gericht op de informatiebehoefte van die organisatie. De HORA geeft richting maar de instellingen kunnen zelf bepalen hoe ze deze richting vertalen in een eigen inrichting.
Binnen de HORA vormen het bedrijfsfunctiemodel, het informatiemodel ('bedrijfsobjectenmodelen') en het applicatiemodel een soort drie-eenheid die bij elkaar de meest belangrijke informatievoorzieningsaspecten beschrijven. Hieronder worden deze modellen nader beschreven:
(1) Bedrijfsfunctiemodel

Een bedrijfsfunctiemodel is een model van de bedrijfsfuncties van een organisatie. Het beschrijft wat een organisatie doet onafhankelijk van hoe het wordt uitgevoerd. Het kijkt naar een organisatie als een verzameling van activiteiten die worden uitgevoerd en clustert deze tot logische eenheden die soortgelijke kennis en competenties vragen. Het model vormt een neutraal referentiekader waarin nog geen organisatie-specifieke keuzen staan. Aangezien organisaties in tijd meestal dezelfde activiteiten blijven uitvoeren is het model daardoor stabiel van aard. Veranderingen vinden vooral plaats op het niveau van bedrijfsprocessen, waarin bedrijfsfuncties op een specifieke manier worden ingevuld en met elkaar gecombineerd tot een stroom van activiteiten. Dit maakt het bedrijfsfunctiemodel structureel anders dan een procesmodel. Een procesmodel legt de nadruk op het afhandelen van gebeurtenissen door een specifieke volgordelijkheid van activiteiten aan de hand van specifieke bedrijfsregels.
De toepassingsmogelijkheden van een bedrijfsfunctiemodel zijn breed. Vanwege de stabiliteit van het model is het erg geschikt om gebruikt te worden als algemeen ankerpunt om andere modellen aan te relateren waarbij in eerste instantie nog niet gesproken wordt over organisatie- en IT-inrichting.

In het onderstaande worden de meer generieke bedrijfsfuncties verder gespecificeerd:
STURING
Strategie en governance
• Strategische planning
• Enterprise governance
• Organisatiemanagement
• Enterprise risicomanagement
Beleid en planvorming
• Beleidsvorming en evaluatie
• Enterprise architectuur
• Tactische planning
• Productportfoliomanagement
Verandermanagement
• Programma en project- portfoliomanagement
• Programmamanagement
• Projectmanagement
• Innovatie
Verbetermanagement
• Procesmanagement
• Performancemanagement
• Kwaliteitsmanagement
• Operationeel management
Verantwoording
• Interne rapportages
• Jaarverslaglegging
• Accreditatie
• Uitvoering Standard Evaluation Protocol
• Overige externe rapportages
• Integrale veiligheidsbewaking
BEDRIJFSVOERING
Human Resource Management
• Formatieplanning
• Werving en selectie
• Medewerkerontwikkeling
• Medewerkerbeoordeling
• Medewerkeradministratie
• Tijdregistratie
• Salaris- en declaratieverwerking
• Ziekte en verzuimadministratie
Financieel management
• Begrotingsconstructie
• Grootboekbeheer
• Activabeheer
• Facturering
• Debiteurenbeheer
• Crediteurenbeheer
• Betalingen
• Vermogensbeheer
Facilitair management
• Gebouwbeveiliging
• Cateringbeheer
• Schoonmaak
• Afvalbeheer
• Vastgoedontwikkeling
• Gebouwbeheer
• Goederenafhandeling
• Bedrijfshulpverlening
• Documentafhandeling en archivering
Informatie en Technologie management
• Functioneel beheer
• Gegevensbeheer
• Informatiebeveiliging
• Identiteitenbeheer
• Applicatie-ontwikkeling
• Applicatiebeheer
• IT-infrastructuurontwikkeling
• IT-infrastructuurbeheer Communicatiemanagement
Communicatiemanagement
• Imago-ontwikkeling
• Interne communicatie
• Externe communicatie
Inkoopmanagement
• Aanbesteden
• Leveranciersbeheer
• Contractbeheer
• Bestellen
Contactmanagement
• Contactbeheer
• Servicemanagement
• Relatiebeheer
• Alumnibeheer
Juridisch management
• Compliancebeheer
• Juridisch adviseren
• Juridische bescherming
• Afhandeling bezwaren en beroepen
• Klachtenafhandeling
(2) Informatiemodel

"Het informatiemodel beschrijft de gegevens die instellingen voor onderwijs en onderzoek beheren. Het wordt ook wel een bedrijfsobjectmodel of een conceptueel gegevensmodel genoemd. Het is nadrukkelijk nog geen logisch gegevensmodel. Het model beschrijft de grotere eenheden van gegevens in een taal die breed in de organisatie herkenbaar is en geeft dus nog geen details over de precieze gegevensstructuur. Het legt focus op bedrijfsobjecten met een grotere verzameling van gestructureerde gegevens die breed worden gedeeld in de organisatie. Het model lijkt op het bedrijfsfunctiemodel in de zin dat het ook onafhankelijk is van de inrichting van organisatie en IT en daardoor ook een stabiel referentiekader biedt. Nog meer dan het bedrijfsfunctiemodel creëert het een gemeenschappelijke taal voor de meest gebruikte objecten waar instellingen mee werken. De namen die voor de bedrijfsobjecten gekozen zijn hebben in de dagelijkse praktijk soms niet een eenduidige betekenis. Het model probeert onduidelijkheden over betekenis te vermijden en bevat daardoor op een aantal plaatsen woorden die minder herkenbaar zijn, maar wel een eenduidige betekenis hebben. Zo is bijvoorbeeld het woord “deelnemer” gekozen in plaats van “student” omdat er in de praktijk allerlei mensen deel kunnen nemen aan het onderwijs die niet volledig te vatten zijn onder de term “student”. Denk daarbij aan prospects (voorbereidend onderwijs), promovendi, extranei en cursisten (postacademisch onderwijs) die aan (een deel van de) onderwijsactiviteiten kunnen deelnemen. We hebben niet geprobeerd al deze (en anderssoortige) rollen uit te modelleren in het informatiemodel. Vanuit het perspectief van het informatiemodel is alleen relevant dat al deze mensen kunnen deelnemen aan het onderwijs.
De toepassing van het informatiemodel ligt vooral in het ondersteunen van organisatiebrede discussies over verantwoordelijkheden voor het beheren van gegevens. In veel instellingen zijn het bronsysteem en het eigenaarschap van gegevens onvoldoende helder aangewezen. Deze onduidelijkheden veroorzaken een lagere kwaliteit van gegevens waardoor het lastig is een consistent en integraal beeld te krijgen. In het kader van verantwoording, die steeds meer aandacht krijgt vanuit de overheid, is dit onacceptabel. Van elk bedrijfsobject zou duidelijk moeten zijn wie eindverantwoordelijk is en wie de gegevens functioneel beheert. Een andere belangrijke toepassing is het bepalen van de applicatie die kan worden beschouwd als bron voor de bij het bedrijfsobject behorende gegevens (ook wel: “system of record”)."
BIV-classificatie
Een BIV-classificatie geeft aan welke mate van beschikbaarheid, integriteit en vertrouwelijkheid gewenst is voor een bepaald gegeven. Het is de basis voor het bepalen van passende informatiebeveiligingsmaatregelen, die op zowel processen, organisatie als technologie impact zullen hebben. (...) Een BIV-classificatie bestaat uit drie scores: een B-score, I-score en V-score. De waardes van deze scores kunnen zijn: hoog, middel of laag. Voor vertrouwelijkheid is er ook een “openbaar” die aangeeft dat specifieke gegevens publiek beschikbaar zijn. Gegevens die een grote rol spelen in de dagelijke operatie van een instelling zijn geclassificeerd met een hogere B-score. Gegevens die nodig zijn voor geplande bijeenkomsten zoals toetsmateriaal scoren de hoogste B-score. De integriteit van sturende en financiële gegevens scoren een verhoogde I score. De gegevens die nodig zijn voor een goede uitvoering van het onderwijs scoren de hoogste I score. De vertrouwelijkheidsscore wordt bepaald door de bedrijfseconomische waarde en door de regelgeving rond de bescherming van persoonsgegevens. Gegevens die de identiteit, nationaliteit of ras vastleggen en gegevens die een economische situatie beschrijven scoren een hogere V-score. Gegevens die de medische, psychische of sociale situatie beschrijven van een persoon krijgen de hoogste V-score.
De V-score wordt in een aantal gevallen sterk beïnvloedt door specifieke attributen. Dit geldt met name voor bedrijfsobjecten met persoonsgegevens doordat de Wet Bescherming Persoonsgegevens allerlei eisen stelt aan vertrouwelijkheid. Het College Bescherming Persoonsgegevens heeft specifieke richtsnoeren opgesteld voor het publiceren van persoonsgegevens op internet [37]. Zuivere persoonsgegevens bevinden zich in de bedrijfsobjecten deelnemer, medewerker en individu. Er zijn bedrijfsobjecten die de relatie tussen de instelling en de personen weergeven. Zo bestaan er rond een deelmer de gevoelige bedrijfsobjecten onderwijsovereenkomst, examenprogramma, onderwijseenheiddeelname, leer- en lesgroep, toetsresultaat en onderwijseenheidresultaat. Dit zijn alle transactiegeoriënteerde gegevenssets met een beperkte set aan attributen. Het heeft geen zin dergelijke bedrijfsobjecten nader te bestuderen op attribuutniveau.
(3) Applicatiemodel

"Het applicatiemodel (ook wel 'applicatie-architectuur') beschrijft de een organisatie nodig heeft om haar processen te ondersteunen. Het model beschrijft deze applicaties (ook wel 'applicatiecomponenten') op een logisch niveau, onafhankelijk van specifieke productkeuzen. Applicaties worden primair gevormd door functionaliteit die ze aanbieden en de gegevens die ze beheren. Het bedrijfsfunctiemodel, het bedrijfsobjectenmodelen het applicatiemodel vormen daardoor een soort drie-eenheid die bij elkaar de meest belangrijke informatievoorzieningsaspecten beschrijven. Het onderscheid in technische deelcomponenten is in het applicatiemodel niet relevant.
Binnen het applicatiemodel kan onderscheid worden gemaakt tussen applicaties die bedrijfsfuncties direct ondersteunen (specifieke applicaties) en applicaties die in veel verschillende bedrijfsfuncties worden gebruikt (generieke applicaties)."
BIV-classificatie
Ook applicaties kunnen worden voorzien van een BIV-classificatie als basis voor informatiebeveiligingsmaatregelen. De BIV-classificatie van bedrijfsobjecten kan gebruikt worden om een BIV-classificatie voor applicaties af te leiden. Cruciaal voor het bepalen van de BIV-classificatie van een applicatie is de vraag of een applicatie die geen bronsysteem voor een bepaald bedrijfsobject is, de gevoelige attributen van dat bedrijfsobject ontsluit. Als die gevoelige attributen niet ontsloten worden kan de BIV-classificatie van dat bedrijfsobject buiten beschouwing worden gelaten bij de classificatie van die applicatie."
Bron: HORA (Hoger Onderwijs Referentie Architectuur)


De basis van een procesarchitectuur omvat ... , naast de architectuurprincipes, meestal ook een overzicht van de onderkende processen. Het overzicht van de processen is een logisch resultaat van de toepassing van de principes op (een deel van) het bedrijf. Dit overzicht van processen met hun onderlinge relaties is het architectuurmodel.
De diepgang waarmee de procesarchitectuur wordt beschreven is soms beperkt tot het niveau van de bedrijfsprocessen. Als de procesarchitectuur wordt gebruikt om de relaties met externe partijen (zoals klanten of leveranciers) in kaart te brengen, kan daar meestal mee worden volstaan. Zodra het bedrijf de procesarchitectuur wil gebruiken voor interne processturing, zijn ook de werkprocessen relevant. Met de afgebakende werkprocessen wordt voor de interne processturing de basis gelegd. De architectuurprincipes voor deze afbakening en het hieruit voortvloeiende overzicht van werkprocessen zijn dan een essentiële verdieping van de procesarchitectuur.
Het slechts opnemen van de naam van een bedrijfs- of werkproces in de procesarchitectuur is veelal nietszeggend. Het is belangrijk om deze processen nader toe te lichten. Alleen dan kan bij deskundigen en gebruikers eenheid van taal ontstaan en is eenduidigheid omtrent de gekozen afbakening van processen realiseerbaar. De ervaring leert dat een gestructureerde beschrijving van de onderdelen van de procesarchitectuur daarbij helpt. De onderstaande tabel biedt concreet houvast bij het specificeren van bedrijfs- en werkprocessen.
| Basisgegevens (per proces) |
Optionele gegevens (per proces |
| Naam proces |
Prestatie-indicatoren |
| Soort proces |
Risicoklasse |
| Resultaat |
Betrokken actoren (rollen/functies/services/applicaties) |
| Afnemer/klantgroep |
Aantal betrokken fte's |
| Trigger/aanleiding/event |
Informatiedrager (formulier, brief, rapportage, etc.) |
| Proceseigenaar (bedrijfsprocessen) |
Gegevensdrager (CD-rom, tape, USB-stick etc.) |
| Procesmanager (werkprocessen) |
|
| Relaties met andere processen |
|
| Omschrijving proces |
|
(...)
Om een scherpe afbakening van de processen te krijgen moeten begin en einde helder geformuleerd worden. Hiertoe zijn in de procesarchitectuur voor elk bedrijfs- en werkproces één of meer 'triggers/aanleidingen/events' respectievelijk 'resultaten' beschreven.
Om procesgericht te kunnen sturen moeten managers en medewerkers verantwoordelijk, of liever aansprakelijk, worden gemaakt. De decompositiehiërarchie is het aanknopingspunt om hun taken, verantwoordelijkheden en bevoegdheden eenduidig af te bakenen en te definiëren. In de procesarchitectuur moet daarom voor elk bedrijfsproces de verantwoordelijke 'proceseigenaar' en voor elk werkproces de verantwoordelijke 'procesmanager' worden beschreven. Om de procesarchitectuur stabiel te houden, wordt niet verwezen naar een concrete persoon. Waar mogelijk wordt verwezen naar een bepaalde rol of functie in het bedrijf. Bijvoorbeeld: de Chief Operations Officer is proceseigenaar van alle kernprocessen.
Het is belangrijk om vast te stellen in welke mate van detail de relaties tussen de processen beschreven moeten worden. De relaties tussen processen kunnen van geheel verschillende aard zijn. Afhankelijk van de situatie kan het zinvol zijn om de volgende relaties te onderkennen (niet limitatief):
-
Hiërarchische relatie: de relatie tussen een bedrijfsproces en de werkprocessen waaruit deze is opgebouwd is een hiërarchische relatie ('decompositierelatie').
-
Trigger-relatie: een proces kan een ander proces starten, ofwel triggeren. Een trigger-relatie wordt ook wel een causaal verband genoemd.
-
Gegevensafhankelijkheid: een proces registreert een bepaald gegeven dat door een ander proces wordt gebruikt.
-
Standaardisatie: indien twee processen een overeenkomstig ontwerp kennen (bijvoorbeeld een noodzakelijke volgorde van processtappen), dan kan het zinvol zijn om ervoor te zorgen dat deze overeenkomst blijvend is. Dat betekent dat wanneer het ontwerp van het ene proces gewijzigd wordt, het ontwerp van het andere proces 'automatisch' ook moet wijzigen. Er is sprake van standaardisatie van procesdelen over verschillende processen heen.
(...)
Een procesarchitectuur heeft een bepaalde stijl door de gehanteerde architectuurprincipes en ontwerpkaders. De gehanteerde architectuurprincipes zijn bepalend voor de afbakening van de bedrijfs- en de werkprocessen en hun onderlinge relaties, terwijl de ontwerpkaders bepalend zijn voor de inrichting van deze processen. De gekozen architectuurstijl is daarmee van invloed op de specifieke kenmerken van de inrichting en de besturing van de processen die onder architectuur worden ontworpen. (...) Hoewel bedrijfsprocessen in principe sinds mensenheugenis bestaan, is business process management als vakgebied relatief jong. Er heeft zich daardoor nog geen algemeen aanvaarde classificatie van procesarchitectuurstijlen ontwikkeld. Wel kunnen we, in diverse bedrijven om ons heen kijkend, een aantal kenmerkende procesinrichtingen onderkennen.
(...)
Resultaat- of event-georiënteerde bedrijfsprocessen
In de basis begint elk proces als gevolg van een 'event' (gebeurtenis) en levert elk proces een product op. Voor de afbakening van bedrijfsprocessen zijn daarom twee verschillende principes mogelijk:
(1) Voor iedere product/markt-combinatie (PMC) wordt een afzonderlijk bedrijfsproces onderkent: De PMC's zoals vastgelegd in de productarchitectuur, of in een productencatalogus zijn dus leidend voor de afbakening van de bedrijfsprocessen. Er vindt sturing op het resultaat (= levering product) plaats. Zo ontstaan voor een bank bijvoorbeeld de processen 'Openen betaalrekening (particulier)', 'Openen betaalrekening (zakelijk)', 'Opheffen betaalrekening (particulier of zakelijk)', 'Wijzigen kredietruimte (particulier)' en 'Wijzigen kredietruimte (zakelijk)'.
(2) Voor ieder 'event' wordt een afzonderlijk bedrijfsproces onderkend: dit geldt zowel voor 'life events' als 'clock events'. Het geheel van 'events' is leidend voor de afbakening van de bedrijfsprocessen. Er vindt sturing op de afhandeling van het 'event' plaats. Zo ontstaan voor een bank bijvoorbeeld de processen 'Verwerken verhuizing klant' en 'Verwerken staken onderneming'.
In een voorbeeldsituatie waarin sprake is van
Door toepassing van het eerste principe (1) geldt in een situatie waarin sprake is van twee 'events' en vijf producten dat vijf verschillende processen worden onderkend. Nadat het bedrijf in kennis is gesteld van het optreden van één van de twee events, worden de bijbehorende bedrijfsprocessen gestart. Er wordt gestuurd op het leveren van drie aparte producten. Het is hierbij goed mogelijk dat het bedrijf de verschillende producten op verschillende momenten in de tijd levert. Aan elk bedrijfsproces is namelijk een aparte set van prestatie-indicatoren en bijbehorende normen gekoppeld.
Door toepassing van het tweede principe (2), afbakening op basis van 'events', worden twee verschillende bedrijfsprocessen onderkent. Nadat het bedrijf in kennis gesteld is van het optreden van bijvoorbeeld 'event' X, wordt een geïntegreerd bedrijfsproces gestart voor de producten die hierbij horen. Er wordt dus gestuurd op het leveren van drie producten. De proceseigenaar zal ernaar streven dat voor de levering van de drie producten zoveel mogelijk gezamenlijke processtappen worden uitgevoerd. Zo wordt er voor gezorgd dat gegevens eenmalig worden uitgevraagd en dat communicatie en levering van de drie producten tegelijkertijd plaatsvindt.
'Make to stock' of 'make to order'
In productie-omgevingen zijn make to stock (= productie op voorraad) en make to order (= productie op bestelling) bekende principes. In het geval van make to stock worden in de productie voorraden van (deel)producten gecreëerd en zijn bedrijfsprocessen onderkend voor het op peil houden van de voorraad met eindproducten. Andere bedrijfsprocessen putten pas uit deze voorraad op het moment dat het eindproduct daadwerkelijk aan de klant moet worden geleverd. In het geval van make to order worden (deel)producten uitsluitend op basis van een bestelling of klantorder geproduceerd en aan het einde van het productieproces meteen aan de klant uitgeleverd.
Werkprocessen als eenheid van sturing
De afbakening van werkprocessen is cruciaal voor de structurering en belegging van activiteiten binnen het bedrijf. Het belangrijkste principe hiervoor is dat de afbakening van de werkprocessen moet corresponderen met de afbakening van de verantwoordelijkheidsgebieden van de procesmanagers.
Zie ook:
Bron: Werken onder architectuur, Rob van de Wetering en Gerard van der Zaal