Produkten toesnijden op de wensen van de klant is van evident belang geworden. Hoewel autofabrikanten reeds lang in staat zijn hun produkten voor elke individuele klant op maat af te leveren, blijken ‘mass-customization’ en informatietechnologie tot op heden niet samen te gaan. Consultants Jaap Hoebe en André Leijser beschrijven een methode om op basis van een bedrijfsmodel een informatiesysteem te ontwikkelen en te sturen. De flexibiliteit van het systeem stelt de organisatie in staat om snel nieuwe produkten op de markt te brengen.
Om te kunnen inspelen op de steeds wisselende eisen van klanten heeft de industrie bedrijfsprocessen opgezet die flexibel omgaan met veel verschillende componenten. Ook in de informatietechnologie komt het component-denken steeds meer voor. Uitgangspunt daarbij is dat informatiesystemen vaak hetzelfde doen. Denk aan het aanmaken van een polis voor een vaartuigverzekering en een polis voor een autoverzekering. Veel taken die voor beide polissen geautomatiseerd zijn, komen overeen: het invoeren van klantgegevens, het invoeren van produktgegevens en het afdrukken van de polis.
Deze geautomatiseerde taken kunnen hergebruikt worden. Het verzekeringsbedrijf kan besluiten om aan bepaalde klanten de vaartuig- en autoverzekering als één produkt met speciale condities te verkopen. Indien de produktcomponenten van de bestaande verzekeringen gemodelleerd zijn, en gekoppeld zijn aan informatiesystemen, is het nieuwe produkt eenvoudig te realiseren. Het kan samengesteld worden uit de bestaande produktcomponenten, inclusief een specifieke kortingscomponent. Alleen voor de kortingscomponent moet een nieuw stukje software ontwikkeld worden. De koppeling tussen de produktcomponenten en het informatiesysteem maakt het mogelijk nieuwe produkten aan te bieden, waarbij de geautomatiseerde procesondersteuning efficiënt en effectief tot stand komt.
Van bedrijfsmodel naar applicatie
Om bovenstaande koppeling te realiseren moeten de volgende fasen doorlopen worden. Allereerst moeten het bedrijfsproces en zijn produkten in kaart worden gebracht (business modelling). Tijdens deze fase worden tevens de produktcomponenten gekoppeld aan de primaire en secundaire bedrijfsprocessen. Het resultaat hiervan, het bedrijfsmodel, wordt vastgelegd in een actieve repository en dient als uitgangspunt voor de volgende fasen: information modelling en application modelling. Tijdens deze fasen wordt de aansluiting van het bedrijfsmodel aan het informatiesysteem gemodelleerd. Daarbij wordt een koppeling gelegd tussen het bedrijfsmodel en software-componenten (zie kader).
Tijdens de fase business modelling wordt het bedrijf gemodelleerd. De modelleur kan het bedrijf in vier stappen in kaart brengen: modellering van de produkt-marktcombinaties, van de produktie, van de organisatie, en van de besturing.
Eerst bepaalt de produktontwikkelaar de produkt/markt-combinaties (pmc’s) waarmee het bedrijf de markt benadert. Hij beschrijft deze pmc’s in termen van produkten en diensten die aan een bepaalde doelgroep via een specifiek distributiekanaal worden geleverd. Na de analyse is een pmc onderverdeeld in produktcomponenten, servicecomponenten, distributiecomponenten en doelgroepcomponenten.
Een huurdersverzekering bestaat bijvoorbeeld uit de volgende componenten:
– produktcomponent: inboedelverzekering en aansprakelijkheidsverzekering
– servicecomponent: afzeggen van bestaande verzekeringen
– distributiecomponent: direct writer of tussenpersoon
– doelgroepcomponent: regio Randstad (hogere premie) of overige regio’s.
De produktontwikkelaar kan elke component op detail-niveau verder uitwerken. Zo kan hij de inboedelverzekering in varianten opsplitsen. Varianten kunnen zijn: inboedelverzekering met extra dekking voor sieraden of voor computerapparatuur.
Vervolgens stelt de modelleur vast hoe de produkten en services geproduceerd worden. Daarbij kan hij redeneren vanuit de produkten: welke activiteiten moeten uitgevoerd worden om een bepaald produkt of service te leveren? Ook kan hij vanuit gebeurtenissen redeneren: welke activiteiten moeten worden uitgevoerd om een bepaalde gebeurtenis af te handelen? De activiteiten kunnen op detailniveau worden uitgewerkt door een activiteit in een aantal handelingen op te delen.
Als derde stap brengt de modelleur de organisatie in kaart. Hij onderscheidt afdelingen, operationele eenheden, middelen en rollen die onderling gerelateerd zijn. Het is mogelijk om middelen (mensen en machines) toe te wijzen aan operationele eenheden.
Ten slotte legt de modelleur de besturing van de activiteiten en handelingen vast. Dit is mogelijk met behulp van werkstroomanalyse. Bij activiteiten kunnen condities worden bepaald. Een acceptant mag bijvoorbeeld een schadeafhandeling tot een schadebedrag van � 500.000,- beoordelen. Zodra het bedrag hierboven komt, moet een acceptatie-comité de schadeafhandeling uitvoeren. De resultaten van de activiteiten kunnen worden vastgelegd in het werkdossier. Dat is een logboek van een gebeurtenis waarin mutatiegegevens per activiteit worden bijgehouden. Per gebeurtenis kan de modelleur vastleggen welke gegevens wel en welke niet in het werkdossier terecht moeten komen. Daarnaast zijn operationele eenheden en rollen te koppelen aan de gemodelleerde activiteiten. Op deze wijze kan de operationeel manager de werkstroom manipuleren.
‘Information en application modelling’
Het resultaat van business modelling (het bedrijfsmodel) wordt vastgelegd in een actieve repository. Daarna volgen de tweede en derde fase: information modelling en application modelling. De systeemontwikkelaars zetten het bedrijfsmodel om in een werkend informatiesysteem. Hiertoe moeten de handelingen die de modelleur heeft onderkend, gekoppeld worden aan geautomatiseerde taken. Door handelingen te koppelen aan operaties en operaties aan database-objecten (informatieve bewerking) respectievelijk software-modules wordt de koppeling volledig.
Hierdoor wordt aan het bedrijfsmodel daadwerkelijk programmatuur gekoppeld. Het is de kracht van de actieve repository dat het aanpassen van ondermeer het produktieproces geen gevolgen heeft voor de programmatuur. Zo is het mogelijk om de volgorde van activiteiten en de toewijzing van activiteiten aan personen on the fly aan te passen. Indien blijkt dat een proces voor opstoppingen zorgt, kan de operationele manager besluiten de volgorde van de activiteiten te veranderen en de activiteiten aan meerdere personen toe te wijzen. Doordat de repository de besturing heeft over de applicatie, wordt de werkstroom direct aangepast.
Bovenstaande aanpak is een methode om een informatiesysteem te ontwikkelen en te sturen op basis van een bedrijfsmodel. De organisatie kan het model aanpassen, waardoor ook het ondersteunende informatiesysteem direct wordt aangepast. Hierdoor ontstaat een flexibel informatiesysteem waardoor de organisatie snel nieuwe produkten op de markt kan brengen. Mass customization wordt hierdoor mogelijk.
Jaap Hoebe en André Leijser zijn respectievelijk werkzaam als senior consultant en als junior consultant bij Cap Gemini
[1] Verhoef, T.F.: Software-ontwikkeling met componenten: Beheer is complex. Computable
Integratie bedrijfsmodel met software-componenten
In het artikel ‘Software-ontwikkeling met componenten; beheer is complex’, Computable 29 (06.09.1996) p. 33-36, beschrijft T.F. Verhoef drie manieren om componenten samen te stellen: aggregatie, concatenatie en instantiatie. Deze integratie kan op logische en bedrijfsgerichte wijze tot stand komen indien men uitgaat van het bedrijfsmodel. Aggregatie wordt op activiteit-niveau gemodelleerd, concatenatie op handeling-niveau en instantiatie op operatie-niveau. Deze drie manieren om componenten samen te stellen worden hieronder toegelicht.
Aggregatie vindt plaats op activiteit-niveau. Voorwaarden als als/dan-constructies kunnen per activiteit gemodelleerd worden. De activiteit ‘Automatisch afboeken’ moet alleen plaatsvinden indien de klant heeft aangegeven dat hij ‘automatisch’ het bedrag van zijn rekening wil laten afschrijven. Indien dit het geval is, wordt de activiteit uitgevoerd en worden alle benodigde handelingen met de daaraan gekoppelde modules opgestart en uitgevoerd.
Concatenatie vindt plaats op handeling-niveau. Door handelingen in een bepaalde volgorde te zetten worden modules in die volgorde aangeroepen. De volgorde van de handelingen wordt bepaald door de bedrijfsregels die voor het betrokken bedrijf gelden. Het wijzigen van klantgegevens wordt uitgevoerd nadat deze zijn opgehaald. Eerst wordt de module ‘Selecteren klant’ opgestart en vervolgens de module ‘Wijzigen klantgegevens’ met de uitvoerparameter van ‘Selecteren klant’. Op deze wijze worden handelingen en daarmee software-componenten aan elkaar geschakeld.
Instantiatie (parameterisatie) vindt plaats op operatie-niveau. Operaties hebben in- en uitvoerparameters. Het berekenen van het factuurbedrag hangt bijvoorbeeld af van de wijze van betaling en van de frequentie van betaling. Door deze twee componenten als parameter door te geven, wordt het totaal factuurbedrag opgehoogd met een premie voor de betaalwijze en gedeeld door de termijnen. De in- en uitvoerparameters van de operatie worden gekoppeld aan de handelingen uit het bedrijfsmodel en aan de parameters van de software-componenten. De operatie legt de koppeling tussen software-componenten (modules) en het bedrijfsmodel.
Het bedrijfsmodel kan – zoals beschreven – de integratie verzorgen van software-componenten tot een applicatie. Noodzakelijk hiervoor is dat de voorwaarden per activiteit, de bedrijfsregels en de parameters worden vastgelegd in een actieve repository. Daarvan uit kunnen vervolgens de software-componenten worden aangestuurd. Aan het bedrijfsmodel wordt daadwerkelijk programmatuur gekoppeld. De organisatie kan het model aanpassen, waardoor ook het ondersteunende informatiesysteem direct wordt aangepast.
