Ontworpen wendbaarheid

Ontworpen wendbaarheid

In verschillende sectoren zijn grote vernieuwingstrajecten gestart op basis van nieuwe kennis, proces- en documenttechnologieën. De resultaten zijn wisselend. Hoe kan wendbaarheid worden beheerst door een modulaire configuratieaanpak voor de afzonderlijke onderdelen van de bedrijfsvoering, die is ontworpen vanuit het businessmodel en de bedrijfsarchitectuur?

Wiel Bruls, Marc Lankhorst, Edward Giesen, Paul Oude Luttighuis, Hans Slaets

Wendbaarheid – het vermogen om snel aanpas­singen door te voeren – is een zeer gewenste eigenschap van door ICT ondersteunde oplossin­gen voor bedrijfsvoering. De traagheid waarmee ICT-ondersteuning kan worden aangepast aan veranderende bedrijfsvoering is dan ook een knellend probleem. Naarmate het aantal syste­men toeneemt, neemt de complexiteit toe en de flexibiliteit af. De roep om ‘agility’ en de wens grootschalige ICT-inrichtingen wendbaarder te maken is een terugkerend thema.

Er is in de ICT-industrie bij herhaling gepro­beerd dit vraagstuk op te lossen. Initieel adresse­ren vooral pakketleveranciers de wens om gestan­daardiseerde functionaliteit aangereikt te krijgen, op zo’n manier dat deze aanpasbaar is aan de eigen bedrijfssituatie en kan meegroeien met veranderingen. Deze pakketfunctionaliteit heeft vastomlijnde grenzen waarbinnen aanpassingen mogelijk zijn. Service-gebaseerde architecturen verbreden de grenzen van deze aanpak: ze gaan uit van herbruikbare componenten die flexibel in elkaar te klikken zijn tot bedrijfsfuncties en processen. Configureerbare technologieplatforms ten slotte verbreden aanpasbaarheid tot alle deel­aspecten van de bedrijfsvoering, zoals bedrijfs­regels, zaakverwerking, dossiervorming, klantin­teracties, informatieanalyse en verwerking. Het aantal opties wordt met deze ontwikkelingen zo groot dat het proces van configuratie zelf en de daarvoor benodigde modellering van processen, kennis en informatie tot aanzienlijke doorlooptijden en complexiteit kunnen leiden.

Vooral in de publieke (en in mindere mate ook de financiële) sector, heeft de opkomst van deze configureerbare technologieplatforms een golf van vernieuwing op gang gebracht. In Nederland – wereldwijd een voorloper op dit gebied – is een complete niche van innovatieve bedrijven ont­staan die kennis, processen en informatie model­leren als voeding voor applicaties die gebruik maken van deze platforms. Soms met vertaalslagen vanuit deze modellen naar de technologie­platforms, soms de modellen direct executerend door het technologieplatform.

De ervaringen met deze transformaties – hoe innovatief en vernieuwend ook – lijken niet onverdeeld positief. Ze beogen een oplossing voor de bedrijfsvoering te ontwerpen die configu­reerbaar is als een integraal geheel. Dit leidt tot trajecten waarin uit een aantal technologieplat­forms een integraal uitvoeringsplatform wordt samengesteld dat de bedrijfsvoering ondersteunt. Vervolgens wordt de modellering van de beno­digde wettelijke kennis en de bedrijfsvoering integraal uitgevoerd. Aansluitend moet daaruit de configuratie-informatie afgeleid worden voor de verschillende onderdelen van het uitvoerings­platform die op verschillende technologiebases kunnen staan. Daarbij treden de volgende pro­blemen op:

De grote mate van detaillering en complexiteit van de integrale modellering maakt de configu­ratie ontoegankelijk en ondoorzichtig. De relatie met individuele delen van de bedrijfsvoeringom­geving (zoals klantportaal, aanvraagafhande­lingsysteem, informatiemagazijn) die operatio­nele configuratie-informatie vanuit de centrale configuratiemodellen ontvangen, is moeilijk te traceren.

De gekozen technologie van het uitvoerings­platform waarnaar de configuratie vertaald moet worden kan een beperkte of afwijkende aanpasbaarheid hebben. Daardoor is uitgebreid maatwerk en customisation nodig om de beoogde flexibiliteit te krijgen. Zo kan de keuze voor een ‘off the shelf ’-CRM-systeem met een gelimiteer­de zaakbesturingsaanpak grote maatwerkexten­sies vergen om de benodigde dynamische zaakbesturingsaanpak mogelijk te maken.

De gekozen bandbreedte van de oplossing kan bij nader inzien te nauw gekozen zijn of te veel vanuit één perspectief, wat de acceptatie van het systeem door gebruikers belemmert. De keuze voor een op werkstroom gebaseerde oplossing kan bijvoorbeeld knellend gaan werken voor kenniswerkers indien deze initieel vooral op administratief routinewerk ingericht is.

De benodigde expertise en vaardigheden voor configuratie zijn schaars, wat kan leiden tot flessenhalzen en processen over meerdere partij­en die de flexibiliteit tenietdoen. Waar gestreefd werd naar een oplossing die zonder ICT-expertise aanpasbaar is, kunnen nieuwe afhankelijkheden ontstaan van kennisarchitecten, regelontwikke­laars en testtrajecten.

In een gezamenlijk project hebben IBM en Novay een methodisch kader ontwikkeld om deze problemen te voorkomen. Beschikbare en bewezen methoden en technieken van beide zijn daarin als basis samengebracht. Enerzijds de ‘Actionable Business Architecture’-aanpak ontwikkeld door IBM waarin op basis van strategische analyse van het bedrijfsmodel en industrietrends via projectie op de bedrijfs- en ICT-architectuur de modulaire structuur van een bedrijfsvoeringoplossing uitgewerkt wordt. En anderzijds analysetechnieken en modellen uit het ‘Agile Service Development’-project van Novay waarin modelmatig vorm gegeven wordt aan de ICT-inrichting na analyse van de dynamiek in het bedrijfsmodel. Deze zijn vervolgens gesyn­thetiseerd en verrijkt met op variatiemodellering gerichte technieken.

Apart ontwerp

De kerngedachte achter de ontwikkelde aanpak is dat wendbaarheid ontworpen dient te worden. Wendbaarheid expliciet positioneren als resultaat van een ontwerpproces creëert een eigen identi­teit en eigen doelstellingen: onderhoudbaarheid van configuratie, inzichtelijkheid voor de business, gewenste en mogelijke bandbreedte van de oplossingen. Door goed ontwerpen wor­den de eerder genoemde problemen voorkomen. ‘Goed ontwerpen’ impliceert: eenduidige begrij­pelijke modellen, die goed gesegmenteerd en afgebakend zijn, verbonden met en passend bij het uitvoeringsplatform, met een expliciet geko­zen bandbreedte van configuratie, uitvoerbaar met een beperkte set van vaardigheden.

De voorgestelde aanpak is deels geïnspireerd door concepten die ontwikkeld zijn voor mas­samaatwerkproductie (‘mass customization’) in de industriële fabricage - in de discipline van ‘Product Line Engineering’. Een productaanbod van bijvoorbeeld een autofabrikant wordt daarbij vormgegeven als een portfolio (een productlijn) van producten, dat modulair opgebouwd is. Dit portfolio is zo ontworpen dat hergebruik van de basisdelen mogelijk is en dat bepaalde product­delen (‘features’) eenvoudig aangepast kunnen worden (bijvoorbeeld type bekleding, motortype kleur, et cetera). De assemblage vindt plaats in een fabriek die afgestemd is op de bandbreedte van de te bouwen productlijn (compacte perso­nenauto’s bijvoorbeeld) en kan via configuratie eenvoudig aangepast worden. Figuur 1 laat zien dat ook een product waarin ICT een belangrijke factor is op eenzelfde conceptuele basis gestoeld kan worden.

De linkerkant van figuur 1 toont de concepten toegepast op een industrieel voorbeeld (autofa­bricage), de rechterkant toegepast op een admi­nistratief voorbeeld (vergunningaanvraag). De modulaire productopbouw is boven in de figuur getoond (als een ‘feature’ model), de implemen­tatie middels een fabrieksconcept is onder in de figuur getoond. Het gekozen voorbeeld is de aanvraag van vergunningen – wat vooral zichtbaar is in de ‘feature’-boom rechtsboven.

In onze aanpak trekken we de modulaire productopbouw uit de Product Line Enginee­ring-discipline door naar de gehele bedrijfsinrichting. De fabricagelijn bestaat uit losge­koppelde verwerkingseenheden die afzonderlijk configureerbaar zijn. Dit impliceert dat ook de fabriek die het product assembleert modulair opgebouwd is – en ondersteund wordt door een platform dat gedimensioneerd is op een bepaalde bandbreedte van verwerking die door configuratie kan worden aangepast op het te assembleren product. De getoonde voorbeelden zijn de operationele eenheden in een fabriek voor de productie van auto’s (links) en het verlenen van vergunningen (rechts). De vergunningen­omgeving bevat losse componenten die specifiek verwerking uitvoeren van een bedrijfsfunctie. Bij­voorbeeld een portaal waarin aanvragen worden ingevoerd, een magazijn voor opslag van feiten en bijlagen, een oplossing voor het behandelen van een aanvraag en voor het terugkoppelen van de resultaten (rapporteren). De indeling is algemeen vormgegeven en zou ook van toepassing kunnen zijn op andere typen producten – bijvoorbeeld een verzekeringaanvraag, belastingaangifte of uitkeringaanvraag.

De veranderingen in beide fabrieken (die gezamenlijk de wendbaarheid realiseren) zijn gemodelleerd in een spectrum van drie niveaus (midden in de figuur). Van lichte aanpassingen via eenvoudige configuraties op niveau 1, via functionele uitbreidingen van de productielijn op niveau 2 tot ingrijpende aanpassingen aan de fabriek zelf op niveau 3.

Het zal intuïtief duidelijk zijn dat assemblage van zeer verschillende producten op eenzelfde fabri­cagelijn moeilijker wordt naarmate de verschillen groter zijn. Compacte personenauto’s en SUV’s op dezelfde fabricagelijn assembleren is moeilijk, vrachtwagens assembleren is onmogelijk. De inrichting van de ICT-fabriek is op een vergelijk­bare manier beperkt van bandbreedte. Kunnen aanvragen voor eenvoudige vergunningen op dezelfde fabricagelijn worden afgehandeld als samengestelde vergunningen? Vast wel. Kunnen massale rechtszaken voor overtredingen van het snelheidsverbod op de A2 op dezelfde pro­ductiestraat worden afgehandeld als complexe strafrechtzaken met uitvoerige dossiers en over­leggen tussen juridische medewerkers? Vast niet. Vanwege deze bandbreedte zien we de verwer­kende productieomgeving in een aantal smaken verschijnen. Grootschalige massale verwerking van eenvoudige aanvragen, werkstroomgerichte verwerking van standaardzaken, en kenniswer­ker-gerichte verwerking van complexe aanvragen, et cetera. De hiervoor ingerichte omgevingen maken keuzes voor platformcomponenten en de inrichting daarvan. Die stellen grenzen aan de bandbreedte van wat de huidige fabriek kan ondersteunen (niveau 1 en 2), maar ook aan ver­andering bij verdere ontwikkeling (niveau 3). et zal ook intuïtief duidelijk zijn dat de inrich­ting van de fabriek zelf – de modulariteit ervan en hoe delen gekoppeld zijn – op niveau 3 een belangrijke rol speelt bij de wendbaarheid. Hoe eenvoudig is het een nieuw type verfinrichting toe te voegen aan een bestaande fabriek? Wat is de manier waarop de planning integraal plaats­vindt over verschillende productielijnen? Daar­naast zijn er optimalisatievragen: Wanneer is het verstandig een inrichting helemaal toe te snijden op één type product? En welke componenten kunnen er toch gemeenschappelijk zijn (de bestel-website?)? En transitievragen: In welke fases ga je over van een bestaande inrichting naar een nieuwe? De in het Industry Solution Agility-project ontwikkelde methodische aanpak is te zien in figuur 2.

Figuur 2 projecteert de analyseaanpak als een aparte lijn van analyse en ontwerpactiviteiten op bestaande strategie, architectuur en engineeringmethodes. In deze aparte lijn worden de variatie en de effecten in kaart gebracht en wordt de te ondersteunen configuratie ontwor­pen. De centrale artefacten op architectuurniveau uit bestaande methodes – businessmodel, bedrijfsvoeringmodel en ICT-platform – zijn getoond in het hart van figuur 2.

 

Strategieniveau

In de in het ISA-project ontwikkelde aanpak start de wendbaarheidanalyse op strategieniveau bij het businessmodel, met klant, product, productie en regelgeving als belangrijke deelgebieden – zie Osterwalder. Hiervoor worden de belangrijkste bronnen van variatie en de variaties bepaald en wordt de bandbreedte vastgesteld die deze creëren in de huidige en toekomstige ‘capabi­lities’. Via een projectie van de impact op het bedrijfsvoeringsmodel (klantinteractie, productie, partnerintegratie) worden de contouren gevisu­aliseerd van mogelijke configuratie-aanpakken en de bijpassende fabrieksinrichting van het ICT-platform. De eerste keuzes worden gemaakt voor de fabrieksindeling en de bandbreedte van fabrieksdelen. Bijvoorbeeld de keuze voor een aantal productielijnen (massaal, werkstroom en kennisgericht) die verschillende verwerkings­mechanismen per product ondersteunen, geïn­tegreerd onder een gezamenlijke aanvraagom­geving, en ondersteund door een gezamenlijke dossieromgeving – die op afstand staat van de productielijnen en apart benaderbaar is.

 

Architectuurniveau

Op architectuurniveau wordt vervolgens meer in detail de afbakening en ontkoppeling per compo­nent bepaald. Ook wordt de configuratieaanpak ontworpen en de projectie daarvan op de ele­menten in het ICT-platform die deze configuratie ondersteunen. Het configuratie-ontwerpproces moet de bandbreedte van de gewenste wend­baarheid en de selectie van het ICT-platform dat deze bandbreedte kan ondersteunen con­sequent op elkaar afstemmen. Dit gebeurt op basis van variatiepatronen in het businessmodel die als strategische ‘use cases’ te beschouwen zijn (bijvoorbeeld nieuwe klantsegmenten met eigen karakteristieken, nieuwe samenwerkings­patronen, nieuwe wettelijke regelingen). De op te leveren configuratieschema’s moeten tot goed gevormde en voor de business begrijpelijke ‘sjablonen’ leiden die de productie besturen. De inzichtelijkheid voor de business is gebaat bij de toepassing van eenvoudige metaforen. Bijvoor­beeld een bevoorradingsketen van auto-onder elen als metafoor voor een informatie verwer­kende straat – waarmee een publieke instelling informatie van derden betrekt om de uitvoering van regelingen op te baseren. Het configura­tiesjabloon is in dit geval gemodelleerd op een pijplijn die sequentieel functies uitvoert en de ontvangen feiteninformatie verwerkt tot halffa­bricaten – wettelijke grondslagen waarop regelge­ving van toepassing is. Of een catalogus gedreven bestelproces als metafoor voor aanvragen voor vergunningen, belastingen of uitkeringen die zijn gebaseerd op wettelijke regelingen. Daarin wordt afzonderlijke regelgeving gecombineerd tot een overkoepelende menukaart van aanvragen. De catalogus bepaalt welke regelsets gecombineerd worden en door welke productiestraat de aan­vraag afgehandeld wordt (massaal, werkstroom of kenniswerker bijvoorbeeld).

Engineeringsniveau

Het uiteindelijk doel van ontworpen wendbaar­heid is eenvoudige configuratie op enginee­ringniveau van de inrichting vanuit een voor de business begrijpelijke omgeving. De ontworpen configuratieschema’s worden gedetailleerd en ‘gemapt’ op de verschillende technologiecom­ponenten. Indien nodig dienen er vertaalslagen ondersteund te worden die de configuratiedata converteren naar de metadata van de ICT-pro­ducten van het platform. Bijvoorbeeld een vertaling van een hiërarchische sjabloon voor een behandelplan in de specifieke metadata die het CRM-systeem vereist. Of de vertaling van een catalogus van regelschema’s in operationele stuurinformatie voor klantgerichte portalen geba­seerd op formulier- of regeltechnologie.

 

Strategische en operationele wendbaarheid

De kern van de wendbaarheid die met behulp van deze aanpak wordt verkregen speelt zich af op twee niveaus:

1. Strategische wendbaarheid ontstaat waar gelijktijdige ontkoppeling van bedrijfsvoering­componenten en van onderliggende delen van het technische platform scharnierpunten voor verandering introduceren. Dit is een diepe fun­damentele wendbaarheid op het niveau van de bedrijfsvoering en fabrieksinrichting die langetermijnkeuzes en inzicht vanuit het businessmodel nodig heeft. Bijvoorbeeld de ontkoppeling van een feiten- en bijlagenleverstraat en deze op afstand plaatsen van de productiestraat waar aan­vragen worden verwerkt. Dit creëert op dit scharnierpunt vele toekomstige veranderscenario’s, bijvoorbeeld het ophalen van informatie indien deze niet geleverd is, of het op steekproefbasis opvragen van informatie uit de productieomge­ving.

2. Operationele wendbaarheid ontstaat door een configuratieaanpak per individuele com­ponent. De goede keuze van de bandbreedte is de kern van de operationele wendbaarheid. Bijvoorbeeld een catalogus-gedreven configuratie van een vergunning uit modulaire regelsets die door individuele uitvoeringsorganisatie worden beheerd.

De hier geïntroduceerde methodische aanpak ondersteunt ‘ontworpen wendbaarheid’. Hiermee wordt het mogelijk wendbaarheid te ontwerpen die een groot spectrum van veranderingen afdekt. De opgestelde configuratieschema’s zijn te beschouwen als een domeinspecifieke taal – op maat gesneden voor het specifieke businessdo­mein en de gekozen strategie. Dat differentieert onze aanpak van eerdere pogingen. Denk daarbij aan pogingen gericht op aanleg van één centrale opslagfaciliteit voor technologie-specifieke confi­guratiedata (metadata), echter zonder integratie onder het businessmodel.

De aanpak is daarnaast gebaseerd op de funda­mentele veronderstelling dat op veel mogelijke ontwikkelingen redelijk valt te anticiperen, en op basis hiervan ontwerp van wendbaarheid moge­lijk is. Het valt te verwachten dat op termijn zich­zelf vormende ecosystemen spontaan clusters van diensten genereren – waar wendbaarheid ontstaat eerder dan ontworpen wordt. Voor de huidige onderneming echter is ontworpen wend­baarheid een antwoord op veel problemen.

 

KADER: Tactieken voor wendbaarheid
Anticiperen op veranderingen in het businessmodel: een van de krachtigste gebruiken van het hier gepresenteerde kader is de bepaling van de impact van strategische ontwikkelingen op het businessmodel. Er is een aantal manieren waarop innovatie van businessmodellen verloopt (zie Giesen). Onderzoek van elk van deze manieren en projectie volgens het analysekader creëert een redelijke compleet spectrum van toekomstige keuzes, op basis waarvan fundamentele scharnierpunten voor de inrichting bepaald kunnen worden.
Het goede abstractieniveau en partitioneren: vooral bij de kennismodellering op basis van wettelijke regelgeving zien we op dit moment de valkuilen ontstaan die eerder voorkwamen bij de introductie van databases – de ambitie om een ondernemingsbreed ‘enterprise information model’ op te stellen. Dit leidde tot zeer complexe en uitgebreide modellen die nauwelijks meer te interpreteren waren. De kennismodellen zoals die nu ontwikkeld worden, beginnen vaak met een vergelijkbaar groot detailniveau. Deze modellering wordt beheersbaar door eerst een goede top-downstructuur te creëren. Deze moet een abstractieniveau hebben dat aansluit bij de belangrijkste elementen uit het businessmodel (klanten, projecten, behandeling, activiteiten en objecten). Vervolgens kunnen hieronder meer gedetailleerde, losse modellen worden ontwikkeld. Elk fabriekscomponent heeft daarbij zijn eigen configuratiemetaforen (‘right sized models')
Evolutionaire patronen: We hebben eerder gepleit voor een evolutionaire aanpak van ICT-oplossingen (Bruls). Ook in geval van een configuratieaanpak geldt dit. Transitie naar een nieuwe doelomgeving kan stapsgewijs plaatsvinden met de introductie van integratielagen over bestaande systemen heen. Dat impliceert dat er ook configuratiepatronen op het niveau van deze integratielagen zullen ontstaan (bijvoorbeeld integratie van informatie uit silosystemen). Configuratieschema’s kunnen geleidelijk verrijkt worden naarmate een inrichting verder evolueert. Bijvoorbeeld een eenvoudig distributieknooppunt dat geleidelijk verwerkingsfunctionaliteit toevoegt die tot complexere besturingspatronen leidt.

 

 

De auteurs danken Peter Visser (enterprisearchitect bij het ministerie van I&M) voor review en suggesties.

 

Wiel Bruls

is enterprisearchitect bij IBM Global Business Services en architectuurleider voor de publieke sector.

E-mail: wiel_bruls@nl.ibm.com

Marc Lankhorst

is service line manager enterprise architecture bij BiZZdesign. E-mail: m.lankhorst@bizzdesign.nl

Edward Giesen

is partner bij IBM Global Business Services en leider van de Europese Strategy / Business Modeling practice.

E-mail: edward.giesen@nl.ibm.com

Paul Oude Luttighuis

werkt als adviseur bij Le Blanc Advies. E-mail: paul.oudeluttighuis@leblancadvies.nl

Hans Slaets

is enterprise engineer bij IBM Global Business Services. E-mail: hans_slaets@nl.ibm.com

 

Literatuur

Blecker, T. and G. Friedrich (2006) “Mass Customization: Challenges and Solutions”, Springer Science+Business Media, Inc. ISBN-13: 978-0387-32222-3.

Bruls, W. (2011) Transformatie Strategieën in de publieke sector Informatie 52, 7, pp 44 – 49.

Gartner, “IBM’s Federated Metadata Management Strategy”. Research Report G00147616, 16 April 2007

Giesen, E. S. J. Berman, R. Bell and A. Blitz (2007) “Three ways to successfully innovate your business model”, Strategy & Leadership, 35(6), pp. 27-33.

Harishankar, R., K. Holley, J. Sanz, E. Giesen, K. Daley, S. Antoun, M. Ibrahim, A. Botros, S. Vaidya, R. High, “Actionable Business Architecture: IBM’s approach”, IBM White Paper GBW03125-USEN-00, 2010.

Lankhorst, M. (ed.), Agile Service Development – Combining Adaptive Methods and Flexible Solutions, Springer, 2012.

Osterwalder, A., Y. Pigneur, and C.L. Tucci (2005) “Clarifying Business Models: Origins, Present and Future of the Concept”, Communications of the Association for Information Systems (16), pp. 1–25

 

 

 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag