De infrastructurele benadering voorbij?

De infrastructurele benadering voorbij? Wat kan de infrastructurele benadering nog toevoegen bij het gebruik van ERP pakketten zoals SAP.

Werkstuk ter afsluiting van de Architecten leergang

André Hollants

1999 HobbitSoft Consultancy

www.hobbitsoft.nl

1

Inhoudsopgave SAMENVATTING MET CONCLUSIE EN AANBEVELING........................................................ 3

1 INLEIDING ........................................................................................................................................ 6

2 DE INFRASTRUCTURELE BENADERING................................................................................. 7 2.1 MODEL (GROEIFASEN) VAN NOLAN: .............................................................................................. 7 2.2 DE PROBLEMATIEK VAN DE INTEGRATIEFASE ............................................................................... 8 3 HET BASISBEDRIJFSMODEL EN HET ORGANISATIEMODEL ........................................ 11 3.1 HET BASISBEDRIJFSMODEL ........................................................................................................... 11 3.2 EEN VOORBEELD VOLGENS DE INFRASTRUCTURELE BENADERING ........................................... 11 3.3 HET ORGANISATIEMODEL ............................................................................................................. 13 4 CONCEPTEN EN ACHTERGRONDEN VAN HET ERP-PAKKET SAP ............................... 15 4.1 GESCHIEDENIS ............................................................................................................................... 15 4.2 DE VOORWAARDEN VAN HET GEBRUIK VAN SAP ........................................................................ 15 4.3 KENMERKEN VAN BUSINESS ENGINEERING (BE) ........................................................................ 16 4.5 DE AANPAK VOLGENS SAP ............................................................................................................ 17 4.6 SAP EN DE INFRASTRUCTURELE BENADERING ............................................................................ 18 5 GEVOLGEN VOOR DE INFRASTRUCTURELE BENADERING.......................................... 19

DEFINITIES: ...................................................................................................................................... 22

GEBRUIKTE LITERATUUR ........................................................................................................... 24


www.hobbitsoft.nl

2

Samenvatting met conclusie en aanbeveling In dit werkstuk is gekeken naar de inzet van de infrastructurele benadering bij het gebruik van ERP pakketten zoals SAP. Hierbij stonden drie vragen centraal: 1. Voegt de infrastructurele methode nog iets toe bij gebruik van een ERP pakket, en zo ja, op wat voor manier kan zo'n benadering dan zinvol zijn? 2. Welke facetten spelen een belangrijke rol bij het gebruik van een ERP pakket zoals SAP en zijn bij de infrastructurele benadering hiervoor voldoende tools aanwezig? 3. Geeft beantwoording van de bovenstaande vragen aanleiding tot gevolgen voor de infrastructurele benadering zelf? In dit stuk wordt BMI (BelastingdienstMethode Informatieplanning) als synoniem gebruikt voor de infrastructurele benadering. Hierover zijn vrijwel alle architecten het eens. Verder is uitgegaan van de vooronderstelling dat de infrastructurele benadering als methode volledig wordt afgedekt door het Panfox-model van het organisatiemodel en het basisbedrijfsmodel en de verdere uitwerking van deze twee modellen. Dit laatste wordt niet door alle architecten gedeeld. In dit werkstuk wordt eerst ingegaan op de infrastructurele benadering en de achterliggende concepten (H2 en H3) en vervolgens op de achterliggende concepten van een ERP pakket zoals SAP (H4). In het laatste hoofdstuk is gekeken of de inzichten uit de voorgaande hoofdstukken ook invloed hebben op het gebruik van de infrastructurele benadering. Vanuit dit werkstuk zijn de volgende conclusies getrokken: Binnen de infrastructurele benadering wordt met ‘onafhankelijk’ bedoeld onafhankelijk van de huidige inrichting. Dit heeft tot gevolg dat de functie zelf geen onderwerp van gesprek is. De functiebeschrijving geeft alleen de bijdrage van de functie aan zijn (huidige) omgeving weer. Voorbeeld: Functies zijn ook afhankelijk van de inrichting. Hoe gedetailleerder de functieomschrijving, des te afhankelijker de functie van de inrichting is. Dit geldt vooral indien er niets is om functies aan te kunnen toetsen zoals bijvoorbeeld wetgeving. Voorbeeld: ‘innen’ is onafhankelijk van de inrichting, ‘verzoek om betaling’ is afhankelijk van de inrichting (bij contante betaling is deze functie niet zinvol om te onderscheiden) Het organisatiemodel is afhankelijk van het gemaakte basisbedrijfsmodel, en dan met name van de daarin beschreven functies. De vooronderstelling die hier gemaakt wordt is dat je in het basisbedrijfsmodel de juiste functies hebt. Zoals hierboven is gebleken hoeft deze vooronderstelling niet juist te zijn. Het organisatiemodel moet rekening houden met vragen als ‘efficiëntie’, ’knelpunten’ en ‘technologie’. Vanuit de infrastructurele benadering worden hier echter geen goede methodes voor geleverd. Vanuit de methode zijn de knelpunten niet inzichtelijk te maken. Of iets efficiënt gaat is afhankelijk van de inrichting ‘hoe’ je de functie uit gaat voeren. Ook hiervoor zijn binnen de infrastructurele benadering geen goede methodes voor. De infrastructurele benadering is zeer krachtig in de verdere uitwerking van het objectmodel uit het basisbedrijfsmodel. De infrastructurele benadering sluit qua methode niet aan bij een ERP pakket als SAP. Voor een ERP pakket is het noodzakelijk de huidige processen te kennen met de knelpunten en de gewenste nieuwe processen die men wil bereiken. De uitwerking van een basisbedrijfsmodel is voor een ERP pakket niet zo relevant. De gegevensarchitectuur is bij een ERP pakket een ‘gegeven’ en is niet zomaar aan te passen. Een methode zoals Testbed lijkt veel geschikter te zijn voor dit soort omgevingen. Beantwoording van de gestelde vragen: 1. Voegt de infrastructurele methode nog iets toe bij gebruik van een ERP pakket, en zo ja, op wat voor manier kan zo'n benadering dan zinvol zijn? De infrastructurele benadering voegt in zoverre wat toe dat duidelijk is welke (bedrijfs)functie men


www.hobbitsoft.nl

3

met een ERP pakket wil ondersteunen. Een complete uitwerking van de infrastructurele benadering lijkt echter niet zinvol te zijn omdat bij een implementatie van een ERP pakket als SAP vooral sterke behoefte is aan een inzicht van de huidige processen en knelpunten. Dit zijn nu net die aspecten waar de infrastructurele benadering zwak in is. 2. Welke facetten spelen een belangrijke rol bij het gebruik van een ERP pakket zoals SAP en zijn bij de infrastructurele benadering hiervoor voldoende tools aanwezig? Wat bij een ERP pakket als SAP belangrijk is, is het hebben van een ‘blauwdruk’ van de organisatie waarin het volgende beschreven is : - Gebeurtenissen (wanneer moet wat worden gedaan) - Taken of functies (wat moet er precies worden gedaan) - Organisatie (wie moet wat doen) - Communicatie (wat moet men weten om het goed te kunnen doen) Zoals reeds beschreven is de infrastructurele benadering hier niet de beste methode. Een methode als Testbed lijkt hier meer voor de hand te liggen. 3. Geeft beantwoording van de bovenstaande vragen aanleiding tot gevolgen van de infrastructurele benadering zelf? Ja, het lijkt mij zinvol om de infrastructurele benadering uit te breiden met een methode die sterk in procesmodellering is. Een logische kandidaat hiervoor lijkt Testbed te zijn. Bovendien zal men vooraf veel duidelijker moeten maken waarvoor het IP (InformatiePlan)gaat dienen en zal er een toetsing achteraf moeten zijn om te beoordelen of de gevolgde methode ook tot een daadwerkelijke inbreng heeft geleid. De kracht van de infrastructurele benadering lijkt vooral te liggen bij de gegevensmodellering. Hier wordt naar mijn idee nog te weinig gebruik van gemaakt. Aanbeveling: Vanuit mijn ervaring lijkt het dat men veel te snel begint met het maken van een ‘standaard’ IP, zonder eerst na te gaan wat nu eigenlijk precies de vraag is. Vaak is niet duidelijk voor wie en met welk doel het IP wordt gemaakt. Het lijkt soms zelfs een ritueel dat uitgevoerd moet worden. Dit is zeer jammer omdat er veel tijd zit in het maken van een IP en er veel boven water komt waarvan niet duidelijk is of dit relevant is of niet. Het zou dan ook goed zijn om van tevoren duidelijk te krijgen wat men met een IP wil bereiken en dan te kijken welke methode hiervoor het meest geschikt is en hoever men moet gaan met de uitwerking. Voorgesteld wordt om een fasegewijze manier van werken te kiezen. Een fase zal hierbij een tijdspanne van bijvoorbeeld een maand kunnen hebben. Na iedere fase zal dan een evaluatie moeten plaatsvinden of men nog hetzelfde doel nastreeft en of de opgeleverde producten ook aan dit doel beantwoorden. Een mogelijkheid is om het IP anders in te gaan richten waarbij het huidige IP opgesplitst wordt in twee delen: 1. Een bedrijfskundige kant. Hierin geven de informatiemanagers van de directie(s) aan welke beleidsuitgangspunten er zijn en hoe zij deze tot uiting willen zien komen in de te ontwerpen processen. Deze processen zullen dan op hoog niveau gemodelleerd moeten worden en afgestemd moeten worden met de opdrachtgevers. Zij moeten bepalen of de processen voldoen aan hun beleidsdoelstellingen. Het ontwerp is hierbij dus kaderstellend. Vanuit een knelpuntenanalyse kan dan worden aangegeven welke processen als eerste aangepakt moeten worden omdat daar het meeste belang bij is of nu de meeste knelpunten oplevert. Dit hoeven overigens niet uitsluitend IT problemen te zijn. Een mogelijke methode hiervoor kan Testbed zijn. 2. Een automatiseringskant. De IT afdeling zal verantwoordelijk zijn om de ICT wensen zo goed mogelijk vorm te geven. Hiervoor kan de infrastructurele benadering vervolgens dienen voor de uitwerking waarbij bekend is binnen welke kaders en aan welke eisen de te ontwerpen informatievoorziening moet voldoen. Het meegeven van de kaders en de eisen zullen waarschijnlijk al een verbetering zijn t.o.v. de huidige situatie. Nu wordt die namelijk vooral vanuit de materiedeskundige bekend en die zullen over het algemeen niet op de hoogte zijn met het (toekomstige) beleid. De verantwoordelijkheid van het zo efficiënt mogelijk inrichten van de informatievoorziening kan dan bij de IT afdeling komen te liggen. Voor deze inrichting zie ik zeker een rol weggelegd voor de


www.hobbitsoft.nl

4

infrastructurele benadering. Met behulp van deze methode kan namelijk een efficiënte gegevensarchitectuur worden opgezet. De klant bepaalt uiteraard welke gegevens in de structuur opgenomen dienen te worden, maar de IT afdeling kan zijn expertise vooral inzetten in de wijze waarop dit moet gebeuren. Een bijkomend voordeel hierbij is dat de verantwoordelijkheid daar komt te liggen waar ook de grootste expertise op dit gebied is. De dienst kan zich focussen op de inrichting van de processen en het bepalen van de benodigde gegevens om gestelde doelstellingen te bereiken en de IT afdeling kan zich focussen op een zo goed mogelijke ondersteuning hiervan met ICT middelen. Een eerste stap hierbij is het via ‘bouwstenen’ uitvoeren van de CRUD functies op gegevens die via een goede gegevensmodellering zijn opgeslagen. De infrastructurele benadering lijkt op het terrein van gegevensmodellering een zeer krachtig instrument te zijn.


www.hobbitsoft.nl

5

1 Inleiding In dit werkstuk wordt gekeken in hoeverre de Infrastructurele benadering bruikbaar is bij de inzet van een ERP pakket zoals SAP. De keuze uit deze twee is vanuit de Belastingdienst duidelijk: 1. De infrastructurele benadering wordt binnen het BAC als standaard gebruikt bij de BMI methode (Belastingdienst Methode Informatieplanning) 2. Het ERP pakket SAP is gepositioneerd als het pakket waar alle ondersteunende processen van de Belastingdienst in vormgegeven moeten worden. De belangrijkste vragen die in dit werkstuk behandeld worden zijn: - Voegt de infrastructurele methode nog iets toe bij gebruik van een ERP pakket, en zo ja, op wat voor manier kan zo'n benadering dan zinvol zijn? - Welke facetten spelen een belangrijke rol bij het gebruik van een ERP pakket zoals SAP en zijn bij de infrastructurele benadering hiervoor voldoende tools aanwezig? - Geeft beantwoording van de bovenstaande vragen aanleiding tot gevolgen van de infrastructurele benadering zelf? Vanuit mijn ervaring, die uitsluitend de facilitaire diensten betreft, lijkt het nut van informatie plannen (IP), gebaseerd op de Infrastructurele benadering, eigenlijk minimaal te zijn. De IP’s worden niet tot nauwelijks gebruikt door het BAC en ook de facilitaire diensten lijken nauwelijks gebruik te maken van de plannen. Uit navraag bij collegae architecten uit de leergang blijkt het beeld bij de andere SO afdelingen in een aantal gevallen niet veel anders te zijn. De vraag is dan ook legitiem of al de inspanning die nodig is om een IP te maken wel zinvol is. Zeker met de komst van de startarchitectuur lijkt dit alleen maar minder te worden. Na bestudering van de theorie blijkt echter dat deze behoorlijk compleet is waardoor je dus zou verwachten dat een IP wel degelijk een zinvolle bijdrage kan vormen. Blijkbaar is er een verschil tussen de theorie en de praktijk. Het is dan ook een nuttige exercitie om dit kritisch te onderzoeken en te kijken waar de theorie en de praktijk uit elkaar gaan lopen. Hiervoor zal eerst de infrastructurele methode zelf (en de uitwerking hiervan binnen de Panfox aanpak) onderwerp van gesprek zijn. Ik zal mij hier beperken tot het basisbedrijfsmodel en het organisatiemodel. Deze twee modellen vormen namelijk de basis van de overige modellen. Bovendien zijn dit ook de modellen die minimaal door het management begrepen en beoordeeld moeten worden. Binnen de Belastingdienst is de dienst hier namelijk verantwoordelijk voor en niet het BAC. Het vormt voor hen de link van de bedrijfsvoering, waar zij verantwoordelijk voor zijn, naar de ondersteuning in de informatievoorziening. De bouw van deze informatievoorziening wordt, over het algemeen, door een automatiseringsafdeling (het BAC) gedaan. Overigens dient opgemerkt te worden dat er geen eensluidend beeld is over de infrastructurele benadering. Na gesprekken met een aantal informatie architecten blijkt dat men, afgezien van de globale hoofdlijnen, verschillende beelden heeft. In dit stuk is de veronderstelling gemaakt dat het hoofdmodel van Panfox de volledige methode bestrijkt (zie figuur 2.1) en dat het organisatiemodel en het basisbedrijfsmodel hierin dan ook de volledige basis vormen voor een informatieplan. Ook wordt in dit stuk BMI en de infrastructurele benadering aan elkaar gelijk gesteld. Eerst zal er ingegaan worden op de infrastructurele benadering. In hoofdstuk 3 zal respectievelijk het basisbedrijfsmodel en het organisatiemodel aan bod komen. In hoofdstuk 4 zal er nader ingegaan worden op wat een ERP pakket als SAP vereist. Hierbij zal gekeken worden naar de (theoretische)ontwikkelingen en concepten die tot uiting komen in ERP pakketten zoals SAP. In hoofdstuk 5 zal er gekeken worden hoe de tot dan toe geconstateerde punten invloed hebben op de infrastructurele benadering. Ook zal gekeken worden of er aanpassingen nodig zijn op de huidige manier van werken. Om het stuk leesbaar te houden is achterin een lijst met definities gegeven. De in de tekst onderstreepte woorden kunnen in deze definitielijst worden opgezocht zodat hun betekenis duidelijk wordt.


www.hobbitsoft.nl

6

2 De infrastructurele benadering Het aanbieden van informatie roept nieuwe behoeften op. De informatievoorziening vertoont daardoor de tendens van autonome groei waardoor beheersing van die groei vroeg of laat noodzakelijk wordt. Nolan onderkende fasen waarbij een onderneming zich in een (of meerdere) fasen bevindt. De onderkende fasen volgen elkaar niet noodzakelijk en onontkoombaar op. Elke fase staat voor een karakteristieke situatie die wordt gekenmerkt door de werkwijze en aard van de te ontwikkelen informatiesystemen. Op een gegeven moment vormt die werkwijze een belemmering voor een verdere groei zodat men overgaat naar een andere werkwijze (= andere fase). Het groeifase model van Nolan helpt bij het onderkennen van de probleemsituaties en het opsporen van de belemmeringen. 2.1 Model (groeifasen) van Nolan: Introductiefase: In deze fase wordt ergens in de onderneming kennis gemaakt met de nieuwe technische mogelijkheden op het gebied van de informatievoorziening. De nadruk ligt op het onderzoeken van de mogelijkheden en het zo efficiënt mogelijk benutten ervan. Automatiseringsproblemen zijn technische problemen. Systemen hebben eenvoudige functionaliteit (kan wel technisch complex zijn). De fase wordt afgesloten met het inzicht dat de opgedane kennis niet beperkt moet blijven tot dat ene bedrijfsonderdeel waar de introductie heeft plaatsgevonden. Uitbouwfase: Hierin wordt een organisatorische eenheid gecreëerd die zich volledig concentreert op de ontwikkeling van de informatievoorziening. Gevolg hiervan is dat er een versnelling van de ontwikkelingen plaatsvindt. Het betreft vooral toepassingen waarvan overduidelijk is dat de baten de kosten ruim overtreffen. De werkwijze is meestal incrementeel. Men start met eenvoudige systeemopzet en deze wordt steeds complexer door de toevoeging van nieuwe functionaliteit. Karakteristiek in deze fase is dat systemen nooit ‘af’ zijn. De grootte is beperkt tot wat 3 à 4 personen kunnen bouwen, overzien en onderhouden. Iedere nieuwe ontwikkeling vraagt extra mensen zodat het aantal mensen en kosten explosief stijgen. Deze fase wordt afgesloten met grote doorlooptijden, hoge budget overschrijdingen en grote inspanning voor het onderhoud. Formalisatiefase: De ontwikkeling van de informatievoorziening moet dusdanig gestructureerd plaatsvinden dat een betere besturing ervan mogelijk wordt. De informatievoorziening wordt projectgewijs ter hand genomen. Essentieel is dat een project een begin en een einde heeft. Drie redenen waardoor een zekere mate van samenhang tussen informatiesystemen belangrijk wordt: 1. Inzicht dat er een andere strategie noodzakelijk is om een verdere groei van de informatievoorziening mogelijk te maken. De oplossing wordt gezocht in een systematisch geheel van samenwerkende informatiesystemen. Subsystemen zijn niet alleen een eenheid van ontwerp, maar moeten bovendien een zelfstandig bestaansrecht hebben. 2. Systemen zijn zodanig in omvang toegenomen dat ze elkaar gedeeltelijk overlappen (dezelfde gegevens dienen in meerdere systemen ingevoerd te worden) 3. Er komen steeds meer technische hulpmiddelen ter beschikking. In feite ontstaat hiermee weer een nieuwe cyclus. Integratiefase: Door bovenstaand inzicht wordt er een groeiend belang gehecht aan de onderlinge samenhang van de informatiesystemen. Hierin worden zowel de integratietechnologie, de verantwoordelijkheid voor het gebruik en verdere uitbouw van de technologie in de organisatie belegd. Er gaat hierbij belangstelling ontstaan voor een informatieplan met daarin de visie op de informatievoorziening voor de langere termijn. Dit plan moet het projectmatig ontwikkelen van informatiesystemen mogelijk maken, zonder dat daarbij de noodzakelijke samenhang verloren gaat.


www.hobbitsoft.nl

7

Deze fase wordt afgesloten omdat door de toenemende integratie de samenhang zelf onoverzichtelijk en onbeheersbaar wordt. Het structureren van de samenhang betekent dan het structureren van de gegevenshuishouding die zoveel mogelijk onafhankelijk is van de informatiesystemen. Gegevensgerichte fase: In deze fase wordt de samenhang gegarandeerd doordat ze alle aangesloten zijn op dezelfde gegevensstructuur. Deze fase kunnen we zien als de bij de integratiefase behorende ‘formalisatie’fase. Vervolgfase: Na de voorgaande fase zal het door nieuwe technische ontwikkelingen mogelijk moeten zijn om systemen te realiseren die de grenzen van het bedrijf of de instelling overstijgen, bedrijven gaan deel uitmaken van een netwerkorganisatie. Daarnaast zal men kunnen denken aan een kennisgerichte fase. Vanuit bovenstaande fasen blijkt dat men steeds meer naar de ontwikkeling van de totale informatievoorziening kijkt. Hierbij wordt de informatiearchitectuur een instrument waarmee de samenhang tussen de systemen bewaakt kan worden. Deze architectuur moet dan ook een zichtbare aansluiting bieden tussen de bedrijfsdoelstellingen en de componenten waaruit de informatievoorziening is opgebouwd. Bij de afbakening en prioriteitsstelling van projecten gaan ook andere overwegingen een rol spelen zoals ‘hoe past dit systeem in het uiteindelijke geheel’. Niet alleen inzicht in het uiteindelijke doel, maar ook de weg waarlangs dat doel bereikt kan worden is noodzakelijk. 2.2 De problematiek van de integratiefase De infrastructurele benadering heeft als doel om oplossingen te kunnen geven op problemen die vanaf de integratiefase ontstaan. Om deze reden zal dan ook wat dieper op de problemen ingegaan worden die bij deze fase horen. Elementen van de problematiek die karakteristiek zijn voor de informatievoorziening aan het begin van de integratiefase zijn: - Flexibiliteit van de informatiesystemen: systemen moeten een zekere mate van algemeenheid bezitten d.w.z. dat ze ontworpen zijn voor een klasse van situaties waarbij de specifieke voor dat moment geldende situatie wordt geselecteerd door het instellen van de bijbehorende parameters. Dit worden geparameteriseerde systemen genoemd. Deze aanpasbaarheid valt of staat met een goede en integere documentatie (liefst zelfdocumenterende systemen: documentatie en programmatekst zijn een). Ook een goede modulaire structuur draagt bij aan de onderhoudbaarheid. Bovendien moeten de systemen een zodanige structuur hebben dat het effect van wijzigingen zoveel mogelijk gelokaliseerd blijft. -

Sub-optimalisatie: dit is het verschijnsel waarbij door het optimaliseren van de deelresultaten het totale resultaat verre van optimaal is. Dit ontstaat door het nastreven van beperkte doelen zonder oog voor het totale belang. In feite is het een organisatievraagstuk: hoe moet een gewenst resultaat zodanig gesplitst worden in deelresultaten dat de noodzaak van wederzijdse afstemming zoveel mogelijk wordt beperkt? Aan wie moeten de verantwoordelijkheden voor het bepalen van de verschillende resultaten worden toegedeeld? - Horizontale suboptimalisatie: het verschijnsel waarbij informatiesystemen goed voldoen aan specifieke bedrijfsonderdelen waarvoor ze zijn ontworpen maar een eiland zijn in het geheel. Dit is meestal gevolg van de projectgewijze aanpak. De projectleider zorgt voor onafhankelijkheid van buiten de projecten waardoor overlap ontstaat. Tweede gevolg is het ontbreken van een samenhang tussen de verschillende systemen zodat informatiebehoeften die gegevens uit verschillende systemen nodig hebben niet kunnen worden voorzien. Deze vorm van suboptimalisatie kan worden voorkomen door de systemen zodanig t.o.v. elkaar af te bakenen dat daarmee de behoefte aan wederzijdse afstemming tot een minimum beperkt wordt. Wat aan afstemming overblijft geldt voor projecten als randvoorwaarden. Het antwoord hierop is om te bouwen volgens een architectuur - Verticale suboptimalisatie: ontstaat vooral bij het ontwerpen en bouwen in een aantal opeenvolgende fasen. De projectgroep is gericht op het behalen van de mijlpaal dan op het tot stand brengen van het systeem. De uitloop gaat pas optreden in de laatste fasen, de omvang van het systeem door de fasen heen neemt steeds verder af en tenslotte zullen door het


www.hobbitsoft.nl

8

constant ter discussie stellen van de eisen en wensen van gebruikers deze wensen en eisen steeds meer die van de opdrachtgever overheersen. Deze vorm van suboptimalisatie kan voorkomen worden door een aantal projectleden en verantwoordelijken uit het voortraject mede verantwoordelijk te maken voor het na-traject. Bovendien moet gestreefd worden naar een beperkte doorlooptijd en moet een project starten vanuit een goed afgebakend aandachtsgebied en bijbehorende probleemstelling. -

Het verliezen van gegevens: doordat de informatievoorziening voortschrijd kan de situatie voorkomen dat het bedrijf steeds minder greep krijgt op de aanwezige gegevens. De fysieke verschijningsvorm is wel aanwezig, maar het wordt steeds onduidelijker welke feiten en gebeurtenissen ze representeren. De interpretatie is niet meer ondubbelzinnig bekend. Dit komt deels door de komst van complexe systemen en de komst van databasemanagementsystemen die de relatie tussen invoergegevens, de verschillende bestanden en de verschillende overzichten steeds onoverzichtelijker maken. De conclusie hiervan is dat als bestanden vervuild zijn, het gevaarlijk en vrijwel onmogelijk is om gegevens in een later stadium voor andere doeleinden te gebruiken dan waarvoor ze zijn vastgelegd. Ook zou er een onderscheid gemaakt moeten worden tussen de feitelijke representaties van de gegevens op de verschillende geheugenmedia en de feiten en gebeurtenissen die daarmee vastgelegd zijn. Tot slot moet een functionele specificatie niet alleen zichtbaar maken wat er aan gegevens ingevoerd moet worden en wat voor informatie het produceert, maar ook wat voor gegevens ermee beheerd worden en wat voor gegevens uit andere systemen gebruikt worden.

-

De lotsverbondenheid tussen gegevens en programma’s: voor de komst van moderne databasemanagementsystemen, moest een bestand ook uniek aan een programma gekoppeld worden. Conversie duidt erop dat de gegevensverzamelingen binnen een bedrijf bezitten een harde kern: er is een verzameling gegevens die altijd nodig is, ongeacht de manier waarop het bedrijfsproces wordt uitgevoerd. Deze gegevens noemen we bedrijfsgegevens. Gegevensverzamelingen moeten onderscheiden kunnen worden van de toepassingsprogrammatuur en zelfstandig kunnen bestaan. Ook moet de integriteit van deze gegevens zelfstandig gewaarborgd kunnen worden.

Een groot deel van de bovengenoemde problemen wordt veroorzaakt door de projectgerichte wijze waarop informatiesystemen ontworpen zijn. Informatiesystemen vormen hulpmiddelen bij het voeren van de diverse administraties van het bedrijf. Vanuit de administratieve organisatie wordt administreren gedefinieerd als het structureren, verzamelen, opslaan, onderhouden en ter beschikking stellen van gegevens. Vanuit de methoden die gebruikt worden bij het ontwikkelen van informatiesystemen wordt echter vooral de nadruk gelegd op de analyse van wat er met de gegevens moet gebeuren in plaats van een analyse van de feiten en gebeurtenissen die ze representeren. Deze technieken moeten dus aangevuld worden waarmee gegevens beschreven kunnen worden. De infrastructurele benadering van Panfox is gebaseerd op het van elkaar onderscheidbaar maken van de gegevens en de toepassingssystemen. De gegevensverzamelingen en het gegevensbeheer moeten zodanig georganiseerd worden dat gegevens slechts eenmaal worden waargenomen en geregistreerd. De verschillende toepassingssystemen moeten vervolgens over alle gegevens kunnen beschikken die ze nodig hebben. Uitgangspunten en richtlijnen worden gegroepeerd in een viertal categorieën: - Een functionele decompositie van de informatievoorziening en de informatiesystemen. Zij moeten zodanig modulair gestructureerd worden dat een module precies één functie vervult (functionele decompositie) De functies moeten zo nauw mogelijk aansluiten bij de bedrijfsfuncties. Welke bedrijfsfuncties we beschouwen en hoe deze opgesplitst worden staat beschreven in een bedrijfsfunctiemodel. Deze moet een herkenbare weergave vormen van de visie van het bedrijfsmanagement op de strategische doelen en de taakstelling van het bedrijf. Naar doelstelling zijn er drie soorten informatiesysteem: 1. Realisatie: een informatiesysteem waarmee een bedrijfsfunctie wordt gerealiseerd. Dit kan alleen indien de bedrijfsfunctie het nemen van een formaliseerbare beslissing betreft (mechanisatie van een onderdeel van een bedrijfsproces) 2. Ondersteuning: een informatiesysteem waarmee een bedrijfsfunctie wordt ondersteund. Het is gericht op het verbeteren van de efficiëntie of de effectiviteit van een bedrijfsproces door het bedrijfsproces te voorzien van de benodigde informatie.


www.hobbitsoft.nl

9

3. Besturing: een informatiesysteem waarmee een bedrijfsonderdeel wordt bestuurd. Het is gericht op het vergroten van het besturend vermogen bij het nemen van strategische of tactische beslissingen. -

Aandacht voor de integrale samenhang van informatiesystemen. Zij hangen met elkaar samen als ze gegevens met elkaar uitwisselen. Deze samenhang moet gestructureerd worden. Het is makkelijk om de systemen integraal af te stemmen. Voor deze integrale samenhang wordt informatieplanning een instrument. In het informatieplan moet de samenhang tussen de systemen gestructureerd worden. Vanuit het informatieplan worden dus aan de verschillende projecten randvoorwaarden meegegeven. Deze randvoorwaarden dienen bewaakt en bijgesteld te worden. De verantwoordelijkheid moet daar belegd worden waar het belang voor een goede samenwerking tussen een aantal informatiesystemen het grootst is (optimale koppeling van belang en verantwoordelijkheid).

-

Gemeenschappelijk gebruik van de gegevens mogelijk maken. Om gegevens voor meer dan een doel te kunnen gebruiken moet de definitie van dat gegeven wel aan een aantal voorwaarden voldoen. Gegevens dienen gedefinieerd en gestructureerd te worden onafhankelijk van het gebruik en onafhankelijk van de wijze waarop ze zijn vastgelegd en opgeslagen. De gegevens worden alleen daar gedefinieerd, gestructureerd en verzameld waar ze ook daadwerkelijk nodig zijn.

-

Stabiele en veranderingsgevoelige delen van de informatiesystemen scheiden. Een stabiele visie op het bedrijf ontstaat door resultaatgericht te beschrijven wat er gebeurt zoveel mogelijk onafhankelijk van hoe dat gebeurt. Deze visie wordt vastgelegd in het basisbedrijfsmodel. Doorslaggevend hierbij moet zijn of verwacht wordt dat het wel of niet in de toekomst zal veranderen.

figuur 2.1 geeft aan hoe in de informatiearchitectuur de diverse onderdelen met elkaar samenhangen.

Informatiearchitectuur Knelpunten

technologie

Efficientiedoelen

Bijdrage aan omgeving Effectiviteitsdoelen

Organisatiemodel

diagnose Architectuur van de bedrijfsvoering

Basisbedrijfsmodel

Bedrijf Toepassingssystemen

diagnose

Gegevens Gegevensarchitectuur

ontwerp

Systeemarchitectuur


www.hobbitsoft.nl

10

3 Het basisbedrijfsmodel en het organisatiemodel Zoals eerder aangegeven in de inleiding en ook te zien is in figuur 2.1 vormen het basisbedrijfsmodel en het organisatiemodel de uitgangspunten voor de infrastructurele benadering. De functie van het basisbedrijfsmodel is ten eerste om aan te geven wat niet zal wijzigen bij aanpassingen in de bedrijfsprocessen en de bijbehorende informatievoorziening. Het vormt daardoor de basis voor een stabiel en overzichtelijk referentiekader voor het uitzetten van de verandering. De tweede functie van het model is het helpen onderkennen van stabiele componenten in de informatievoorziening. Hierbij wordt gekeken wat voor gegevens hierbij nodig zijn. Je krijgt een inventarisatie van de bedrijfsgegevens die ondergebracht zullen worden in de gegevensinfrastructuur. Het organisatiemodel wordt gebruikt bij het verbeteren van de bedrijfsprestatie. Er zal een verandering van de aard, de samenhang en de volgorde van de uit te voeren werkzaamheden plaatsvinden. Deze integrale herziening van de bedrijfsprocessen wordt vaak aangeduid met procesherontwerp (BPR). Randvoorwaarden hierbij zijn de te leveren bijdragen die eerder in het basisbedrijfsmodel zijn beschreven en die qua aard en structuur geen onderwerp van discussie zijn. Het wordt hierdoor dan ook een bruikbaar uitgangspunt voor de afbakening van de toepassingssystemen. 3.1 Het basisbedrijfsmodel Het basisbedrijfsmodel bestaat uit drie onderdelen: • Functiemodel: een functie wordt hierbij gedefinieerd als het uiteindelijke resultaat van een (uitgevoerde) taak. Samenhangende functies zijn functies die elkaars resultaat gebruiken. In het model worden alleen die functies genoemd die bijdragen aan de functionaliteit van het veranderingsgebied. Belangrijkste kwaliteitseis is dat het functiemodel de resultaten, die het veranderingsgebied moet behalen en de verbeteringen die daarin moeten worden aangebracht, definieert en structureert. • Objectmodel: Dit is een gestructureerde beschrijving van alle dingen uit het aandachtsgebied waarover we gegevens willen vastleggen. Aangezien we streven naar gemeenschappelijk gegevensgebruik dienen de betekenissen eenduidig te zijn. Het objectmodel maakt deel uit van het stabiele referentiekader waartegen de verandering wordt afgezet, beschrijft welke soorten objecten we onderkennen en definieert deze en levert een bijdrage aan het inrichten van de gegevenstructuur. • Interactiemodel: Doel van dit model is om autonoom beheerbare gegevensgebieden zichtbaar te maken. Alleen die gegevens zijn relevant die door de functies (uit het functiemodel) gebruikt worden. De gegevensgroepen worden dan ook uit de functies gedefinieerd, bovendien moeten we van ieder gegeven ondubbelzinnig vast kunnen stellen van welke gegevensgroepen deze deel uitmaakt en wie het gegeven beheerd. 3.2 Een voorbeeld volgens de infrastructurele benadering Om dit te verduidelijken gaan we gebruik maken van een voorbeeld die ook in de cursus is gebruikt, te weten: de orderafwikkeling van een handelsonderneming. Deze onderneming wil haar marktaandeel vergroten en acht reorganisatie noodzakelijk. Als doelstelling was meegegeven: • Het aangaan van partnerships (o.a. inzicht in de voorraden bij de partners en op grond van eigen expertise hier de aanvulling van de voorraden bij de partners zelf bepaald. • Herkenbare en dagelijkse bezorging bij grootafnemers • Voor particulieren ook leveringen vanuit magazijn mogelijk maken Het functiemodel luidde uiteindelijk: 0: Orderafwikkeling 1: Leveren 1.1: Samenstellen van de levering 1.2: Bezorgen van de levering 2: Afwikkelen van de betalingsverplichtingen 2.1 Vaststellen van de betalingsverplichting 2.2: Verzoek om betaling


www.hobbitsoft.nl

11

2.3: Toewijzen van de ontvangen betalingen Als objecttypen zijn benoemd: Concrete zaken: Klanten Gebeurtenissen: Bestellingen, Betalingen en Leveringen Concepten: Voorraden, Artikelsoorten en Vorderingen Het interactiemodel: Per functie wordt aangegeven welke eigenschappen van welke objecten relevant zijn en welke daarvan veranderd worden. Overigens dient er opgemerkt te worden dat met inrichtingsonafhankelijk blijkbaar wordt bedoeld onafhankelijk van de huidige inrichting. De bijdrage wordt geformuleerd vanuit het perspectief van het bestaande (bedrijfs)proces. Het waarom van de functie is niet relevant. Dit wordt duidelijk indien men op een meer gedetailleerd niveau komt. Het ziet er naar uit dat er een afhankelijkheid bestaat in de mate van detail bij de functies en objecten t.o.v. de inrichtingsonafhankelijkheid (als zijnde functie van de onderneming) als geheel. Hiermee wordt bedoeld dat de functie weliswaar inrichtingsonafhankelijk kan worden beschreven maar dat de functie zelf geen onderwerp van gesprek is. Hoe lager het niveau is waarop de functie betrekking heeft, des te meer deze afhankelijk is van de (huidige) inrichting. Indien de functies dus niet te toetsen zijn aan bijvoorbeeld wetgeving dan is de functie voor een groot deel afhankelijk van de gekozen inrichting. Inrichtingsonafhankelijk kan dus alleen indien de functies globaal zijn gedefinieerd. Dit geldt ook voor de objecten (gegevens) die op globaal niveau worden gedefinieerd. Als we kijken naar het niveau waarop sturing kan plaatsvinden dan zien we dat sturing in ieder geval deels afhankelijk is van de inrichting. Sturing vindt plaats op output van een proces of op output van een procesonderdeel op het niveau van de lagere managementlagen. Kennelijk is er dus een afhankelijkheid tussen het niveau van sturing en de afhankelijkheid van de inrichting: hoe lager de sturing, des te afhankelijker de functies zijn van de inrichting (afhankelijk van hoe het proces is ingericht). Dit heeft ook zijn weerslag in de benodigde gegevens die afhangen van de gewenste inrichting.

Afhankelijkheid inrichting

Basisbedrijfmodel vs. organisatiemodel

Inrichtingsonafhankelijke deel (basisbedrijfsmodel)

e nst we Ge

ring stu Inrichtingsafhankelijke deel (organisatiemodel)

globaal

Gedetailleerd Mate van detail functies en objectgegevens


www.hobbitsoft.nl

12

3.3 Het organisatiemodel Knelpunten

technologie

Efficientiedoelen

Bijdrage aan omgeving Effectiviteitsdoelen

Organisatiemodel

diagnose Architectuur van de bedrijfsvoering

Basisbedrijfsmodel

Bedrijf Toepassingssystemen

diagnose

Gegevens Gegevensarchitectuur

ontwerp

Systeemarchitectuur

Hoewel dit niet duidelijk uit het plaatje blijkt vormt, binnen de Infrastructurele benadering, het basisbedrijfsmodel een belangrijk uitgangspunt bij het ontwerpen van de organisatiearchitectuur en de verdere detaillering daarvan in het organisatiemodel. Zienswijze vanuit deze benadering is namelijk dat processen de functies realiseren uit het veranderingsgebied die zijn beschreven in het basisbedrijfsmodel. Wat hierbij van belang is, is de definitie van proces binnen de infrastructurele benadering. Deze luidt: een samenhangend geheel van voorzieningen, ingericht voor het realiseren van een specifieke gevalscategorie. Een gevalscategorie is hierbij een klasse ‘gevallen’ die op gelijksoortige wijze behandeld worden. De organisatiearchitectuur beschrijft de inrichting van het veranderingsgebied door middel van het onderkennen van de gewenste processen. Het organisatiemodel beschrijft waaruit de communicatie tussen die processen dan bestaat zodanig, dat we er de afbakening van de toepassingssystemen op kunnen baseren. De organisatiearchitectuur is een ontwerp waarin het bedrijfsbeleid en de bedrijfsvisie op de rol van de productietechnologie, de medewerkers en de informatietechnologie worden vormgegeven. De organisatiearchitectuur geeft antwoord op de volgende vragen: - welke gevalscategorieën onderkennen we?; - met welke processen behandelen we de gevallen van een gevalscategorie, welke technologie schakelen we daarbij in?; - welke bijdragen leveren de onderkende processen aan de veranderingsdoelen, welke knelpunten lossen ze op, welke functies realiseren ze voor welke gevallen?; - welke feedback krijgen de processen uit de omgeving? Wat is de benodigde regelcapaciteit van de processen? Welke competentie is vereist van de medewerkers? In de uitwerking hiervan wordt gebruik gemaakt van de eerder in het bedrijfsmodel gevonden functies die wordt uitgezet tegen de gevalscategorieën. Hoe men deze gevalscategorieën het beste kan kiezen (onderbouwing) en wat de gevolgen van de keuzes zijn is niet binnen de methode aangegeven. Zeker gezien het feit dat men hierbij beter vanuit de gevalscategorieën kan kijken dan vanuit de functies is dit een groot gemis binnen de infrastructurele benadering. Bovendien wordt vanuit de gevalscategorieën alleen maar aangegeven welke functies worden uitgevoerd. Het zegt dan ook niets over de wijze waarop een gevalscategorie wordt uitgevoerd. Al we kijken naar het plaatje aan het begin van deze paragraaf dan valt nog wat op. Het organisatiemodel suggereert te maken te hebben met knelpunten, technologie en efficiëntie doelen. In de uitwerking van het organisatiemodel zien we hier echter nauwelijks iets van terug. Als men kijkt vanuit de uitwerking dan komt het model er eigenlijk zo uit te zien:


www.hobbitsoft.nl

13

Informatiearchitectuur Efficientiedoelen?

Bedrijf Knelpunten? Technologie?

Toepassingssystemen

Gegevens Effectiviteitsdoelen

Basisbedrijfsmodel

Bijdrage aan omgeving

Organisatiemodel

Architectuur van de bedrijfsvoering

ontwerp

Gegevensarchitectuur

Systeemarchitectuur

Het organisatiemodel is afhankelijk van het gemaakte basisbedrijfsmodel, en dan met name van de daarin beschreven functies. De vooronderstelling die hier gemaakt wordt is dat je alle functies kunt beschrijven vanuit het basisbedrijfsmodel. Als voorbeeld nemen we uit de opgave de functie “Afwikkelen van de betalingsverplichtingen”. Deze was uitgesplitst in: 2.1: Vaststellen van de betalingsverplichting 2.2: Verzoek om betaling 2.3: Toewijzen van de ontvangen betalingen Mijn stelling is nu dat deze functies deels afhankelijk zijn van de gekozen inrichting. Als men namelijk uitsluitend contante betalingen zou hebben gehad dan waren de functies 2.2 en 2.3 waarschijnlijk nooit beschreven. Deze functies zijn in dat geval namelijk niet relevant. De enige functie die relevant is, is dat er betaald wordt. Als men ook nog kijkt naar de doelstelling dat het organisatiemodel afhankelijk is van ‘efficiëntie’, ’knelpunten’ en ‘technologie’, dan zijn deze helemaal niet terug te vinden in het model. Of iets efficiënt gaat is afhankelijk van de inrichting ‘hoe’ je de functie uit gaat voeren. Hiervoor zijn binnen de infrastructurele benadering geen tools voor. Ditzelfde geldt ook voor de ‘knelpunten’. De enige knelpunten die je met de infrastructurele benadering zal kunnen vinden zijn functies die je niet uitvoert, maar wel zou moeten doen. Het is de vraag of je die vindt volgens de methode. Functies die overbodig zijn zal je al veel moeilijker vinden, omdat de functies juist zijn opgesteld vanuit de huidige werkzaamheden en iedere functie zal over het algemeen wel ergens een bijdrage aan hebben, maar of die ook noodzakelijk is hangt af van de inrichting. Je zou de functies dan ook moeten toetsen aan bijvoorbeeld wetgeving of beleid.


www.hobbitsoft.nl

14

4 Concepten en achtergronden van het ERP-pakket SAP 4.1 Geschiedenis Vroeger werd er vanuit de IT bepaald hoe er geautomatiseerd werd. Dit was in de begintijd van de automatisering en de hoofdreden hiervan was dat computers nog niet tot veel in staat waren. Een andere reden was gelegen in het feit dat het zeer moeilijk was om computers te programmeren. De programmeurs waren dan ook veelal hoog technisch geschoolde medewerkers. In de loop der jaren waarin de computers goedkoper en krachtiger werden en daardoor ook meer processen voor automatisering in aanmerking kwamen, zien we een verschuiving naar de gebruikersorganisatie. Na verloop van tijd merken we dat de grote rekencentra van vroeger zich steeds meer decentraliseren en dat de gebruiker een steeds grotere invloed krijgt op de inzet van IT-middelen. Er worden diverse applicaties gebouwd voor evenzoveel afdelingen, hierdoor worden de (deel)processen steeds efficiënter. Een groot probleem hierbij is dat weliswaar de deelprocessen worden geoptimaliseerd, maar dat het bedrijfsproces als geheel hier veel minder baat bij heeft. Een aantal grote bedrijven zijn hierna aan de gang gegaan met zogenaamde BPR (Business Proces Redesign) trajecten. In het kort komt de methode hier op neer dat men kijkt naar het gehele bedrijfsproces en vanuit de doelen en wensen dit bedrijfsproces geheel opnieuw opzet waarbij IT een zeer belangrijke rol speelt bij het automatiseren van bepaalde functies. Met name processen die te maken hebben met de 'stroom van gegevens' is dit zeer effectief (inkoopproces, uitbrengen van offertes door verzekeringsmaatschappijen enz.). Een volgende stap in dit gehele proces is de afstemming van bedrijfsprocessen onderling. Dit wordt ook wel BE (Business Engineering) genoemd. Hierbij wordt IT niet alleen ingezet bij het automatiseren van functies, maar wordt IT gebruikt voor het ontwerpen of opnieuw ontwerpen van processen (hierbij bedoeld als onderlinge samenhangende stappen of ‘ketens’ van bedrijfsactiviteiten. Toepassing van BE op de procesketens die over functionele en/of organisatorische grenzen heen gaan kunnen hierdoor geïntegreerd worden. Om dit goed te kunnen doen is het wel nodig om de beschikking te hebben over een bedrijfsmodel of bedrijfsprocesdiagram waarin niet alleen een beschrijving van taken en organisatiestructuur staat, maar ook een beschrijving van de interne werkwijze. 4.2 De voorwaarden van het gebruik van SAP Kijken we naar SAP dan kunnen we zeggen dat dit pakket min of meer vanuit de business engineering is ontworpen. Bij SAP wordt gesproken van 'best practices'. Men (SAP) gaat er vanuit dat zij de meest geschikte bedrijfsprocessen hebben gekozen/ontworpen die zich in de praktijk hebben bewezen. Zij hebben dit gedaan door bij succesvolle bedrijven te kijken hoe zij de processen hebben georganiseerd. Uit deze verschillende processen heeft men geabstraheerd totdat men komt tot processen die in principe voor ieder bedrijf bruikbaar zijn. Het SAP systeem is zo opgezet dat de gegevens maar eenmalig, bij de bron, worden vastgelegd. De vooronderstelling bij het gebruik van SAP is echter wel dat de organisatie min of meer is opgezet volgens deze 'best practices' of bereid is zich hieraan aan te passen. Dit proces georiënteerde denken houdt in dat er 'offers' gebracht moeten worden om de organisatie als geheel te verbeteren. Deze 'offers' vertalen zich vooral in een grotere afhankelijkheid van anderen en een verdwijnen van de functionele oriëntatie. Uit het voorgaande blijkt dat er aan een aantal voorwaarden voldaan moet worden om een pakket als SAP efficiënt te kunnen inzetten. De belangrijkste zijn: 1. Er dient een goede afstemming plaats te vinden tussen de verschillende projecten binnen SAP. Dit heeft vooral te maken met het feit dat instellingen die men doet vanuit het ene project, effect kunnen hebben op het andere project. 2. Men moet bereid zijn tot het brengen van 'offers' in het belang van het gehele bedrijf. Dit heeft vooral te maken met het feit dat SAP een standaard pakket is. Men heeft de keus om de eigen processen aan te passen aan de zogenaamde ‘best practices’ van SAP waarbinnen overigens nog een redelijke variatie aanwezig is. Wil men dit niet doen en dus het eigen proces één op één omzetten naar SAP dan is dit wel mogelijk. Als dit echter teveel afwijkt dan wordt dit maatwerk en dat leidt in de toekomst tot grote problemen m.b.t. beheer en het upgraden naar nieuwere versies. Het is dan ook noodzakelijk dat de concepten die achter SAP liggen met zijn integrale karakter volledig worden ondersteund door zowel het strategische management, als door de overige managementlagen en het projectmanagement. Dit vereist een visie op het vormgeven van eenduidige


www.hobbitsoft.nl

15

bedrijfsprocessen en de samenhang tussen de verschillende bedrijfsonderdelen. Zonder deze visie is het moeilijk om een goede inrichting van het ERP (enterprise resource planning) pakket SAP te krijgen. 4.3 Kenmerken van Business Engineering (BE) Omdat SAP en andere ERP pakketten sterk leunen op de concepten van BE zal er in deze paragraaf wat dieper op ingegaan worden. De essentie van BE is het ontwikkelen van radicaal nieuwe, procesgeoriënteerde bedrijfsoplossingen, ondersteund door informatietechnologie. Het gaat hierbij dan ook om het herstructureren van de gehele organisatie tot een efficiënter geheel. BE brengt geen verandering tot stand door een onderneming volledige te automatiseren, maar door de taken van de onderneming opnieuw te definiëren in algemeen omvattende en procesgeoriënteerde termen. De belangrijkste doelstelling hierbij is de optimalisatie van bedrijfsprocessen. Om deze doelstelling te bereiken kijkt men naar: • Zorgen dat de onderneming zich richt op het creëren van toegevoegde waarde voor klanten en leveranciers; • Integratie van alle kritieke bedrijfsprocessen; • Zich richten op het beheer van totale processen en niet slechts op het beheer van individuele taken; • Reduceren of zelfs elimineren van het ‘zijsprongen’ in de keten. Wanneer BE op de juiste wijze wordt toegepast, wordt de onderneming in staat gesteld vereenvoudigingen in de genoemde gebieden aan te brengen voordat men gaat automatiseren. BE geeft individuele medewerkers de verantwoordelijkheid voor een groter aantal activiteiten en beslissingen. De bedrijfsprocessen houden niet op bij de grenzen van een afdeling. Wat hierbij een vereiste is, is dat iedereen dezelfde taal spreekt en er een uiterst effectieve communicatie is binnen de organisatie. Vanuit de praktijk blijkt dat succesvolle BE ontwikkelingen voldoen aan: • Het bedrijf concentreert zich op doorslaggevende redenen voor wijzigingen in bedrijfsprocessen. • Het project wordt geleid door gekwalificeerde en ervaren personen. • Het management heeft regelmatig contact met de medewerkers. • De onderneming is gericht op vernieuwing en op innovatieve toepassing. Niet succesvolle BE ontwikkelingen leiden aan: • De automatiseringsafdeling ziet in dat reengineering positieve effecten kan hebben, maar mist de kracht om hieraan leiding te geven. • De onderneming heeft onvoldoende inzicht in haar eigen bedrijfsprocessen en in hun onderlinge samenhang. • De onderneming tracht processen te repareren in plaats van ze radicaal te herzien. Het verband tussen BE en IT is dat men eerst de bedrijfsdoelstellingen uit moet werken en de belangrijke succesbepalende factoren aan moet wijzen. Vervolgens moet men de bedrijfsprocessen stroomlijnen en optimaliseren (sommige zelfs elimineren) en pas daarna moet er begonnen worden met het toepassen van informatietechnologie. Bedrijven hebben het grootste voordeel van IT wanneer deze is gebaseerd op een gedetailleerd bedrijfsmodel en op diepgaande analyse van de bedrijfsprocessen. Kortom: eerst organiseren en dan pas automatiseren Vanwege de integratie van processen hebben afdelingen elkaars informatie nodig. Gegevensstromen moeten de grenzen die bepaalde organisatiegebieden afbakenen dan ook kunnen overschrijden. Vanuit de IT kan dit gedaan worden met behulp van client/server applicaties die de complexe structuur verbergt voor de gebruikers. De gebruikers moeten zich kunnen concentreren op het verzamelen van de informatie waarom een klant vraagt, zonder zich te hoeven afvragen waar die zich precies bevind (in welke applicatie of via een ingewikkelde commando structuur). Dit is het nadeel van functioneel georiënteerde systemen die gebaseerd zijn op grond van individuele bedrijfsfuncties. Een ERP pakket als SAP is dan ook niet functie georiënteerd, maar gaat uit van processen die werken met zogenaamde bedrijfsobjecten (order, ontvangstbewijs, factuur enz.).


www.hobbitsoft.nl

16

4.5 De aanpak volgens SAP De eerste fase van een SAP traject zou moeten beginnen met het maken van een bedrijfsblauwdruk (in SAP ook het referentiemodel genoemd). Deze is bedoeld voor het op een inzichtelijke manier illustreren van complexe processen. Het doel van een bedrijfsblauwdruk is dan ook niet de ontwikkeling van een systeemprototype, maar het stroomlijnen van de beschreven complexe bedrijfsprocessen. De blauwdruk geeft een overzicht van functies, processen, gegevensstromen en organisatiestructuren. Het vormt daarbij een weergave van verschillende bedrijfssituaties en maakt het mogelijk door de processen te navigeren die in deze situaties een rol spelen. De blauwdruk bevat 4 hoofdelementen: 1. Gebeurtenissen (wanneer moet wat worden gedaan) 2. Taken of functies (wat moet er precies worden gedaan) 3. Organisatie (wie moet wat doen) 4. Communicatie (wat moet men weten om het goed te kunnen doen) Vastlegging hiervan binnen SAP wordt gedaan door gebruik te maken van een zogenaamde EPCmethode. EPC staat voor event-controlled proces chains waarbij de belangrijkste kenmerken bestaan uit de vragen wanneer iets gedaan moet worden, wat er gedaan moet worden, door wie dit moet doen en welke informatie hierbij nodig is. De verschillende gezichtspunten komen tot uiting in onderling consistente modellen: • Component model: wat wordt er gedaan? Dit geeft een overzicht van de belangrijkste zakelijke activiteiten, maar biedt geen informatie over de volgorde waarop deze worden uitgevoerd, en evenmin wie deze activiteiten uitvoert. Geeft dus een overzicht van de functies binnen een bepaalde bedrijfsomgeving en van de wijze waarop deze zijn samengesteld uit taken en deeltaken. • Organisatiemodel: wie doet wat, of wie is waarvoor verantwoordelijk? Hiermee kan de organisatiestructuur worden geanalyseerd en eventueel worden herzien. Het beschrijft de relaties tussen organisatie-eenheden. • Datamodel: welke informatie is nodig om een taak uit te voeren? Geeft een overzicht van de belangrijkste gegevensobjecten en hun onderlinge samenhang. • Interactiemodel: Welke informatie moet worden uitgewisseld tussen organisatie- of applicatie onderdelen? Dit model toont de communicatiestromen tussen operationele gebieden. Het brengt informatiestromen tussen verzenders en ontvangers van informatie in beeld.

R/3 Referentiemodel

Interactiemodel

Organisatiemodel

Procesmodel

Datamodel

Componentenmodel

Binnen SAP zijn al deze modellen views vanuit het centrale procesmodel van R/3 Kijken we naar SAP dan zien we dat het pakket voor al deze vragen al is ingevuld. Het pakket geeft dan ook een groot aantal processen waaruit je kan kiezen. De integratie van al deze gegevens en de sturing van de processen zijn ‘ingebakken’ in het pakket. Waar het pakket echter niet best in is, is dat


www.hobbitsoft.nl

17

je vanuit een bepaalde bestaande positie komt. Het SAP pakket is helemaal gericht op de toekomstige situatie. Dit is ook te zien aan de hulpmiddelen die je vanuit SAP beschikbaar hebt. Het ingevulde referentiemodel vormt hierbij de leidraad en alle hulpmiddelen zijn erop gericht hoe deze zo snel mogelijk is te bereiken. Het grote probleem bij SAP implementaties is dan ook de migratie van de huidige situatie naar de toekomstige situatie. Hiervoor is het noodzakelijk om de huidige situatie (het huidige proces) goed te kennen en de nieuwe situatie. Op die manier is er een inschatting te maken wat de organisatie zal moeten doen om van de huidige situatie te migreren naar de nieuwe situatie. Ook hier geldt, net als bij de infrastructurele benadering, er niet gekeken wordt naar de huidige knelpunten. De vooronderstelling is dat de processen die in SAP zitten de ‘best practices’ zijn. Als je je organisatie maar aanpast aan deze ‘best practices’ dan heb je in ieder geval je processen op orde. 4.6 SAP en de infrastructurele benadering Als we kijken naar de beschreven aanpak en de aanpak van de infrastructurele benadering dan zien wij dat hier nogal een verschil tussen is. Deze verschillende benaderingen leiden ook tot een aantal problemen. Daar waar de infrastructurele benadering veel aandacht besteed aan het basisbedrijfsmodel met daarin het objectmodel, het functiemodel en het interactiemodel, ligt de nadruk bij SAP vrijwel geheel bij de inrichting van bedrijfsprocessen. Zo is een gedetailleerde uitwerking van het objectmodel dan ook weinig zinvol voor een pakket als SAP. De manier waarop de gegevens zijn opgeslagen binnen SAP zijn niet zichtbaar en is ook niet echt relevant. Wel maakt SAP gebruik van een ‘schil’ om de gegevens heen zodat deze gebruikt kunnen worden door niet SAP programmatuur inzicht in deze schil is wel degelijk van belang indien men gegevens uit SAP ook wil benaderen/gebruiken vanuit een niet SAP pakketten. Met betrekking tot de functies ligt bij SAP altijd de nadruk op het proces (de functie is hierbij dan te vertalen als het doel van het proces). De functies afzonderlijk te beschrijven heeft dan ook alleen zin indien dit op globaal niveau wordt beschreven en dus bij voorkeur in termen van bedrijfsfuncties op hoog niveau. In SAP gaat het niet zozeer naar de bijdrage van de functie aan zijn omgeving, maar aan de bijdrage in de waardeketen van een proces. SAP geeft je de mogelijkheid om de functie op diverse manieren in te richten. SAP geeft hierbij wel aan welke van de inrichtingen je het beste kunt gebruiken als je weet wat voor type processen voor de organisatie het belangrijkste zijn. Dit alles leidt ertoe dat men geen functies moet gebruiken om te kijken naar wat men met SAP wil ondersteunen, maar naar de processen die men door SAP wil ondersteunen. Om dit goed te kunnen beoordelen is noodzakelijk om de visie en de inrichting van de (huidige) processen te kennen en welke knelpunten men wil oplossen. Dit tezamen kan dan gebruikt worden om te bepalen of, en zo ja hoe, deze processen ondersteunt kunnen worden door een ERP pakket zoals SAP. Kijkt men naar de infrastructurele benadering dan zal deze het inzicht in de huidige processen niet kunnen leveren en ook de toekomstige situatie in termen van inrichting worden niet tot nauwelijks inzichtelijk vanuit de methode. Een veel betere optie hiervoor lijkt Testbed te vormen. Deze methode valt echter buiten het kader van dit werkstuk. Naar mijn mening kan deze methode een enorme aanvulling geven op de infrastructurele benadering. De meerwaarde zal hierbij vooral zitten aan de ‘voorkant’ (de analyse van knelpunten, efficiëntie en beleidsvraagstukken) en het organisatiemodel. De conclusie die men hier wel uit kan trekken is dat de infrastructurele benadering niet aansluit op de benadering nodig voor een ERP pakket zoals SAP. De infrastructurele benadering geeft o.a. inzicht aan gegevensstructuren via de gegevensbeheersystemen die echter binnen SAP al vastliggen en om SAP goed te kunnen implementeren is inzicht in de processen (inrichting) belangrijk die echter niet door de infrastructurele benadering worden opgeleverd. Bij het maken van een informatieplan voor een omgeving waarin SAP wordt gebruikt is de methode van de infrastructurele benadering zeker niet de meest geschikte. Het detailleren en uitdiepen van het basisbedrijfsmodel is dan ook grotendeels verspilde moeite. Men kan stoppen bij een zeer globale schets. Voor het beschrijven van de huidige processen en de toekomstige processen kan men veel beter een andere methode gebruiken zoals bijvoorbeeld de Testbed methodiek, want inzicht in processen speelt bij SAP een belangrijke rol.


www.hobbitsoft.nl

18

5 Gevolgen voor de infrastructurele benadering Zoals reeds eerder in de inleiding genoemd is, wil het BAC ook ‘component based’ werken en de ERP leverancier worden van de belastingdienst. Nu we gezien hebben dat een volledig uitgewerkte BMI methode nauwelijks toegevoegde waarde heeft bij een ERP pakket is de vraag gerechtvaardigd of we met deze methode wel op de goede weg zijn. Een ERP pakket maakt namelijk ook gebruik van componenten. Een van de vragen die wij kunnen stellen is hoe een ERP leverancier als SAP erin is geslaagd om te bereiken wat wij als BAC ook graag willen, namelijk het maken van herbruikbare componenten die in verschillende processen gebruikt kunnen worden. Binnen SAP is opvallend dat je de herbruikbare componenten vooral op die plekken vindt die betrekking hebben op het ophalen en wijzigen van gegevens. In het vervolg van dit hoofdstuk wil ik aangeven wat wij vanuit een ERP benadering kunnen leren, dus los van het gebruik van het ERP pakket zelf. Zoals in het voorgaande hoofdstuk is beschreven is het uitgangspunt van SAP altijd de procesbenadering (de waardeketen) geweest. De hoofdprocessen dienen hierbij geïntegreerd te worden. Vanwege de integratie van processen hebben afdelingen elkaars informatie nodig. Gegevensstromen moeten de grenzen die bepaalde organisatiegebieden afbakenen dan ook kunnen overschrijden. Als we ook rekening houden met de nieuwe ontwikkelingen binnen SAP dan zien wij dat gegevens vanuit SAP steeds beter beschikbaar komt terwijl hun onderliggende wijze van opslag aan het oog onttrokken wordt. Via een BAPI (Business Application Program Interface) kan aan het systeem de gewenste gegevens gevraagd worden. Op deze manier heeft SAP dan ook de ‘bouwstenen’ voor het benaderen van de opgeslagen of te verwerken gegevens. Kijken we naar de infrastructurele benadering dan is het objectmodel en de gegevensarchitecturen goed uitgewerkt. Combineren wij dit met wat wij van SAP kunnen leren dan zullen wij in ons streven naar componentenbouw ons in eerste instantie vooral op de (CRUD) functies moeten richten. Deze zouden de kern moeten vormen voor het hergebruik van componenten. Hierbij zijn de CRUD functies niet meer in de applicaties gebouwd, maar zijn het herbruikbare componenten die door applicaties worden aangeroepen. Een applicatie is namelijk in grote mate afhankelijk van de gekozen procesinrichting, terwijl de gegevens een zeer stabiele structuur vormen. Als de CRUD componenten alleen maar op de gegevens werken, hebben deze ook een zeer stabiele structuur. Uiteindelijk kan men zelfs komen tot een universele workflow die over de CRUD componenten heen ligt waarmee een zeer flexiblele applicatielaag ontstaat, maar dit is vooralsnog toekomstmuziek.

Applicatie

CRUD component

Applicatie

CRUD component

DBMS

Een voorwaarde van de CRUD componenten zou wel moeten zijn dat de onderliggende database(s) geen invloed heeft op de component en dat de componenten op een uniforme wijze aangeroepen


www.hobbitsoft.nl

19

kunnen worden, ongeacht de taal van het ‘calling’ programma. Wel moet er hierbij goed nagedacht worden over waar de authorisatie komt te liggen en wat de impact op de performance is. Een vraag die nu nog overblijft is wat er gedaan moet worden met de processen. Als ze bij een ERP pakket zoals SAP zo’n belangrijke rol spelen in plaats van functies wat is hiervan dan de oorzaak? Om op deze vraag een antwoord te krijgen is het noodzakelijk om te kijken naar de bedrijfsvoering van een bedrijf. Als we kijken naar verschillende bedrijven die hetzelfde produceren dan zien wij toch een verschil in winstgevendheid. Nader onderzoek leert dat de winstgevendheid van een bedrijf onder andere afhangt van de mate van efficiëntie van het bedrijf. Kijken wij bijvoorbeeld naar verzekeraars dan kan de manier waarop men de klant benadert zeer verschillend zijn. De ene verzekeraar maakt gebruik van tussenpersonen en de andere maakt gebruik van telefonische aanvragen. Hoewel de producten min of meer gelijk zijn is het hierbij vooral de uitvoering die van belang is. Vergelijken we dit met de infrastructurele benadering dan zien wij dat de functies van deze bedrijven min of meer gelijk zijn. Een functiemodel van het ene bedrijf is zeer goed te gebruiken voor het andere bedrijf. Het verschil ligt met name in de wijze waarop men deze functies uitvoert. Blijkbaar is het ‘hoe’ hier veel belangrijker dan het ‘wat’. Waardoor wordt de wijze van de uitvoering van de functies eigenlijk bepaald? Vanuit de management literatuur en vanuit de praktijk blijkt dat de inrichting van de hoofdprocessen vooral een bepaalde strategie van het bedrijf als oorzaak hebben. Zo zal een bedrijf dat als strategie heeft om de klant optimaal te bedienen een andere inrichting van zijn processen kiezen als een bedrijf dat als strategie heeft de goedkoopste te zijn. Wat we echter ook uit de praktijk kunnen leren is dat vele bedrijven niet snel kunnen omschakelen omdat zij (onder andere) te maken hebben informatiesystemen die niet zo makkelijk zijn om te vormen. De grootste bottleneck is dan niet eens zozeer het systeem zelf als wel de gegevens die in (via) dit systeem zijn opgeslagen. Het systeemonafhankelijk maken van gegevens blijkt dan ook zeer belangrijk. Dit is één van de onderdelen waarin de infrastructurele benadering naar mijn idee erg sterk is en misschien nog te weinig wordt gebruikt. De conclusie die men hieruit kan trekken is dat de keuze van de bedrijfsvoering bepalend is voor de inrichting van de processen en de hierbij behorende informatievoorziening. De huidige informatiesystemen zijn echter ook vaak een belemmering om tot deze verandering te komen. Een interessante vraag is dan ook of de infrastructurele benadering hier een rol kan spelen en zo ja, welke. Zoals in de voorgaande hoofdstukken is beschreven is er in de infrastructurele benadering een duidelijk onderscheid gemaakt tussen inrichtingsafhankelijke en een inrichtingsonafhankelijke gedeelte. Het inrichtingsonafhankelijke stuk bestaat uit een beschrijving van de functies en objecten en vormen hierbij de input aan het organisatiemodel. Een interessante vraag is nu wat dit bijdraagt in de visievorming en strategie van bedrijven. Om hier een antwoord op te krijgen is de belangrijkste vraag waarom een bedrijf wil veranderen. De reden tot verandering kan zeer divers zijn (geen vraag meer in de markt, concurrentie, nieuw management enz.). Wat de grootste motivator tot verandering is, is dat het management niet tevreden is met de huidige uitvoering van een (deel)proces waarvoor de persoon (resultaat)verantwoordelijk is. Soms weet de manager waar bepaalde knelpunten in het proces zich bevinden, maar meer algemeen is vaak alleen het symptoom bekend. Waar de infrastructurele methode dan ook aan zou moeten voldoen is het inzichtelijk maken van knelpunten. Om een knelpunt inzichtelijk te maken is het noodzakelijk om de huidige situatie te beschrijven. Alleen op die manier kunnen vermoedens worden getoetst aan de werkelijkheid. De (methodische) beschrijving moet dan ook voldoen aan de volgende kenmerken: • Het beschrijft het huidige proces op een manier die herkenbaar is voor het management. • Het moet in staat zijn knelpunten te kunnen analyseren en te toetsen. • Het moet alternatieven kunnen beschrijven waarbij aangegeven kan worden of knelpunten hiermee opgelost kunnen worden. • Het moet een gewenste situatie kunnen beschrijven waarbij toetsing aan de huidige situatie mogelijk is zodat duidelijk is waar er wat veranderd moet worden (migratie)


www.hobbitsoft.nl

20

Beschouwen we op deze manier de infrastructurele benadering dan zien wij dat deze benadering hier niet aan voldoet. Voor dit soort vraagstukken lijkt de infrastructurele benadering dan ook geen oplossing te geven. Een constatering hierbij is dat het opstellen van een IP met betrekking tot het organisatie stuk dus niet met de juiste middelen gebeurd. Zoals eerder aangegeven voorziet een methode als Testbed hier wel in. Kijken we naar wat er zoal in een proces plaatsvindt dan zien we iets door alle processen heen: het gebruiken en creëren van gegevens. Vrijwel ieder proces maakt op de een of andere manier gebruik van gegevens. Het beste kan men dan ook een loskoppeling maken tussen gegevens en processen. Dit kan vertaalt worden door een knip te leggen tussen een bedrijfskundige kant waarbij de processen van belang zijn, en een automatiseringskant (informatiseringskant) waarbij gegevens optimaal worden gebruikt en beheerd. Ik leg hierbij de knip dus niet bij functies, maar bij de gegevens als stabiel gedeelte. De processen bepalen namelijk voor een deel de benodigde functies (zie hoofdstuk 3). De infrastructurele benadering is wel goed uitgerust om vragen te beantwoorden met betrekking tot gegevensarchitecturen (de verdere uitwerking van een basisbedrijfsmodel en dan vooral het objectmodel) Ik hoop dat met dit hoofdstuk duidelijk is geworden dat de vraagstelling en het doel bepalend zijn waarom men een ‘informatieplan’ wil maken. Afhankelijk hiervan kan men dan bepalen of men de infrastructurele benadering moet gebruiken en tot op welk niveau deze uitgewerkt moet worden, of dat men beter een andere methode kan gebruiken zoals bijvoorbeeld Testbed, of dat men een combinatie hiervan kan gebruiken. Zo zal men bij een ‘nieuwe’ wet zoals bijvoorbeeld rekeningrijden misschien eerder geneigd zijn om eerst een functiemodel op hoog niveau te willen maken. Heeft men het gevoel dat bepaalde processen niet optimaal werken dan ligt een beschrijving van het huidige proces met een beschrijving van de daarbij behorende knelpunten eerder voor de hand. Bij het wijzigen van beleid ligt een toetsing van het huidige proces aan de beleidsdoelstellingen meer voor de hand. Vanuit mijn ervaring lijkt het dat men veel te snel begint met het maken van een ‘standaard’ IP, zonder eerst na te gaan wat nu eigenlijk de vraag is. Vaak is niet duidelijk voor wie met welk doel het IP wordt gemaakt, en lijkt het een ritueel dat uitgevoerd wordt. Dit is zeer jammer omdat er veel tijd zit in het maken van een IP en er veel boven water komt waarvan niet duidelijk is of dit relevant is of niet. Het zou dan ook goed zijn om van tevoren duidelijk te krijgen wat men met een IP wil bereiken en dan te kijken welke methode hiervoor het meest geschikt is en hoever men moet gaan met de uitwerking. Het is hierbij handig om voor een fasegewijze manier van werken te kiezen. Een fase zal hierbij een tijdspanne van bijvoorbeeld een maand kunnen hebben. Na iedere fase zal dan een evaluatie moeten plaatsvinden of men nog hetzelfde doel nastreeft en of de opgeleverde producten ook aan het doel beantwoorden.


www.hobbitsoft.nl

21

Definities: Aandachtsgebied: het geheel van veranderingsgebied en relevante omgeving. Afbakenen: kiezen van het te belichten aspect, het innemen van een besturingsstandpunt en het karakteriseren van het betrokken bedrijfsonderdeel in termen van activiteiten, mensen en middelen. Automatisering: het proces binnen de informatisering dat zich bezighoud met het inschakelen van geautomatiseerde hulpmiddelen (ook wel het verbeteren van de efficiëntie van de informatievoorziening zelf). Autonoom: dat je gegevens uit een gegevensgebied kunt beheren zonder dat je daarvoor gegevens uit de andere gebieden hoeft te raadplegen. Architectuur: de wijze waarop een visie of idee herkenbaar is geconcretiseerd in de opbouw van iets. Basisbedrijfsmodel: In dit model wordt een stabiele visie op het bedrijf beschreven door resultaatgericht te beschrijven over wat er gebeurt en dit zoveel mogelijk onafhankelijk te beschrijven m.b.t. hoe dat gebeurt. Het beschrijft wat ondanks alle (toekomstige) veranderingen hetzelfde moet blijven. Bedrijf: een geheel van activiteiten, mensen en middelen die op enigerlei wijze moeten samenhangen, teneinde een bijdrage te leveren aan de omgeving, danwel een gemeenschappelijk doel te realiseren. Bedrijfsfunctie: Een geheel van uit te voeren taken gericht op het behalen van één resultaat. Representeren dus de bijdragen en de deelbijdragen die het bedrijfsonderdeel aan de omgeving levert, onafhankelijk van de wijze waarop dit gebeurt. Bedrijfsfunctiemodel: Hierin staat beschreven welke bedrijfsfuncties we beschouwen en hoe deze opgesplitst worden Bedrijfsgegevens: gegevens die altijd nodig zijn, ongeacht de wijze waarop de wijze van de bedrijfsprocessen zijn ingericht. Blauwdruk functie: een beschrijving van wat gerealiseerd moet worden. Een precieze afbakening van de systemen is hierbij van belang. CRUD functie: Create Read Update Delete Effectiviteit: mate waarin vooraf opgestelde resultaten worden gerealiseerd. Efficiëntie: de verhouding tussen de (opgestelde) resultaten en de daarvoor geleverde inspanning. Flexibel: mate waarin het mogelijk is om informatiesystemen snel en tegen lage kosten aan te passen aan veranderde omstandigheden (functionaliteiten blijven behouden). Functiemodel: gevonden functies (de bijdrage van een taak of activiteit, gekenmerkt door eenheid van resultaat en eenheid van veranderingsdoel) die hiërarchisch gegroepeerd zijn. Gaat om een resultaatgerichte beschrijving van de stabiele taken. Functiemodule: module die gegevens verwerkt, d.w.z. berekent een functionele relatie tussen invoer en uitvoer. Functionele decompositie: zodanig modulair gestructureerd dat een module precies één functie vervult voor de bedrijfsprocessen. Gevalscategorie: Een klasse van ‘gevallen’ die op gelijksoortige wijze behandeld worden. Gegeven: een formele, abstracte, en waargeachte uitspraak over de werkelijkheid, waarmee het resultaat van een waarneming wordt gerepresenteerd. We moeten dus kunnen achterhalen welke toestand in de werkelijkheid ermee correspondeert. Gegevensarchitectuur: de wijze van splitsing van de gegevenshuishouding in deelgebieden en de beleidsuitspraken die voor de deelgebieden gelden. Zie ook de functie Gegevensbeheersysteem: goed toegankelijke gegevensverzameling met de daarbij behorende beheertaken. Gegevensgroep: die groep van gegevens over objecten van een objecttype, die zich ten opzichte van de functies volkomen identiek gedragen. Zie ook kenmerken Gegevenshuishouding: het systematisch geheel van mensen, middelen, gegevensverzamelingen en activiteiten, gericht op het plannen en structureren; verzamelen en vastleggen; onderhouden, beheren en toegankelijk maken van de voor de bedrijfsprocessen benodigde gegevens. Gegevensinfrastructuur: systematisch geheel van gemeenschappelijk te gebruiken gegevensbeheersystemen. Wordt gevormd door de bedrijfsgegevens die zijn opgeslagen in een aantal samenhangende, goed toegankelijke administraties, met de bijbehorende (software) hulpmiddelen en diensten die het beheer en gebruik van die gegevens in voorziene, maar ook onvoorziene omstandigheden ondersteunen. Zij slaan de resultaten van functiemodules op. Gegevensmanagement: het zodanig richting geven aan en organiseren van de gegevenshuishouding dat daardoor een infrastructurele voorziening ontstaat voor de hele informatievoorziening.


www.hobbitsoft.nl

22

Gegevensonafhankelijkheid: het definiëren en structureren van gegevens, onafhankelijk van het gebruik en onafhankelijk van de wijze waarop ze zijn opgeslagen. Gegevensverzamelingen hebben dus een zelfstandig bestaansrecht. Informatie: de toename van voor het bedrijf relevante kennis bij de gebruiker, door het aanbieden van gegevens op het juiste moment, op de juiste plaats en in de juiste vorm. Er moet dus sprake zijn van nieuws Informatie-architectuur: een voortschrijdende visie die in de vorm van onderling samenhangende architecturen wordt uitgewerkt, aangevuld en vastgelegd. Informatiebeleid: de operationalisering van het bedrijfsbeleid voor het aspect informatievoorziening. Informatiegebied: cluster van bedrijfsprocessen die een relatief autonoom gebied vormen. Informatiemanagement: de verantwoordelijkheid om te bepalen welke bijdrage van de informatievoorziening gewenst wordt, door de bestaande en toekomstige behoeften te inventariseren, op elkaar af te stemmen en de onderlinge prioriteiten te bepalen. Informatieresourcemanagement: verantwoordelijkheid om de hulpmiddelen te creëren waarmee de gevraagde bijdrage (van het informatiseringproces) geleverd kan worden. Informatiesysteem: een systeem dat zowel gegevensverwerkende als gegevensbeherende taken uitvoert. Informatievoorziening: het systematisch geheel van mensen, middelen en activiteiten dat is gericht op het tijdig en juist verstrekken van adequate informatie aan de bedrijfsactiviteiten. Informatiseren: het proces van voortdurend ontwikkelen, uitbouwen en aanpassen van de informatievoorziening. Nadruk ligt op het innovatieve gebruik van IT. Infrastructuur: structureert en realiseert op een overzichtelijke wijze de samenhang binnen de informatievoorziening en bestaat uit een geheel van gemeenschappelijk te gebruiken faciliteiten. Interactiemodel: de interactie tussen de functies uit het functiemodel en de objecten uit het objectmodel, de beschrijving van de samenhang tussen de stabiele taken en objecten. Kwaliteit: een goede aansluiting op het bedrijfsbeleid en/of de mogelijkheid snel in nieuwe informatiebehoeften te voorzien. (bruikbaarheid en duurzaamheid) Objectenmodel: een lijst van samenhangende definities van systeemobjecten, van de dingen waarvan eigenschappen gebruikt of gewijzigd worden door de stabiele taken. Organisatie: wijze waarop het bedrijf is ingericht d.w.z. de structuur (componenten waaruit het bedrijf is opgebouwd), de functie die de componenten vervullen in het geheel, de wijze waarop de coördinatie is geregeld en de regelingen die zijn getroffen om onzekerheden op te vangen. Organisatiemodel: model dat beschrijft op welke wijze de aan de omgeving te leveren bijdrage tot stand komt. Geeft aan welke (bedrijfs)processen daarbij een rol spelen en hoe die samenhangen d.w.z. wat voor gegevens ze met elkaar uitwisselen. Proces: een geheel van activiteiten met als kenmerk eenheid van tijd, plaats en handeling Procesinfrastructuur: laag op de gegevensinfrastructuur en bestaat uit een samenhangend geheel van herbruikbare, gestandaardiseerde en goed vindbare software componenten met de bijbehorende hulpmiddelen, diensten, standaards en regels die het beheer en juiste gebruik van die softwarecomponenten vergemakkelijken. Zij dienen voor de toepassingssystemen. Product: De schriftelijke vastlegging van een ontwerp. Randvoorwaarde: een afbakening van de grenzen waarbuiten je niet mag treden, bijv. Een budget dat niet overschreden mag worden. Resultaat: de mate waarin relevante partijen overeenstemming bereiken over inhoud en functie van die producten. Richtlijn: aanwijzing over de wijze waarop de doelen gerealiseerd kunnen worden. Sub-optimalisatie: het verschijnsel waarbij het optimaliseren van het eigen deelresultaat leidt tot een verre van optimaal totaalresultaat. Systeem: een verzameling objecten die als onderling samenhangend worden beschouwd. Systeemontwikkelingsinfrastructuur: de samenhangende inrichting van het ontwikkelproces met methoden, technieken, hulpmiddelen en gereedschap (relevante standaards en handboeken plus een koppeling van de relevante elementen uit de technische infrastructuur, de gegevensinfrastructuur en de procesinfrastructuur. Technische infrastructuur: computersystemen met besturingssoftware, geheugenmedia, bijbehorende data(base)managementsystemen, netwerken enz. Toepassingssysteem: een systeem dat gegevensverwerkende taken verricht ter ondersteuning van specifieke bedrijfsprocessen (alle bedrijfsprocessen van een bedrijfsonderdeel) of gebruikers en dat voor de gegevens die daarbij van belang zijn, een beroep doet op de gegevensinfrastructuur. Uitgangspunt: vooronderstelling van de ontwikkelingen die we constateren of verwachten binnen een aandachtsgebied.


www.hobbitsoft.nl

23

Gebruikte literatuur Argelo, Sikko ;Boterman, Jan: Praktijkboek informatieplanning; Opbrengsten en werkwijzen; Stenfert Kroese 1991 Berlo, Ger; Diesel, Jan; Kingma, Jan enz.: Handboek Architecturen; Belastingdienst 1 maart 1999 Bond, Bruce; Pond, Kyle; Berg, Tom: ERP Scenario; Gartner group 21 june 1999 Prof.dr.drs. T Huppe (red.): Informatievoorziening in dienst van effectiviteitsverbetering; Stenfert Kroese 1990 Oosterhaven, J.A.: Informatiestrategie; Samson 1994 Panfox: Ondernemen met informatie; Panfox B.V. 1992 Sanden, Wim van der; Sturm, Bart: Informatie-architectuur: De infrastructurele benadering; Panfox B.V. 1997


www.hobbitsoft.nl

24

De infrastructurele benadering voorbij?

Recommend Documents