Modellen en EIS (Enterprise Information System)

Modellen en EIS (Enterprise Information System) (Dit materiaal is eigendom van de Open Universiteit daarom geldt dat gebruik, vermenigvuldiging of wijziging alleen mag plaatsvinden met instemming van de Open Universiteit).

De cursus Enterprise Modelling bestaat uit vier hoofdstukken: - H 1: Modellen van een onderneming - H 2: Enterprise Information Systems & Enterprise Resources Planning - H 3: Implementatie en migratie van ERP/ Het logistiek domein - H 4: Modellen en Architectuur. Het doel van dit eerste deel is om een inleiding te geven bij het thema van deze cursus. Het gaat daarbij om twee aspecten. Deze onderwerpen vormen de springplank naar de rest van de cursus: - een inleiding op het modelleren - het belangrijkste toepassingsgebied van modellering: de automatisering (Enterprise Information Systems). Deze onderwerpen worden behandeld in dit diktaat. Het eerste hoofdstuk geeft een inleiding over wat een model is en in welke situaties modellen bruikbaar kunnen zijn. Het tweede hoofdstuk beschrijft Enterprise Information Systems. De term Enterprise Information Systems wordt in alle Nederlandstalige literatuur onvertaald gelaten, wij sluiten ons aan bij dit gebruik. Nadat in deze eerste twee hoofdstukken de twee onderwerpen zijn neergezet zal in het derde hoofdstuk het logistieke domein verkend worden; deze cursus gebruikt dit domein ter illustratie van modelleertoepassingen. Tenslotte wordt in het vierde hoofdstuk toegewerkt naar een voorlopige conclusie over het gebruik van modellen.

1

Inhoud 1 MODELLEN VAN EEN ONDERNEMING 5 1.1 Inleiding 5 1.2 Modellen 6 1.3 Eigenschappen van een model. 8 1.4 Enterprise modeling 9 1.5 Modellen als weerspiegeling van de werkelijkheid 19 1.6 Modellen in een verandertraject 24 1.7 Samenvatting. 25 2 ENTERPRISE INFORMATION SYSTEMS & ENTERPRISE RESOURCES PLANNING. 34 2.1 Introductie 34 2.2 Afbakening en begrippen 34 2.3 Tussen maatwerk en standaardsoftwarepakket/ERP. 39 2.4 Ontwikkeling ERP systemen vauit bedrijfsperspectief: ERP & Beyond 42 2.5 Ontwikkeling ERP systemen vanuit technologisch perspectief; de noodzaak samen te werken 46 2.6 Samenvatting 48 3 IMPLEMENTATIE EN MIGRATIE VAN ERP/ HET LOGISTIEK DOMEIN52 3.1 Introductie 52 3.2 Implementatie van ERP systemen 52 3.3 Gebruik van modellen bij invoer van EIS/ERP 56 3.4 Logistiek kader 59 3.4.1 Inleiding 59 3.4.2 Discrete productie 59 3.4.3 Primaire processen 59 3.4.4 Stuklijst 62 3.4.5 Routering 63 3.4.6 Goederenstroom 64 3.4.7 Bedrijfsbesturing/Klant Order Ontkoppel Punt 65 3.5 Samenvatting 67 4 MODELLEN EN ARCHITECTUUR 74 4.1 INTRODUCTIE 74 4.2 Een allesomvattend model voor EIS 75 4.2.1 Ontwerp, analyse en besturing 75 4.2.2 Generieke modellen 75 4.2.3 Implementatietrajecten 76 4.2.4 Toenemende complexiteit 76 4.3 Modellen en Architectuur gedefinieerd. 77 4.4 Vier architecturen 78 4.4.1 CIMOSA 78 4.4.2 PERA 79 4.4.3 GERAM 80 4.4.4 Zachman model 81

2

4.5

3

Conclusies

83

Inhoud hoofdstuk 1

Modellen van een onderneming Introductie Hoofdstuk 1 2 3 4 5 6

Modellen Eigenschappen van een model Enterprise Modelling Waarom modelleren? Functies van modellen: analyse, ontwerp en besturing Samenvatting

Zelftoets Terugkoppeling 1 2

4

Uitwerking van de opgaven Uitwerking van de zelftoets

1

Modellen van een onderneming

INTRODUCTIE 1.1 Inleiding In dit hoofdstuk staat de vraag centraal: wat heeft een organisatie aan modellen van de eigen organisatie? Het hoofdstuk begint met de rol van modellen en modelleren in het dagelijks leven. Daarna wordt de stap naar modellen voor de organisatie gezet en worden een aantal eigenschappen van modellen besproken. Aanvankelijk gebeurt dat aan de hand van een voorbeeldbedrijf daarna wordt getoond wat de gevolgen kunnen zijn van het gebruiken van de verkeerde modellen. Na bestudering van dit hoofdstuk heeft de student een beeld van het belang van het modelleren bij het besturen van een organisatie. In dit hoofdstuk zal bij wijze van illustratie een aantal modellen worden gebruikt. Het is niet nodig deze modellen allemaal te kennen. Modellen en hun betekenis voor de bedrijfsvoering is het centrale thema in de rest van dit deel. In de volgende delen zal dieper worden ingegaan op modellen. Dit hoofdstuk vormt zo als het ware een miniatuurweergave van de stof die in deze cursus zal worden behandeld. LEERDOELEN Na het bestuderen van dit hoofdstuk: – kunt u aangeven wat een model is – Kunt u in een concrete situatie aangeven welke functie modellen vervullen – kunt u aangeven wat Enterprise Modelling is – kunt u vertellen welke eigenschappen modellen hebben – kunt u het belang van een juist model kunt beargumenteren – kunt u aangeven hoe modellen helpen bij analyse, ontwerp en besturing van een organisatie. – kunt u aangeven de relatie tussen modellen en de automatisering van bedrijfsprocessen.

5

Kernbegrip

LEERKERN 1.2

Model

Modellen

Wat is een model en wanneer gebruiken we een model? Een model is een vereenvoudigde weergave van de werkelijkheid. Dat klinkt abstract, maar voorbeelden van het gebruik van modellen in het dagelijks leven liggen voor het oprapen. Het gaat bijvoorbeeld om kinderen die vadertje en moedertje spelen en zo hun eigen “vereenvoudigde weergave van de werkelijkheid” creëren. Ook een hobbyist die op zolder speelt met treintjes, iemand die de route naar zijn vakantieadres bestudeert met behulp van een model (landkaart), maar ook iemand die de kans heeft een blauwtje te lopen weegt in gedachten kansen af en stelt zich voor wat er zou kunnen gebeuren. Hij bouwt als het ware een model en simuleert in gedachten de verschillende mogelijke uitkomsten.

OPGAVE 1.1

Geef zelf enkele voorbeelden van het gebruik van modellen in het dagelijkse leven. Vaak zijn modellen veel geformaliseerder dan in de voorbeelden hierboven: het Centraal Plan Bureau maakt een model van de Nederlandse Economie en adviseert op basis daarvan het kabinet. Een student maakt op basis van tekenafspraken een schema van een goederenstroom. Eminente geleerden stoppen al hun methodologische kennis in miniatuurbootjes in het waterloopkundig laboratorium. Allemaal voorbeelden van modellen waar veel geformaliseerde kennis en ervaring in zit. We lijken veel vaker dan we ons bewust zijn zo’n vereenvoudigde weergave van de werkelijkheid te gebruiken. Dat geldt voor zowel formele als informele modellen. Modellen hanteren we zo vanzelfsprekend dat we er niet bij stil staan. Dat geldt vaak ook voor modellen van organisaties. Sommige modellen van organisaties worden bewust gehanteerd, andere niet. Je kunt een onderneming zien als een “zelf-bewust” systeem dat modellen bevat over het eigen handelen. Er is dan opnieuw sprake van formele modellen en informele modellen. De formele modellen staan in jaarverslagen, mission-statements, handboeken, en in allerlei documenten. Het informele model gaat over het werkelijke gedrag van de organisatie. Dat werkelijke gedrag wordt vaak beheerst door het model dat het systeem van zichzelf heeft. Dat kan overlappen met het officiële model maar hoeft niet. In sommige organisaties ontstaat zo een verschil tussen hoe we ons in werkelijkheid gedragen en hoe we geacht worden ons te gedragen. Uiteraard worden modellen ook vaak gebruikt om een gewenste situatie vast te leggen. Veranderen door groei of een overname brengt de managers terug naar de ontwerptafel. Op basis van ambitie, omgevingsfactoren en mogelijkheden maken de managers een model van een nieuwe organisatie, of een deel van de organisatie. Zo beschouwt verschilt het modelleren van organisaties door de managers niet van het werk van een productontwikkelaar of een systeemontwikkelaar; beiden maken keuzes op basis van eisen en wensen die leiden tot een bepaald 6

ontwerp. In organisaties worden kortom verschillende modellen gebruikt,

Figuur 0 een blauwdruk (hoe het is gepland) en een rooddruk (hoe het werkt) Bron Ribbers en Verstegen; Toegepaste Logistiek.

waarbij sprake kan zijn van formele en van informele modellen. De informele modellen bepalen in grote mate ons individuele handelen en tonen ons daardoor de grote rol die “modellen” spelen. Op deze informele modellen zullen we verder niet meer ingaan, maar de aandacht richten op de formele modellen. Die formele modellen zijn in deze cursus gericht op het begrijpen en besturen van organisaties. In de bovenstaande figuur is het organogram zo’n weergave waarbij een aantal functies in een hierarchische porsities ten opzicht van elkaar zijn geplaatst. Dat organogram helpt bij het inzicht in de situatie, wie moet je hebben voor een klacht over inkoop, maar ook bij het besturen, wie is verantwoordelijk vooor de afdeling inkoop. OPGAVE 1.2

a) Benoem een aantal bedrijfssituaties of bedrijfsveranderingen waarin het opstellen van een model van de organisatie dienstig is. b) Leg het verschil tussen begrijpen en besturen uit aan de hand van een voorbeeld Modellen worden uiteraard niet alleen in directiekamers gebruikt, maar door de hele onderneming heen. Ieder functioneel gebied heeft zijn eigen modellen. - Planning maakt op basis van een vaste procedure een plan voor de komende productieperiode. In die planning zijn de belangrijkste 7

variabelen opgenomen die nodig zijn om een afgewogen beslissing te kunnen maken wanneer voorraden aan te vullen, wanneer te produceren, wanneer de fabriek stil te zetten. - De administratie heeft een vast model dat men hanteert voor het boeken van posten. - Verkoop hanteert vaste manieren om de klanten in kaart te brengen en in het vizier te houden. Zo onderhoudt iedere afdeling een eigen model van wat van belang is voor het uitoefenen van de functie. Aan het eind van deze paragraaf mogen we concluderen dat modellen blijkbaar nogal wat verschillende verschijningsvormen hebben. De essentie vanmodellen is dat ze een hulpmiddel vormen bioj het besturen en begrijpen van organisaties. In de volgende paragraaf volgt daarom een afbakening van het begrip.

1.3

Eigenschappen van een model.

Een model is een vereenvoudigde weergave van de werkelijkheid en gericht op begrijpen en besturen van de werkelijkheid. Wat zijn daarnaast de eigenschappen van een model zijn. Hieronder volgen drie eigenschappen van een model zoals die in het vervolg gebruikt zullen worden. Het gaat om: 1) een formele weergave van 2) een beperkt aantal aspecten 3) vanuit een bepaalde visie. Deze eigenschappen worden hieronder verder uitgewerkt. Een formele weergave van ….. In deze module gaat het bij een model altijd om een grafische (organogram, datamodel), wiskundige (voorraadplanning of sterkteberekening) of tekstuele beschrijving (gebruiksaanwijzing of bedrijfspresentatie). Soms gaat het om een combinatie van deze drie. Afspraken over de betekenis van gebruikte symbolen zijn daarbij noodzakelijk. Voor het tekenen van een goederenstroom spreken we bijvoorbeeld af dat pijlen een verplaatsing betekenen, een rechthoek een bewerking en een driehoek op een punt een voorraad voorstelt. (zie bijvoorbeeld paragraaf 3 Farmaco-case) Model voor voorradberekening In het magazijn van een groothandel in bouwmaterialen heeft men te maken met een gemiddelde vraag naar een bepaald type professionele boormachines. Men verkoopt er gemiddeld drie stuks per week. De importeur doet er gemiddeld een week over om de boormachines bij de groothandel te krijgen. Als regel bestelt de groothandel er tien tegelijk. Om te kijken of er nog boormachines nodig zijn berekent het voorraadsysteem wanner te bestellen. Als geldt [actuele voorraad – gemiddelde verbruik = 0]dan wordt er bijbesteld. Het gaat hier om een simpel rekenkundig model. Als er nog drie op voorraad liggen wordt er nu bijbesteld. Als er rekening gehouden zou worden met afwijkingen van de gemiddelde vraag en de gemiddelde doorlooptijd dan wordt het model al een stuk complexer.

8

- ….. een beperkt aantal aspecten ……Bij een model gaat het alleen maar om die aspecten die van belang / interessant zijn. Het meest volledige model van een huis is een huis. Het Centraal Plan Bureau zou de Nederlandse samenleving kunnen nabouwen ten behoeve van de economische berekeningen maar als model heb je daar niks aan. Het wordt pas een model als de schaal wordt aangepast, als er delen worden weggelaten. Het gaat bij modelleren vaak om de kunst van het weglaten. Wat moet dan worden weggelaten? Wat moet worden weggelaten hangt af van het doel van het model. Een model heeft altijd een doel. Dat doel bepaalt de gebruikswaarde. Een simulatiemodel van een nieuw magazijn is er op gericht vast te stellen hoe het orderverzamelen zo efficiënt mogelijk kan verlopen. De constructie van het dak en de kleur van de stelling is daarbij niet relevant. Wel van belang is de plaats van de snellopers binnen het magazijn, de lay-out van de gangpaden en de hoogte van de stellingen. De positie van de snellopers dient zo dicht mogelijk bij de inpakruimte te zijn om loopafstanden te minimaliseren, de gangpaden moeten breed genoeg zijn om een vorkheftruck te kunnen laten keren, maar hoe breder de gangpaden hoe minder opslagruimte overblijft. Kortom: alleen die aspecten die een relevante invloed uitoefenen op het doel, efficient orderverzamelen, spelen mee. De variabelen worden dus gekozen omdat ze geacht worden van belang te zijn voor het resultaat. -…..vanuit een bepaalde visie. Een model bevat een view (van (een deel van) de organisatie). Met een view wordt bedoeld dat er altijd een bepaald perspectief verbonden is met een model. Bij een automatiseringstraject van een productieplanning bestaan er bijvoorbeeld views van: -de kosten van het project en de deadlines (view van de projectleider) -de informatiebehoefte van de planner (de gebruiker) -de systeemarchitectuur en inpasbaarheid van de oplossing ( de automatiseerder) Voorbeelden kunnen verder betrekking hebben op zowel structuur (organogram) als proces (orderverwerking) van een organisatie. OPGAVE 1.3

a) Ga voor jezelf na of het tweede en derde aspect wel verschillend zijn. b) Pas de drie elementen toe op een voorbeeld uit de eigen (werk-)ervaring Uit de voorbeelden in deze paragraaf komt opnieuw naar voren dat we ons in vrijwel alle situaties bedienen van voorstellingen en modellen. Het onderstreept eens te meer de noodzaak vast te stellen welke modellen we gebruiken in onze organisaties en hoe we met die modellen omgaan.

1.4

9

Enterprise modeling

Onder enterprise modelling verstaan we het totaal aan samenhangende modellen voor de weergave (van aspecten / delen) van een organisatie1. Dat er een samenhang bestaat in de echte organisatie zal duidelijk zijn, een order komt via verkoop binnen, gaat naar productie, productie geeft door welke materialen men nodig heeft, inkoop bestelt de materialen en uiteindelijk stuurt de administratie een factuur aan de klant. Per afdeling bestaan er meerdere modellen. Een model om de productie te besturen, een model om de facturen te boeken, een model om budgetten op te stellen, enzovoort. Die modellen moeten ook samenhangen, als het besturingsmodel van de administratie standaard na 20 dagen aanmaningen begint te sturen kan dat strijdig zijn met het model van verkoop. De afdeling verkoop vindt namelijk dat de betalingscondities een onderdeel van de commerciële onderhandleingstraject zijn en heeft met deze klant een uitgestelde betaling afgesproken. Hier is prake van modellen van delen van een organisatie die een samenhang dienen te vertonen De case die verderop in deze paragraag volgt heeft betrekking op selectie en implementatie van een Enterprise Resources Planning (ERP-)pakket. Zo’n pakket beoogt alle functies in een bedrijf te ondersteunen. Bij pakket selectie en implementatie wordt een grote variëteit aan modellen gebruikt. Omdat selectie en implementatie van software meestal de aanleiding vormt voor modelleren zal het volgende hoofdstuk in zijn geheel gewijd zijn aan het onderwerp Enterprise Information Systems. Het opstellen van de modellen vormt een van de eerste stappen in een traject van selectie / implementatie. Bij het modelleren gaat het er dan om vast te stellen welke processen worden ondersteund door het systeem. Deze processen dienen te worden gemodelleerd en deze modellen worden vervolgens nagebootst in het ERP-systeem. De werkelijkheid wordt als het ware gespiegeld in het systeem waarbij de spiegel alleen die dingen uit de echte wereld laat zien die opgenomen moeten worden in het systeem. Er zijn situaties bekend waarbij goedlopende bedrijven door het perspectief van een snelle en goedkope implementatie aan de rand van het faillissement zijn gebracht. Zo werd bijvoorbeeld een fabrikant van automaten een snelle implementatie voorgespiegeld. Aangetrokken door het perspectief van dat snelle traject (en daarmee lage kosten) ging men met dit buro in zee. Conform de afspraken werd na twee maanden het systeem opgeleverd, maar het systeem werkte zo gebrekkig dat bijvoorbeeld alle boekingen van en naar het magazijn zo arbeids intensief waren dat men al snel het systeem links liet liggen omdat handmatig bijhouden veel effectiever en eficienter leek. Dat holde het gebrekkig lopende systeem nog verder uit. Al spoedig gold de noodzaak van handmatige verwerking voor vrijwel alle transacties. Dat vormde een enorm grote belasting voor het personeel en leidde tot zeer veel fouten waardoor klanten ontevreden werden en wegliepen. Ondertussen moest met een ander adviesburo de foute implementatie ongedaan worden gemaakt en het hele systeem opnieuw geimplementeerd worden, uiteraard na hermodellering van de processen.…… In veel literatuur wordt onder Enterprise Modelling verstaan die modellen van een organisatie die in een computersysteem staan. Wij hanteren deze restrictie niet. Het gaat dus om alle modellen van een organisatie. 1

10

De in haast opgestelde en niet kloppende modellen van de bedrijfsprocessen die in het systeem gebracht werden weken af van de processen in de werkelijkheid. Als het model van de werkelijkheid niet klopt kun je dat model uiteraard ook niet gebruiken om die werkelijkheid mee te sturen. OPGAVE 1.4 Geef aan wat mogelijke consequenties kunnen zijn van het onzorgvuldig formuleren van de (besturings-) modellen. Het ontwerpen van de modellen gebeurt top-down. Dat wil zeggen eerst wordt het overkoepelend bedrijfsmodel vastgesteld. De andere modellen of “weergaven van de werkelijkheid” dienen daar dan in te passen. Het gaat immers om de samenhang. In de praktijk wordt hierbij een top-down model gevolgd. Eerst wordt het overkoepelend besturingsmodel vastgesteld. Vervolgens wordt er op basis van de overkoepelende besturing per onderdeel vastgesteld wat de karakteristieken van dat onderdeel zijn die in het model en dus ook in het systeem dienen terug te keren. Het gaat daarbij om een systematiek zoals in onderstaande figuur.

bedrijf

inkopen

producere

voorraadbeheer

bestellen

bedrijf

hoofdproces

verkopen

ontvangst

adm. verwerken

proces

i

verzamelen

info

in system. kijken

controle

subproces

versturen

Gegevens samenbrengen

lijstopstellen

activiteit

Figuur 3 Voorbeeld van top down uitwerken van processen en activiteiten die een systeem moet ondersteunen.

Hieronder zullen eerst kort een drietal modellen worden beschreven. Vervolgens zal worden vastgesteld hoe in een concrete situate et die modellen wordt omgegaan in de case Farmaco.

11

Drie grondvormen van organisaties. In de recente literatuur wrden wel drie grondvormen van organisaties beschreven. Het gaat om de value shop, value chain en value network. the value chain Het eerste model is een model van Porter. Centraal in dit model staat het begrip toegevoegde waarde. De toegevoegde waarde ontstaat door input om te zetten naar output ten behoeve van de klant. Uitgangspunt hier is dat iedere handeling of bewerking waarde moet leveren ten behoeve van de klant. Bij de productie van printers bijvoorbeeld werd minutieus onderzocht welke bewerkingen noodzakelijk waren, de rest werd geschrapt. Het is de optimale efficiëntie die zorgt voor de waarde voor de klant. Om die toegevoegde waarde te bereiken worden er een aantal standaardprocessen onderscheiden. De primaire processen zijn de processen die direct waarde toevoegen aan het product of de dienst die aan de klant wordt geleverd. De primaire processen bestaan uit de inkomende goederenstroom, de bewerkingen op de goederen en de uitgaande goederenstroom. De waarde die hier wordt toegevoegd voor de klant bestaat uit het bij elkaar krijgen van de juiste uitgangsmaterialen, het bewerken en assembleren van die materialen en ze uit leveren aan de klant. Daarnaast wordt waarde toegevoegd door het verkopen en onderhouden van het product. De grondvorm van dit model is er een die toepassing vindt in bijna alle productie en distributie omgevingen. Typisch een model dat ondersteuning biedt bij productiesituaties. In de figuur hieronder wordt een onderscheid gemaakt naar de ondersteunende en de primaire processen. De primaire processen voegen waarde toe voor de klant (ingaande logistiek, verwerken, uitgaande logistiek, marketing en sales en nazorg of service); de ondersteunende processen leveren niet aan de klant, maar aan de primaire processen. Firm infrastructure

M A

Human Resource Management

R G

Technology Development

I N

Procurement

Operations

Inbound Logistics

Outbound

Marketing

Logistics

& Sales

Service

Figuur 4 Toegevoegde waarde model van Porter

the value shop (waarbij shop niet gehanteerd wordt in de betekenis van winkel maar van werkplaats) de waarde voor de klant wordt hier verkregen door kennis te mobiliseren om een probleem op te lossen, verschillende

12

disciplines leveren kennis en vaardigheden waarbij het totaal meer is dan de som van de delen. Een automatiseringsteam kan voor een opdrachtgever een systeem implementeren, maar een projectleider of programmeur kan dat in zijn eentje niet. Het is de combinatie van de inbreng van verschillende professionals die waarde levert. Een ander voorbeeld van het in een stappen een inschakelen van kennis en vaardigheden die leiden tot een oplossing van een probleem is het in een team van artsen stellen van een diagnose, of in het geval van een Research afdeling van een farmaceutisch bedrijf het vinden van een oplossing voor een medisch of farmaceutisch probleem. Onderstaande figuur toont opnieuw een onderverdeling naar primaire en ondersteunende activiteiten. Primair in de value shop is het probleem zoeken, oplossen, implementeren en evalueren. Het uit voeren van deze cyclus vraagt op dezelfde manier ondersteuning als bij de waardeketen van de eerste figuur. Ondersteunende Infrastrucuur van de organisate Human Resource Management Technologie - ontwikkeling Inkoop Probleem zoeken / acquisitie

Oplossingsmogelijkheden

keuze

Controle en Evaluatie

Uitvoering

Figuur 5 Het model van de value shop: mobiliseren van kennis en vaardigheden levert de toegevoegde waarde

the value network de waarde voor de klant wordt (mede) bepaald door deelname in een bepaald netwerk, door deelname aan dat netwerk ontstaat toegang tot kennis en bronnen die anders niet toegankelijk zouden zijn. Een voorbeeld is de huizenjager die voor actuele kennis van de markt naar een makelaar gaat. Het netwerk levert de waarde. Voor het value network gelden een paar karakteristieken: de aanbieder creëert waarde voor klanten door de klanten aan elkaar te koppelen. Dat is bij een bank bijvoorbeeld vragers en aanbieders van geld. de aanbieder heeft de beschikking over een infrastructuur, een computernetwerk, een telefoondienst of anderszins een technische

13

ondersteuning voor het vormen van een netwerk (hoewel dat soms als bij een bank een “anoniem” netwerk is). De aanbieder is gericht op het identificeren en te gelde maken van mogelijke relaties tussen de klanten Hoe groter het netwerk hoe meer de waarde voor de klant toeneemt Onderstaande figuuur toont dat een bedrijf (bijvoorbeeld een internet aanbieder) op basis van de infrastructuur (modems en servers) diensten aanbiedt (internettoegang en het plaatsen van homepages) en dat via netwerken (internet ) aanbiedt. Zowel de aanbieders als de gebruikers van bijvoorbeeld de homepages zijn klant van de internet aanbieder. Hoe groter het aantal klanten hoe aantrekkelijker het wordt om deel te nemen aan dit netwerk. klant infrastructuur diensten Figuur 6 value network

netwerk verkoop

OPGAVE 1.5 Noem enkele overeenkomsten en verschillen tussen de drie modellen.

klant

Na deze korte inleiding over modellen van waardetoevoeging, gaan we kijken naar de toepassing van modellen binnen een traject van selectie en implementatie van Enterprise Information Systems. Dit gebeurt aan de hand van een case over het bedrijf Farmaco. Case FARMACO

Een producent van medicijnen, Farmaco, staat op het punt over te gaan op de aanschaf van een nieuw systeem. Het nieuwe systeem dient alle bedrijfsfuncties te ondersteunen. Het bedrijf ontwikkelt medicijnen en beschikt over een grote R&D afdeling. Na het ontwikkelen worden de medicijnen in eigen beheer in een aantal verschillende afdelingen geproduceerd. Eerst maakt men de zogenaamde actieve of werkzame stof. Meestal gebeurt dat middels een aantal ketelprocessen. Vervolgens maakt men van de actieve stof tabletten en tot slot volgt het verpakken waarbij men de tabletten in blisters stopt, de blisters in doosjes verpakt en de doosjes weer in omdozen conform de klantwens. Het totaal van de 14

operatie kent veel variabelen die de besturing onoverzichtelijk maken. De afnemers zijn gevestigd in verschillende Europese landen. Type bedrijf Bij de keuze voor een systeem wordt bij Farmaco als eerste gekeken naar de structuur van de onderneming. Men probeert de totale onderneming onder te brengen in één model. Daarvoor hanteert metn de indeling zoals die in de vorige paragraaf is gebruikt. Dat lukt niet goed. De eisen die de research stelt verschillen enorm met die van de fabrieken. Van deze drie modellen lijken er twee van toepassing op Farmaco. Voor de productie en distributie past het model van Porter uitstekend, maar voor de Research is beslist een ander model nodig. Het model van de value shop sluit het best bij research aan. Het model van een netwerk valt af, geconcludeerd kan worden dat het niet de opzet van een farmaceutisch bedrijf als Farmaco is om klanten een netwerk aan te bieden. Men komt tot de conclusie dat de productie en de research op een gescheiden manier dienen te worden geautomatiseerd. OPGAVE 1.6 Welke verschillen zouden er in de bedrijfsvoering bestaan die samenvoeging in één systeem bemoeilijken?

Type Productie In de komende hoofdstukken zal blijken dat productie en logistiek belangrijke onderdelen zijn voor een ERP-systeem. Nu is vastgesteld dat bij Farmaco twee typen problemen spelen concentreert de case zich verder op het productie gedeelte. Voor het productiegedeelte nodigt men de medewerkers van hoog tot laag uit om de bestaande productie situatie in kaart te brengen. Men doet dit middels een brown-paper sessie. Aan de muren van een vergaderzaal worden rollen papier gehangen (men gebruikte daar vaak bruin inpakpapier voor vandaar de naam brown-paper sessie). Vervolgens wordt op de strook inpakpapier het bedrijfsproces weergegeven. Dat doen de medewerkers zelf met behulp van post-it plakkers waarop de (hoofd-) activiteiten staan vermeld. Al discussierend zullen de post-its in het begin mogelijk nog een paar keer verplaatst worden of de beschrijving op de plakkers wordt aangepast. Vervolgens wordt vastgesteld hoe de bestaande processen verbeterd kunnen worden. Het model dat aldus ontstaat vormt het model dat ondersteund moet worden door het nieuwe systeem.

15

Stappen van een brown paper sessie 1.

Verzamel een team. Bij voorkeur bestaat het team uit personen die betrokken zijn bij het proces, maar ook uit verschillende lagen zowel uitvoerders als leidinggevenden. Het team moet “empowered” zijn. Dat wil zeggen verantwoordelijkheid en bevoegdheid om aanzienlijke aanpassingen in het proces door te voeren

2.

Beschrijf de processen. Leg vast hoe het werk nu gebeurt. Dus niet zoals het in de handboeken staat, maar hoe het in werkelijkheid gebeurt. Het is vaak het makkelijkst om eerst een globaal overzicht te maken van alle stappen en vervolgens de details vast te leggen. Een globaal overzicht bestaat uit de hoofdstappen. Details zijn bijv. beslisof keuzepunten, overdracht van werk, afstand die een product / document aflegt, authorisaties, controles, parallelle activiteiten, leg ook de tijdsaspecten vast zoals de doorlooptijden, beschrijf de uitgevoerde transformatie / bewerking, etc. De processen legt men vast in een grafische weergave. Lang niet altijd zal men alle aspecten op een post-it vast kunnen leggen. Nummer dan de verschillende processtappen. In een begeleidende tekst kun je dan per nummer aanvullende informatie verschaffen.

3.

Stel de problemen vast. Dit zijn de gebieden waarvan je kunt vaststellen dat er verbetering nodig is omdat de procesuitvoering niet strookt met de procesdoelstelling (bijvoorbeeld aantal producten), er sprake is van oponthoud, bottlenecks, onvoldoende hulpmiddelen, versnippering van het traject door een ver doorgevoerde specialisatie en wat je maar meer kunt bedenken.

4.

Brainstorm over oplossingen. Stel vast hoe je de problemen kunt oplossen. Belangrijk is dat tijdens het brainstormen geen kritiek wordt gegeven. Alle ideeën kunnen, soms geldt hoe wilder hoe beter, want dat levert naast ongerijmde ideeën soms hele onvermoede bruikbare oplossingen.

5.

Evalueer de acties en doe voorstellen voor verbetering.

6.

De geoptimaliseerde processen vormen de processen die uitgangspunt zijn voor het nieuwe systeem.

Al ontwikkelend ontstaat een beeld van de productieprocessen. Een figuur van de processen op het allerhoogste niveau staat hieronder. Vanuit de grondstoffen worden in een aatal stappen chemische stoffen vervaardigd die uitgangspunt zijn voor een medicijn. (de driehoeken op een punt zijn voorraadpunten). De aktieve stof wordt samen met vul- en smaakstoffen tot tabletten geslagen op de tabletteerafdeling, vervolgend worden de medicijnen verpakt en naar de verschillende afnemers getransporteerd.

16

grondstoffen

tabletten

actieve stof productie

magazij n

Tabletteer-

Verpakkings

afdeling

-

klant distributie

afdeling

hulpstoffe n

verpakkingsmateriaal

Figuur 7 Overzicht van de goederenstroom bij Farmaco

OPGAVE 1.7 Geef aan wat de relatie is tussen bovenstaand model en het model van Porter. Het blijkt dat er sprake is van verschillende typen productie: te weten (semi-)proces productie bij de productie van actieve stof en serieproductie bij de productie van tabletten en bij het verpakken. Binnen de logistiek bestaat een basismodel (het model van Bertrand) dat op basis van een tweetal dimensies (capaciteitscomplexiteit en materiaalcomplexiteit) een aantal uitspraken kan doen over de verschillende productievormen.

Figuur 8 Indeling van productiewijzen volgens Bertrand

De kracht van zo’n bestaand model is dat er al erg veel kennis en research inzit. Op basis van bovenstaand model kunnen uitspraken worden gedaan over problemen en situaties die in soortgelijke bedrijven spelen en zich dus waarschijnlijk ook bij Farmaco zullen voordoen. Een fase verder hebben we te maken met de besturing van de verschillende bedrijfsfuncties. Voor de tabletteer en de verpakafdeling wordt vervolgens op basis van een algemeen model (zie Bertrand.) een specifieke invulling gemaakt. Dit model vraagt behoorlijk wat kennis van zowel de situatie als de logistieke besturingstheorie en is uitsluitend ter informatie toegevoegd. Hiermee ontstaat een overzicht van de modelleer 17

activiteiten zoals die vaak worden uitgevoerd bij de invoering van een Enterprise Information System. Logistieke parameters verkoopplan Beschikbare capaciteiten en productienormen Afroep en inkooporders

voorspellinge

Aggregaatp lanning producti eplan

bezettingsp lanning

Verkooporganisaties

Materiaal-

coördinatie

aanvulo rders

Werkorder prioriteiten

Ingeplande

werklastacc eptatie

Voorraad informatie

Werkorder vrijgave

Voorachterstand in productie actieve stof

werkorder

tabletten Tablettee rafdeling

eindproduct Verpakkin gsafdeling

Figuur 9 Overzicht van de tabletteer- en verpakkingsafdeling van Farmaco

Soorten modellen. Ten aanzien van de modellen bij Farmaco kan geconstateerd worden dat er deels sprak is van modellen die Farmaco zelf opstelt, deels van modellen die al bestaan. De modellen die het bedrijf zelf opstelt zijn beschrijvend, ze geven weer hoe de processen en de besturing van de processen verlopen. De modellen die al bestaan zijn modellen die weergeven hoe een proces het best kan worden ingericht. In deze voorschrijvende modellen zit een helboel kennis en onderzoek verwerkt. Bie ieder implementatie traject wordt gebruik gemakt van een combinatie van deze typen modellen Samenvatting Farmaco case. Onder enterprise modelling verstaan we het totaal aan samenhangende modellen voor de weergave (van aspecten / delen) van een organisatie. In het begin van de case kon geconcludeerd worden dat niet alle bedrijfsonderdelen in één model ondergebracht konden worden. De

18

modellen in deze case geven vervolgens een steeds gedetailleerder beeld van de processen zoals die fysiek verlopen, maar ook van de planning en besturing en de informatie die daarbij nodig is. Enterprise modelling kan daarom worden opgevat als het totaal aan samenhangende modellen voor de weergave van de structuur, de processen, de informatie, de capaciteitsbronnen, de doelen en de beperkingen van een organisatie. Tot zover deze case.

1.5

Modellen als weerspiegeling van de werkelijkheid

In de afgelopen paragraven is besproken wat een model is en waarom het handig is met modellen te werken. Een model is een hulpmiddel om grip te krijgen op een situatie. Bij het modelleren van bedrijfsprocessen bedoelen we met grip krijgen dat een model moet helpen bij het begrijpen, analyseren, ontwerpen en besturen van een organisatie. Hoe verloopt dat mechanisme van grip krijgen op de werkelijkheid met behulp van een model? In deze paragraaf zal eerst de relatie tussen model en werkelijkheid worden bekeken. Het belang van een relevante afspiegeling van de werkelijkheid wordt geïllustreerd in het tweede deel van de paragraaf. Een spiegel van de werkelijkheid Een computersysteem helpt bij het besturen van processen. Bij productie in een meubelfabriek bijvoorbeeld gaat het om de status van een werkorder en de productievoortgang. Een order voor de productie van een partij stoelen wordt uitgegeven. De buizen voor het frame van de stoelen en de stof en de vulling voor de zitting worden vrijgegeven. Deze materialen worden door een medewerker uit het magazijn bij elkaar gezocht en overgedragen aan intern transport. Intern transport brengt de materialen naar de productie waar de materialen worden bewerkt en samengevoegd tot stoelen. Uiteindelijk worden de gereed gekomen stoelen weer in opslag gebracht en na verloop van tijd uitgeleverd aan de verschillende afnemers. Al die processen uit de echte wereld hebben als het ware hun evenknie in de virtuele wereld van de computer. Een virtuele wereld is een schijnbare wereld. In het geval van de computer gaat het om het registreren van gegevens over de processen uit de echte wereld.

19

Virtuele wereld: digitaal & electronisch

Materialen

Materialen

Materialen

verzamelen

vervoeren

bewerken

Materialen

Materialen

Materialen

verzamelen

vervoeren

bewerken

Assembleren

In magazijn plaatsen

spiegel

Echte wereld

Assembleren

In magazijn plaatsen

Figuur 10 voorbeeld van proces spiegelen.

Een ander voorbeeld betreft van Gend & Loos of een andere vervoerder die pakketpost bezorgt. Elk pakket, een fysiek object in de fysieke wereld, wordt gespiegeld in de virtuele wereld. Het virtuele object bestaat uit een aantal gegevens die het pakketje weergeven. De status van het pakket wordt on line bijgehouden omdat iedere keer als het pakketje in een luchthaven of een ander distributiepunt wordt gescand er een aantal statusgegevens wordt toegevoegd. Uitsluitend de gegevens die relevant zijn voor de besturing worden zo vastgelegd en onderhouden. Wat wel en wat niet relevant is wordt bepaald bij het opstellen van het model. Wat wordt opgenomen in het model hangt weer af van de analyse van de situatie. werkelijkheid

model

systeem

Figuur 11 het model als scharnier tussen werkelijkheid en systeem

De scharnier tussen de fysieke wereld en het systeem is een model. Zonder een goed model is het een kwestie van geluk of het systeem wel goed zal werken of niet. Wat gebeurt er nu als de echte wereld en het model uit elkaar gaan lopen? In de volgende paragraaf zullen enkele voorbeelden hiervan worden behandeld. Modellen vervullen dus een functie. Ze helpen bij het analyseren, ontwerpen en besturen van een organisatie. Over het algemeen is er ook in de tijd gezien sprake van deze volgorde, eerst analyseren, dan ontwerpen en tot slot besturen.

20

De analyse geeft zicht op de problemen die spelen in de huidige situatie en op de eisen en wensen die men heeft voor de nieuwe situatie. Vervolgens ontwikkelt men een aantal oplossingsvarianten. Tot slot dient de oplossing te worden geconsolideerd in de besturing Het belang van een juiste afspiegeling De drie aspecten analyse ontwerp en besturing worden hieronder verder uitgewerkt. Bij elk van de onderwerpen zal een voorbeeld gegeven worden van een model dat slecht past. Deze paragraaf vormt daarmee een illustratie van de stelling dat de modellen de relevante werkelijkheid dienen te weerspiegelen. Relevant is dat wat helpt bij het besturen van de werkelijkheid. Modellen zijn onmisbaar, maar als je het verkeerde model toepast leidt dat op zijn minst tot behoorlijk ongemak. • beschrijven en analyseren Een analyse helpt om de aandacht te richten. Een goede analyse is als de diagnose van de dokter. Een arts hoort een veelheid aan symptomen en weet daaruit de rode draad te halen. Een onoverzichtelijke probleemkluwen wordt zo teruggebracht tot een of enkele oorzaken waarop de aandacht zich dient te richten. Als je die oorzaak aanpakt verdwijnen de symptomen vanzelf. Voor je kunt analyseren dien je echter het hele verhaal te kennen, daarbij horen ook de symptomen en een heleboel ruis, dat zijn namelijk de symptomen die geen rol spelen. Beschrijven en analyseren horen daarom bij elkaar, bij EM dient een beschrijving als input voor de analyse. -Bij het beschrijven staat centraal: wat tref ik aan en hoe vat ik dat samen. Al werkend wordt informatie opgedaan die wordt verwerkt in het model. Vanuit de realiteit werkt men naar een model. Het gaat om het construeren van de “ist”2 bijvoorbeeld in de vorm van een Brown paper (beschrijvend). Amazon.com, de verkoper van boeken via het internet, had in de periode na de opstart problemen met de tijdige levering van de producten. Men wist veel van het verkopen via Internet maar weinig over de logistieke operatie. Om dit op te lossen werd een logistiek expert weggekocht bij Wall Mart, een van de grootste supermarktketens van de Verenigde Staten. Deze man met enorm veel ervaring in logistiek voor de retailsector ontwikkelde voor Amazon.com magazijnconcepten. Het concept bestaat hieruit dat een geavanceerd computersysteem weet met welke order een orderverzamelaar bezig is. De orderverzamelaar loopt door een magazijngebied en boven de schappen waar hij iets uit moet halen gaat een lampje branden. Hierdoor neemt de orderverzameltijd af en het aantal fouten (verkeerde artikelen) wordt minimaal. Het systeem werkt uitstekend als je voor een klant of een order veel verschillende artikelen bij elkaar moet zoeken en het signaleringssysteem je langs de stellingen loodst. Helaas, bij Amazon.com heeft men enorm veel orders, maar een order vraagt één, hooguit twee artikelen en geen tientallen als bij Wall Mart. Wat had de logistiek manager hier verzuimd?

Onder “ist” wordt verstaan een beschrijving van de huidige situatie, de tegenhanger van de ist vormt de “soll” die een beschrijving van de toekomstige of gewenste situatie bevat.

2

21

De logistiek manager had geen model gemaakt van de bestaande situatie. Hij had alleen oog voor de oplossing en niet voor de verschillen tussen Wall Mart en Amazon.com. Zijn model paste niet op de werkelijkheid van Amazon.com - “Wat zegt het model over deze situatie” Het model wordt dan gebruikt voor classificatie en beoordeling. De richting is hier dus omgekeerd: vanuit een model kijkt men naar de realiteit. Men gebruikt de instantkennis van het model om iets over de situatie te weten te komen. Dit gebeurde bijvoorbeeld bij het Bertrand model bij Farmaco. Als er zo’n bestaand model wordt gebruikt heeft dat twee aspecten: het is beschrijvend (geeft aan wat je zou moeten kunnen verwachten) en voorschrijvend (als een deel van het model niet van toepassing is op de situatie geeft dat informatie over die situatie) Een gerenommeerd adviesburo verzocht een student bij wijze van afstudeeropdracht een algemeen model te maken van de pensioenbranche. Dit algemeen model zou een samenvatting van de processen in de branche moeten geven en een bundeling van de kennis van het kantoor moeten opleveren. Uiteindelijk zou het als referentiemodel voor de branche moeten dienen. De processen in dat referentiemodel zouden de optimale situatie dienen te weerspiegelen. Als uitgangspunt koos het bureau voor het model van Porter, zie paragraaf drie. Dit model is echter toegesneden op een productiebedrijf. De vraag die hierboven werd gesteld “Wat zegt het model over deze situatie?” kan achteraf worden beantwoord met: onvoldoende. Het model van een productiebedrijf laat zich niet goed toepassen op een dienstverlener. • ontwerpen “Wat wil ik dat dit object straks presteert?”. Bij een ontwerp spelen altijd twee aspecten waar men het ontwerp op moet afstemmen. Ten eerste dient het ontwerp de problemen op te lossen die spelen in de huidige situatie. Ontwerpen is dan het oplossen van een probleem. Oplossen doe je door zo te modelleren dat de oplossing voor de hand ligt. Ten tweede moet het ontwerp rekening houden met de eisen en wensen die voortvloeien uit de gewenste ideale situatie. Als de ist-problemen en de soll-wensen samenkomen in een oplossing is er meestal sprake van een goed ontwerp. Problemen ontstaan vaak pas als het ontwerp gerealiseerd wordt en niet voldoende blijkt te werken, het model, de blauwdruk , het ontwerp hield onvoldoende rekening met omstandigheden en randvoorwaarden. Indien mogelijk is het dan ook verstandig om een ontwerp altijd eerst uit te testen in een simulatie. De simulaties stellen een onderzoeker in staat om dingen uit te proberen die in de werkelijkheid ondoenlijk zijn omdat het teveel tijd kost, het onethisch is, teveel geld kost etc. Binnen een wereldwijd opererende scheepvaartonderneming wilde men de kosten van de containeroperatie beter beheersen. De investeringen in containers kunnen enorm oplopen. Om dit te bereiken ontwierp men een systeem dat de doorstroomsnelheid van de containers zou moeten verhogen. Naarmate de bezettingsgraad van een container stijgt heeft men er immers minder van nodig. Men ontwierp een systeem dat wel genoemd werd het hot-potato-systeem. Het systeem is ontleend aan een spelletje dat cowboys speelden rond het kampvuur, een aardappel wordt gloeiend heet verwarmd in het vuur en vervolgens zo snel mogelijk doorgegeven, anders brandt de cowboy zijn vingers. Dat zou ook met 22

containers moeten gebeuren, men deelde de aardbol op in een aantal regio’s. De kosten van de container kwamen voor rekening van degene in wiens gebied de container zich bevond. Als een container van de ene regio naar de andere verhuisde gingen de kosten mee. Er waren twee redenen waarom de uitvoering haperde, de eerste was dat de regio’s elkaar allerlei materiaal toestuurde waar men vanaf wilde, dat leidde ertoe dat sommige lege units soms maanden lang aan boord van de schepen bleef rondreizen en kostbare ruimte in beslag nam. De tweede was dat men de regio’s zodanig in de systemen had geprogrammeerd dat op het moment dat een regio werd gesplitst het computersysteem dat niet aankon.

• Besturen. Het begrip besturen geeft vaak een eerste associatie met een beperkt aantal mensen aan de top van de onderneming. In feite is echter iedereen betrokken bij het besturen en heb je aan de top alleen meer macht. Ieder proces vraagt om sturing, of het nu gaat om productie, klantenservice, personeelszaken of inkoop, alle verschillende onderdelen van een organisatie dragen bij aan het beheren en besturen. De besturing op uitvoerend niveau is meestal het uitvoeren van standaardafspraken. Die afspraken gaan dan over de manier waarop dingen binnen de organisatie gebeuren: een bundeling van procedures, afspraken, processen en methoden. Philips hanteerde sinds jaar en dag tot tevredenheid het zogenaamde “arko” of artikel koderingsysteem. Ieder artikel krijgt een unieke code waarmee het product wordt geïdentificeerd. Ieder getal kent 17 posities: “de 17nc”. (nc = numerieke code). Het systeem werkt binnen sommige bedrijven nog steeds naar behoren. Regelmatig zet Philips een van zijn bedrijfsonderdelen in de etalage. Bij een van de verkochte ondernemingen blijkt dit coderingssysteem na een aantal jaren niet meer te voldoen, het systeem raakt vervuild.

company

96

22

land

Figuur 12 De

5 divisie

product -groep

67

presentatie

890

12

product

productcode bestaande uit 17 betekenisvolle posities.

OPGAVE 1.8 a) Geef een aantal mogelijke oorzaken van het vastlopen van dit systeem b) Wat zijn de mogelijke gevolgen van een vervuild artikelcoderingssysteem

23

bestemming

34 taal

567

1.6 Modellen in een verandertraject Modellen vormen een weerspiegeling van de werkelijkheid. Het gaat daarbij om een formele weergave van een beperkt aantal aspecten vanuit een bepaalde visie. Bij Farmaco zijn een aantal modellen besproken zoals die gehanteerd zijn bij het selecteren en invoeren van een nieuw computersysteem. Welke functies hebben modellen binnen zo’n traject van een nieuw computersysteem? Een aantal van die functies staan hieronder bvermeld. 1 Een model helpt een proces te begrijpen. Als een proces / model goed wordt begrepen kan het proces ook beter worden gestuurd. Voorbeeld hiervan vormen de drie modellen van bedrijfstypen; value network, value chain en value shop. 2 Een model vereenvoudigt. Een model staat je toe dat je een deel van de organisatie bekijkt of alleen een aspect. Het belicht alleen die aspecten die vanuit een bepaald oogpunt relevant zijn. Lastig is wel dat elk model van een deel dient te passen in het totaal. Dat roept een probleem in het leven hoe al deze modellen consistent te houden. Dit probleem zal verderop in de cursus worden uitgewerkt. 3 Een model is een hulpmiddel bij de communicatie. Een plaatje of voorstelling werkt makkelijker dan alineas tekst. Zouden we de figuren in de case willen vervangen door geschreven tekst dan levert dat nogal wat problemen op. Op basis van geschreven tekst zou dit veel meer tijd kosten, veel minder direct werken, veel dubbelzinnigheden kunnen bevatten en veel minder effectief zijn. In een afbeelding kunnen makkelijker aspecten worden aangewezen en besproken dan in de tekst. 4 Een model creeert een gezamenlijk beeld. Zo kan bij Farmaco bijvoorbeeld de “brown paper” worden samengesteld door een groep die bestaat uit medewerkers met totaal verschillende functies. Als men al discussierend langs zo’n brown paper loopt ontstaat er vaak grond om een proces te verbeteren. Het vastleggen van een proces lokt vrijwel altijd discussie op en levert meestal ook een startpunt voor een verandering of verbetering op. 5 Een model geeft een beeld van processen en taken/rollen. De processen en rollen worden duidelijk door de discussie. Er ontstaat meer inzicht in elkaars werk en daarmee wordt de taakafbakening verfijnd. Maar bij Farmaco speelt ook nog iets anders. Het model wordt stapsgewijs opgebouwd, startend op het hoogste niveau en geleidelijk aan wordt dat steeds verder verfijnd. Uiteindelijk leidt dat tot een overzicht van activiteiten. Die activiteiten vallen in logische samenhangende clusters uiteen. Bijvoorbeeld in het model van Bertrand is een natuurlijke scheiding zichtbaar tussen de afdelings- en de fabriekslogistiek. Door stapsgewijs te

24

werken ontstaat dus een samenhangend beeld van de functies nodig om de verschillende processen te besturen. 5 Een model geeft een referentie. Als we naar Farmaco kijken dan zien we dat binnen het bedrijf veel modellen worden ontwikkeld. Eigenlijk is dat jammer. Er gaat veel tijd en energie in zitten en waarom zou je iedere keer opnieuw het wiel moeten uitvinden? Het mooiste zou zijn een standaard model toe te passen. Een standaardmodel is gebaseerd op een grote hoeveelheid onderzoek en kennis en heeft zichzelf al bewezen. De behoefte aan standaardisatie is één van de grote problemen waar het tweede deel van de cursus op voortbouwt. 6 Misschien is wel het belangrijkste aspect dat door veel met modellen te werken; de gebruiker (student) een intuïtie ontwikkelt voor de variabelen die van belang zijn in een omgeving, een situatie. Dat vermogen is een essentieel onderdeel van effectief besluiten nemen. In de tekst tot nu toe is vaak teruggegrepen op voorbeelden uit Informatica gerelateerde toepassingen. Dat is niet toevallig. De systemen die een bedrijfsbrede toepassing ondersteunen zijn een enorme motor geweest bij het van ontwikkelen van modellen. Een ERP systeem zoals dat bij Farmaco wordt ingevoerd dient veel verschillende functies te ondersteunen. Inkoop moet de orders er in kwijt kunnen, logsitiek moet er de goederenbeweging mee kunnen controleren, de administratie moet er de facturen mee kunnen beheren, kortom er zijn veel gebruikers en daarmee veel eisen. De uitdaging is de afgelopen decennia geweest om modellen te ontwikkelen die al die wensen combineren. Het toepassingsgebied van deze overkoepelende modellen ligt hoofdzakelijk binnen de automatisering. Naast de kennismaking met wat begrippen over modelleren in dit hoofdstuk past daarom ook een kennismaking met het toepassingsgebied van die modellen: de Enterprise Information Systems. De komende hoofdstukken zullen daarom gewijd zijn aan de beschrijving van deze systemen. De plaats van dit hoofdstuk in deze cursus is een eerste kennismaking te bieden met modelleren. Na dit hoofdstuk volgt een deel over de Enterprise Information Systems. De module wordt afgesloten met wat voorbeelden van een overkoepelend model. De vraag komt dan naar voren of er wel een overkoepelend model kan bestaan dat alle wensen van alle gebruikers kan faciliteren. 1.7 Samenvatting. Het blijkt dat we ons in de praktijk van het dagelijks leven continu bedienen van modellen in de ene of andere vorm. Ook binnen bedrijven worden veel modellen gehanteerd. Wat heeft een bedrijf aan modellen van het eigen bedrijf? Modellen worden met name opgesteld bij veranderingen in de bedrijfsvoering ten gevolge van bijvoorbeeld automatisering, fusies / overnames of Business Process Redesign. Aan de hand van het voorbeeld van Farmaco wordt duidelijk dat de modellen op alle niveaus van de organisatie worden toegepast. Het zelf opstellen van modellen van de eigen organisatie leidt tot een bewustwordingsproces dat vaak aanleiding geeft tot veranderingen. Modellen hebben een aantal functies. Ze helpen bij het beschrijven, analyseren, ontwerpen en besturen van een organisatie. De notie dat modellen in vrijwel alle facetten van de bedrijfsvoering worden toegepast

25

benadrukt de noodzaak dat die modellen dan ook goed dienen te zijn. Als het model niet strookt met de realiteit dan wordt het model een last in plaats van een ondersteuning van de werkzaamheden, of nog erger kan de onderneming zelfs bedreigen in het bestaan. Na dit hoofdstuk zal de aandacht verlegd worden naar het toepassingsgebied van modellen: de Enterprise Information Systems

ZELFTOETS 1

Beoordeel de juistheid van de stellingen: Stelling 1: Een informeel model van een organisatie gaat over het werkelijke gedrag van mensen binnen een organisatie. Stelling 2: Het afbeelden van een stad door een kind. A stelling 1 is juist stelling 2 is juist B stelling 1 is juist stelling 2 is onjuist C stelling 1 is onjuist stelling 2 is juist D stelling 1 is onjuist stelling 2 is onjuist

2

Een model heeft drie eigenschappen. Licht de eigenschappen toe aan de hand van een model van een te bouwen huis.

3

Wat wordt verstaan onder Enterprise Modelling.

4

Ga na of in de voorbeelden hieronder sprake is van een value chain, value shop of value network: - een internet provider, - een hamburgerrestaurant, - een uitzendburo, - een advocatenkantoor, - een broodbakkerij, - een adviesbureau.

5

Geef drie mogelijke gevolgen van het hanteren van een verkeerd model bij de implementatie van een EIS.

6

Geef aan op welke wijze modellen helpen bij het beschrijven en analyseren, ontwerpen en besturen van een organisatie.

7

a) Onderzoek in welke mate de functies van een model als genoemd in paragraaf 5 van toepassing zijn op figuur 2 t/m 9

8

Verdiepingsvraag (geen verplichte stof) Model voor Containerplanning. Een containerplanner moet bepalen hoeveel lege zeecontainers hij nodig heeft voor een afvaart. Van de boekingsagent ontvangt hij een overzicht van de verwachte en de al geboekte lading voor het betreffende schip. De lading moet in containers, de vraag is dan: heeft hij voldoende containers? Om dit vast te kunnen stellen moet hij kijken naar het beschikbaar komen van de volle containers en de behoefte aan lege containers in de tijd gezien. Containers worden gelost uit een zeeschip. Gemiddeld wordt een derde van de containers op de terminal leeg gemaakt en is na twee dagen

26

leeg, eenderde komt na gemiddeld vijf dagen retour van de klant, en het laatste deel na zeven dagen. Ongeveer een derde van alle containers heeft schade en wordt na 5 dagen uit reparatie vrijgegeven

27

9

TERUGKOPPELING 1

Uitwerking van de opgaven

Opgave 1 Voorbeelden van modellen kunnen zijn: - een agenda als planningsmodel van de dag of een vergadering - het verwachtingspatroon van de student ten aanzien van de functie van een docent. Er is een model (een rolverwachting) waarvan men denkt dat de docent zich daaraan houdt. - een bouwtekening van een huis - een organogram van een organisatie - een samenvatting van een hoofdstuk Opgave 2 a) Bij fusies of verzelfstandiging van bedrijven, bij kwaliteits- en vereterprojecten, bij automatiseringsprojecten en bij groei van een bedrijf waarbij men bijvoorbeeld van een pioniersfase overgaat naar een meer geformaliseerde organisatie. b) Bij begrijpen gaat het om het inzicht in een situatie; bij besturen om het gebruiken van dat inzicht door in te grijpen. Voorbeeld: Eerst weten hoe het productieproces verloopt: hoeveel schakels zijn er, wat zijn knelpunten, welke machines hebben capaciteit over, welke zitten vol, enzovoort alvorens maatregelen te nemen om het proces te versnellen. Opgave 3 a)Een beperkt aantal aspecten kan zijn dat alleen de informatiestromen worden weergegeven. Het gebruikersperspectief “vanuit een bepaalde visie” houdt in dat sommige stromen alleen van belang zijn voor de administratie, andere weer alleen voor verkoop. b) voorbeeld: een organogram geeft de structuur weer van de hierarchische relaties vanuit het oogpunt van delegatie van verantwoordelijkheden. Opgave 4 Indien de modellen niet zorgvuldig worden opgesteld leidt dat tot verkeerde pakketkeuzes. Een systeem bevat verder ook de processen die in de modellen zijn opgesteld. Als het systeem is ingesteld op processen die zich niet in de werkelijkheid voordoen ontstaat hier een probleem. Opgave 5 Overeenkomst: hat gaat om: - een overkoepelend model - vanuit het oogpunt van waardetoevoeging Verschillen: - het gaat om drie verschillende typen processen: een productie proces; een kennis verwerkend proces; een faciliterend proces.

Opgave 6 Enkele verschillen kunnen zijn: Productie 28

Research

-

herhalende productie standaardisatie productiecapaciteit gericht op standaardisatie arbeidsintensief -----

-

iedere keer een apart project unieke situatie menscapaciteit gericht op informatie en kennisverwerving kennisintensief --------

Opgave 7 De figuur is een verbijzondering van de fasen inbound logistics, operations en outbound logistics uit de figuur van Porter Opgave 8 a) Mogelijke oorzaken kunnen zijn: - onvoldoende posities voor de producten - organisatiewijzigingen die niet in de codering kunnen worden weergegeven - betekenisverlies als door verkoop / fusie bepaalde delen van de code betekenisloos worden. - het beheren van de codes: verschillende functionarissen die voor een zelfde product een andere code uitgeven of omgekeerd dat voor verschillende producten een code wordt afgegeven. b) Mogelijke gevolgen kunnen zijn: - twee maal hetzelfde product in oplsag - mislopen van inkoopvoordeel - het systeem wordt als onbetrouwbaar beschouwd en steeds minder goed gebruikt.

Uitwerking van de zelftoets 1

B Zoalshier behandeld is een informeel model het model dat het werkelijke gedrag beschrijft. Een kindertekening is geen formele weergave

2

Formele weergave: bouwtekening door de architect Beperkt aantal aspecten: tekeningen ten behoeve van de aanleg voor elelctra Bepaalde visie: de tekening tbv de koper verschilt met die van de aannemer of de electricien.

3

Onder Enterprise Modelling verstaan we het total aan samenhangende mnodellen voor de weergave van een organisatie of delen van een organisatie.

4

Er is sprake van - een value network bij een internet provider, - een value chain bij een hamburgerrestaurant, - een value network bij een uitzendburo, - een value shop bij een advocatenkantoor, - een value chain bij een broodbakkerij, - een value shop bij een adviesbureau.

29

5

Mogelijke gevolgen kunnen bijvoorbeeld zijn: - Het sysyteem ondersteunt de functies niet meer waardoor men schaduwbestanden gaat bijhouden - Het systeem weerspiegelt niet de echte goederenstroom, administratie en werkelijkheid lopen niet meer parallel - Bepaalde functies, bij voorbeeld inkoop, ontbreken waardoor de informatiestroom stagneert

6

a) Beschrijven en alyseren: het hanteren van een referentiemodel helpt vast te stellen hoe de prestaties zijn van de organisatie. Door het opstellen van een model van de eigen organisatie ontstaat ook een beter begrip van het functioneren. Ontwerpen: op basis van eisen, wensen en gesignaleerde problemen kan een model gemaakt worden waaraan de eisen getoetst kunnen worden. Besturen: bij het besturen van bijvoorbeeld een productielijn wordt gebruik gemaakt van een model met doorlooptijden, uitval, afval en capaciteiten. b) type bedrijf: value

7

Figuur negen wordt hieronder uitgewerkt, voor de anderen wordt volstaan met een matrix. Logistieke parameters verkoopplan Beschikbare capaciteiten

Aggregaatpl

Afroep en inkooporders

producti

bezettingspl

Materiaald Werkorder

Ingeplande werklastacce

Verkoopaanvulor

Voorraad informati

Werkorderv

Voor- achterstand in productie

actieve t f

voorspellingen

werkor

tabletten Tablett eer-

Verpakk ings-

eindprod t

Figuur 9 Overzicht van de tabletteer- en verpakkingsafdeling van Farmaco

De figuur helpt de bestaande situatie beter te begrijpen doordat het de verschillende planningsfuncties en de twee afdelingen in samenhang toont. De figuur is een vereenvoudiging van de werkelijkheid waar bij alleen de relelvante aspecten vanuit de plannigsview worden getoond.

30

Het is een hulpmiddel bij de communicatie omdat planning nu makkelijker bespreekbaar is. Het creeert een gezamenlijk beeld van de planningssituatie bij Farmaco. Het geeft een referentiepunt Het model geeft weer welke planningsprocessen er zijn en wat er dient te gebeuren. Legt niet vast welke functies er precies allemaal zijn, maar wel de taken die er zijn. Het beeld is van toepassing bij Farmaco, maar is tevens een standaardmodel waaraan productiestuaties worden getoetst Het model helpt besluiten te nemen over taaktoewijzing, over operationele problemen, etc. Een model…. Fig 2 Fig 3 Fig4-6 Fig 7 Fig 8 Fig 9 helpt een proces te begrijpen X X X X X X Vereenvoudigt X X X X X X is een hulpmiddel bij X X X X X X communicatie Creeert een gezamenlijk beeld X X X X X X Geeft een beeld van X X X X processen en rollen/taken Referentiemiddel X X X X Helpt besluiten nemen X X X X X

8

uitwerking verdiepingsvraag. Een eerste model dat we opstellen bestaat uit een tijdas. nieuwe afvaart

lossen

1/3 klaar

1/3 x 2/3

(1/3 x 2/3) +

1/3 x 1/3

1/3 x 1/3

klaar

(1/3x1/3)

klaar

klaar

klaar

Een model om de beschikbaarheid van de containers aan te geven is nu vrij eenvoudig opgesteld. na 2 dagen: (# gelost x 1/3 x 2/3) na 5 dagen: (# gelost x 1/3 x 2/3) na 7 dagen: (# gelost x 1/3 x 2/3) + (# gelost x 1/3 x 1/3) na 10 dagen: (# gelost x 1/3 x 1/3) na 12 dagen: (# gelost x 1/3 x 1/3) Het model wordt natuurlijk veel lastiger op te stellen als er onregelmatige afvaarten zijn en als ook de voorspelling van het aantal volle containers erin wordt betrokken. Dat levert al gauw een veelheid aan algoritmes op. Als zo vaak bij planningsmodellen bleek in deze situatie een boekingsagent met veel ervaring op basis van zijn informele model (waarin bijvoorbeeld de koers van de dollar en kennis van de verschillende

31

markten een rol speelt) veel accurater te kunnen voorspellen wat de verhouding tussen import en export is dan de geformaliseerde modellen. Een manier om bij de containerplanning vast te stellen wat het effect is van het terug dringen van de reparatietijd met 1 dag is door te kijken welk effect dat heeft op de kosten van repositioneren van lege containers. Zo ontstaat er zicht op welke variabelen de modellen sterk reageren.

32

Inhoud H2 Enterprise Information Systems & Enterprise Resources Planning 2.1 Introductie 2.2 Afbakening en begrippen 2.3 Tussen maatwerk en standaardsoftwarepakket/ERP. 2.4 Ontwikkeling ERP systemen vauit bedrijfsperspectief: ERP & Beyond 2.5 Ontwikkeling ERP systemen vanuit technologisch perspectief; de noodzaak samen te werken 2.6 Samenvatting Zelftoets Terugkoppeling 1 Uitwerking van de opgaven 2 Uitwerking van de zelftoets

33

2

2.1

Enterprise Planning.

Information

Systems

&

Enterprise

Resources

Introductie

In het vorige hoofdstuk hebben we kennisgemaakt met algemene begrippen van modellen en de rol die modellen vervullen. Het begrip Enterprise Modeling is eveneens ingevoerd. In dit hoofdstuk wordt de context waarin Enterprise Modeling zich afspeelt beschreven. Na het vaststellen van begrippen en kader, worden van Enterprise Information Systems/ Enterprise Resources Planning (EIS/ERP) voor- en nadelen besproken, waarna ontstaan en ontwikkeling geschetst worden, zowel vanuit bedrijfskundig als vanuit technologisch perspectief. Daarbij zal het begrip integratie een sleutelrol blijken te vervullen. Regelmatig zullen we gebruik maken van modellen om begrippen te illustreren. In hoofdstuk 3 wordt nader ingegaan op implementatietrajecten van EIS/ERP systemen en het logistieke domein waar deze systemen toegepast worden. Leerdoelen Na bestudering van dit hoofdstuk en bijbehorende opgaven - kunt u het begrip ERP en de toepassing ervan beschrijven - kunt u belangrijke kenmerken van ERP benoemen - kunt u voor- en nadelen van maatwerk en standaardsoftwarepakketten aangeven - kunt u het belang van integratie beschrijven - kunt u ontwikkeling van erp systemen beschrijven vanuit bedrijfskundig en technologisch perspectief.

2.2

ERP

Afbakening en begrippen

In deze paragraaf zullen we eerst het begrip ERP afbakenen en vervolgens enkele belangrijke begrippen die met ERP samenhangen aan de orde stellen. ERP staat voor ´Enterprise Resources Planning´. Die omschrijving suggereert een zeer brede functionaliteit, voor de hele ´enterprise´ bruikbaar. Voor een ERP -systeem nemen we in eerste instantie de omschrijving 'een bedrijfsbreed geautomatiseerd systeem' als uitgangspunt. Nader omschreven: een geautomatiseerde systeem, dat processen in de bedrijfsvoering van de hele onderneming beoogt te ondersteunen. Daarmee bakenen we het terrein af voor dit blok. Buiten de afbakening valt dan bijv. de cultuur in een bedrijf. Deze omschrijving mist nog een wezenlijk aspect van ERP systemen: hetzelfde pakket is voor meerdere bedrijven toepasbaar.

Definitie ERP

Als definitie zullen we daarom hanteren: Een ERP-systeem is een standaard softwarepakket met sterk geïntegreerde functionaliteit op vele gebieden, zodanig dat het veelal de gehele bedrijfsvoering van organisaties kan ondersteunen3. 3

Zie ERP in bedrijf, Koedijk en Verstelle. Uitg. Tutein Nolthenius

34

Of Een ERP-systeem is een geïntegreerd standaard softwarepakket voor de ondersteuning van de totale bedrijfsvoering, procesgericht en over de afdelingsgrenzen heen.

Brede functionaliteit

Bedrijfsbesturings model

Het is duidelijk dat hier een slag om de arm gehouden wordt: het pakket kan bedrijfsbrede functionaliteit bieden. Nu is bedrijfsbreed wel erg breed. Wat valt er onder en wat niet? Is er een grens aan te geven? Om ons een beeld te kunnen vormen van de breedte van EIS/ERPsystemen gebruiken we het model in figuur 1. Het betreft hier een zogenaamd Bedrijfsbesturingsmodel. In zo´n model kun je ´in één oogopslag´ de belangrijke bedrijfsfuncties onderkennen. De aangegeven functies zijn nodig bij de besturing van het primaire proces, bijvoorbeeld de productie van fietsen. De zgn. goederenstroom is in het onderste deel van de figuur aangegeven als een doorlopende zwarte pijl met rechthoeken (die productieactiviteiten vertegenwoordigen) en driehoeken (die opslagpunten aanduiden). Er is een verkoopafdeling die zorg draagt voor de verkoop en orders binnensleept. De planningsafdelingen (Master Planning, Requirementsplanning) houden rekening met geboekte orders en verwachte afzet (op grond verkoopcijfers over vorige periode) en stellen een productieschema op. In dat schema wordt per periode aangegeven op welk niveau de productie van fietsen moet liggen om aan concrete en verwachte vraag te kunnen voldoen. De afdeling inkoop speelt een belangrijke rol om materialen die nodig zijn voor productie (spaken, fietsbellen, lampen, frameonderdelen etc.) op gewenste tijdstippen op voldoende voorraadniveau te hebben. Natuurlijk moet de productie van de fietsen en de onderdelen ervan gestuurd worden. Dat doet de productieafdeling. Het magazijn zorgt voor opslaan en uitslaan van de goederen. De ´assembly scheduling´ wordt ingeschakeld als aangepaste fietsen geassembleerd moeten worden met afwijkende specificaties. Vanzelfsprekend is er een ondersteunende financiële functie nodig. Het plaatje is niet generiek (= toepasbaar op alle bedrijven) van aard. Zo kan iemand die vertrouwd is met dit soort plaatjes aan de hand van bijvoorbeeld de functies Masterplanning en Requirementsplanning afleiden dat dit besturingsmodel betrekking heeft op een productiebedrijf en geen relevantie heeft voor een pensioenbedrijf.

35

Support L e v e r a n c i e r

Produktie

IN

K l a n t

Verkoop Assembly Scheduling

Requirements Planning

Receiving

Onderhoud en overige diensten

Kwaliteit

Master Planning

Inkoop

Produktie

Magazijn

T R

Urenverantwoording

ProduktBeheer

………..

grond stof

Produktie

Magazijn

UIT

Comp. Manuf.

IN

Comp.

Magazijn

UIT

Sub Assem. Manuf.

IN

Semi Fin.

Magazijn

UIT

Eind Assem.

IN

Eind prod

UIT

verpakking

expedit ie

Finance TR = TRANSPORTEUR

Figuur 1. Business Control Model In figuur 2 geven we een alternatief besturingsmodel voor een slagerij/winkel, die grootvlees (complete koe bijv., in de figuur aangeduid met gv) inkoopt. Het grootvlees wordt voor een deel verwerkt tot direct verkoopbare eindproducten (EP) als bieflappen, entrecotes, soepvlees e.d.. Een ander deel wordt in eerste instantie verwerkt tot componenten (CMP) (stukjes vlees, vet, (soep)botten) voordat verdere verwerking kan plaatsvinden. Beide producten (EP en CMP) zie je terug in het eerste opslagpunt. Tenslotte worden componenten verwerkt/geassembleerd tot bijv. worst, barbecue- en gourmetschotels.De klant kan in de winkel de aangeboden producten kopen. Ook hier zal sprake zijn van een ondersteunende functie financiën.

36

T R

L E V E R A N C I E R

T R

Inkoop Verkoop

Produktie

Ontvangst

GV

CMP fabric.

CMP & EP

Eind Assem.

EP

verpakkin g

K L A N T

UIT

Financiën TR = TRANSPORTEUR; GV=grootvlees; EP= eindproduct; CMP= componenten

Figuur 2. Business control model voor slagerij/winkel In beide voorbeelden is het model betrekkelijk overzichtelijk gebleven. Zouden ook externe instanties als overheid/belastingen/milieuwetgeving erbij betrokken worden, dan wordt de complexiteit van het model beduidend groter en verliezen we eerder het zicht op de primaire bedrijfsfuncties. EIS/ERP systemen kunnen vrijwel alle genoemde functies ondersteunen. Het hier getoonde model gebruiken we uitsluitend om een overzicht te bieden van de belangrijkste functies in een bepaalde bedrijfstak (in fig. 1 dus een productiebedrijf). Niet alle denkbare bedrijfsfuncties zijn in dit model aanwezig. Zo ontbreekt bijvoorbeeld klantrelatiebeheer. ERP systemen zijn om dezelfde reden geen 'totaaloplossing' te noemen. Niettemin is de beschikbare functionaliteit in de producten van de grotere leveranciers van EIS/ERP systemen bijzonder breed. Naast de ondersteuning van productieprocessen kunnen deze systemen ook functionaliteit bieden op gebieden als financiële administratie, marketing, verkoop, human resource management en kostenbeheersing.

Flexibel door aanpasbaarheid

Bedrijfsbrede toepassingen zijn vanzelfsprekend niet alleen van belang voor productiebedrijven. Allerhande bedrijfstakken, zoals bijvoorbeeld het bank- en verzekeringswezen, kunnen er gebruik van maken, vanwege de ´ingebakken´ flexibiliteit. ERP-systemen kunnen namelijk in principe door parameterinstellingen bedrijfstakspecifiek gemaakt worden. Bij de invoering van deze systemen kan door het instellen van waarden voor bepaalde paramaters functionaliteit beschikbaar gesteld of uitgeschakeld worden. Zo kun je dan op hoog niveau aangeven of bijvoorbeeld bepaalde financiële

37

functies, partijbeheer, locatiebeheer gebruikt zullen worden, welk plansysteem gehanteerd zal worden etc. De werkelijkheid is weerbarstiger dan bovenstaande zinsneden doen vermoeden. Volledig parametriseerbaar is een fictie en bovendien vergt het instellen van de parameters veel kennis van de betreffende bedrijfstak. Na deze afbakening van het begrip ERP, waarbij ´en passant´ gebruik gemaakt is van bedrijfsbesturingsmodellen, staan we in het vervolg van de paragraaf nog even stil bij de begrippen integratie, real-time en globaal, die een belangrijke rol spelen bij toepassing van ERP systemen. Integratie

K l a n t

Integratie Integratie wordt vaak in verband gebracht met ERP systemen. Dat is met name het geval vanwege de samenhang die aangebracht wordt tussen verschillende bedrijfsprocessen/processtappen die één gezamenlijk eindresultaat tot doel hebben en waarvan het ene subproces niet zonder het andere kan. In onderstaande figuur (fig. 3) is dat verduidelijkt voor een verkoopproces.

VerkoopOrder order haalbaar? in te voeren

Bevestigen Pickinglist verkoop printen order

Goederen uit magazijn halen

Verpakken goederen voor verzending

Verzenden goederen

Facturering afsluiten order

Figuur 3 Geïntegreerd verkoopproces De klant plaatst een order en via diverse tussenstappen ontvangt de klant tenslotte de factuur. Alle stappen hangen met elkaar samen en moeten in de juiste volgorde afgehandeld worden. Diverse bedrijfsafdelingen kunnen bij deze procesgang betrokken zijn: de verkoopafdeling (orderinvoer), magazijn (picken en verzenden goederen), financiën (facturering). Opgave 1 Noem zelf een aantal met elkaar samenhangende stappen van het inkoopproces. Real-time en ´global´

2.2.1.1

Real-time en ´global´

Afgezien van het integratieaspect is het voor wereldwijd opererende bedrijven van groot belang over één systeem te beschikken (met meerdere talen en valuta) dat bovendien real-time informatie verschaft. Daarmee wordt het mogelijk om op elk moment de voorraad van een bepaald artikel in elk gewenst magazijn, waar ook ter wereld, te raadplegen, en daarbij bovendien de waarde in meerdere valuta aan te kunnen geven.

38

K l a n t

2.3

Tussen maatwerk en standaardsoftwarepakket/ERP.

In deze paragraaf behandelen we maatwerk- en standaardoplossingen voor geautomatiseerde systemen. Daarbij zullen we met name voor- en nadelen van standaardsoftwarepakketten de revue laten passeren. Maatwerk

Maatwerk In de beginjaren van het bestaan van geautomatiseerde systemen werden vrijwel altijd maatwerkapplicaties geleverd. Zo ontstonden klantspecifieke systemen die vooral arbeidsintensieve administratieve processen gingen vervangen. Applicaties waren veelal gericht op een beperkt toepassingsgebied. Binnen een bedrijf werden op deze manier meerdere applicaties ontwikkeld: voorraadbeheersysteem, planningsysteem, boekhoudsysteem, etc. die als los van elkaar staande 'eilanden' gebruikt werden. Niet alleen het toepassingsgebied van deze applicaties verschilde, ook waren vaak de gebruikte technologie en onderliggende database sterk verschillend. Het kan zijn dat een bedrijf zodanig unieke bedrijfsprocessen hanteert, dat standaardoplossingen niet beschikbaar zijn. In zo´n situatie kan maatwerk noodzakelijk zijn. Het grote voordeel van maatwerk is natuurlijk dat bij juiste uitvoering een goed bij de wensen van de klant passende functionaliteit geboden wordt. Nadelen zijn er ook, afgezien nog van het eerder genoemde eilandaspect: - vaak langdurige ontwikkeltrajecten - hoge ontwikkelkosten - in onderhoudsfase is deskundigheid van ontwikkelaars vaak niet blijvend ter beschikking - toegepaste technologie niet noodzakelijk de beste, dat zal nog moeten blijken.

Standaardsoftware pakket

Kenmerken

Standaardsoftwarepakketten/ERP Bedrijven/organisaties kwamen tot de overtuiging dat het merendeel van de bedrijfsprocessen en van gegevens verwerkende processen vrijwel standaard zijn. Een beperkt aantal processen is bedrijfstakspecifiek of uniek voor het bedrijf/de organisatie. Mede daarom zijn standaardsoftwarepakketten in de mode geraakt als beproefde oplossing, die tegen lagere kosten, in kortere tijd en met minder moeite dan ontwikkelingstrajecten voor maatwerk te implementeren waren. Zulke pakketten boden vaak beperkte functionaliteit, bijvoorbeeld voor de salarisadministratie of voor boekhouding of voor voorraadbeheer. Belangrijke kenmerken van standaardsoftwarepakketten: - algemeen toepasbaar - klaar voor gebruik - ontworpen als pakket - kan worden geconfigureerd naar eigen behoefte - geen maatwerk nodig - ondersteund door externe partijen - integratie van belangrijke bedrijfsfuncties - real-time informatie.

Opgave 2. Bij sommige van genoemde kenmerken zijn kanttekeningen te maken die het kenmerk ondersteunen dan wel bestrijden.

39

Welke kanttekeningen zijn er te maken bij het kenmerk geen maatwerk nodig? Er is wel wat af te dingen van een aantal van deze kenmerken. In algemene zin blijven echter de genoemde kenmerken geldig. Met het verstrijken van de tijd groeide de behoefte aan het ondersteunen van de bestuurlijke informatievoorziening en het verstrekken van doeltreffende managementinformatie. De toen bestaande eilandapplicaties boden onvoldoende mogelijkheid data te aggregeren tot managementinformatie. Integratie van applicaties werd een noodzaak. Ook de hoge kosten voor maatwerk waren aanleiding tot het ontwikkelen en gebruik van standaardsoftwarepakketten die bedrijfsbrede functionaliteit boden: ERP pakketten. Onder ERP hebben we in §2.2 verstaan 'een geïntegreerd standaard softwarepakket voor de ondersteuning van de totale bedrijfsvoering, procesgericht en over de afdelingsgrenzen heen'. Voorbeeld van geïntegreerd bedrijfsproces:

Elk bedrijf verstuurt facturen en veel bedrijven hebben één of meerdere afdelingen die zich bezighouden met het opstellen en versturen van facturen. Het opstellen van een factuur voor uitgeleverde fysieke goederen is een bedrijfsproces op zichzelf. Een database met verzendgegevens moet geraadpleegd worden om de juiste verzonden partijen te vinden waarvoor facturering moet plaatsvinden. Elke verzending moet betrekking hebben op door klanten geplaatste orders. Vervolgens moet de prijs vastgesteld worden voor de geleverde producten. Hier spelen regels voor het vaststellen van de juiste prijs een rol. Zijn tussentijdse prijswijzigingen door te berekenen? Is bij uitlevering afgeweken van de order? Zijn er afspraken met de klant gemaakt? Deze regels zijn terug te vinden in een contract met de klant. Daarom moet een contracten-database geraadpleegd worden. Op de officiële prijs worden mogelijk kortingen gegeven, waarvoor toegang tot historische financiële gegevens nodig kan zijn. Tenslotte moet toegang tot de klanten-database mogelijk zijn om het factureeradres te achterhalen.

De integratie komt met name tot uiting in gemeenschappelijk gebruik van gegevens tussen verschillende groepen gebruikers, op eenvoudige en efficiënte manier, over afdelingsgrenzen heen. In klassieke organisaties werden al deze stappen - zoeken van de verzonden partij, vergelijken van verzonden partij met oorspronkelijke order, vaststellen van de prijzen, contracten raadplegen - door verschillende afdelingen uitgevoerd. Daarom duurde het vaak lang voordat een factuur verstuurd werd naar een klant. Bovendien hadden diverse afdelingen vaak eigen applicaties die niet vanuit hetzelfde denkkader of objectmodel ontworpen waren en dientengevolge lastig met elkaar te koppelen waren.

40

Dit voorbeeld illustreert wat in ERP onder integratie verstaan wordt. Integratie beoogt applicaties te ontwerpen die gebaseerd zijn op een centraal beheerde gemeenschappelijke gegevens en op samenhang van bedrijfsprocessen (bijvoorbeeld van order tot uitlevering en facturering van goederen) die de grenzen van functionele afdelingen overschrijden. Opgave 3. Benoem het gemeenschappelijk gebruik van gegevens tussen verschillende groepen gebruikers bij het inkoopproces. Er zijn veel bedrijfsprocessen die integratie vergen. Het bovenstaande voorbeeld voor het opstellen van een factuur kan uitgebreid worden met talloze processen in bijvoorbeeld personeelsmanagement, dienstverlening, logistiek, fabricage, inkoop en accounting. Het blijft hetzelfde verhaal met een variatie op hetzelfde thema: een bepaald bedrijfsproces kan alleen effectief uitgevoerd worden als het toegang heeft tot gegevens en bedrijfsregels uit andere plaatsen binnen de 'enterprise'. Ook bij dit aspect van integratie is de werkelijkheid veel weerbarstiger dan de ´mooie´ voorstelling van zaken die hier gegeven is. We komen nog even terug op de hierboven gemaakte belangrijke opmerking over integratie: De integratie komt met name tot uiting in gemeenschappelijk gebruik van gegevens tussen verschillende groepen gebruikers, op eenvoudige en efficiënte manier, over afdelingsgrenzen heen. Voor een deel zullen gemeenschappelijk opgeslagen gegevens van bijvoorbeeld auto-onderdelen van belang zijn voor zowel de financiële als de magazijnfuncties. Het gaat dan bijv. om artikelnummer, omschrijving, kostprijs, voorraad. De ontwerpafdeling heeft meer gegevens nodig, zoals technische specificaties en kwaliteitskenmerken. Maar voor zover de benodigde gegevens overeenkomen zal gemeenschappelijk beheer en opslag een belangrijk winstpunt blijven. Plussen en minnen ERP

Sterke en zwakke kanten van ERP systemen Één van de meest in het oog springende voordelen van ERP is de integratie van bedrijfsfuncties. Gegevens van bijvoorbeeld artikelen worden éénmaal opgeslagen en zijn in principe toegankelijk voor alle bedrijfsfuncties (denk bijv. aan verkoop, productie en magazijn). Verder zijn als sterke punten nog te noemen: - ERP is procesgeoriënteerd i.t.t. functioneel gericht. Daarbij valt met name te denken aan het ondersteunen van de samenhang van belangrijke bedrijfsprocessen. Het primaat ligt niet bij de afdeling verkoop of enige andere afdeling, maar op het proces waaraan diverse afdelingen een bijdrage leveren. - ERP is flexibel; door configureren en parametriseren zijn de pakketten aan te passen aan specifieke bedrijfstakken (automobielindustrie, levensmiddelenbranche) en bedrijfswensen. De flexibiliteit is echter begrensd. Niet alles is mogelijk zonder maatwerkaanpassingen. Zo zijn voorgeprogrammeerde formulieren en rapporten niet in een handomdraai omgezet en zullen niet alle processen zo in te richten zijn dat een bedrijf zich daar helemaal bij thuis voelt. - ERP biedt koppelingsmogelijkheden naar toepassingen van concurrenten. Dat is met name van belang bij onderlinge afstemming

41

-

van productie tussen producenten en toeleveranciers. De koppeling moet weliswaar gerealiseerd, maar de bestaande ERP pakketten bieden een krachtig instrument voor afstemming op elkaar. ERP is een totaal systeem van één leverancier; voor beheer en gebruik biedt dat veel voordelen boven applicaties die afkomstig zijn van verschillende leveranciers.

De huidige generatie ERP systemen heeft onvermijdelijk ook een aantal zwakke kanten. Daarvan is misschien wel de meest belangrijke het monolithische karakter (´uit één stuk´ vervaardigd) van deze systemen. Het is een totaal systeem van één leverancier: niet alle onderdelen 'lopen lekker' en men is ´met handen en voeten´gebonden aan deze leverancier. Ook beogen erp systemen bedrijfsbrede functionaliteit te bieden. Daarom is opwaarderen (upgrading) van een bepaald onderdeel naar een nieuwere versie meestal niet mogelijk. Men is dan aangewezen op opwaarderen van het hele pakket. Ook kan een nieuwere versie van de software veel inspanning vergen voor het herschrijven van de gebruikersinterfaces en van eerder gedane toevoegingen, het terugzetten van parameters en herhaling van veel activiteiten die bij de eerdere implementatie ook al uitgevoerd waren. Als nadelen kunnen verder nog genoemd worden: - ERP is een ingewikkeld pakket, er is zóveel functionaliteit te gebruiken en te beheren; dat heeft consequenties voor onderhoud en training - ERP is duur - invoering van ERP is vaak lastig. nestgeur

ERP pakketten en nestgeur Grote spelers op het gebied van ERP systemen zijn SAP, Oracle, JDEdwards, Peoplesoft, Invensys/Baan, Navision. Er zijn veel verschillen tussen de pakketten onderling. Ze zijn veelal ontstaan door uitbreiding van een bepaalde specialistische basisfunctionaliteit. Zo bouwde Baan een MRP applicatie uit, voor met name productiebedrijven, met functionaliteit op andere gebieden (bijv. financiën, inkoop en verkoop). SAP heeft zijn oorsprong vooral in financiële systemen terwijl Peoplesoft zijn sterke kant heeft in pakketten voor personeelsbeheer. Die nestgeur is vaak herkenbaar in de wijze waarop het pakket presteert. Gebruiksgemak, eenvoudige koppelingen, goed lopende bedrijfsprocessen zijn niet over alle functies heen dezelfde. In die opzichten kan van leverancier X het onderdeel A zodoende sterk verschillen van onderdeel B. In het eerder behandeld bedrijfsbesturingsmodel (figuur 1) is globaal aangegeven welke basisfuncties een ERP pakket ongeveer afdekt. Er is echter geen standaard voor wat een standaardsoftwarepakket zou moeten bevatten om ERP pakket genoemd te mogen worden.

2.4

Ontwikkeling ERP systemen vauit bedrijfsperspectief: ERP & Beyond

Eind negentiger jaren van de vorige eeuw hebben bedrijven op grote schaal ERP pakketten aangeschaft. Na jaren van enorme groei kwam er rond 1998 een kentering in de verkoop van ERP pakketten. Zowel de groei als de kentering is mogelijk gerelateerd aan de invoering van de Euro en het Jaar 2000 probleem. Tegenwoordig zien bedrijven ERP als

42

transactieverwerkende ruggengraat: een krachtig platform voor verdere ontwikkeling van nieuwe bedrijfstoepassingen. Vanuit historisch oogpunt liggen de wortels van ERP in de logistiek. De term ERP heeft nauw te maken met het begrip Material Requirements Planning (MRP I), een algoritme voor coördinatie van materiaalstromen dat in de vroege jaren zeventig van de vorige eeuw is uitgevonden. Hier zag je trouwens al dat integratie een rol ging spelen: bij deze techniek is de integratie tussen productie en magazijn een vereiste. Later werd de term Manufacturing Resources Planning (MRP II) ingevoerd, om aan te geven dat het niet alleen om materiaalstromen ging maar ook om capaciteitsstromen. De zogenaamde Rough Cut Capacity Planning (RCCP) en Capacity Requirements Planning (CRP) voorzagen in juist die capaciteitsplanning. De Gartner groep bedacht later de term Enterprise Resources Planning (ERP) om aan te geven dat een bedrijfsomspannende integratie van processen beoogd wordt in de bedrijfsbrede softwarepakketten. Terzijde: Het woord planning in de term Enterprise Resources Planning zet ons eigenlijk op het verkeerde been. ERP beoogt integratie terwijl planning slechts een van de vele toepassingsgebieden is. Trends

Trends Misschien is de belangrijkste trend van de afgelopen decennia wel geweest dat bedrijven zich meer op hun processen dan op de structuur van de organisatie zijn gaan richten. Deze trend staat als 'business process re-engineering' (BPR) te boek. ERP systemen liepen gelijk op met deze trend vanwege de ondersteuning van bedrijfsprocessen en de corresponderende integratie van bedrijfsapplicaties die ze bieden. Een tweede trend die zich vooral in volgroeide markten voor doet, is die waarbij de aandacht verschuift van standaard producten en diensten naar meer klantgerichte producten: de klant bepaalt, desgewenst on-line, hoe het product eruit moet zien. ERP systemen ondersteunen in principe deze trend. Het zal duidelijk zijn dat ERP systemen niet voor alle wensen en eisen oplossingen bieden. Nieuwe ontwikkelingen zijn niet zo maar te ondersteunen met de 'traditionele' ERP pakketten. In de beginjaren van ERP was de euforie groot. Alle bedrijfsprocessen zouden ermee afgedekt kunnen worden. Die belofte kon maar ten dele waar gemaakt worden. Het ligt voor de hand dat een leverancier niet alle markten kan bedienen; de daartoe vereiste onderzoeks- en ontwikkelinspanning zou veel te groot zijn. Veel nichespelers bouwden specialistische oplossingen/applicaties voor niet aanwezige functionaliteit. ERP leveranciers kochten veel van deze spelers op om hun eigen product beter te positioneren.

Opgave 4. Noem tenminste één knelpunt dat kan optreden bij ´assimilatie´ van zo´n ´aangebouwde´ functionaliteit.

Beyond ERP

Nieuwe ontwikkelingen op ERP gebied die verder reiken dan de functionaliteit van de oorspronkelijke pakketten worden wel aangeduid met de term ´Beyond ERP´. Daarmee wordt duidelijk gemaakt dat er

43

meer is dan hetgeen de monolithische, logge ERP systemen bieden. Zo zijn in de jaren rond de millenniumwisseling bijvoorbeeld applicaties voor Supply Chain Management, Customer Relationship Management en E-business (of E-commerce) actueel. We staan kort bij deze applicaties stil. Supply Chain

2.4.1.1

Supply Chain

Bij Supply Chain Management gaat het om het automatiseren van een (complete) leveranciersketen met als doel het optimaliseren van een bevoorradingsketen van de leverancier van een leverancier tot de klant van een klant. Laat negentiger jaren van de vorige eeuw en aanvang eenentwintigste eeuw is de focus op bedrijfsprocessen verschoven tot buiten de grenzen van het bedrijf, zodat klanten- en leveranciersprocessen ook binnen vizier komen. We spreken dan van ketenintegratie (supply chain). In zo'n situatie kunnen bedrijven er bijvoorbeeld voor kiezen over te gaan tot 'self-billing', facturen worden gegenereerd door de klant, die de leverancier informeert met verwijzing naar de zending, de ontvangstbevestiging en de order. De klant betaalt vervolgens zo'n factuur. Dit type 'business process redesign' over bedrijfsmuren heen kan leiden tot aanzienlijke besparingen aan beide kanten. Er zijn echter ook aanzienlijke aanpassingen nodig van ERP systemen en de noodzaak bestaande ERP systemen samen te laten werken over bedrijfsmuren heen. Herontwerp van bedrijfsprocessen over de keten heen voor alle klanten en alle leveranciers tegelijk is in één [golf/keer/actie] niet mogelijk. Dat is ook niet wenselijk. Bedrijven willen bewust differentiëren tussen klanten, marktsegmenten, regio's en vele andere overwegingen. Integratie in de keten leidt dus niet tot convergentie van bedrijfsprocessen bij de afzonderlijke bedrijven in de keten. ERP systemen zijn meestal niet zo flexibel om daar ruimte voor te bieden. Uit bovenstaande blijkt dat er krachten in het spel zijn die elkaar tegenwerken. Vanuit bedrijven speelt de behoefte tot samenwerking over de keten heen en tegelijkertijd de wens tot differentiatie van bedrijfsprocessen. De generatie ERP systemen van rond de eeuwwisseling zijn niet berekend op samenwerking, zijn slecht in staat differentiatie te ondersteunen en overgang van één versie naar een andere is in het geheel niet eenvoudig. De roep vanuit het bedrijfsleven is juist nu in staat gesteld te worden 'voortdurend' te veranderen. Hier ligt een uitdaging voor de toekomst. Diverse ERP leveranciers bieden uitbreidingen op hun pakket aan voor ondersteuning van ketenintegratie.

44

Voorbeelden van ´samenwerking´ in de keten. Een producent van batterijen A levert aan een grootgrutter B. B plaatst zo nu en dan een bestelling bij A. A krijgt onvoldoende zicht op de feitelijke voorraad bij B om zijn planning er effectief op te kunnen afstemmen. Daarom verschaft B aan A inzicht in de voorraad van A´s producten, zodat A beter kan plannen. Een autofabrikant C gebruikt een ERP-systeem (van SAP). De toeleveranciers van onderdelen worden ´gedwongen´ de productieplanning van C te raadplegen en ervoor te zorgen dat de voorraad tijdig aangevuld wordt zodat C altijd voldoende onderdelen op voorraad heeft. Ook wordt toeleveranciers voorgeschreven hoe onderdelen verpakt moeten worden. CRM

Customer relationship management (CRM) ERP pakketten registreren weliswaar klantgegevens, klantorders en betalingsgegevens, maar een pro-actieve benadering van de klant blijkt nauwelijks mogelijk met deze systemen. De uitspraak ´de klant is koning´ geldt zeker in onze tijd. Als nooit tevoren is voor de klant de concurrentie nu slechts ´een muisklik´ van verwijderd. De klant een centrale rol geven in de bedrijfsprocessen is onvermijdelijk. Daar moeten applicaties ondersteuning aan geven, voor meerdere communicatiekanalen (telefoon, internet, fysiek, post, ….). Uitbreidingen van ERP pakketten met CRM-applicaties worden in de jaren voor en na de millenniumwisseling veel toegepast. Meerdere leveranciers hebben zich op deze markt begeven, onder andere SAP, Siebel, Baan.

Electronic-Business

2.4.1.2

Electronic-business

E-Business staat voor electronisch zakendoen, waarbij door gebruik van internettechnologie de belangrijkste processen in een onderneming getransformeerd en verbeterd worden. Denk daarbij aan verbetering van de dienstverlening, stroomlijning van levering en bevoorrading en snellere en effectievere communicatie met de klant. Terugkijkend op de pre-Internet periode kunnen we constateren dat handel in die tijd grote beperkingen kende vergeleken met de huidige mogelijkheden dankzij informatie- en internettechnologie. In het bijzonder geldt dat voor ruimte en tijd. Toen waren klanten vaak aangewezen op (of misschien overgeleverd aan) één of enkele leveranciers. Nu liggen alternatieven op straat bij wijze van spreken. Via Internet kunnen concurrenten opgespoord, prijzen vergeleken en productspecificaties opgevraagd worden. Toen werden orders per post verstuurd. Nu worden orders on-line ingeboekt en bevestigd. In principe zijn er geen geografische beperkingen meer voor een bedrijf dat zich op Internethandel werpt. Ook qua tijd is het geen enkel probleem om 24 u per dag open te zijn. Een bedrijf als Amazon.com heeft ca 5 miljoen boeken te koop zonder deze fysiek in opslag te hebben. Zonder beperkingen in ruimte is elke hoeveelheid boeken acceptabel.

45

Internet heeft gevolgen voor het traditionele, van nature tactisch, verkoopmodel. Bedrijven waren gewend een product, een dienst of informatie aan te bieden en vervolgens de 4 marketing principes toe te passen (prijs, product, promotie en plaatsing) als basis voor hun inspanningen om tot verkoop te komen. E-business speelt zich meer op strategisch niveau af. Het dwingt bedrijven de hele cyclus van marktontwikkeling, vraag oproepen, beantwoording van die vraag, klantondersteuning tot en met klantenbinding als hun product te zien. In tactische modellen zijn deze fasen niet meer dan bijzondere functies die horen bij voor- en nazorg van verkoop. In een strategisch model echter zijn het bouwstenen van de gehele verkoopboodschap. E-business speelt zich af tussen bedrijven onderling, we spreken dan van Business - to - Business (B2B), of tussen bedrijven en consument, ook wel business - to - consumer genoemd (B2C). Voor beide situaties zijn er oplossingen beschikbaar als uitbreiding op de traditionele ERP systemen. Technologisch perspectief

2.5

Ontwikkeling ERP systemen vanuit technologisch perspectief; de noodzaak samen te werken

In deze paragraaf geven we heel in het kort weer welke uitdagingen er liggen voor het integreren van (Beyond-)ERP-systemen. Verder is achtergrondinformatie te vinden in appendix X en op enkele web-sites. Voor het begrip van het volgende hoofdstuk is deze paragraaf niet strikt noodzakelijk. Technologie heeft een belangrijke rol gespeeld bij de ontwikkeling van ERP systemen. Zonder database technologie bijvoorbeeld is integratie op gegevensniveau ondenkbaar. De huidige technologische ontwikkelingen van ERP software zijn opnieuw in de eerste plaats gericht op integratie. Nu echter integratie over heterogene omgevingen voor de uitwisseling van boodschappen. Gedurende de negentiger jaren vond uitwisseling van boodschappen plaats door middel van electronic data interchange (EDI) technologie, een gestandaardiseerde manier van uitwisseling van electronische boodschappen tussen verschillende systemen. Deze technologie biedt de mogelijkheid een beperkt aantal boodschappen batchgewijs uit te wisselen. In feite komt het erop neer dat uitvoer van een applicatie A1 van bedrijf C1 niet geprint wordt maar electronisch aangeboden wordt aan een applicatie A2 van bedrijf C2, waar deze uitvoer gelezen kan worden zonder menselijke tussenkomst. EDI is een zwakke vorm van integratie; de vereiste consistentie controles kunnen alleen lokaal uitgevoerd worden. Daarom wordt het moeilijk inconsistentie tussen databases in bedrijven C1 en C2 op te lossen. Twee mogelijke alternatieven voor EDI lijken de moeite waard: A. sterkere integratie tussen heterogene systemen van een bepaald bedrijf B. applicaties voor E-business, gebruikmakend van het internet. Deze zullen we hieronder beschrijven. Integratie van heterogene systemen

A. Sterkere integratie tussen heterogene systemen binnen een bedrijf vereist allereerst dat een applicatie in het ene systeem objecten uit het andere systeem kan inspecteren alvorens door te gaan met haar eigen processen. Die interactie over heterogene systemen vereist een slimme aanpak,

46

waarbij een soort makelaar (´broker´ in het engels) bemiddelt tussen objecten op deze heterogene systemen. De zgn. Object Request Brokers (ORB) leveren de technologie om deze rol te vervullen. Een vroege standaard voor ORB's is CORBA4 (voor Unix omgevingen). De software die deze soort connecties realiseert heet middleware. Als ORB technologie wordt toegepast in samenhang met klassieke clientserver omgevingen dan treden maar al te gauw prestatie-problemen op. Dat wordt veroorzaakt door het feit dat voor elk verzoek om een object een nieuw applicatieprogramma moet worden opgestart: als applicatie A1 in omgeving E1 vraagt om een object van applicatie A2 uit omgeving E2 dan moet A1 wachten op het resultaat. De oplossing voor dit probleem ligt in het 'state-full' maken van boodschappen, terwijl de applicaties 'state-less' worden. Daarmee bedoelen we dat de boodschap voldoende informatie bevat om een applicatie te herstarten op het punt waar de boodschap verzonden werd. Dan kan de applicatie afsluiten na het versturen van de boodschap en weer opgestart worden na het ontvangen van het resultaat. Dit mechanisme is robuust als de juiste afhandeling van boodschappen en transacties gegarandeerd kan worden. Enterprise Application Integration, XML

De vereiste technologie voor integratie door middel van ORB en/of 'state-full' boodschappen wordt nu aangeboden door zogenaamde Enterprise Application Integration (EAI) software-suites. Zowel ERP leveranciers als onafhankelijke systeem integrators leveren EAI oplossingen. Een belangrijke ontwikkeling is Extented Markup Language (XML), een recente standaard voor 'zichzelf beschrijvende' boodschappen. Het zelfbeschrijvende karakter staat 'state-full' boodschappen toe. B. De tweede recente ontwikkeling houdt verband met electronic commerce/business. De term E-Business verwijst naar een groot scala van bedrijfsapplicaties die aangeroepen kunnen worden via het internet. Er is een belangrijk verschil met EDI: E-Business heeft te maken met gebruik van applicaties, die elders op een computer aangeboden worden, door gebruikers (mens-computer communicatie), terwijl EDI batchgeorienteerde communicatie betreft tussen twee meestal geografisch gescheiden systemen, die bovendien heterogene programmatuur gebruiken (computer-computer communicatie). Het is echter niet ongebruikelijk beide toepassingen in een bedrijfsproces te gebruiken. Zo kan een klant via een verkoop-website bestellingen doen die door de leverancier middels een EDI bericht bevestigd worden. Voor E-business is in grote lijnen hetzelfde type technologie nodig als voor EAI suites. De ontwikkelingen onder A en B geschetst moeten op den duur leiden tot open systemen die op 'eenvoudige' wijze met elkaar kunnen communiceren en data uitwisselen. Dan is de weg open om componenten van verschillende leveranciers te koppelen tot een goed passende bedrijfsbrede software ondersteuning.

4

zie ook www.omg.org, www.corba.org en appendix X

47

2.6

Samenvatting

Dit hoofdstuk stond in het teken van Enterprise Information Systems/Enterprise Resources Planning. Na verkenning van het begrip ERP zijn afwegingen voor gebruik van standaardpakketten en maatwerk aan de orde geweest. De functionaliteit van zulke erp-systemen is aan de hand van een business control model kort toegelicht en daarbij zijn kanttekeningen gemaakt bij het begrip ´bedrijfsbrede ondersteuning´. De centrale rol van het begrip integratie in EIS/ERP systemen is aan de orde gesteld, alsmede voor- en nadelen van gebruik van erp-systemen. Tenslotte zijn ontstaan en ontwikkeling van deze systemen belicht vanuit bedrijfskundig en technologisch perspectief. In het volgende hoofdstuk zullen we met name de invoering en het gebruik van zulke systemen bespreken.

2.6.1.1 1. 2. 3. 4. 5. 6.

Zelftoets Wat is de betekenis van het woord integratie in de context van erp-systemen? Noem nog enkele bedrijfsfuncties die in het bedrijfsbesturingsmodel van figuur 1 niet voorkomen. Noem 2 argumenten op grond waarvan gebruik van EIS/ERP systemen van groot belang is voor bedrijven. Noem een voor- en een nadeel van gebruik van ERP pakketten die nog niet genoemd zijn in de betreffende paragraaf. Noem enkele situaties waarin maatwerkoplossingen de voorkeur verdienen boven standaardpakketten. Bij ketenintegratie kan een producent X bij wijze van spreken samenwerken nastreven vanaf de leveranciers van zijn leveranciers tot de klanten van zijn klanten. Noem zowel vanuit bedrijfskundig als vanuit technologisch perspectief voorbeelden van belemmerende factoren.

Terugkoppeling Uitwerking van de opgaven Opgave 1 Bij het inkoopproces doen zich bijvoorbeeld de volgende samenhangende processen voor. Na het plaatsen van een order bij een leverancier (eventueel voorafgegaan door een offertetraject), komen op de afgesproken datum de goederen bij het magazijn. Het magazijn is op de hoogte van de levering (artikelen, aantallen). Daar worden deze gecontroleerd (aantallen, kwaliteit) en daarna opgeslagen. De ontvangsten worden geregistreerd en eventuele claims worden opgesteld. Tenslotte wordt de factuur ontvangen en na controle aangepast of vrijgegeven voor betaling. Opgave 2 Voor de conversie van data uit het oude systeem is vrijwel altijd maatwerk nodig. Dat geldt ook voor koppeling van het nieuwe systeem aan oudere systemen, die nog dienst blijven doen. Ook kan bij maatwerk nog opgemerkt worden dat inspanning in de vorm van maatwerk op het pakket weliswaar niet hoeft plaats te vinden, maar in ruil daarvoor is de nodige inspanning vereist om het flexibele 48

brede pakket klantspecifiek te maken door middel van de al eerder genoemde parameterinstellingen. Klaar voor gebruik gaat voorbij aan de vaak forse inspanning die nodig is voor de invoering en scholing van medewerkers. Opgave 3 Bij inkoop is het noodzakelijk informatie beschikbaar te hebben van de planningsafdeling (ingeplande productie en de daarmee samenhangende materiaalbehoefte), van het magazijn (voorraden) en van leverancierrelatiebeheer (leveringscontracten). Het magazijn heeft bij ontvangst en inspectie de inkoopgegevens nodig. Bij claims en reclame zullen ordergegevens, ontvangst en inspectiegegevens beschikbaar moeten zijn bij de afdeling relatiebeheer. Opgave 4 Technologisch gezien is het opnemen van nieuwe applicaties in een groter geheel (de moeder applicatie) niet altijd even eenvoudig. Daarbij kan bijvoorbeeld het verschil in gebruikte DBMS (database management system, bijv. Oracle, DB2) een rol spelen. Het ene DBMS biedt meer mogelijkheden dan een ander, waardoor er beperkingen kunnen ontstaan bij integratie. Ook kan het platform waarop de software ontwikkeld is tot beperkingen lijden. Omzetten van bijv. software op Unix gebaseerd naar software dat op Windows platformen moet werken leidt tot grote hoeveelheden werk (herschrijven van sofware). Tenslotte kan ook nog de ontwerpmethodologie en de gebruikte programmeertaal voor complicaties zorgen. Is de in te bouwen applicatie niet object georienteerd ontwikkeld en de moederapplicatie wel, dan kan dat tot forse complicaties leiden in ´het aan elkaar knopen´ van beide applicaties.

Uitwerking van de zelftoets 1. Bij ERP systemen gaat het bij integratie vooral om de samenhang van bedrijfsprocessen. De activiteiten van medewerker B worden beïnvloed door die van medewerker A omdat beide activiteiten met elkaar samenhangen (volgordelijkheid, tijdigheid, kwaliteit); medewerker C op zijn beurt is bij zijn werkzaamheden weer afhankelijk van werkzaamheden die door B uitgevoerd worden. Medewerkers zijn veelal in verschillende afdelingen werkzaam. De samenhang/integratie zit in de gezamenlijke werkzaamheden die één bepaald proces ondersteunen; dat proces gaat voor dwars door afdelingen heen. 2. Bijvoorbeeld Marketing, Management, Financieel beheer. 3. Hierbij zou je onderscheid moeten maken naar bedrijfsgrootte. Het midden en kleinbedrijf heeft minder belang bij applicaties die wereldwijde planning mogelijk maken, om maar iets te noemen, terwijl dat juist een factor van belang is voor grote, wereldwijd opererende bedrijven. Voor beide categorieën gelden zeker volgende argumenten: a. Integratie van processen en gegevens (van orderinvoer tot en met de financiële afhandeling van de orders)

49

4.

5.

6.

b. Internettoepassingen (bijvoorbeeld voor inkoop- en verkoopfuncties) vereisen een betrouwbaar informatieen transactieverwerkend systeem als backbone. Voordeel: erp biedt mogelijkheden voor ketenintegratie; klanten en leveranciers kunnen bij elkaar in de keuken kijken Nadeel: een erp pakket biedt veel overbodige functionaliteit. Dat vergt ook beheer. In de tekst is al genoemd dat bedrijven, waarin de procesgang sterk afwijkt van wat gebruikelijk is in de betreffende industrietak, noodgedwongen aangewezen zijn op maatwerk. Ook kan een bedrijf voor maatwerk kiezen omdat zelfs mineure aanpassingen in bedrijfsprocessen toch ongewenst zijn vanuit concurrentieoogpunt. Het onderscheidend vermogen zou erdoor kunnen verdwijnen. Tenslotte kan maatwerk overwogen worden om als één van de eerste in de industrietak/branche een breed geïntegreerd pakket beschikbaar te hebben dat als referentie en mogelijk zelfs als standaardpakket gaat dienen voor andere bedrijven in dezelfde branche. In zo´n geval kunnen ontwikkelkosten terugverdiend worden (hetzij door lagere ontwikkelkosten, hetzij door dividenden uit latere verkopen. Producent X kan zijn leveranciers ´naar zijn pijpen laten dansen´, bij wijze van spreken. X zal dan vanuit bedrijfskundig perspectief standaardisering (wijze van uitvoering en aanlevering) en uitwisselbaarheid van goederen voorschrijven. De leveranciers worden daarin belemmerd in hun vrijheid. Vanuit technologisch perspectief kunnen ketendeelnemers met goed functionerende systemen gedwongen worden hun informatievoorziening en planning ´open te stellen´ voor X. Dat zou kunnen betekenen dat hun systemen aangepast moeten worden of mogelijk zelfs vervangen om X ter wille te zijn. Verder zullen zijn klanten onafhankelijkheid en vrijheid van keuze hoog in het vaandel hebben en daarom zich niet te sterk willen binden aan X.

Literatuurlijst: 1. Bertrand, Wortmann en Wijngaard: Productiebeheersing en material management, Stenfert Kroese 1990. 2. Ballou: logistiek management, Academic Service 1992. 3. Koedijk en Verstelle: ERP in bedrijf, Tutein Nolthenius 1999. 4. Bakker et. al. : logistiek management, Thieme Meulenhof 1997. 5. Geraards en Igel: Flexibiliteit in logistiek, Samson.

50

Inhoud H3:Implementatie en migratie van ERP/ Het logistiek domein 3.1 Introductie 3.2 Implementatie van ERP systemen 3.3 Gebruik van modellen bij invoer van EIS/ERP 3.4 Logistiek kader 3.4.1 Inleiding 3.4.2 Discrete productie 3.4.3 Primaire processen 3.4.4 Stuklijst 3.4.5 Routering 3.4.6 Goederenstroom 3.4.7 Bedrijfsbesturing/Klant Order Ontkoppel Punt 3.5 Samenvatting Zelftoets Terugkoppeling 1 Uitwerking van de opgaven 2 Uitwerking van de zelftoets

51

3

3.1

Implementatie en migratie van ERP/ Het logistiek domein

Introductie

In het vorige hoofdstuk zijn EIS/ERP systemen geïntroduceerd als context voor ´enterprise modeling´. In dit hoofdstuk willen we in de eerste plaats stil staan bij implementatie en migratie van ERP systemen. Dat doen we omdat enterprise modeling nauw samenhangt met juist de invoering en het gebruik van zulke systemen. Het invoeren van ERP systemen is nooit eenvoudig geweest. Daar zijn meerdere redenen voor aan te voeren. In deze paragraaf noemen we een aantal factoren die een rol spelen. Tenslotte zullen we in dit hoofdstuk het logistieke domein kort beschrijven, omdat in latere hoofdstukken vaak gebruik gemaakt zal worden van modellen die betrekking hebben op logistieke concepten. Leerdoelen Na het bestuderen van dit hoofdstuk en het maken van de opdrachten wordt verwacht dat u - belangrijke aandachtspunten weet te noemen bij de invoering van EIS/ERP systemen, vanuit verschillende perspectieven - belangrijke risicofactoren weet te benoemen die een rol spelen bij het invoeren van EIS/ERP - referentiemodellen en de rol die deze spelen bij implementatie van EIS/ERP systemen kunt beschrijven - belangrijke concepten uit de logistieke wereld weet te benoemen en te beschrijven.

herontwerp

3.2

Implementatie van ERP systemen

Invoering van ERP gaat veelal gepaard met herontwerp van bedrijfsprocessen. In paragraaf 2.4 is dat in relatie gebracht tot integratie van leverancierketens. Echter, de invoering binnen een bestaand bedrijf met haar bestaande bedrijfsprocessen, leidt ook vaak tot aanpassingen van deze processen. Dat kan te maken hebben met al aanwezige knelpunten, in bijvoorbeeld de orderafhandeling. Bij de invoering van ERP kan dat dan tegelijkertijd ´meegenomen´ worden. Meestal heeft het herontwerpen van bedrijfsprocessen echter te maken met de in een ERP systeem beschikbare procesmodellen (referentiemodellen), waar men zich dan aan gaat spiegelen. Later in dit hoofstuk zullen we nader op het gebruik van deze modellen ingaan. Reorganisatie is vaak het gevolg, met name om functionele barrières in een organisatie te slechten. Dat compliceert het invoeren in niet geringe mate. Afgezien van bovengenoemde complicerende factor zijn er meerdere factoren die het invoeren van een ERP systeem kunnen doen falen. In dit verband is een onderzoek van KPMG noemenswaard (zie “ERP in bedrijf”). Onder 252 bedrijven werd navraag gedaan welke oorzaken ten

52

grondslag lagen aan het mislukken van ERP invoeringstrajecten. Figuur 5 geeft een aardig beeld van deze oorzaken. Op bijv. de omvang van het traject (benodigde inspanning en consequenties) verkijkt men zich in 2% van de gevallen. Onbekendheid met scope (reikwijdte) en complexiteit, is met 17% al een flinke risicofactor. Wat vooral opvalt: - slechts in 7 % van de onderzochte gevallen was ondeugdelijke software of hardware de aanleiding tot het falen van het project - falen was voor bijna 50 % te herleiden tot slecht projectmanagement en onduidelijke doelstellingen. Omvang

Anders

5%

2%

Verkeerde hardware of software

7% Onbekendheid met scope en complexiteit

Gebrekkig Project Management 32%

17%

Gebrek aan communicatie 20% Geen doelstellingen 17%

Uit Uiteen eenKPMG KPMGonderzoek onderzoeknaar naar252 252bedrijven bedrijven

Figuur 4. Faalfactoren Opgave 1 Welke algemene conclusie lijkt uit figuur 4 naar voren te komen? Het wel of niet slagen van ERP implementaties heeft op grond van het bovenvermeld onderzoek nauw te maken met de manier waarop een implementatie van ERP-systemen aangepakt en bestuurd wordt. Men wil de invoering van een ERP systeem natuurlijk goed gestuurd laten verlopen. Vier invalshoeken van organisatie

In “ERP in bedrijf” worden vier invalshoeken van een organisatie genoemd die daarbij van belang zijn, elk met een eigen belang om invoering van ERP succesvol te laten verlopen: organisatie & management, processen & diensten, mensen & cultuur en IT systeem & infrastructuur. In blok 2 zullen we organisaties vanuit 7 invalshoeken bekijken. We voegen dan bijvoorbeeld product en hulpmiddelen/bronnen als invalshoeken toe. In deze paragraaf beperken we ons tot bovengenoemde vier invalshoeken, die een rol spelen bij het invoeren van een ERP systeem.

53

De invalshoeken die in figuur 45 aangegeven zijn worden hierna besproken. Naast de voor de hand liggende invalshoeken processen & diensten en IT systeem & infratructuur zijn er organisatie & management en mensen & cultuur. Alle invalshoeken moeten voortdurend in de gaten gehouden worden om tot een goede implementatie van een ERP pakket te komen. We noemen een aantal aandachtspunten per invalshoek. Organisatie & Management: - inbedding van nieuwe werkwijze in de structuur - benodigde managementinformatie; hoe vindt besluitvorming plaats. IT systemen en infrastructuur: - gewenste applicatie architectuur en gegevens architectuur - noodzakelijke IT beheersorganisatie. Mensen & cultuur: - hoe wordt de organisatie ingericht - welke competenties zijn nodig - hoe vindt competentie ontwikkeling plaats. Processen & diensten: - werkwijze van processen - wat zijn de grenzen - welke relaties bestaan er tussen processen.

organisatie & management

Performance

IT systemen & infrastructuur

processen & diensten

mensen & cultuur

Figuur 5. Vier Invalshoeken Opgave 2. Schets mogelijke gevolgen van het negeren van de invalshoek ´Medewerkers/Cultuur´. Zie “ERP in bedrijf” onder redactie van A. Koedijk en A. Verstelle. Uitgegeven bij Tutein Nolthenius)

5

54

Falen van implementatie van ERP systemen heeft afgezien van bovengenoemde faalfactoren, echter ook te maken met dieper liggende oorzaken, die direct met de aard van ERP-software te maken hebben. Deze zijn aan te duiden met de term intrinsieke complexiteitsfactoren. We sommen een aantal zaken op: - De brede functionaliteit, het grote aantal op elkaar inwerkende processen, legio klantwensen, en het grote aantal databasetabellen leiden samen tot een grote mate van complexiteit. - Standaardsoftware is van nature geparametriseerd. Het zetten van de juiste parameters is vaak omslachtig omdat de vertaling van vereiste bedrijfsfuncties naar parameterwaarden niet zo eenvoudig is. - Nieuwere versies van de software zijn om allerlei redenen niet compatibel met oudere versies. Dientengevolge kan de migratie van de ene versie naar de andere een aanzienlijke inspanning vereisen. Ook leidt het gebruik van verschillende versies van dezelfde software in dezelfde bedrijfsomgeving tot vrijwel dezelfde integratieproblemen als gebruik van software van verschillende leveranciers. Opgave 3 Geef een mogelijke oplossing voor dit probleem. Multi-site is een term die gebruikt wordt om aan te geven dat een enterprise haar aktiviteiten uitvoert op meerdere lokaties.

-

Multi-site implementaties leveren de nodige complicaties op. Deze implementaties kunnen op meerdere manieren uitgevoerd worden. We bespreken de uitersten. 1. Alle sites worden gerepresenteerd in een gemeenschappelijk “enterprisemodel” en er wordt één gezamenlijke database gecreëerd die alle sites omvat. Zo werken de meeste financiële applicaties in grote bedrijven, maar ook geavanceerde planningsystemen voor ´supply chains´ (ketens). Een belangrijk nadeel van deze oplossing is dat alle vestigingen dezelfde versie van alle software moeten gebruiken. Bovendien kan de c/s architectuur leiden tot prestatieproblemen. 2. Elke vestiging afzonderlijk heeft een eigen ERP systeem. Belangrijk nadeel van deze oplossing is dat de betreffende ERP systemen moeten kunnen samenwerken. En daar zijn ze nog onvoldoende op berekend.

Leveranciers van ERP software hebben op verschillende manieren geprobeerd het implementatieproces (met name de parameterinstellingen) te ondersteunen. Te noemen zijn wizards en expert systemen. Maar de oorsprong van het probleem ligt in het feit dat bedrijfswensen gespecificeerd zijn in een natuurlijke taal terwijl parameters het gedrag van dit soort systemen op laag niveau beïnvloeden. Daarom worden talen en gereedschappen voor het modelleren van de 'enterprise' veel gebruikt om bedrijfsmodellen te maken. Het doel daarbij was een 'soepele' overgang te bewerkstelligen van bedrijfsmodel naar een werkend softwaresysteem. De voortgang die daarbij geboekt is verschilt van leverancier tot leverancier. Zo wordt multi-site onvoldoende afgedekt door de huidige enterprise modeling.

55

3.3

Referentiemodel Bedrijfsbesturings model & procesmodel

Gebruik van modellen bij invoer van EIS/ERP

Het invoeren van EIS/ERP vergt zoals eerder betoogd, een enorme inspanning. Bij diverse implementaties is door leveranciers en implementatiepartners in de loop der jaren een hoog niveau van kennis over diverse branches opgebouwd. Voor diverse branches zijn met behulp van de opgedane expertise modellen opgezet, ook wel branche- of referentiemodellen genoemd. Deze beschrijven de bedrijfspraktijk voor een bepaalde branche tot in detail. De referentiemodellen van Baan maken daarbij gebruik van “business control models”/bedrijfsbesturingsmodellen (zie de voorbeelden in fig. 1 en 2 van hoofdstuk 2) en procesmodellen (zie het voorbeeld in fig. 6 voor één van de talrijke processen). De “business control models” geven de belangrijke bedrijfsfuncties weer (het ´wat´). Voor elk van de bedrijfsfuncties is in processchema´s tot in detail aangegeven welke stappen gezet moeten worden om de betreffende bedrijfsfunctie te vervullen (het ´hoe´) In fig. 6 is een beperkt onderdeel van het inkooproces weergegeven. Zo valt uit de figuur af te lezen dat als eerste stap (aktiviteit 20) “check supplier feasibility” uitgevoerd moet worden. In deze stap kan bijvoorbeeld nagegaan worden of de producten op tijd leverbaar zijn, maar ook de kwaliteit van product en levering kan daarbij aan de orde zijn. Vervolgens wordt de mogelijkheid geboden (keuzebox 40) een bestaande order te raadplegen (aktiviteit 60). Daarna wordt de keuze (keuzebox 80) geboden een bestaande order aan te passen (aktiviteit 100) of een nieuwe order in te voeren (aktiviteit 120). Aktiviteit 100 is een zgn. genest proces, meerdere processtappen ´hangen´ hieronder in een afzonderlijk gespecificeerd prodesschema (hier niet opgenomen). Met de business control models en de processchema´s kunnen voor een bepaalde branche de belangrijkste functies en processen vastgelegd worden en kunnen ´best practice´ voor die branche vertegenwoordigen. Het configureren van de software voor een 'standaard'-omgevingen is vanzelfsprekend veel eenvoudiger dan voor een nieuwe bedrijfstak, waar de processen fors afwijken van de tot dan toe bekende.

56

fig. 6 Processchema als voorbeeld

57

Terzijde/intermezzo: in figuur 5 is gebruik gemaakt van petri net diagrammen, in enigszins aangepaste vorm, voor het beschrijven van een proces. Het gaat hier om een deel van een inkoopproces. De Petri net diagramtechniek leent zich goed voor het modelleren van processen, gebruikmakend van slechts enkele bouwstenen: rechthoeken, vierkanten, cirkels en pijlen. Aktiviteiten worden weergegeven met rechthoeken (al dan niet genest, zie aktiviteit 100), keuzemogelijkheden met vierkantjes en statussen met cirkels. De pijlen verbinden de bouwstenen Het diagram is afkomstig uit de Dynamic Enterprise Modeler (DEM) van Baan. Icoontjes zijn specifiek voor DEM en geven aan dat de aktiviteit handmatig (M), of softwarematig (het connectorteken) verloopt; de T geeft aan dat er tekst gekoppeld is aan de rechthoek/het vierkant; het sleutel-incoontje duidt op een ´toolbox´ met print- en displayfuncties, die behulpzaam kunnen zijn bij reviews. De getallen zijn alleen van belang in de context van DEM en doen hier niet terzake. Zie ook: http://tmitwww.tm.tue.nl/staff/wvdaalst/Petri_nets

Bedrijven die in een later stadium over gaan tot aanschaf van een EIS/ERP systeem, kunnen gebruik maken van voor hun bedrijfstak ontworpen referentiemodellen. Opgave 4 Waardoor kan het gebruik van referentiemodellen tot versnelde implementatie leiden? Opgave 5 In deze paragraaf is sprake van bedrijfsbesturingsmodellen en procesmodellen. Voor de invoering van een ERP-systeem missen we nog modellen van andere, wezenlijke invalshoeken. Noem er twee. Naast de twee genoemde modellen, waarin hoofdzakelijk het hoe en wat van een bedrijf aan de orde gekomen is, zijn er invalshoeken die natuurlijk ook meegenomen moeten worden bij de invoering van een ERP-systeem. Deze invalshoeken (bijvoorbeeld besturing, organisatie, medewerkers) zijn niet standaard onderdelen van referentiemodellen. Van een enterprise-model zouden we dat wel willen eisen. In blok 2 zullen meer invalshoeken aan de orde komen om zo voor een “enterprise” tot een meer omvattend model te komen. Tot slot van deze paragraaf nog even een enigszins speculatieve blik op de toekomstige ontwikkelingen. In een eerdere paragraaf hebben we besproken dat differentiatie van bedrijfsprocessen over de keten heen een belangrijke trend is. Ook is beschreven dat eenvoudiger overgang van kleinere softwareonderdelen naar nieuwere versies nodig is voor beheersbare ERP implementaties en de broodnodige flexibiliteit.

Executeerbare bedrijfsspecificaties

Het mogelijke resultaat van deze twee bewegingen zal waarschijnlijk zijn dat superieure enterprise models in de toekomst een belangrijke rol gaan spelen. Gedifferentieerde bedrijfsprocessen zullen toch in een zodanige vorm beschreven moeten kunnen worden, dat mens èn computer (software) deze kunnen lezen en interpreteren. We zijn echter nog een hele stap verwijderd van 'executeerbare' bedrijfsmodellen en bedrijfsspecificaties. Deze moeten door de mens op intuïtief eenvoudige wijze aan te passen zijn aan de snel veranderende omgeving en door machines/computers eenvoudig om te zetten naar

58

passende software oplossingen ('met een druk op de knop'). Dat beogen enterprise models nu net te doen. Dat blijft voorlopig nog toekomstmuziek. Maar ´er zit muziek in´.

3.4 Logistiek kader 3.4.1 Inleiding ERP pakketten hebben hun oorsprong vooral in de logistieke sector liggen. Mede om die reden zullen we in het vervolg van de cursus voorbeelden ontlenen aan de wereld van de logistiek. In deze paragraaf belichten we de belangrijkste begrippen uit de logistiek waarmee we tijdens de cursus in aanraking zullen komen. Eerst geven we aan dat we ons beperken tot discrete productie omgevingen. De belangrijke primaire processen in zo´n productieomgeving worden vervolgens besproken. Dan komen stuklijst, routering, goederenstroom en bedrijfsbesturingsmodellen aan de orde. Discrete productie

3.4.2

Discrete productie

Fabrieken houden zich bezig met het produceren van allerlei producten. We zullen ons beperken tot zogenaamde discrete producten, die per stuk te bewerken en te gebruiken zijn. Het kan hierbij gaan om eindproducten die voor de consument bestemd zijn of om componenten/halffabrikaten die door weer andere fabrieken bewerkt worden tot een eindproduct. Niet discrete productie treffen we aan in de zogenaamde procesindustrie. Daar worden bijvoorbeeld chemicaliën en voedingsstoffen bereid. Primaire processen

3.4.3

Primaire processen

Als meest wezenlijke processen binnen een productiebedrijf onderscheiden we in de eerste plaats de fysieke productie en daarnaast bijvoorbeeld: - van order tot uitlevering/facturering, vooral op de administratieve processen gericht - van behoefte tot planning - van 'zand tot klant', of van 'korrel tot borrel'. Aan de hand van onderstaande figuur (fig. 7) zullen we de belangrijkste functies binnen een productiebedrijf bespreken. Het is geen totaal plaatje, er ontbreken functies (financiën bijvoorbeeld), maar het leent zich goed voor een globale beschrijving van de belangrijkste bedrijfsprocessen. Het plaatje is een model van de werkelijkheid, die vanzelfsprekend veel complexer is dan in dit plaatje weergegeven kan worden. Het klantorder ontkoppelpunt wordt later in dit hoofdstuk besproken. In een ERP-systeem kunnen de te noemen functies bij uitstek ondersteund worden. De integratieve aspecten (zie hoofdstuk 2) komen tot hun recht.

59

We lopen stap voor stap de processen door. Hoofd produktie planning Inkoop orders

HPP

Inkoop orders Inkoop

Afgeleide vraag planning

4

3

Vraagvoorspelling

Produktieorders eindprodukten

Verkoop orders

Klantorder ontkoppelpunt

produktieorders onderdelen

5

2

Inkoopartikelen en grondstoffen

Verkoop

6

Verkoop orders

Productie Eindprodukten

HPP = hoofdproduktieplan

Distributie

7

Uitgeleverde goederen

Figuur 7 Bedrijfsfuncties en primaire processen. 1.

2. 3.

60

Als een verkooporder geplaatst wordt, dan kan deze bij voldoende voorraad direct uitgeleverd worden. Zo niet, dan wordt bij de periodieke planning (3 en 4) rekening gehouden met de geboekte orders die nog uitgeleverd moeten worden. Periodiek (bijvoorbeeld jaarlijks) worden de verkoopprognoses opgesteld. Ook deze gegevens worden meegenomen bij de periodieke planning. Periodiek wordt een hoofdproductieplan (HPP) opgesteld/bijgewerkt. Van de eindproducten wordt op basis van verwachte vraag een productieplan gemaakt/berekend. Hierin staat aangegeven wanneer en in welke aantallen de eindproducten geproduceerd moeten worden om aan de verwachte vraag te kunnen voldoen. Bij het berekenen van de aantallen te produceren eindproducten wordt rekening gehouden met: - nog uitstaande orders - voorraad - veiligheidsniveau van voorraad - geblokkeerde voorraad - uitstaande bestellingen van onderdelen - geplande ontvangsten uit productie. De uitvoer van het HPP-proces zijn concrete productieorders en mogelijk ook inkooporders van bijzondere onderdelen (bijvoorbeeld onderdelen met lange levertijd). Ook moeten bij dit proces de consequenties voor de productiemiddelen doorgerekend worden. Dat kan in dit stadium slechts op globaal niveau gebeuren. HPP is in het algemeen een lange termijnplanning.

1

Intermezzo. Een hoofdproductieplan voor een bepaald product zou in eenvoudige vorm er zo uit kunnen zien: Week 31 32 33 34 Verwachte afzet 150 100 150 150 Gepl. Invent. 10 10 10 10 Te produceren 160 100 150 150 Hierbij is uitgegaan van inventarisniveau 0 bij aanvang van week 31. In die week moeten er dus 150 stuks geproduceerd worden om aan de verwachte vraag te kunnen voldoen en nog eens 10 om een minimum inventarisniveau van 10 te kunnen aanleggen. Natuurlijk gaat dat in de practijk een stuk lastiger. Er moet dan bijvoorbeeld ook rekening gehouden worden met al geregistreerde orders en de hoeveelheid die uit productie komt. 4.

5.

6.

7.

61

Afgeleide vraag planning (AVP) gebruikt het HPP om op basis daarvan na te gaan welke onderdelen/grondstoffen wanneer beschikbaar moeten zijn voor het produceren van de eindproducten op de data die in het HPP opgenomen zijn. Die onderdelen kunnen maak- of koopartikelen/grondstoffen zijn. Afhankelijk van het niveau van de beschikbare voorraad worden eventueel inkoop- en productieorders gegenereerd voor koop- resp. en maakartikelen. Voor maakartikelen wordt de benodigde personeels- en machinecapaciteit doorgerekend. Ook hier geldt dat rekening gehouden wordt met al geplande ontvangsten uit inkoop en productie en eerdere allocaties van artikelen op productieorders. De samenstelling/opbouw van de eindproducten moet bekend zijn; welke grondstoffen/onderdelen zijn nodig en wat zijn de lever- of productietijden van onderdelen. AVP is een korte termijnplanning voor de productie van maakartikelen die als onderdeel gebruikt worden in het eindproduct. De inkoopafdeling krijgt onder andere orders te verwerken die door de planningsafdelingen gegenereerd zijn. Prijzen en levertijden worden onderhandeld met leveranciers. Op de afgesproken afleverdata worden de goederen ontvangen, geïnspecteerd en geteld voordat ze in het magazijn worden opgeslagen. De productieafdeling laten we voor onze beschrijving zowel de productieplanning als de werkvloerproductie uitvoeren. Voor de planning van de productie staat eventuele softwarematige ondersteuning ter beschikking. Alle orders voor de komende korte termijn (dagen, een week) worden ingepland en verdeeld over de beschikbare capaciteiten (medewerkers, machines). Werkbonnen (welke bewerkingen op welke machines, welke aantallen) worden opgesteld en goederen worden uit het magazijn gehaald. Uiteindelijk vindt de feitelijke productie plaats en worden de goederen na een eventuele test/inspectie in het magazijn opgeslagen. De distributieafdeling draagt zorg voor uitlevering van de goederen. De verkooporders die uitgeleverd moeten worden bepalen de aantallen en data voor levering en transport. De artikelen worden uit het magazijn gehaald, verpakt en verscheept.

Financiële en magazijnfuncties zijn voor de eenvoud grotendeels buiten dit model gehouden. Stuklijst

3.4.4

Stuklijst

In de vorige paragraaf (punt 4) is aan de orde geweest dat voor het vaststellen van de benodigde onderdelen van een eindproduct de samenstelling ervan bekend moet zijn. Hier bespreken we een stuklijst als model om die informatie weer te geven. In fig. 8 zijn de onderdelen van een bureaustoel in een hiërarchisch model weergegeven. De getallen bij de onderdelen geven aan hoeveel exemplaren of hoeveel meter van het betreffende onderdeel/materiaal in één bureaustoel verwerkt is. Stuklijst Bureaustoel Zitting 1 Zitframe 1

Bekleding 0.5

Onderstel 1 Wiel 5

Frame 1

Rugleuning 1 Rugframe 1

Armsteun 2

Bekleding 0.3

Figuur 8 Voorbeeld van een stuklijst Voor feitelijk gebruik bij planning is dit model niet geschikt. Daarvoor heb je informatie nodig over artikelnummers, levertijden, is het een maak- of koopartikel etc. Een andere weergave van de stuklijst zien we in tabel 1. Oudernr

Volgnr kindnr Hoeveelheid 1 7419 5612 2 7453 1 5612 3 7832 1 5612 4 7579 2 7419 1 3265 1 7419 2 8113 0.5 7453 1 7291 1 7453 2 6439 5 7832 1 3478 1 7832 2 8113 0.3 Tabel 1: een andere weergave van een stuklijst. Koppelen we deze tabel met de artikeltabel (tabel 2), waarin artikelnummer, omschrijving, eenheid en de prijs (van de koopartikelen) opgenomen zijn, dan kunnen we de stuklijst reconstrueren. Immers, ouder 5612, de bureaustoel, heeft kinderen 7419 (zitting, 1x), 7453 (onderstel, 1x), 7832 (rugleuning, 1x) en 7579 (armsteun, 2x). Elk van de kinderen van zelf weer als ouder in tabel 1 genoemd zijn. Door combinatie van beide tabellen is te achterhalen wat de materiaalkosten zullen zijn voor de betreffende bureaustoel.

62

Opgave 6 Ga na dat de materiaalkosten van de bureaustoel 289.594 bedragen. Artikelnummer 5612 7419 7453 7832 7579 * 3265 * 8113 * 6439 * 7291 * 3478 * Tabel 2: artikeltabel.

Omschrijving Bureaustoel Zitting Onderstel Rugleuning Armsteun Zitframe Bekleding Wiel Frame Rugframe

Eenheid Stuk Stuk Stuk Stuk Stuk Stuk M(eter) Stuk Stuk Stuk

Prijs

24.67 59.76 27.58 5.32 89.22 42.61

Voor het eenvoudig vaststellen uit welke onderdelen een product bestaat, is het hiërarchisch schema (fig. 8) toereikend. Willen we bovendien materiaalkosten berekenen, dan heb je de gegevens uit tabel 2 ook nodig. Voor het berekenen van de productietijd van de bureaustoel is aanvullende informatie nodig. Opgave 7 Welke informatie heb je minimaal nodig om de productiekosten en productietijd (per eindartikel) te kunnen berekenen? Routering

3.4.5

Routering

Materialen/onderdelen ondergaan een reeks bewerkingen voordat er sprake kan zijn van een eindproduct. Voorbeelden van bewerkingen zijn zagen, buigen, lassen, assembleren en spuiten. Daarbij zullen veelal machines en mensen betrokken zijn. In een routering wordt voor een bepaald product aangegeven welke bewerkingen uitgevoerd moeten worden, in welke volgorde, hoeveel tijd een bewerking vergt, welke hulpmiddelen daarbij nodig zijn en waar in de fabriek (werkplaats) de bewerkingen plaatsvinden. Onderstaande fig. 9 beschrijft een routering voor een concrete situatie. Een desktop computer heeft een behuizing (desktop basis). Voor de productie worden 3 werkplaatslokaties gebruikt (050, 100 en 200). Elk van die lokaties is voorzien van evt. machines en hulpmiddelen om bepaalde bewerkingen te kunnen uitvoeren. De hier genoemde gegevens zijn voldoende om vast te stellen hoeveel tijd de productie van de behuizing in beslag neemt, afgezien van omsteltijden.

63

artikel: 3100 Desktop Basis

Routerings Code: 001

werkplaats 050 taken: 085 090 snijden frezen

Artikel: Routing Code: Bewerking 10 20 30 40

werkpl 200 taken: 210 buigen

werkpl 100 taken: 110 boren

Desktop Basis 1 Taak 085 090 110 210

Werkplaats 050 050 100 200

Machine 080

Opzet 0.00 0.00 0.08 0.25

Prod. snelh 60/Hr 90/Hr 120/Hr 30/Hr

Figuur 9. Routering van een product Goederenstroom

3.4.6

Goederenstroom

De goederenstroom binnen een bedrijf wordt gestuurd door diverse processen. Enkele daarvan zijn we al tegengekomen bij distributie (voor uitlevering van producten) en bij inkoop (voor ontvangst en inspectie van de goederen). De belangrijkste controle functies voor de besturing van de goederenstroom zijn de magazijn- en de productiefunctie. Deze functies bepalen in grote mate het 'verhaal/de gebeurtenissen' van de goederen. Daarbij gaat het onder andere om het opslaan van de onderdelen/grondstoffen, het tijdig bezorgen van de onderdelen op de werkvloer voor fabricage en het bewerken van de goederen. Figuur 10 laat een voorbeeld zien van (een model van) de goederenstroom binnen een productiebedrijf. In de figuur zijn ook de controlefuncties (rechthoekjes boven de goederenstroom) opgenomen. Toelichting: De ontvangst en inspectie van goederen wordt gestuurd door “ontvangst en inspectie besturing”. De opslag van ruw materiaal wordt gestuurd door de inslagfunctie, voorraadbeheer en uitslagfunctie. Elke bewerking wordt aangestuurd door een productiefunctie. Na diverse bewerkingen en tussenliggende opslagpunten worden tenslotte goederen uitgeleverd, waarbij sturing optreedt vanuit magazijnfuncties. Receipt. Control (Purchase)

Transport Leveranc

Inbound Control

ontvangst & inspectie

Stock/ Location Control

Picking Control

Ruw Mat

Production Operation Control

Component fabricage

Inbound Control

Stock/ Location Control

Production Operation Control

Picking Control

Compo nenten

Assemblage

= bewerking Figuur 10 Goederenstroom

64

Inbound Control

= opslag

Stock/ Location Control

Eind produkt en

Picking Control

Packing Control

verpakking

Shipping Control

verzenden

Transp ort Klant

Klant Order Ontkoppel Punt

3.4.7

Bedrijfsbesturing/Klant Order Ontkoppel Punt

De inrichting van een bedrijf kan vanuit verschillende uitgangspunten/'strategieën' vormgegeven worden. Één van de uitgangspunten is bijvoorbeeld de mate van inbreng van de klant bij ontwerp en productie van goederen. De keuzes die daarbij gemaakt worden kunnen vergaande consequenties hebben voor de inrichting van het bedrijf. De spijkerbroekenfabrikant Ivel heeft na gedegen marktonderzoek een goed beeld van mogelijke afzet van een aantal modieuze modellen voor de broeken. Op grond daarvan worden verwachte verkoopcijfers opgesteld voor de diverse modellijnen. Op basis van deze cijfers gaat de planningafdeling de productie van broeken plannen en worden de goederen ingekocht. Daarna wordt op de geplande data de productie ter hand genomen. De gerede producten worden tenslotte opgeslagen in het magazijn, in afwachting van bestellingen. Inamra is een concurrent van Ivel en gaat heel anders te werk. Via het Internet kunnen klanten (bestaand of nieuw) kiezen uit een groot aantal varianten van een serie basislijnen. Elementen zijn tussen de basislijnen uitwisselbaar zodat een bijna onbeperkt aantal variaties ontstaat. Inamra houdt geen voorraad van eindproducten. Inamra beschikt over zeer flexibele machines die klantspecifieke broeken kunnen produceren. Omsteltijden zijn verwaarloosbaar. Dagelijks vindt productie plaats van ingekomen bestellingen.

Productie vindt in bovengenoemde voorbeelden plaats op basis van verschillende uitgangspunten. Ivel produceert op voorraad terwijl Inamra maakt op bestelling. Bij Ivel heeft de klant geen invloed op de productie. De klant kan alleen maar afnemen wat Ivel aan eindproducten te bieden heeft. Ivel loopt daarmee risico: onverkochte voorraden eindproducten. Bij Inamra is de klant koning. Het hele productieproces komt pas op gang na het binnenlopen van concrete orders. Inamra loopt natuurlijk ook risico's. We noemen: - onvoldoende klanten weten de website te vinden - de basislijnen vallen niet in de smaak. De wijze waarop productie plaatsvindt binnen deze bedrijven karakteriseren we nu als volgt (tabel 3): Bedrijf Ivel Inamra

Wijze van productie Productie op voorraad Productie op klantorder

Tabel 3. Er zijn meer varianten denkbaar. We behandelen er nog twee. In een autofabriek zijn (onder)delen als chassis, deuren, motoren, bumpers, uitlaten, wielen etc. op voorraad. Een klant kant naar hartelust combineren, variëren. In de fabriek worden de juiste (onder)delen

65

geassembleerd tot een 'uniek' exemplaar. Deze variant noemen we Assembleren op order. Een bruggenbouwer levert vanzelfsprekend niet op voorraad. Als een gemeente besluit een brug aan te leggen over een plaatselijke rivier, dan zal de bruggenbouwer specifiek voor deze klant een brug moeten ontwerpen. Vanaf het allereerste begin van de levenscyclus van de brug is de klant betrokken bij het proces. Deze variant noemen we Ontwerp/Productie op order. We zien in alle genoemde voorbeelden dat de rol van de klant in belangrijke mate bepaalt hoe de bedrijfsvoering eruit zal gaan zien. Bij Productie op voorraad is het vaststellen van de verwachte vraag van groot belang. De planning zal daarop afgestemd moeten zijn. Bij Productie op klantorder speelt planning in veel mindere mate een rol, hier gaat het vooral om de verwachte benodigde voorraad grondstoffen/onderdelen (knopen, ritsen, garen, stof). Bij de autofabrikant zal naast de planning van gewenste voorraad onderdelen ook de assemblage gepland moeten worden. We zien dat in elk van deze omgevingen er een punt komt waar de productie niet meer op voorspelde vraag gebaseerd te is maar op feitelijke klantwensen. De focus van productie verschuift daarbij van inventaris-opbouw om aan verwachte vraag te voldoen naar het bouwen van eindproducten in directe reactie op klantorders. Het punt waar zich die verandering manifesteert staat bekend als Klant Order Ontkoppel Punt (KOOP). In fig. 11 zijn de productiewijzen en het KOOP in samenhang weergegeven. Ruw Materiaal

ONTW

Componenten

PROD

Leverancier

Halffabr

Eindprodukten

PROD

PROD

Klant

Produktie op voorraad

Assemblage op order

Produktie op order

Ontwerp en produktie op order

Produktie gebaseerd op voorspelling

Opslagpunt

Produktie gebaseerd op order

Figuur 11 Klant Order Ontkoppel Punt en Productiewijzen De figuur geeft duidelijk aan dat bij productie op voorraad KOOP bij het opslagpunt van de eindproducten ligt. Bij de tweede en volgende ligt dat

66

punt steeds verder naar links, zodat het productieproces meer klantspecifiek wordt.

3.5

Samenvatting

In dit hoofdstuk hebben we eerst gezien dat implementeren van ERP systemen geen sinecure is. Belangrijke aandachtspunten zijn daarbij aan de orde gesteld, zoals faalfactoren en intrinsieke complexiteitsfactoren. Bij het implementeren spelen referentiemodellen een belangrijke rol; deze modellen kunnen overgenomen (herbruik) worden door andere bedrijven. Zij staan model voor hergebruik van ´ingeblikte´ expertise en “best-practice”. Ook hebben we stilgestaan bij de rol van enterprisemodeling bij implementatietrajecten van ERP-systemen. Tenslotte zijn belangrijke concepten, ontleend aan de logistieke wereld, besproken. Deze concepten zullen in het vervolg van de cursus terugkomen als ´kapstokken´ waaraan enteprise modeling opgehangen wordt. In de veelheid aan modellen die we in dit hoofstuk tegenkwamen zal in het volgende hoofdstuk structuur aangebracht worden. Een omvattend model wordt daar gepresenteerd. Opgaven 1. In paragraaf 3.2 wordt genoemd dat invoering van ERP veelal gepaarde gaat met herontwerp van bedrijfsprocessen. Waarom past het bedrijf zich aan bij de ERP software en niet andersom? 2. In figuur 4 is ´Gebrek aan communicatie´ met 20% een forse risicopost. Wat wordt met gebrek aan communicatie bedoeld en hoe is dat op te lossen? 3a. Geef aan hoe de fysieke goederenstroom bij MacDonald er uitziet (maak een tekening). 3b. Welke productiewijze volgt MacDonalds? 3c. Waar ligt het Klant Order Ontkoppelpunt? 4 Geef aan welke bedrijfsfuncties uit het bedrijfsbesturingsmodel van fig. 1 uit hoofdstuk 2 op grond van de beschrijving van Ivel en Inamra op deze bedrijven van toepassing zijn. 5. Natuurlijk verloopt het inkopen in de praktijk niet zo vlotjes als in stap 5 van paragraaf 3.4.3 beschreven. Hoe zijn leveranties veilig te stellen en knelpunten bij (toe)leveranciers vroegtijdig te herkennen? 6.

67

Vergelijk de productiewijzen Produktie op voorraad en Assemblage op order (zie par. 3.4.7) met elkaar vanuit financieel en personeelplanningsperspectief.

Terugkoppeling. Uitwerking opgaven 1 Bij de faalfactoren uit fig. 4 komt vooral naar voren dat slecht management van een project de grootste risico´s oplevert: gebrekkig projectmanagement, geen doelstellingen, gebrek aan communicatie, samen goed voor 69%! 2 Het niet onderkennen van de menselijke factor bij het invoeren van erp systemen kan leiden tot verlies van draagvlak en medewerking op de werkvloer. Herontwerp van bijv. inkoopprocessen zonder inbreng van inkopers kan verzet van medewerkers oproepen. Een mogelijk ander gevolg kan zijn dat bestaande, onmisbare praktijk onvoldoende onderkend is en zodoende niet ondersteund wordt door het erp systeem. 3 Problemen veroorzaakt door incompatibiliteit van nieuwere versies software met oudere versies kunnen tot het uiterste beperkt of voorkomen worden door: - uiteraard alleen overgaan naar een nieuwere versie van de software als dat absoluut noodzakelijk is - alleen die componenten vervangen die vernieuwd moeten worden. In toenemende mate zal dat mogelijk zijn vanwege ´component based development´. 4 Versnelde implementatie van erp systemen door gebruik te maken van referentiemodellen hangt vooral samen met: - configuratie van de software gaat sneller, omdat belangrijke instellingen al aanwezig zijn in het referentiemodel. Daarbij kun je denken aan instellingen voor de inrichting van bijv. verkoopprocessen, het al dan niet gebruiken van electronische ordersystemen, de manier waarop planning plaatsvindt etc. - Bovendien zullen goedgekozen implementatiepartners bekend zijn met het betreffende referentiemodel en dus met de bedrijfsprocessen van het bedrijf waar ERP ingevoerd wordt. Het wiel hoeft niet opnieuw uitgevonden te worden. 5 Andere modellen dan bedrijfsbesturingsmodellen en procesmodellen: - Voor de IT invalshoek is het zeker van belang zicht te krijgen op de informatiestromen en op de architectuur van de systemen. - Daarnaast spelen modellen voor de projectmatige invoer (denk bijv. aan stappenplan, mijlpalen, scholingstrajecten) van het ERP systeem een zeer belangrijke rol. 6 Voor de stoel hebben we nodig

68

Onderdeel Zitting

Bestaat uit Zitframe Bekleding 0.5m

Kosten

0.5 x 27.58

59.76 13.79

Onderstel Wiel 5x Frame

5 x 5.32

26.60 89.22

Rugleuning Rugframe Bekleding 0.3m Armsteun Totaalbedrag

0.3 x 27.58 2 x 24.67

42.61 8.274 49.34 289.594

7 Voor het berekenen van de productiekosten en productietijd moet je tenminste nog beschikken over bewerkingsgegevens (welke bewerkingen, hoe lang duurt een bewerking, omvang en aard van inzet van menskracht, welke machines zijn erbij betrokken) en tarieven voor gebruik van machines, uurlonen en dergelijke.

Uitwerking zelftoets 1.

Één van de redenen is al genoemd in de tekst: om functionele barrières te slechten. Immers, integratie vraagt om procesoriëntatie over functionele afdelingsgrenzen heen. Andere redenen zijn: - Het aanpassen van de software (maatwerk) bij de organisatie is vaak een dure aangelegenheid; standaardpakketten zijn goedkoper. - Maatwerk levert bij nieuwe versies van de software onvermijdelijk extra werk.

2. Bij “gebrek aan communicatie” kunnen een aantal zaken een rol spelen: het topmanagement geeft onvoldoende blijk (mondeling, schriftelijk) van steun en commitment voor het project en het projectteam. - Het projectteam communiceert niet met de werkvloer. Dat is op te lossen door: - duidelijke communicatie van het management met alle medewerkers in het bedrijf bij de start van het project (doelstelling, looptijd, samenstelling team, speelruimte) en bij belangrijke mijlpalen - het projectteam mijlpaal-rapportages en voortgangsbulletins voor alle betrokken medewerkers uit te laten geven. 3a. De goederenstroom laat zich als volgt globaal beschrijven (zie ook onderstaande figuur 13): intake van goederen, opslag van goederen (halffabrikaten als ingevroren frites, hamburgers, salade, sauzen, ijs, frisdrank), productie (bakken, grilleren), assembleren, inpakken en uitleveren.

69

Transport Leveranc

ontvangst

halff abrika ten

= bewerking

productie

assembleren

inapkken

eind prod ukt

uitleveren

klant

= opslag

figuur 13: Fysieke goederenstroom bij McDonalds. 3b. Productie op voorraad. De productie wordt afgestemd op verwachte afzet en is tijdsafhankelijk. De klant kan kiezen uit het vaste assortiment. 3c. Het klant order ontkoppelpunt ligt bij het eindproduct. 4. Voor Ivel zijn functies als inkoop, verkoop, planning (eindproducten, materiaalbehoefte), magazijnbeheer (inslag, uitslag, voorraadbeheer), productiebeheer (aansturing van de productie), financiën en marketing nodig. Voor Inamra liggen de zaken enigszins anders. Naast inkoop en verkoop is er ook hier een planningsafdeling, die echter niet de productie van eindartikelen plant. Zij plant wel op grond van verwachte afzet de materiaalbehoefte (knopen, garen, rollen stof, labels) en adviseert inkoop van deze grondstoffen. Productie, inslag en uitslag worden gestuurd door productiebeheer resp. magazijnbeheer. Het assembleren wordt gestuurd door assemblageplanning. Tenslotte is er nog een functie financiën nodig 5. Grote bedrijven kunnen toeleveranciers aan zich binden en hoge eisen stellen aan kwaliteit van goederen en stipte levering. Door bijvoorbeeld te werken met preferred suppliers is een hoge leveringsbetrouwbaarheid op te bouwen. Toeleveranciers kan toegang gegeven worden tot het eigen planningssysteem zodat deze op elk gewenst moment op de hoogte zijn van voorraad en productieplannen bij de afnemer. 6. Perspectief/prod.wijze Productie op voorraad Financieel Hoge voorraadkosten; er is geinvesteerd in materialen en uren. Personeelplanning

70

Op basis van verwachte afzet wordt personeel ingezet.

Assemblage op order Lagere voorraadkosten. Voorraadniveaus beter afgestemd op klantvraag. Afhankelijk van de vraag wordt personeel (geworven en) ingezet.

Appendix X CORBA defines a model that specifies interoperability between distributed objects on a network in a way that is transparent to the programmer. It achieves this by defining ways for specifying the externally visible characterestics of a distributed object in a way that is implementation-independant. This model is based on clients requesting the services from distributed objects or servers through a well-defined interface, by issuing requests to the objects in the form of events. An event carries information about an operation that needs to be performed including the object name (called an object reference) of the service provider and the actual parameters if any. CORBA automatically handles a lot of network programming tasks such as object registration, object location, object activation, request demultiplexing, frame and error-handling, marshalling and operation dispatching. CORBA objects are accessed through the use of an interface. OMG's Interface Definition Language (IDL for short) is used to define interfaces, their attributes, methods and parameters to those methods within the interface. The central component of CORBA is the Object Request Broker (ORB for short). This component provides all the communication infrastructure needed to identify and locate objects, handle connection management and deliver data and request communication. One CORBA object never talks directly with another. Instead, the object requests for an interface to the ORB running on the local machine. The local ORB then passes the request to an ORB on the other machine. The remote ORB then locates the appropriate object and passes back an object reference to the requester. The functions of the ORB are as follows: -Lookup and instantiate objects on remote machines -Marshal parameters from one application object to the other -Handle security issues across machine boundaries -Retrieve and publish data on objects on local machine for another ORB to use -Invoke methods on a remote object using static method invocation -Invoke methods on a remote object using dynamic method invocation -Automatically instantiate objects that are'nt currently running -Route callback methods to the appropriate local object being managed -Communicate with other ORBs using Internet Inter-ORB Protocol ( IIOP ) The other components that make up a CORBA application are Object Services, Application Interfaces, Domain Interfaces and Common Facilities. CORBA's architecture is based on Object Orientation, and built around three key building blocks: OMG Interface Definition Language, OMG IDL The Object Request Broker or ORB The standard protocol IIOP CORBA applications are composed of objects, individual units of running software that combine functionality and data, and that frequently (but not always) represent something in the real world. Typically, there are

71

many instances of an object of a single type - for example, your ecommerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected. For each object type, such as your shopping cart, you define its interface in OMG IDL. This fixes the operations it will perform, and the parameters (input and output) for each. This interface definition is independent of your programming language, but maps to all of the popular programming languages via a set of OMG standards: OMG has standardized mappings for C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLscript. This is the essence of CORBA - how it enables interoperability, with all of the transparencies we've claimed. The interface to each object is defined very strictly. But, in contrast, the implementation of an object - its running code, and its data - is hidden from the rest of the system (that is, encapsulated) behind a boundary that the client may not cross. Clients access objects only through their advertised interface, invoking only those operations that that object chooses to expose, with only those parameters (input and output) that are included in the invocation. Figure 1 shows how everything fits together, at least within a single process: You compile your IDL into client stubs and object skeletons, and write your object (shown on the right) and a client for it (on the left). Stubs and skeletons serve as proxies for clients and servers, respectively. Because IDL defines interfaces so strictly, the stub on the client side has no trouble meshing perfectly with the skeleton on the server side, even if the two are compiled into different programming languages, or even running on different ORBs from different vendors. In CORBA, every object instance has its own unique object reference, an identifying electronic token. Clients use the object references to direct their invocations, identifying to the ORB the exact instance they want to invoke (Ensuring, for example, that the books you select go into your own shopping cart, and not into your neighbor's.) The client acts as if it's invoking an operation on the object instance, but it's actually invoking on the IDL stub which acts as a proxy. Passing through the stub on the client side, the invocation continues through the ORB (Object Request Broker), and the skeleton on the implementation side, to get to the object where it is executed.

72

Inhoud H4: Modellen en Architectuur Introductie 4.1 Een allesomvattend model voor EIS 4.1.1 Ontwerp analyse en besturing 4.1.2 Generieke modellen 4.1.3 Implementatietrajecten 4.1.4 Toenemende complexiteit 4.2

Modellen en Architectuur gedefinieerd

4.3 Vier Architecturen 4.3.1 CIMOSA 4.3.2 PERA 4.3.3 GERAM 4.3.4 Zachman Raamwerk 4.4

Conclusies en vooruitblik

Zelftoets Terugkoppeling 1 2

73

Uitwerking van de opgaven Uitwerking van de zelftoets

4

4.1

Modellen en Architectuur

INTRODUCTIE

Is één model mogelijk? In de afgelopen hoofdstukken is de rode draad geweest het verkennen van modellen van organisaties. Gaandeweg zijn in de hoofdstukken in dit eerste deel een aantal eisen verzameld die bijna onmogelijk zijn te verenigen in één model. Om er een aantal op een rijtje te zetten: - in het eerste hoofdstuk is vastgesteld dat er modellen zijn die je gebruikt om een situatie te beschrijven, te analyseren, te ontwerpen en te besturen. Dat zijn fasen uit de levenscyclus van een organisatie of afdeling. Kan één model al die fasen in zich bergen? - In hetzelfde hoofdstuk is een onderscheid gemaakt naar modellen die beschrijven en die voorschrijven. In het ene geval gaat het dus om vastlegging van een bestaande situatie in het andere geval om de vastlegging van een gewenste situatie. Past dat in één model? - In het volgende hoofdstuk is stilgestaan bij Enterprise Information Systems. Dergelijke systemen dienen zowel de behoefte van bijvoorbeeld financiën als van verkoop en logistiek te combineren. Is dat mogelijk? - Er is ook behandeld dat er verschillende views zijn, niet alleen de views van de verschillende functionele gebieden, maar er zijn ook views van de verschillende lagen in het systeem te onderkennen. Met verschillende lagen bedoelen we dat er een model is van het operationeel proces, maar ook van de informatiestromen, van de netwerkarchitectuur, enzovoort. In dit hoofdstuk zullen we kijken naar enkele modellen die beogen een universeel antwoord te geven en al deze verschillende aspecten in zich te verenigen. LEERDOELEN Na het bestuderen van dit hoofdstuk wordt verwacht dat u – een aantal eisen kunt formuleren ten aanzien van modellen en architecturen voor EIS – de verschillen tussen modellen en architecturen kunt aangeven – enkele karakteristieken kent van CIMOSA, PERA, GERAM, Zachman – de verschillen en overeenkomsten tussen deze vier kunt aangeven.

74

4.2

Een allesomvattend model voor EIS

De uitdaging is nu te onderzoeken of het mogelijk is om al de verschillende eisen en aspecten uit de leerstof tot nu toe binnen één model onder te brengen. We brengen daartoe de hoofdstukken tot nu toe bij elkaar door te onderzoeken of er voor EIS pakketten een dergelijk allesomvattend model is op te stellen. Welke manieren bestaan er om een structuur te ontwerpen waarbinnen al deze aspecten op een bevredigende manier geregeld kunnen worden? Het regelen van één of enkele aspecten is redelijk goed uit te voeren, een datamodel van alleen de gegevens is nog goed op te stellen. Het probleem ontstaat door de eis dat aspecten in samenhang dienen te worden geregeld. Het gaat dan naast het datamodel ook om een implementatiemodel en de verbindingen tussen die modellen. Dan ontstaat er een grote mate van complexiteit. In het eerste hoofdstuk kwam naar voren dat een model dient te ondersteunen bij ontwerpen, analyseren en besturen. Een andere belangrijke bron van complexiteit bleek het invoeren van een ERP-pakket. We zullen deze elementen in onderstaande subparagrafen behandelen. 4.2.1 Ontwerp, analyse en besturing Vanuit een ontwerp perspectief dient een EM een organisatie expliciet te kunnen beschrijven. Het moet daardoor mogelijk zijn om meerdere alternatieve ontwerpen te maken. Het moet mogelijk te zijn vragen te stellen als: Kan een proces op een andere manier verlopen? Wat gebeurt er als de capaciteit hier wegvalt? Kunnen we de reactietijd naar de klant ook op een andere manier garanderen? Dit zijn vragen die het model moet kunnen helpen beantwoorden. Vanuit de analyse is het van belang dat een Enterprise Model de veranderingen goed zichtbaar maakt. Als ten behoeve van een alternatief ontwerp sommige de capaciteit in een deel van de organisatie verandert dan moet het model de doorwerking daarvan in de totale organisatie zichtbaar maken. Moeten er mensen worden bijgeschoold, ontstaat er niet elders een probleem nu doordat er een bepaalde afdeling te veel werk krijgt toegeleverd? Kortom het model moet de consequenties van veranderingen op deelgebieden voor het totaal goed in kaart kunnen brengen. Vanuit een besturingsperspectief is het verder noodzakelijk dat een model laat zien wat er gepland is wat wordt uitgevoerd en wat de geschiedenis is. 4.2.2 Generieke modellen Een Enterprise model voor een ERP-pakket dient het ontwerp, de analyse en de besturing te ondersteunen, maar niet voor slechts één bedrijf. Het model moet werken voor verschillende organisaties. Anders gesteld: een referentiemodel omvat alle vereisten die gelden voor alle implementatietrajecten maar is onafhankelijk van een specifieke implementatie. Het dient kortom een algemeen of generiek model te zijn.

75

4.2.3 Implementatietrajecten Een andere vorm van complexiteit openbaart zich bij het implementeren van een pakket. Veruit de meeste problemen ontstaan in het implementatietraject. Een model zou daarom een goed beeld moeten geven van de consequenties van de implementatie. Dat kan door de uitgangssituatie in kaart te brengen en de gevolgen van de invoering voor gebruikers en bedrijfsvoering tijdens en na de invoering. Het kan daarbij gaan om zaken als de doorlooptijd, maar ook de benodigde opleidingen, taakveranderingen enzovoort. 4.2.4 Toenemende complexiteit ERP-paketten ondersteunen meestal wel productie, maar richten zich toch vooral op procesbesturing en dan meestal de processen op een wat hoger niveau. De echte productiebesturing blijft meestal iets dat niet optimaal is afgedekt, een gemiddelde ERP-pakket had zo rond de eeuwwisseling nog de grootste moeite met het plannen van orders tegen eindige capaciteit. Toch is het vooral ook op het uitvoerende niveau dat een toenemende flexibiliteit wordt gevraagd van bedrijven (bijvoorbeeld korte levertijd, klantspecifieke producten). Voor deze meer uitvoerende taken worden ERP-pakketten vaak aangevuld met een zogenaamd Manufacturing Execution System afgekort tot MES. Dergelijke pakketten geven ook op uitvoerend niveau een goede functionaliteit. De consequentie is echter wel dat een al complexe situatie nog complexer is geworden. Experts verwachten een nog toenemende complexiteit. Bij het ondersteunen van een dergelijke geïntegreerde bedrijfsvoering dienen dan ook rekening te houden met de volgende aspecten: 1. de complexiteit van het systeem. Dit vraagt speciale manieren van structureren om die complexiteit te kunnen blijven overzien 2. de verschillende views binnen een onderneming. De technische kijk bestaat naast de economische en sociale benadering. 3. de noodzaak voor teamwerk. De kennis voor het implementeren van een dergelijk systeem kan nooit bij één persoon worden gevonden. 4. de continue verandering van de omgeving en de techniek vraagt om continue verandering van de bedrijfsvoering en de systemen die de bedrijfsvoering ondersteunen. Opgave 4.1 Vat de hierboven vermelde eisen samen in een lijstje. ( deze zullen later worden gebruikt om te toetsen of enkele modellen voldoen aan deze eisen) Het invoeren van een dergelijk pakket vraagt om Enterprise Modellen.. Maar één model is daarbij niet voldoende; het gaat om een set van Enterprise Modellen die alle aspecten van complexiteit afdekken. Die sets van Enterprise Modellen vormen samen een Referentie Architectuur (Reference Architecture). Een referentie architectuur omvat alle vereisten die gelden voor alle implementatietrajecten maar is onafhankelijk van een specifieke implementatie. Wat geldt voor alle trajecten is bijvoorbeeld een fasering van invoering, maar een dergelijk model zal geen rekening houden met de specifieke omstandigheden van deze implementatie. Het bevat kortom een checklist met relevante aspecten. De meest bekende architecturen zijn: GRAI-GIM PERA CIMOSA

76

GERAM Zachman-model ARIS Kort behandeld zullen worden: PERA; CIMOSA; GERAM; Zachman. In de laatste paragraaf zullen deze modellen worden vergeleken en zal een korte vooruitblik volgen naar de komende hoofdstukken. Voor we overstappen naar de bespreking van deze modellen volgen echter eerst enkele definities over modellen en architectuur. 4.3

Modellen en Architectuur gedefinieerd.

Voordat de verschillende methoden uit de volgende paragraven aan de orde komen is het noodzakelijk wat helderheid te scheppen in de terminologie. Wanneer spreken we over een model en wanneer over een architectuur bijvoorbeeld? model

Een model is een vereenvoudigde weergave van de werkelijkheid. De modellen kunnen fysiek zijn, bijvoorbeeld een maquette van een gebouw, maar in de omgeving van EIS zijn computermodellen meer gebruikelijk. Deze computermodellen zijn handig omdat je ze meestal snel kunt veranderen en snel resultaten krijgt. Lastig wordt het als er geprobeerd wordt om computermodellen te definiëren. Computermodellen worden gebruikt om “dingen” te beschrijven, te analyseren en te visualiseren. Het kan gaan om dingen als de computer zelf, netwerken, fabriekshallen, organisatiestructuren, enzovoort.

referentiemodel

Een referentie model is een model wordt gebruikt als voorbeeld model. In een implementatie traject gaat het dan bijvoorbeeld om een model dat geoptimaliseerde processen beschrijft. Omdat het model zo goed voldoet probeert men in een implementatietraject die optimale processen vaak te implementeren bij het bedrijf. Het model dat gebruikt wordt om een bepaalde kwaliteitsstandaard te borgen is ISO 9000. Het ISO 9000 model kan beschouwd worden als een referentie model.

architectuur

Een architectuur is een gestructureerd plan, een raamwerk op basis waarvan een product of organisatie kan worden geconstrueerd. Het biedt een logische structuur voor het classificeren van de modellen die relevant zijn voor het bouwen en het onderhouden van een systeem of organisatie. Dat het hier gaat om een raamwerk betekent dat het onderdak biedt aan verschillende modellen en technieken die helpen een organisatie te begrijpen en te beschrijven. Het gaat dan bijvoorbeeld om proces modellering of kennis management of data warehousing. Geen van deze methoden en technieken benaderen een organisatie als een geheel, ze richten zich op één aspect van de organisatie. Om te zorgen dat al deze aspecten worden geïntegreerd in één benadering is een raamwerk geconstrueerd. Dat raamwerk brengt samen wat de individuele methoden niet kunnen: een meerzijdige view of verschillende perspectieven en een verbinding tussen de verschillende benaderingen die samen wel alle aspecten van een organisatie in kaart brengen.

77

referentie architectuur

De term referentie architectuur betekent dat het model gebruikt kan worden als algemeen voorbeeld voor het opstellen van een architectuur voor een specifieke situatie. Je neemt de referentie architectuur en voegt toe of schrapt weg waar nodig.

Opgave 4.2 Geef aan wat het verschil is tussen een model en een architectuur 4.4

Vier architecturen

Hieronder zullen enkele architecturen behandeld worden. De architecturen zijn tot stand gekomen via uitgebreide wetenschappelijke uitwisselingen en er komen nog steeds toevoegingen en verbeteringen op deze methoden. Het is daarom binnen het bestek van dit hoofdstuk niet mogelijk de modellen volledig te behandelen. De focus zal worden gericht op de architectuur en minder op de achtergronden. CIMOSA

4.4.1 CIMOSA CIMOSA staat voor Computer Integrated Manufacturing Open Systems Architecture. Het is ontwikkeld binnen ESPRIT, een wetenschappelijk ontwikkelings- en samenwerkingsproject van de Europese Unie. Het project is geïnitieerd in 1984. Een van de centrale onderdelen binnen CIMOSA is een driedimensionale matrix. CIMOSA onderscheidt drie modelleer niveaus en vier “views”.

St

ep w

is e

G en er at

io n

Organization View Resource View

Requirement definition modelling level Design Specification Modelling level Implementation Modelling level

Resource View Information View

Information View

Function View

Organization View

Resource View Information View

Function View

Function View

Generic Requirements Definition Building Blocks

Partial Requirements Definition Models

Particular Requirements Definition Model

Generic Design Specification Building Blocks

Partial Design Specification Models

Particular Design Specification Model

Generic Implementation Description Building Blocks

Partial Implementation Description Models

Particular Implementation Description Model

Reference Architecture

Organization View

particular architecture

De drie modelleer niveaus bestaan uit requirements ( de eisen en wensen) design specifiaction( het functionele ontwerp) en implementation (implementatie). Dit zijn de drie niveaus die in elk automatiseringstraject worden doorlopen; van eisen en wensen tot aan de blauwdruk voor

78

implementatie van het systeem. Elk van deze niveaus vraagt een apart modelleer niveau. Daarnaast worden vier “views” gebruikt, te weten: - function view, hier staat de functie centraal, de werkstroom wordt beschreven; - information view hier staat een data model centraal, het gaat niet meer om de werkstromen, maar om de input en de output van de verschillende functies; - resource view beschrijft de structuur van de capaciteiten wat betreft mensen, machines en informatiesystemen. - Organisation view geeft de taken verantwoordelijkheden en bevoegdheden aan. Uitgangspunt bij CIMOSA is verder dat modellen en uitvoering van de modellen zoveel mogelijk computer gestuurd dienen te zijn. PERA

4.4.2 PERA Purdue Enterprise Reference Architecture is ontwikkeld binnen de Purdue Universiteit. Het ontwikkelingstraject is gestart in 1986. Een van de meest opvallende onderdelen binnen PERA is dat het de menselijke functies, bijvoorbeeld innovatievermogen, niet door een computersysteem kunnen worden overgenomen. Één van de belangrijkste onderdelen binnen PERA is dan ook om die menselijke vermogens apart te benoemen. Er worden drie typen taken onderscheiden: informatie systeem taken, fabricage taken, menstaken. Deze drie onderdelen kunnen in wisselende proporties ten opzicht van elkaar voorkomen. startfase

pr

me

sys

od

nse

te

uct

n

me

ie

n

opheffingsfase

startfase

pr

sys

od uct

te mensen

ie

me n

opheffingsfase

. Een ander opvallend aspect van PERA is dat PERA de volledige levenscyclus van een pakket in beschouwing neemt. Waar CIMOSA alleen kijkt naar “requirements, specification, implementation” onderscheidt PERA zeven fases. In de figuur hieronder zijn deze fases weergegeven. In feite zijn dit de fases van een productontwikkelingcyclus. Een dergelijke cyclus start met een idee, gaat via een voorlopig ontwerp naar een detail ontwerp, bouwen, beheren en onderhouden, uitfaseren en eindigt met “disposal” ofwel weggooien. 79

In feite gaat de essentie van PERA maar om twee views, te weten een functionele en een implementatie view. Binnen die functionele view spelen de drie gebieden, waarbij de menselijke factor de brug slaat tussen de production / equipment aan de ene kant en control & info systems aan de andere kant. 4.4.3 GERAM De Generalised Enterprise Reference Architecture and Methodology is een model dat is opgesteld door een internationale federatie (International Federation of Automatic Control Taskforce). Van GERAM komen er wanneer wenselijk nieuwe versies uit. De architectuur van GERAM bouwt voort op onder andere CIMOSA en PERA en bestaat uit een groot aantal componenten, dat maakt het vollediger, maar ook complexer dan de voorgaande modellen. GERAM zal hier echter net als de voorgaande modellen slechts beperkt worden behandeld. Hier onder zal daarom van de 9 componenten slechts de belangrijkste worden getoond, de GERA (Generalized Enterprise Reference Architecture) component.

80

Het model heeft net als de hiervoor behandelde modellen een levenscyclus als uitgangspunt. Daarnaast worden er drie invalshoeken behandeld: - mens georiënteerd - proces georiënteerd - technologie georiënteerd

GERAM is het vermelden waard omdat het de enige methodiek is die ook rekening houdt met ontwikkelingen als gevolg van het vervagen van bedrijfsgrenzen. De samenwerking die bedrijven aangaan vragen dat ook de systemen goed op elkaar worden afgestemd. 4.4.4 Zachman model Het Zachmanmodel is ontwikkeld door John Zachman

81

Er is hier niet zozeer sprake van een model als wel van een “raamwerk voor een architectuur” (Framework for enterprise architecture) Het raamwerk van Zachman bestaat uit twee assen en een aantal velden of intersecties binnen die assen.

Op de verticale as staan de perspectieven weergegeven. De perspectieven geven van boven naar beneden een systematische stapsgewijze detaillering aan. Zo is er een perspectief van een strategische oriëntatie gericht op de omgeving van de organisatie, vervolgens het model van de organisatie zelf, het model van een systeem, het model van de technologie, van de programmatuur en uiteindelijk dat van de gebruiker. Op deze wijze geeft deze methode niet alleen een systematische topdown benadering, maar vormt het ook een weergave van een levenscyclus van een systeem. Opmerkelijk is dat Zachman het model ontleende niet zozeer aan een EIS-omgeving, maar dat hij het construeerde rond de voorbeelden van een gebouw en een vliegtuig. De toepasbaarheid lijkt daarmee universeel voor complexere producten. Voor een beschrijving van de horizontale vlakken laten we Zachman zelf aan het woord: “ Er zijn ook weergaven van de verschillende karakteristieken van het product. Er zijn bijvoorbeeld weergaven van de materialen vanuit het gezichtspunt van de eigenaar, vanuit het gezichtspunt van de ontwerper, vanuit het gezichtspunt van de bouwer, enzovoort. Op dezelfde manier zijn er weergaven voor de functie en afmetingen vanuit het gezichtspunt van de eigenaar, de ontwerper, de bouwer enzovoort. De doorbraak die uiteindelijk leidde tot het raamwerk zoals het nu bestaat kwam door de realisatie dat de velden “materiaal”, “functie”, “afmetingen” eigenlijk beschrijvingen vormden van WAT het product gemaakt is, HOE het werkte en WAAR de onderdelen ten opzichte van elkaar werden gesitueerd. Vanuit die constatering was het duidelijk dat een beschrijving van het product noodzakelijkerwijs ook een beschrijving zou moeten

82

bevatten van WIE iets doet met het product en WANNEER iets gebeurt en WAAROM verschillende productkeuzes gemaakt worden.” Met deze twee assen die weergeven respectievelijk een perspectief en een aspect ontstaat een raamwerk, een soort duiventil voor modellen. Maar het gegeven dat nu een verzameling van modellen onderdak vindt binnen zo’n raamwerk roept weer nieuwe problemen op, het probleem van consistentie tussen de modellen bijvoorbeeld, het vermijden van overlap, het gebruik van een gemeenschappelijke taal, het vinden van de goede interface, enzovoort. Het Zachman model is dan ook meer een demonstratie van de grote hoeveelheid benodigde modellen dan dat het een consistent samenhangend concept biedt voor en Opgave 4.3 Ga na, voor zover daarvoor informatie beschikbaar is in welke mate deze modellen voldoen aan de eisen uit opgave 4.1 4.5 Conclusies De vraag gesteld aan het begin van dit hoofdstuk luidde: “Is er één model mogelijk dat deze enorme complexiteit kan structureren”? Geconcludseerd mag worden dat er verschillende architecturen zijn, elk met een eigen accent. De architecturen die hier de revue zijn gepasserd zijn echter slechts op een oppervlakkig niveau behandeld. Er is in dit hoofdstuk een deel van het eindresultaat van deze architecturen neergezet. Er is niet ingegaan op de achtergronden van de raamwerken en modellen, hun concepten en de keuzes die zijn gemaakt expliciet en impliciet. Hoe verloopt een dergelijk traject? Als startend vanuit de echte wereld van een systeem implementatie gekeken wordt en er wordt geprobeerd een dergelijk model op te bouwen, hoe pakt een onderzoeker dat aan? Welke moeilijkheden ontstaat er. Welke methoden en technieken geven hierbij ondersteuning? Bij het construeren van een dergelijk raamwerk dient aandacht besteed te worden aan de verschillende onderdelen, de modellen. De modellen dienen te voorzien in een behoefte. Het model moet een hulpmiddel zijn om grip te krijgen op de werkelijjkheid, anderzijds dient het ook generiek toepasbaar te zijn. Voor het raamwerk geldt dat dit zo dient te worden opgesteld dat er een zekere volledigheid ontstaat. Die volledigheid dient echter niet te resulteren in elkaar overlappende modellen, maar elkaar aanvullende modellen. Kortom een lastige klus. Het volgende deel zal uitgaande van een realistische omgeving het ontstaan schetsen van een modellen en raamwerk. ZELFTOETS 1

Benoem kort de eisen aan een model als behandeld in dit hoofdstuk

83

2

Gelden de eisen als geformuleerd voor modellen ook voor de architectuur of het raamwerk? Licht het antwoord toe.

3

Hieronder volgen enkele trefwoorden. Geef aan op welke van de vier behandelde architecturen deze trefwoorden van toepassing zijn. - beperkte ondersteuning in de productlevenscyclus - combineert bestaande methodieken - benoemt raamwerk geeft geen modellen. - expliciet mensgericht en wat minder formeel gespecificeerd . TERUGKOPPELING 1

Uitwerking van de opgaven

4.1 Een model als hier beschreven dient te helpen bij het beheersen van complexiteit. Complexiteit ontstaat als er veel factoren een rol spelen. De complexiteit wordt beheersbaar door die factoren in modellen op te nemen. De eisen aan modellen kunnen als volgt worden samengevat: - een model moet helpen bij ontwerpen van een organisatie - een model dient te ondersteunen bij analyses van het ontwerp - een model dient te helpen bij de besturing van operationele processen - een model dient generiek te zijn, een basismodel vormen voor alle soorten bedrijven - een model dient de implementatie van een pakket te ondersteunen. - een model om de complexiteit van het systeem te blijven beheersen - een model voor de verschillende views - een model dat teamwerk faciliteert - een model dient flexibel te zijn om interne en externe veranderingen op te vangen Het is onmogelijk al deze onderdelen in één model te vangen. Daarom is er sprake van een aantal samenhangende modellen die passen binnen een bepaalde architectuur. 4.2 Een model is een vereenvoudigde weergave van de werkelijkheid. Een architectuur is een raamwerk dat een logische structuur biedt voor het classificeren van de modellen. 4.3 Het ingevulde schema ziet er als volgt uit: Norm Ondersteunt ontwerpen Ondersteunt analyseren Ondersteunt besturen is generiek ondersteunt implementatie helpt systeem complexiteit beheersen bevat verschillende 84

CIMOSA

Geram Ja

Zachman Ja

Ja Ja

PERA uitgebreide fasering Ja Ja Ja Ja

Ja Ja Ja Ja

Ja ja Ja ja

Ja

Ja

Ja

ja

ja

Beperkt

Ja

Ja

beperkt

views faciliteert teamwerk Veranderbaar

men kan Ja parallel werken niet gegeven niet gegeven

Ja

Ja

Ja

flexibel

Zonder in details te treden kan worden gesteld dat alle modellen grotendeels tegemoet komen aan de eisen zoals verwoord in de eerste paragraaf van dit hoofdstuk. 2

Uitwerking van de zelftoets

1

Een model: - moet helpen bij ontwerpen van een organisatie - dient te ondersteunen bij analyses van het ontwerp - dient te helpen bij de besturing van operationele processen - dient generiek te zijn, een basismodel vormen voor alle soorten bedrijven - dient de implementatie van een pakket te ondersteunen. - helpt om de complexiteit van het systeem te beheersen - geeft verschillende views - faciliteert teamwerk - dient flexibel te zijn om interne en externe veranderingen op te vangen

2

De modellen passen binnen het raamwerk. Het raamwerk of de architectuur is niet hetzelfde als de modellen. Voor de architectuur geldt dat het een logische structuur biedt voor de modellen. Architectuur benadert een organisatie als een geheel, modellen richten zich op één aspect van de organisatie. Het raamwerk brengt samen wat de individuele methoden niet kunnen: een meerzijdige view of verschillende perspectieven en een verbinding tussen de verschillende benaderingen die samen wel alle aspecten van een organisatie in kaart brengen.

3

De beschrijving geldt als volgt: - Beperkte ondersteuning in de productlevenscyclus – CIMOSA onderscheidt “requirements definition”, “design specification” en “implementation” - combineert bestaande methodieken- GERAM is gebaseerd op zowel CIMOSA als PERA en is daardoor zowel volledig als complex. - benoemt raamwerk geeft geen modellen. – Zachman heeft een architectuur ontworpen zonder de bijbehorende modellen expliciet te beschrijven. Dat geeft flexibiliteit bij de invulling, maar ook een potentieel consistentie-probleem. - expliciet mensgericht en wat minder formeel gespecificeerd – PERA; de menskant neemt een centrale plaats in. Er is echter geen formele methodiek voor de ontwikkeling of weergave van dit menselijk en organisatorisch aspect

85