Page 1

XR.

Editie 23 | Mei 2011 www.xr-magazine.nl

XR Magazine | Kennisdeling over de praktijktoepassing van Enterprise Architectuur

Thema

BPM en Architectuur

Waar begint het werk van de architect?

Business Process Management en Enterprise Architectuur Een gelukkig huwelijk?

IT in een Lean tijdperk De noodzaak voor Lean IT

Architectuur bij DSM De goede dingen goed doen

BPM- en verandertrajecten menselijker maken De waarde van organisatietypologie en transitieleiderschap

10

De Visuele Enterprise Architectuur van BetereZorg

Eenvoud in Architectuur Complexiteit aanpakken met Domain-Driven Design

Een voorbeeld op basis van Dragon1

34

36


Gratis uw evenement op de XR website? Heeft u een training, workshop, congres of seminar die u graag onder de aandacht wil brengen bij een breed publiek? Op de XR website kunt u gratis uw evenement plaatsen. Kijk voor meer informatie op: www.xr-magazine.nl/events


Do you know how to

eXceleRate? We do! BPM en Enterprise Architectuur: een gelukkig huwelijk

4 Voorwoord

BPM- en verandertrajecten menselijker maken

10

IT in een Lean tijdperk

16

BPMS versus ERP

22

Is meer integratie tussen BPM en SOA wenselijk?

26

Poster: Procesarchitectuur woningcorporatie

29

Architectuur bij DSM: De goede dingen goed doen

30

Complexiteit aanpakken met Domain-Driven Design

34

De Visuele Enterprise Architectuur van BetereZorg

36

Professionals over architectuur: Leendert Hinds

44

Business Process Management (BPM) is wellicht een welbekende managementdiscipline, maar BPM blijft heel actueel. De manieren van werken van medewerkers bij organisaties - in het kader van bijvoorbeeld Het Nieuwe Werken - veranderen snel; de wijze waarop klanten producten en diensten afnemen - met het internet als stuwende kracht - van organisaties eveneens. Ook de interactie en transacties tussen organisaties en hun ketenpartners zijn sterk aan verandering onderhevig. Van moderne organisaties wordt dus verwacht dat ze flexibel kunnen opereren en zich constant aanpassen aan veranderende omstandigheden. Daarnaast moeten ze steeds meer belang hechten aan klanttevredenheid, productkwaliteit en time-tomarket snelheid. In de praktijk leidt dit tot de situatie dat veel bedrijfsprocessen opnieuw ontworpen moeten worden. En, met ontwerpen zitten we ook al snel op het terrein van de architect. Als we dan weten dat herstructureren nodig is en hier een architect of BPM team mee aan de slag gaat, dan lijkt de zaak opgelost. Maar bedrijfsprocessen ontwerpen blijkt toch wat lastiger dan we zouden verwachten. Er zijn tal van vragen die de kop op steken bij het ontwerpen die het allemaal wat complexer maken. Welke bedrijfsprocessen heeft een organisatie nu eigenlijk nodig? Zijn er generieke bedrijfsprocessen mogelijk en welke? En u weet vast nog meer en betere vragen te bedenken met zo mogelijk nog lastigere antwoorden. In deze editie van XR Magazine kunt u lezen welke invalshoeken door de auteurs gekozen zijn om deze problematiek te benaderen. Zij belichten in ieder geval welke problemen zij zien. Maar, hebben zij ook de ultieme oplossingen‌? Ik wens u weer veel leesplezier!

Koen van Boekel

mei 2011 XR Magazine

3


BPM en EA

BPM en Enterprise Architectuur: een gelukkig huwelijk In dit artikel wordt de stelling geponeerd dat de beste manier om Business Process Management (BPM) in een bedrijf te implementeren, langs de as van Enterprise Architectuur is. Met name de benadering van Enterprise Architectuur zoals die door het The Open Group Architecture Framework (TOGAF) wordt gepropageerd is een ideaal vehikel om BPM op een planbare en iteratieve manier continu waarde te laten toevoegen. Dit artikel beschrijft hoe Business Process Management op basis van TOGAF ge誰mplementeerd kan worden in de onderneming en welke rol de enterprise architect hierbij heeft. Hans Diepstraten

BPM als onderscheidende factor In een globaliserende wereld leggen bedrijven zich in toenemende mate toe op het optimaliseren van hun hele procesketen, met de klant als uitgangspunt. De managementdiscipline die hieraan uitdrukking geeft wordt Business Process Management (BPM) genoemd. Omdat BPM in dit kader de gehele waardeketen van de onderneming omvat, inclusief de relaties met business partners (leveranciers, co-engineers en co-makers) is steeds vaker de term Enterprise BPM van toepassing, ter onderscheiding van lokale en tactische procesverbeteringen.

Initiatieven om BPM ondernemingsbreed uit te rollen zijn op zijn minst ambitieus en altijd risicovol Initiatieven om BPM ondernemingsbreed uit te rollen zijn op zijn minst ambitieus en altijd risicovol. Een onderzoek van het gezaghebbende instituut BPTrends in 2010 onder een groot aantal bedrijven leverde een complex beeld op van initiatieven waarbij strategievorming, competentieontwikkeling, implementatie van tactische procesver4

XR Magazine mei 2011

beteringen en automatiseringsprojecten in allerlei combinaties werden opgepakt en uitgevoerd. Opvallend in het onderzoek was dat maar liefst 49% van de respondenten aangaf dat het opzetten en inrichten van Enterprise Architectuur als onmisbaar onderdeel werd gezien van het BPM programma van hun bedrijf. De belangrijkste reden hiervoor is dat Enterprise Architectuur bij uitstek een holistische discipline is. BPM vereist inspanning op strategisch, tactisch, organisatorisch en implementatieniveau, en overschrijdt individuele disciplines. Het toepassen van Enterprise Architectuur op basis van bijvoorbeeld TOGAF1 vormt dan ook een perfect raamwerk voor het ontwikkelen van BPM binnen een organisatie. Wat wellicht nog opvallender is in het onderzoek van BPTrends, is dat meer dan de helft van de bedrijven (51%) blijkbaar nog niet tot het inzicht is gekomen dat Enterprise Architectuur kan helpen bij het ontwikkelen van BPM binnen hun organisatie. Als reden hiervoor zou kunnen gelden dat de afstand die bij veel bedrijven tussen business en IT bestaat een gelukkig huwelijk in de weg staat.

Het ideaal: end-to-end procesmanagement De kwaliteit van de bedrijfsprocessen bepaalt voor een belangrijk deel het succes van een bedrijf. Het vermogen om de bedrijfsprocessen integraal te kunnen managen en optimaliseren draagt bij tot die vereiste hoge kwaliteit.


“Het toepassen van Enterprise Architectuur op basis van bijvoorbeeld TOGAF vormt een perfect raamwerk voor het ontwikkelen van BPM binnen een organisatie.”

Door het hanteren van actuele managementconcepten en het toepassen van de beschikbare tools op de juiste manier wordt end-to-end procesmanagement mogelijk. Bedrijfsprocessen zijn in de hedendaagse economische context in hoge mate veranderbaar en moeten flexibel zijn. In een toenemend aantal processen zijn externe partners verantwoordelijk voor de uitvoering van delen van het proces. Ieder bedrijf moet echter controle houden op de uiteindelijke dienstverlening aan de eindklant waarbij de gehele keten in ogenschouw moet worden genomen, dus ook die delen van het proces waar een externe partij verantwoordelijk voor is. De regiefunctie moet in eigen hand gehouden worden, hetgeen betekent dat de procesorchestratie en choreografie door het bedrijf zelf moet worden bewaakt. Om dit mogelijk te maken is een groot aantal gerelateerde zaken noodzakelijk: • Gedeelde procesdefinities (Procesarchitectuur) • Gedeelde data- en begripsdefinities (Informatie architectuur) • Beschikbaarheid van integrale BPM platform tooling (applicaties, infrastructuur) • Overeenstemming over te bereiken verbeteringen (business case) • Overeengekomen scope en fasering voor implementatie van de gehele keten (roadmap planning) • Programma- en projectimplementatiemethodieken

die recht doen aan BPM als specifieke materie en discipline • Competentieontwikkeling voor BPM voor alle verschillende stakeholders Al deze elementen zijn onderdeel van een integrale Enterprise Architectuur.

De Enterprise Architect als BPM regisseur Wie de bovenstaande aspecten even op zich laat inwerken en probeert zich een beeld te vormen van wie hiervoor binnen een bedrijf de aangewezen persoon of groep is om zich hierop te richten en verantwoordelijkheid te nemen, zal tot de conclusie komen dat veel verschillende belanghebbenden ieder voor een deel verantwoordelijk zijn. Juist daarom is het cruciaal dat die verschillende belanghebbenden hun activiteiten en beslissingen op elkaar afstemmen. Enterprise Architectuur levert de conceptuele aanpak, evenals de concrete producten en best practices die het mogelijk maken zo’n complex onderwerp als BPM op een gestructureerde manier in een bedrijf in te voeren. Het is hierbij ook de taak en verantwoordelijkheid van de enterprise architect om de verschillende betrokkenen ieder vanuit hun eigen rol in beweging te krijgen om de juiste activiteiten te ontplooien die passen bij de BPM roadmap. In feite is de enterprise architect vanuit zijn discipline de enige betrokkene die alle verschillende mei 2011 XR Magazine

5


aandachtsgebieden met elkaar in verbinding kan brengen en de regie te kunnen voeren over de uitvoering van de noodzakelijke stappen.

Waar te beginnen

Prelim: Framework and Principles

In de managementtheorie wordt veelal uitgegaan van een ’top down‘ benadering, waarbij de tactische en operationele stappen gezet worden op basis van een gedegen strategische basis. Een nadeel hiervan is dat het nog wel eens tegenvalt om een heldere top down A. BPM strategie op te leveren en vooraf buy-in Architecture te verkrijgen voor een BPM roadmap. ZonVision der duidelijke criteria en aantoonbaar H. B. succes is investeren lastig te motiveArchitecture Business ren. Change Architecture Management Eén van de grote voordelen van een architectuurbenadering als TOGAF is dat het niet per se noodzakelijk is om top down te beginnen. TOGAF is het leidenC. G. Information de architectuurraamwerk binRequirements Implementation Systems nen de Enterprise Architectuur Governance Management Architectures discipline en blinkt uit in het in verband brengen van verschillende aandachtsgebieden en het faseren van de inrichting van een holistische Enterprise Architectuur. F. D. Omdat het raamwerk van TOGAF Migration Technology Planning Architecture daarbij veel houvast biedt is het moE. gelijk overal in de Architectuur OntwikOpportunities kel Methodiek (ADM)–cyclus van TOGAF te and beginnen en daar voortgang te boeken waar Solutions de grootste kans op succes aanwezig is. Mensen komen pas in beweging als er aantoonbaar voordeel te behalen is. De praktijk wijst uit dat er altijd wel een stakeholder is die gemotiveerd is vanuit zijn of haar deel- Figuur 1: TOGAF Architectuur Ontwikkel Methodiek belang om stappen vooruit te zetten. (ADM)-cyclus

6

Realisatie van een door allen gedeelde roadmap

Ontwikkeling van een BPM Roadmap onder architectuur

Bij het realiseren van een BPM roadmap bewijst TOGAF de grote meerwaarde die dit raamwerk kan leveren. TOGAF gaat uit van een incrementele en iteratieve implementatie van Enterprise Architectuur. Dezelfde incrementele benadering is van toepassing op de ontwikkeling en uitvoering van een BPM roadmap. Waar de enterprise architect expliciet de rol van BPM regisseur op zich neemt kan deze een door alle betrokkenen gedeelde roadmap definiëren en realiseren in een aantal afgestemde iteraties. Een dergelijke Roadmap kent daarbij drie belangrijke dimensies: de fasering volgens de fasen van TOGAF, de “capabilities” die vanuit de BPM theorie moeten worden ontwikkeld en ten slotte de ambities van het bedrijf zoals vertaald in een te hanteren maturity model.

In de verschillende fasen van TOGAF komen in wisselende samenstellingen de stakeholders van BPM aan de beurt om stappen te zetten en beslissingen te nemen. Kern hierbij is dat TOGAF dan wel expliciet van “Fasen” spreekt, maar dat hier niet per se een vaste volgorde in tijd en oplevering van deliverables bij hoeft te horen. Die automatische volgtijdelijkheid van de TOGAF fasen is eigenlijk alleen van toepassing bij bedrijven die een zeer hoge maturity hebben bereikt in hun Enterprise Architectuur proces. In verreweg de meeste gevallen is dit echter niet het geval. De fasen van TOGAF zijn daarom eerder aandachtsgebieden c.q. domeinen die wel elkaars producten gebruiken, maar niet in een vaste volgorde worden doorlopen. Juist omdat de producten per

XR Magazine mei 2011


fase bekend zijn, kun je zonder gevaar voor foute stappen in iedere fase voortgang boeken, zolang je die producten en gezichtspunten per fase blijft respecteren.

Fase Business Architectuur De Business architectuur van een onderneming wordt volgens TOGAF gevormd door de bedrijfsstrategie, de governance, de organisatie en de belangrijkste bedrijfsprocessen. In termen van BPM vindt men hier dus een grote mate van overlap. Ross en anderen beschrijven in het standaardwerk “Enterprise Architectuur als Strategie” (2006) [1] hoe een Enterprise Architectuur een “platform voor executie” moet opleveren dat het business model van het bedrijf optimaal ondersteunt. Von Rosing (2010) [2] benadrukt vanuit zijn BPM gedachtegoed dat de business architectuur opgebouwd moet worden vanuit de kerncompetenties en “capabilities” van een bedrijf. Daarbij maakt hij onderscheid tussen enerzijds kerncompetenties die noodzakelijk zijn om überhaupt te kunnen concurreren en kerncompetenties die ook echt een concurrentievoordeel opleveren. Het zijn die laatste competenties die in de inrichting van een Enterprise Architectuur tot bijzondere investeringen en oplossingen kunnen en mogen leiden. Competenties die slechts dienen om volgens industriestandaard te leveren (en derhalve geen concurrentievoordeel opleveren) dienen in zijn ogen te worden ondersteund met standaard IT “best practices” zoals geleverd door bijvoorbeeld Commercial Off the Shelf (COTS) standaard (ERP) pakketten. Door deze benadering van bedrijfsprocessen als implementatie van onderliggende competenties en “capabilities” wordt ook het flexibele en veranderlijke van de bedrijfsprocessen expliciet gemaakt. In end-to-end procesketens zullen meer en meer veranderingen optreden, zoals het uitvoeren van delen van het proces door externe business partners, of het radicaal verkorten van een procesketen door de introductie van een internetgebaseerde procesafloop. De processen moeten dus vooral niet in “elektronisch beton” worden gevangen, maar moeten “orchestreerbaar” zijn.

Fase Informatiearchitectuur Informatietechnologie speelt tegenwoordig een dominante rol in vrijwel alle bedrijfsprocessen en is daarom ook cruciaal met betrekking tot BPM. Enterprise Architectuur zorgt voor een heldere mapping van IT oplossingen en platforms op de eisen die vanuit de BPM filosofie aan IT gesteld worden. BPM gaat uit van end-to-end procesketens. In termen van IT architectuur betekent dit dat applicaties en data de gehele procesketen moeten ondersteunen. De begrippen Orchestratie en Choreografie staan hier centraal. De

ondersteuning van een gehele procesketen over afdelingen, systemen en business partners heen vereist dat data in de gehele procesketen beschikbaar is. Een ander vereiste is dat de benodigde IT-resources in het gehele proces beschikbaar zijn ongeacht in welke applicatie de functionaliteit is opgesloten. Een Service Oriented Architecture (SOA) is daarom een natuurlijke bondgenoot van BPM.

Een Service Oriented Architecture (SOA) is een natuurlijke bondgenoot van BPM Het bekende CORA-model (Common Reference Architecture) [3], zie figuur 2, geeft helder weer hoe een op Service Oriented Architecture gebaseerde IT applicatiearchitectuur BPM kan ondersteunen. De gelaagdheid van een architectuur conform het CORA-model maakt het mogelijk de verschillende aandachtsgebieden efficiënt en effectief te verdelen en zorgt ervoor dat bij het ontwerp en de implementatie een zo flexibel mogelijk resultaat wordt bereikt. Omdat echter de intrinsieke complexiteit van een dergelijke architectuur groot is, kan alleen een goed resultaat bereikt worden als alle componenten ervan ook onder Enterprise Architectuur worden gemanaged en ontwikkeld.

Fase Technische Infrastructuur Hoe een BPM programma ook wordt ingestoken, op een zeker moment zullen feitelijke implementaties van BPM op basis van een Business Process management System (BPMS) plaats gaan vinden. In de meeste grotere bedrijven is de keuze voor een dergelijk BPMS geen sinecure. Omdat de in de markt beschikbare BPMS systemen van oorsprong uit verschillende domeinen zijn ontwikkeld (Workflow- en Case Management systemen, EAI-middleware platforms, Document management systemen) is de kans groot dat zich in het platformportfolio van een bedrijf reeds verschillende kandidaat-BPMS systemen bevinden. Het is de verantwoordelijkheid van de enterprise architect om hierbij de juiste technologische keuzes te maken. Overwegingen hierbij kunnen onder andere zijn de relatieve kwaliteit van de betreffende BPMS-tooling, de mate waarin het BPMS integreert met het bestaande applicatielandschap (zoals de ERP-systemen), de aanwezige kennis binnen de organisatie, de geldende licentiekosten en uiteraard de prioriteiten die binnen het bedrijf bestaan, omdat die uiteindelijk de business case moeten waarmaken. mei 2011 XR Magazine

7


Security & Compliance

Channel Access Ultra Thin Client Ultra Thin Client

Rich Client

Thin Client Web Browser (HTML)

Mobile Device

Webbrowser (RIA)

Portal

Workstation

Electronic Channel

Presentation User Interface Process

User Interface Integration

User Interface

Composition Orchestrated H2A Orchestration

A2A Orchestration

Composed

H2H Collaboration

B2B Orchestration

Business Component

Business Entity

Business Rules

Integration Synchronous communication

Service Policy

Principal Propagation

Service Repository

Encryption

Service Registry

Compliancy

Business activity monitoring

Authorisation

System Management

Single Sign On

System Monitoring

File Transfer

Messaging

Integration metadata

Repository Management

Auditing

Change Management Configuration Management

Application Make Application Logic

Buy Application Entity

Application Logic

Legacy Application Entity

Application Logic

Application Entity

Data Access

Batch Management Backup & Recovery

Data Data Access

Test Management

Logging Common Integration core functionality

SOA Governance

Authentication

User Management

A-Synchronous communication

Service mediation

IT Governance

Data Storage Master Data

Transactional Data

Unstructured Data

Aggregated Data

Canonical Data

Figuur 2: CORA-model

Business Process Management levert meer waarde naarmate ook onderwerpen als integrale procesmonitoring, Business Activity Monitoring en Dashboard rapportages worden meegenomen. In veel gevallen zijn de beschikbare applicaties die deze (niet per se in het BPMS aanwezige) functionaliteit leveren afkomstig van producten van verschillende leveranciers en daar zal dus ook een enterprise architect de samenhang moeten bewaken. Ten slotte is het heel waarschijnlijk dat uiteindelijk meerdere BPMS systemen tegelijkertijd binnen een organisatie zullen worden gebruikt. Het voorkomen van meerdere “inboxen” voor de eindgebruiker leidt dan tot een integratie- en federatie behoefte met betrekking tot de verschillende tools. Deze infrastructurele en platform gerichte aspecten hebben te maken met de levenscyclus van de applicaties en infrastructuur en hebben daarom ook impact op c.q. worden geraakt door beschikbare investeringsbudgetten evenals het operationele beheer. In TOGAF termen wordt hier een sterke nadruk gelegd op het zogenaamde “Enterprise Continuüm” waarmee de maturity van aanwezige componenten en oplossingen kan worden gestuurd en continu afgestemd met de ambities van een bedrijf. Hoe snel een bedrijf kan bewegen in de richting van BPM wordt dus mede bepaald door de aanwezige basisarchitectuur. 8

XR Magazine mei 2011

Fase Opportunities & Solutions In veel gevallen begint een Roadmap voor BPM niet vanuit een formeel architectuurproces of een top down BPM visie, maar vanuit een concrete behoefte die binnen het bedrijf leeft en waarvoor “toevallig” BPM een passende oplossing is. In de TOGAF fase ‘Opportunities & Solutions’ worden de methoden en middelen aangereikt waarmee kandidaat-processen voor BPM(S) kunnen worden geëvalueerd en in prioriteit en aantrekkelijkheid gemeten. Met behulp van een “Process Discovery” methodiek wordt expliciet gemaakt welke waarde een BPMS-oplossing zal toevoegen aan de bestaande procesarchitectuur van een bedrijf. Het gaat hierbij vooral om procesoptimalisatie op basis van hogere transparantie, efficiency en effectiviteit, het verlagen van het aantal fouten in het proces, het wegautomatiseren van handmatige processtappen en het vereenvoudigen van invoerschermen voor de eindgebruiker. In de regel zoekt men in een beginfase van BPMS implementaties naar processen die een hoge zichtbaarheid hebben voor de business, maar relatief laag in complexiteit zijn. Daarmee kan dan ervaring worden opgedaan die later kan worden gebruikt om de complexere processen aan te pakken. Het zal duidelijk zijn dat bij het bepalen van de mogelijkheden en de verwachte voordelen ook de maturity op het gebied van IT tooling en de bestaande IT Roadmaps


moet worden meegewogen. Ook wordt in deze fase gekeken naar de onderhoudbaarheid van een voorgestelde oplossing. De meeste BPMS implementaties worden immers gekenmerkt door een relatief hoge infrastructuurcomplexiteit, waarbij tools uit verschillende lagen van het CORA-model gezamenlijk worden ingezet om een proces te stroomlijnen. Het is de enterprise architect die de technische haalbaarheid van de voorgestelde oplossing toetst en de ontwerpen architectuurprincipes aandraagt waar potentiële projecten zich aan moeten conformeren om het geheel consistent te houden.

Fasen Migratieplanning, Implementatie en Change Management De TOGAF fasen Migratieplanning, Implementatie en Change Management hebben betrekking op de feitelijke executie en operatie van processen. Dit zijn de gebieden die normaliter het domein zijn van respectievelijk het Programma Management en de Beheer organisatie. Enterprise Architectuur helpt een BPM programma in deze fasen op de volgende gebieden: • Scheiding van verantwoordelijkheden en bepaling van de bewegingsvrijheid voor definitie van projecten met een BPM component. • Bewaking van afhankelijkheden en impact bij veranderingen. • Opzetten van Proces en Scenario-gebaseerd testen over de gehele procesketen. • Meten van feitelijke proces performance ten opzichte van Proces Performance Indicatoren. • Versnelling bij het oplossen van procesknelpunten en -issues. • Ondersteunen van management en eindgebruikers door middel van BPM Monitoring Dashboards. • Verlaging van de werkdruk bij operationeel beheer door het leggen van bepaalde procestaken bij eindgebruikers in de business (bijvoorbeeld het bijhouden van business rules). BPM implementaties kunnen bij uitstek op incrementele en iteratieve manier worden opgezet. Dit betekent dat de doorlooptijd van de projecten aanzienlijk lager kan liggen dan men doorgaans gewend is. Door steeds nieuwe functionaliteit toe te voegen op basis van de intrinsieke flexibiliteit van BPM als gescheiden orchestratie- en choreografielaag bovenop de bestaande applicatiearchitectuur kan daarbij continu waarde worden toegevoegd. In de regel worden BPMS implementaties “agile” uitgevoerd, door middel van het gebruik van implementatiemethodieken als SCRUM, ATERN en RUP.

Tot slot In dit korte bestek kon natuurlijk slechts in vogelvlucht ingegaan worden op de meerwaarde die bestaande con-

cepten en “best practices” uit de Enterprise Architectuur kunnen bieden bij het “best practice”ontwikkelen en uitvoeren van BPM programma’s. BPM begint in de business en niet binnen IT. Zowel bij strategische (top down) als tactische (op procesoptimalisatie gerichte) BPM initiatieven is het op de juiste manier verbinden van business en IT een belangrijke succesfactor. Top down BPM (van Business Model naar Capabilities naar Procesarchitectuur) past naadloos in de meer op governance en business architectuur gerichte fasen van TOGAF. Procesoptimalisatie ondersteund door implementatie van BPMS systemen vereist een gedegen en goed doordachte IT architectuur, zowel wat betreft applicaties, data als infrastructuur. De brugfunctie van de enterprise architect is hierbij cruciaal.

De architect kan de business optimaal ondersteunen in een BPM programma De architect speelt ook een belangrijke rol in het stellen van de randvoorwaarden en ontwerpprincipes in de fase waarin mogelijke projecten worden vastgesteld op basis van business prioriteiten. In de Implementatie- en Operatiefase bewaakt de architect de voortdurende aansluiting van oplossingen en technologische mogelijkheden. Tevens zorgt de architect ervoor dat de samenhang van de deliverables en producten uit de gehele TOGAF cyclus op elkaar blijven aansluiten en dat de maturity levels van iedere fase een logisch verband blijven houden. Alleen de enterprise architect heeft de ervaring, capaciteiten en methodische expertise in huis om, geholpen door een raamwerk als TOGAF, de business optimaal te kunnen ondersteunen in een BPM programma en is onmisbaar om dit uiteindelijk tot een succes te maken. Voetnoten 1

Een algemene kennis van TOGAF wordt in dit artikel voorondersteld; zie

www.opengroup.org voor meer informatie.

Referenties [1] Enterprise Architecture as strategy, 2006, ISBN 978-1-59139-839-4 [2] Applying Real-World BPM in an SAP Environment, 2010, ISBN 978-1-59229343-8 [3] CORA-model, www.coramodel.com

Hans Diepstraten (1958) is enterprise architect bij Creetion: www.creetion.com. E-mail: hansdiepstraten@creetion.com mei 2011 XR Magazine

9


Verandertrajecten

BPM- en verandertrajecten menselijker maken De waarde van organisatietypologie en transitieleiderschap Stappenplannen voor een reorganisatie of verandertraject komen sterk overeen tussen organisaties. Ontwerpers en visionairs bepalen een doel en maken een (architectuur)model, hopelijk vanuit de strategie en marktontwikkelingen. Vervolgens wordt er een bedrijfsprocessenmodel ontwikkeld waarbij de operationele problemen als ontwerpvariabelen worden meegenomen. Daarna volgen de (keten)procesbeschrijvingen, eventueel aangevuld met procedures of werkinstructies. Hiermee zijn de blauwdrukken klaar en met een veranderprogrammaplan wordt het ingevoerd. En dan moet het gaan werken... toch? Nee, het succes is beperkt en bijsturingen tijdens het invoeren komen frequent voor. Wat is er mis? Oscar Sijtsma

De mens centraal De namen voor modellen en plannen die gebruikt worden bij reorganisaties of verandertrajecten verschillen sterk tussen organisaties, de aanpak weinig. Wat vergeten wordt in de voorbereiding en te weinig aandacht krijgt tijdens het veranderen is de menselijke kant. Twee belangrijke hoofdzaken ontbreken namelijk te vaak. Als eerste ontbreekt in de blauwdrukken de beschrijving van ‘de zachte kant’ van de nieuwe organisatie. Zaken als de gewenste cultuur, attitude, stijl van leiding geven, gedrag, competenties en attitude per functie. Dit vat ik samen onder de term organisatietypologie.

De organisatietypologie en het transitieleiderschap ontbreken bij reorganisaties en verandertrajecten De tweede ontbrekende hoofdzaak hangt hiermee samen. Als de organisatie moet veranderen dient gekozen te worden met welke manier van veranderen dat moet; het verandergedrag. Het verandergedrag dient bedacht te worden tijdens de voorbereiding en dient bij de invoe10

XR Magazine mei 2011

ring te worden toegepast. De term transitieleiderschap gebruik ik als typering voor de manier van leiden en sturen, communicatiestijl, de mate van strakheid en discipline tijdens de verandering. Veranderen is spannend, het verlaagt het gevoel van veiligheid. Het gebruikelijke en bekende wordt (geleidelijk of drastisch) verlaten. Dat heeft angstgedrag tot gevolg bij sommigen en bij anderen werkt het juist motiverend. Om mensen mee te krijgen in een verandering moet voor iedere betrokkene de noodzaak duidelijk zijn. Dit is essentieel om het noodzakelijke draagvlak te verkrijgen. Maar ook de uitwerking van de motivatie, drive, waarden en normen en attitude zijn essentieel. Deze sturende factoren voor het gewenste gedrag ontbreken meestal in de blauwdrukken, terwijl ze zeer relevant zijn. Een lichte vorm van ongewenst gedrag aan de top leidt tot grote afwijkingen, willekeur en onttrekkingsgedrag op de werkvloer. Als de directeur regelmatig iets te laat is op de stuurgroepvergadering zal de werkvloer zeer regelmatig te laat opleveren. Eén centimeter boven is één meter onder! Ongewenst gedrag vergroot zich uit met elke managementlaag. Daarmee komt u er dus niet, zeker als er juist verbeterd moet worden. Ik wil duidelijk maken dat door de organisatietypologie mee te nemen in het ontwerp (de blauwdruk) dit sturend wordt voor het transitieleiderschap. Daardoor zal de verandering succesvoller zijn, korter duren en het verande-


Soorten verandertrajecten

Hoofddoelen

Klantfocustrajecten

Customer intimacy [1] voordelen zoals: klanttevredenheid, herhalingsaankopen, marktaandeel, hoger gunningspercentage.

Bedrijfsprocesoptimalisaties

Operational excellence [1] voordelen zoals: kostenbesparing, kwaliteitsverbetering, doorlooptijdverkorting.

Organisatieontwikkeling

Om strategische doelen - of operationele afgeleiden daarvan - te halen. Ze kunnen liggen op het vlak van product leadership [1] (meestal tijdelijk), customer intimacy of operational excellence.

Fusie-integraties

Integreren van bedrijven of divisies waarbij het doel van de overname kan passen bij customer intimacy of operational excellence.

Figuur 1: Soorten verandertrajecten

ren aangenamer verlopen voor de mensen: medewerkers, managers en veranderaars.

Soorten verandertrajecten Uit wetenschappelijk onderzoek naar grootscheepse verandertrajecten bij 23 grote Nederlandse bedrijven blijkt dat er vier soorten verandertrajecten zijn: klantfocustrajecten, bedrijfsprocesoptimalisaties, organisatieontwikkeling en fusie-integratie. Dit wetenschappelijk onderzoek [2] en mijn praktijkervaringen van de laatste acht jaar [3] zijn de bronnen waarop dit artikel is gebaseerd. In het onderzoek zijn bestuurders en (concern)directeuren geïnterviewd over de aanpak, structurering, succesfactoren en verbeterpunten van grootschalige verandertrajecten. Er werd gevraagd naar een recent of lopend verandertraject en naar verbeterideeën voor toekomstige verandertrajecten om te achterhalen wat werkt en wat beter moet. Deelnemende bedrijven waren: ABP, Achmea Groep, ADP Nederland, Agis groep, APX, Belastingdienst, E.ON Benelux, Essent, Gemeentewaterleidingen Amsterdam, ING Bank, Kadaster, NAM, NN, NRE Energie, Nuon, Postbank, Rabofacet, SNS Bank, SNS Reaal Groep, Staalbankiers, SVB en UWV. Uit het onderzoek blijkt dat de spontaan - dus ongeholpen - meest genoemde succesfactor voor verandertrajecten zijn (n=23): • Commitment en betrokkenheid van de top van de organisatie voor en tijdens de verandering (13).

Implementeren met programmamanagement aanpak, gebaseerd op gedegen visieontwikkeling en analyse (8). • Duidelijke doelen vaststellen en de veranderingen goed voorbereiden op alle aspecten (8). Elk soort verandertraject heeft zijn eigen hoofddoelen (zie figuur 1). Per soort verandering ontstaat een eigen set van ontwerpeisen, requirements, inrichtingsvariabelen en consequenties. Deze zijn nodig bij het maken van de blauwdrukken.

Voor succes is belangrijk dat managers en medewerkers hun nieuwe rol begrijpen Aangezien uit het onderzoek blijkt dat commitment en betrokkenheid van de top de belangrijkste succesfactor is, mag duidelijk zijn dat de manier waarop dit gedaan wordt ook van groot belang is. Tevens blijkt een groot belang voor analyse en voorbereiding. Aangezien deze informatie betrekking had op gerealiseerde of vergevorderde verandertrajecten concludeer ik hieruit dat er mei 2011 XR Magazine

11


in de uitvoering zaken zijn tegengekomen die beter hadden moeten worden voorbereid. Dit zijn deels onvoorziene consequenties en vaak zaken die met de zachte kant te maken hebben. De programmamanagementaanpak benadrukt het belang van leiderschap. Hoe fraai de architecturen en modellen ook zijn, bij de invoering ervan komen vaak nieuwe zaken naar boven. Hoe goed het programmaplan ook is tijdens het inrichten van de nieuwe bedrijfsvoering, er kunnen altijd nieuwe en onvoorziene gebeurtenissen plaatsvinden. Daar moet je mee om kunnen gaan. Het onderzoek toont aan dat goed leidinggeven aan de verandering net zo belangrijk is als een goede blauwdruk en een goed veranderplan.

processen worden ingevoerd, welke systemen moeten worden aangepast, welke afdelingen geraakt worden enz. Dus vooral wie wat wanneer moet doen. Een aspect van de transitie welke vaak vergeten wordt is hòe ze dat moeten doen. Als mensen anders moeten gaan werken is het belangrijk in het verandertraject de nieuwe manier van werken voor te spiegelen. Rationeel, rechtlijnig en zonder inspraak de nieuwe bedrijfsprocessen invoeren is mogelijk, maar als de mensen daarna klantgericht moeten zijn begrijpt u de discrepantie. Met goed voorbereid en juist toegepast transitieleiderschap zal de verandering lukken. De waarden en normen (en daarmee de cultuur) die horen bij de gewenste bedrijfsvoering moeten vooraf en consistent worden uitgedragen door de verandermanagers, dus de top.

Goed leidinggeven aan de verandering is net zo belangrijk als een goede blauwdruk en een goed veranderplan

Organisatietypologie

Doen wat werkt In de praktijk wordt dit beeld bevestigd. Wanneer verandertrajecten worden gedelegeerd naar een programmamanager en de opdrachtgever niet betrokken is en niet meewerkt dan is het draagvlak laag en de voortgang gering. Het is een voorbeeld van afschuifgedrag en zal door de organisatie worden overgenomen. De trekkers van de verandering hebben een voorbeeldfunctie en er wordt erg op hen gelet. Uiteraard is hierbij het gebruikelijke gewenste gedrag belangrijk. Denk hierbij aan zaken zoals op tijd komen, aan afspraken houden en fatsoens- en communicatienormen. Maar tijdens een verandering wordt extra gelet op het nieuwe gedrag wat hoort bij de nieuwe bedrijfsvoering. Als de afdeling klantgerichter moet worden kan de verandermanager het niet maken om mensen niet uit te laten praten. Als er kosten bespaard moeten worden door uitzonderingen in kostendeclaraties niet meer toe te staan kan de top hierop geen uitzondering zijn. In de voorbereidingsfase dient dit gedragsaspect een plaats te krijgen. De menskant wordt vaak vergeten in ontwerpen en plannen. Ze dient een element te zijn in de business architectuur. Naast de geïntegreerde procesmodellen, bedrijfsprocesbeschrijvingen en werkprocedures is hiervan een beschrijving nodig. De organisatietypologie is deze beschrijving van de menskant van de nieuwe bedrijfsvoering. Het is een waardevol instrument dat naast de meer technische kant de zachte kant invult. In veranderplannen wordt vaak beschreven welke stappen genomen moeten worden, in welke volgorde de 12

XR Magazine mei 2011

Een organisatietypologie (zie kader ‘Organisatietypologie’) is een beschrijving van de gedragsaspecten van een organisatie. Organisatiewaarden en gedragstypering zijn elementen in het (business) architectuurmodel. Een verscheidenheid aan onderdelen kan een organisatietypologie bevatten zoals: • De cultuurbeschrijving, met organisatie competenties en attitude. • Kernkwaliteiten van de organisatie [4] met de gemeenschappelijke waarden en normen. • Functieprofielen met karaktertyperingen en competenties van de ideale functionaris. • Managementprofiel (gedrag) met de leiderschapsstijl, communicatiestijl, competenties, kwaliteiten en waarden en normen inclusief de bonus en beloningsstructuur. De bedoeling van de organisatietypologie is dat duidelijk is voor de medewerkers en de managers welk gedrag hoort bij de nieuwe organisatie. Dus hoe mensen reageren en samenwerken en hoe de organisatie functioneert. De recruiters moeten de organisatietypologie goed begrijpen en toepassen bij de werving van personeel. Het heeft tevens vergaande consequenties voor de selectieeisen voor de personen op de nieuwe sleutelposities. De procesmodellen beschrijven welke activiteiten gedaan worden in welke volgorde, met welke systemen en docu-

Organisatietypologie Onder een organisatietypologie wordt verstaan de beschrijving van de gedragsaspecten van de organisatie. Onderdelen hiervan zijn organisatiewaarden, gewenst gedrag, cultuur, managementstijl, attitude van medewerkers op alle niveaus, verantwoordelijkheid en communicatiestijl.


menten en met welke prestatie- en handelingsindicatoren. De organisatietypologie vult dit aan met de gedragaspecten. Het maakt duidelijk welk gedrag - inclusief de waarden en normen, attitude en competenties - bij de uitvoering hoort. Hierdoor is de voorbereiding vollediger en de complete blauwdruk (inclusief de rode dimensie) voor de gewenste bedrijfsvoering af.

Verander Programmaplan

Transitieleiderschap

Huidige bedrijfsvoering

Architectuur (incl. waarden)

Transitieleiderschap en coaching Met de complete blauwdruk is duidelijk waar het heen moet; nou nog het hoe. Dit wordt voorbereid in een beschrijving van het transitieleiderschap. Het dient als hulpmiddel om het doen te sturen. Transitieleiderschap omvat - als aanvulling op het ‘change program plan’ - zaken als: • Een profiel van de verandermanager(s) met gedragstype, leiderschapsprofiel, competenties, kwaliteiten en waarden en normen. • De leiderschapsstijl. • De gedrags- en managementstijl van comfortgedrag en onder stress. • De communicatiestijl (hoe wordt de boodschap gebracht). • De aanpak van de veranderstrategie (het hoe, het wat staat in het programmaplan). • De interventiemethode voor afwijkingen tijdens de transitie (correctief en preventief). • Een behandelplan om met mensen die de verandering niet aan kunnen om te gaan. • Opleidings-, trainings- en MD-plannen; om mensen te ontwikkeling. In een verandertraject hebben de organisatietypologie en transitieleiderschap hun eigen plaats en waarde (zie figuur 2). Bij het opstellen en invullen van het gewenste transitieleiderschap biedt de performance behaviour me-

Transitieleiderschap Onder transitieleiderschap wordt verstaan de gecombineerde set van gedragsaspecten tijdens de realisatie van de verandering. Dit gaat om fysieke uitingen van gedrag zoals: communicatiestijl, manier van informeren, aansturing, verantwoordelijkheid, autoriteit, zichtbaarheid, voorbeeldgedrag en compassie. Maar ook innerlijke overwegingen die tot het gedrag leiden worden door de mensen in de doelorganisatie opgepakt. Dit gaat over waarden, attitude, compassie, gevoel, betrokkenheid en gevoelens.

Gewenste bedrijfsvoering

Organisatietypologie

Procesmodellen Bedrijfsprocessen Procedures Werkinstructies

Figuur 2: Transitieleiderschap thodiek [5] handvatten. Het is zeer duidelijk dat de P&O adviseurs en HR managers een belangrijke rol hebben in deze plannen. Zij moeten samenwerken met de business architecten, controllers en procesontwerpers. De HR bijdrage mag eigenlijk nooit ontbreken in verandertrajecten. De P&O adviesfunctie heeft een belangrijke rol bij de coaching van de veranderleider(s). Het is evident dat het gewenste gedrag tijdens de transitie door de veranderleiders getoond moet worden. Transitieleiderschap heeft vergaande consequenties voor de selectie van deze personen. De veranderleider dient als het ware de overtreffende trap te zijn van het profiel van de nieuwe topmanagers. Door coaching kan hij zijn gedrag reflecteren en zijn interventies voorbereiden. Hij kan zijn functioneren en gedrag inrichten met transitieleiderschap en de complete blauwdruk. Zijn activiteiten en taken kan hij baseren op het veranderplan (zie figuur 3). Hij past de leiderschapsstijl toe die ervoor zorgt dat op alle niveaus de mensen meekomen. Kanttekening hierbij is wel dat een deel van de medewerkers en managers - meestal circa 20% - uit de oude organisatie niet passen bij de nieuwe organisatie. Daarmee kunt u vast rekening houden in een afvloeiingsplan, maar juist ook in uw gedrag. Van medewerkers mag verwacht worden dat zij zich gaan gedragen naar de waarden en normen van de nieuwe organisatie. Als zij dit niet kunnen (of willen) dan zitten ze niet op een goede plek.

Toepassing in de soorten verandertrajecten In klantfocustrajecten kan de verandermanager niet star het programmaplan doorvoeren en zich blind houden aan de deadlines. Daarbij past niet dat hij geen inspraak duldt en zich autoritair opstelt. Juist een sociale veranderaanpak, een sensitieve communicatiestijl en een sympathieke persoonlijkheid zijn nodig. In de nieuwe bemei 2011 XR Magazine

13


drijfsvoering die customer intimacy hoog in het vaandel heeft, past het om te overleggen, om te gaan met onzekerheid, waardering uit te spreken, initiatief te tonen en waar nodig ad hoc oplossingen binnen de kaders uit te voeren. De veranderleider dient dit gedrag voort te leven. Om te komen tot een operational excellence bedrijfsvoering is haast tegenovergesteld leiderschapsgedrag geboden. Als mensen strikt de werkprocessen, procedures en werkinstructies moeten volgen en uitzonderingen niet mogen toestaan - bijvoorbeeld in een shared service center - dan dient de verandermanager hiervan een voorbeeld te zijn; op tijd, volgens plan, doelgericht, zelfverzekerd, een directe aanpak en dito communicatiestijl. Bij organisatieontwikkelingen kunnen de veranderingen ingrijpend zijn. Soms moet én het oude sterk worden afgeleerd én het nieuwe aangeleerd. Een vergunningenafdeling van een gemeente - volgens het nieuwe werken - ontwikkelen naar een klantgerichte en proactieve cultuur vergt het afleren van de ambtelijke cultuur en van omstandergedrag. Dit gedrag ontstaat door onduidelijke of afwezige gedeelde waarden waardoor mensen verantwoordelijkheid afschuiven en niet handelen [5]. De customer intimacy waarden en het bijgehorende gedrag moeten worden aangeleerd (motiverende en sociale acties) en het omstandergedrag afgeleerd (meer correctieve en dominante acties). In andere gevallen van organisatieontwikkeling is afleren niet van belang. De organisatie wil er iets bij doen, liefst zonder het oude te verliezen. De aspecten van sociaal leiderschap passen hierbij. Een bijzondere situatie treedt op als de strategie zich richt op product leadership. Hierin is het belangrijk het product efficiënt en foutloos te leveren, dus dienen strakke procedures gevolgd te worden en is er geen ruimte voor afwijkingen en improvisatiegedrag. De verkoopkant van deze organisatie wil tevreden klanten vooral door het betere product, maar wel met een klantvriendelijke communicatie terwijl er geen uitzonderingen zijn toegestaan in de levering. Bij verandertrajecten ten gevolge van fusies en overnames gaat het veelal om het beter benutten van schaalvoordelen. Daardoor wil men kosten besparen, kwalitatief beter werken of sneller leveren, en vaak alle drie. De directe communicatie, duidelijk en dominant leiderschap en strakke normen die hierbij horen zijn beschreven bij de operational excellence strategie. Er zijn ook overnames die gericht zijn op het verwerven van marktaandeel. Hierbij spelen vaak aan de voorkant van de organisatie customer intimacy aspecten. In de leveringsorganisatie neemt de schaalgrootte toe. Dit kan betekenen dat de besturing alleen nog werkt op de operational excellence aanpak. Het bijbehorende transitieleiderschap is dan gericht op directe communicatie, duidelijkheid, dominant leiderschap en strakke normen. 14

XR Magazine mei 2011

Transitieleiderschap

Persoonlijkheid

Coach en P&O adviseur Veranderleider Complete blauwdruk

Verander Programmaplan

Figuur 3: Ingrediënten voor de veranderleider

Conclusie Door de organisatietypologie mee te nemen in het ontwerp (de complete blauwdruk) heeft u een sterk stuur in handen voor het transitieleiderschap. Door de gedragsaspecten mee te nemen in de voorbereiding van de blauwdrukken en in de uitvoering van het veranderen zijn transities succesvoller en verloopt het veranderen aangenamer voor medewerker, manager en veranderaar. De consequenties van de zachte gedragsaspecten zijn groot. Dit wordt direct duidelijk bij de keuze van de veranderleiders. Dit zijn vaak niet de huidige directeuren. P&O adviseurs en HR managers hebben een belangrijke rol in het opstellen van de organisatietypologie en het transitieleiderschap. Deze menselijke kant mag niet ontbreken in verandertrajecten en heeft een belangrijke rol bij de coaching van de veranderleider(s). Een winnaar heeft een plan en zal dit, meestal deels, halen. Een verliezer heeft een excuus en bij gebrek aan een plan zelfs niets geleerd. Aan u de keuze. Referenties [1] M. Treacy & F. Wiersema. Discipline van marktleiders. Scriptum 2007 [2] K.W. Sijtsma. Bedrijfsprocesverandertrajecten, een managerial of methodische aanpak. Management Executive, juli 2004 via www.kluwermanagement.nl [3] K.W. Sijtsma. Vaak te blauw Geleerde lessen uit BPM-praktijktrajecten. Business Process Magazine febr 2009 nr 1. Deze en andere publicaties via www.12improve.eu [4] D. Ofman. Bezieling en kwaliteit in organisaties. Servire 2010 [5] N.C.W. Webers, Performance behaviour. SDU Uitgevers 2010. Zie www. flecto.nl

Ir. K.W. Sijtsma MBA is organisatieontwikkelaar en P&O veranderaar. Hij is vakmatig en van nature benieuwd naar langdurige trajecten.


Het Outsourcing Congres 2011 HĂŠt event voor de professionele outsourcing community DONDERDAG 16 JUNI 2011, PHILHARMONIE HAARLEM KEYNOTES Outsourcing Communicatie en Cultuur Amanda Crouch CEO Global Business partnership Alliance Cloud computing en bescherming persoonsgegevens Madeleine McLaggan, College bescherming persoonsgegevens (CBP), collegelid Head in the Cloud & Feet on the Ground Karel van Tuijl VP IT Philips

ONDERWERPEN DE VOORS EN TEGENS VAN DE CLOUD WAT IS DE ROL VAN DE AANBIEDERS IN DE CLOUD? NOODZAAK TOT ARCHITECTUUR-DENKEN BIJ DE CLOUD PRIJSMODELLEN VAN DE CLOUD PRIVACY ASPECTEN VAN DE CLOUD HEEFT DE CLOUD IMPACT OP DE SOURCINGCAPABILITIES VAN DE ORGANISATIE? IS DE MENS DE ZWAKSTE SCHAKEL IN DE CLOUD?

Schrijf u nu direct in voor Het Outsourcing Congres: www.sourcingcongres.nl en ga naar huis met uw Cloud checklist! Bijdragen en deelnemers van het congres zijn afkomstig van onderstaande organisaties: Giarte, CIOnet, VX Company, Sanquin Bloedvoorziening, Grant Thornton, Centric Managed ICT Services, SPS Holding B.V., Agfa-Gevaert B.V, KAS BANK, Rabo Vastgoedgroep, Fencer, Baker & McKenzie Amsterdam N.V., Brinkhof, Omnext, Accenture, Vondst Advocaten, DUO, Stater N.V., Kirkman Company, De Brauw Blackstone Westbroek, Kender Thijssen, DELTA N.V., RDW ICT Bedrijf, Loyens & Loeff N.V., Mansystems, Mitopics BV, De Nederlandsche Bank NV, KPMG Advisory NV, Quint Wellington Redwood, Getronics... Platinum Sponsor:

Mediapartners:

Gold Sponsors:

Silver Sponsors:

156 opzij / 192 naar benz

Organisatie:


Lean IT

IT in een Lean tijdperk In een veranderende tijd waarin complexiteit een gevestigd woord is in ieder IT-bedrijf, problemen efficiënt en effectief bevochten moeten worden en de gebruikersorganisatie centraal staat, dient Lean IT zich aan. Lean IT lijkt daarmee het zoveelste speeltje van het IT-management te zijn, maar is er wel een noodzaak voor? Want, waar staat Lean voor en waarom moeten we hier iets mee doen? En nog belangrijker: hoe doen we hier dan vervolgens iets mee? Simon Plasmeijer in samenwerking met Anend Harkhoe en Bastiaan Slager

De wensfontein Als we voor een wensfontein staan, onze ogen dicht doen en nadenken over wat we willen bereiken met IT, wat zouden we dan wensen? Waarschijnlijk gooien veel managers geld in de fontein voor stabiele en flexibele ITsystemen. Weer andere wensen dat ze meer geslaagde IT-projecten krijgen. Wat er ook bij de fontein gewenst wordt, het zijn allemaal wensen om de gebruikersorganisatie op een zo efficiënt en effectief mogelijke wijze in haar behoefte te voorzien, ondanks de complexiteit in de organisatie en in het IT-landschap. De vraag is of Lean IT daarin kan voorzien? Voordat we daar verder op in gaan en de context van dit artikel schetsen, richten we eerst de blik op de oorsprong en de basis van Lean. Wat is Lean en wat betekent het voor een organisatie?

Introductie Lean Het denken in termen van Lean – dat slank en lenig betekent in het Engels – staat simpel gezegd voor het meer doen met minder terwijl de klant precies krijgt wat hij wil. Hiervoor worden de productiestappen die geen klantwaarde aan het product toevoegen verwijderd uit het productieproces. Hierbij kan gedacht worden aan (interne) controles, backups, inspecties, inwerktijd, wachttijd, transport etc. Hierdoor blijven alleen de noodzakelijke en waarde toevoegende processtappen over. Een belangrijk hulpmiddel bij het identificeren van de niet waarde toe16

XR Magazine mei 2011

voegde stappen zijn de zeven standaardvormen van verspillingen welke zijn weergegeven in tabel 1 [1]. Behalve deze zeven standaardvormen van verspillingen zijn er ook additionele verspillingen. Zo wordt talent gezien als mogelijke verspillingsvorm [2]. Hiervan is sprake als creatieve medewerkers niet betrokken worden in het innovatieproces of als medewerkers werk doen dat door minder geschoolde of goedkopere krachten uitgevoerd kan worden. Een laatste vorm van verspilling is het milieu [3]. Hoewel dit niet zozeer een aparte verspilling is, is het wel een aandachtspunt. In het kader van ‘Lean and Green’ wordt er ook continu nagedacht over hoe organisaties beter met het milieu om kunnen gaan.

Lean staat simpel gezegd voor het meer doen met minder terwijl de klant precies krijgt wat hij wil Wanneer al deze verspillingen nagelopen en verwijderd zijn, is het zaak dat er een continue ‘flow’ ontstaat waardoor de output van het proces probleemloos bij de klant terechtkomt. Continue flow betekent in wezen


Verspillingen

Administratieve / diensten sector

Lean IT

1 Transport

Fysiek of virtueel transport van documenten, inclusief achterhalen van informatie.

Afstaan van informatie over organisatiegrenzen en meerdere systemen heen, veiligheidsbarrières tegen de informatieflow in.

2 Voorraad

Werk dat zich opstapelt in fysieke en digitale postbussen, overmatige hoeveelheden fysieke dossiers, hardware.

Overmatige hoeveelheden informatie zorgen voor problemen in het zoeken en documentversie controle zorgt voor overmatige achterstand en ‘werk in uitvoering’.

3 Beweging

Onnodige beweging van mensen: lopen van bureau naar kast, voortdurend moeten wisselen tussen verschillende computer- en datasystemen.

Zoeken naar informatie, herinvoer van data, overbodige toetsaanslagen, het frequent verschuiven van prioriteiten.

4 Wachten / vertraging

Vertraging tussen processtappen. Denk aan trage applicatie respons tijden.

Systeem downtime, onnodige work-flow stappen.

5 Overbewerking

Activiteiten die vergelijkbaar zijn aan ander werk in het proces die geen waarde toevoegen. We doen het al jaren zo.

Overtollige data, onnodige transacties, niet-gebruikte rapportages, softwarefuncties die gebruikers niet nodig hebben.

6 Overproductie

Meer waarde toevoegen dan waar de klant voor wil betalen. Bijvoorbeeld te nauwkeurige inspecties, sneller incidenten afhandelen dan gevraagd.

Grote hoeveelheden e-mails, rapporten, systeem waarschuwingen, etc. die niet gelezen worden en waarop ook geen actie wordt ondernomen.

7 Fouten

Producten die niet aan de klanteisen voldoen en in de prullenbak belanden of herbewerkt moeten worden. Denk aan bugs in software.

Incorrecte, niet op tijd aangeleverde en verwarrende informatie die leidt tot slechte beslissingen.

Tabel 1: De verspillingen volgens de Lean filosofie [4]

dat het geproduceerde item niet stil komt te liggen tijdens het productieproces en het op het door de klant gewenste moment geleverd wordt. Dit is een natuurlijke en onverstoorde stroom of golfbeweging van het begin tot het einde (de klant). In de ideale flow-situatie is er geen sprake meer van medewerkers die halffabricaten leveren aan de volgende afdeling - in Lean termen ook wel een push genoemd - terwijl die daar op dat moment nog niks mee kan. In de optimale flow vraagt een medewerker van een afdeling om een halffabricaat (= pull) en krijgt hij die op dat moment ook direct. Zo wordt voorkomen dat er onnodig in massa wordt geproduceerd en dat het ligt te wachten op iemand die er ook echt wat mee gaat doen. Toegevoegde waarde denken, continue flow en pull vormen in een notendop de basisprincipes van het Lean denken die het mogelijk maken om perfectie na te streven waarbij er geen sprake meer is van verspilling. Maar welke noodzaak is er om Lean IT toe te passen? Of kunnen we gewoon aan de slag met Lean, omdat het kan?

names en nieuwe technologieën worden organisaties gedwongen om te veranderen. Door de recente economische opschudding ligt hiernaast bij veel organisaties de nadruk op het snijden in de IT kosten en het verhogen van de service levels. IT afdelingen moeten voortdurend hun services verbeteren om aantrekkelijk te blijven voor klanten. Ze moeten de effectiviteit en efficiëntie van de services verbeteren en deze beter laten aansluiten op de wensen van de bedrijfsvoering [4]. In de praktijk blijkt dit vaak lastiger dan gedacht en falen veel ICT-projecten, worden kosten overschreden en werken systemen vaak niet zoals gewenst.

IT afdelingen moeten voortdurend hun services verbeteren om aantrekkelijk te blijven voor klanten

Omdat het kan? Nee, omdat het moet! De eerder genoemde wensen uit de IT-wereld komen niet zomaar uit de lucht vallen. Deze wensen zijn tot stand gekomen door de ontwikkelingen die de laatste decennia een enorme vlucht hebben genomen. Door de toenemende concurrentie, privatisering, deregulering, fusies, over-

Het meest duidelijk komt dit tot uiting bij de overheid die – als we de media mogen geloven – geplaagd lijkt te worden door een ware ICT-vloek. Zo maakte de korpschef van regio IJsselland in januari van dit jaar kenbaar dat de computerproblemen “catastrofale vormen” mei 2011 XR Magazine

17


hadden aangenomen en dat “het niet functioneren van de systemen de slagader raakte van de politieorganisatie” [5]. Andere voorbeelden zijn de invoering van de OVchipkaart, het Elektronisch Patiënten Dossier en C2000. Sinds midden april kan ook de gemeente Rotterdam aan dit lijstje worden toegevoegd door een overschrijding van het budget met 40 miljoen. Redenen? Te laat, te duur en te beperkt [6]. Bovengenoemde voorbeelden illustreren dat veel bedrijven worstelen met ICT-projecten, maar dat problemen rond ICT zich enkel voordoen bij de overheid is onterecht gedacht. Ook in de private sector gaat er vaak iets mis. Uit een recent onderzoek blijkt zelfs dat 70% van de ICTprojecten faalt of een behoorlijke uitdaging vormt voor de organisatie [4]. Al met al zijn er genoeg argumenten te bedenken om na te denken over hoe we beter met deze problemen om kunnen gaan. In de volgende paragraaf gaan we daarom in op hoe volgens de Lean IT methodiek dit probleem het beste aangepakt kan worden.

De handleiding (hoe?!) Nu de problemen zijn benoemd, kijken we naar het toepassingsgebied van Lean Informatie Technologie (IT). Het besef dat het gaat om Informatie Technologie, en in die volgorde, staat centraal bij Lean IT. De informatie staat voorop en wordt ondersteund door de technologie. Hiervoor worden binnen de literatuur van Lean IT twee toepassingsgebieden onderscheiden [4]: naar buiten gerichte en naar binnen gerichte Lean IT. Het naar buiten gerichte gebied richt zich primair op de IT-organisatie die probeert de bedrijfsvoering te ondersteunen met informatie(systemen). Het naar binnen gerichte aspect neemt juist de bedrijfsvoering als uitgangspunt welke optimaal ondersteund moet worden door de IT(-organisatie) om het streven naar perfectie te realiseren. De kerngedachte is dat met Lean IT wordt getracht deze twee toepassingsgebieden, inclusief de medewerkers uit beide organisatie onderdelen, samen te brengen, te integreren, te alignen en te synchroniseren. Hiervoor zijn crossfunctionele teams nodig die als schakel dienen tussen het management en de werkvloer en het midden houden tussen top-down en bottom-up. Deze teams worden gevormd door medewerkers uit enerzijds de IT-organisatie en anderzijds de bedrijfsvoering. Samen verbinden zij de verbeteringen met de strategische doelstellingen. Een goede procesmatige en veranderkundige begeleiding is hierin onmisbaar om ook problemen met bijvoorbeeld de IT-taal versus de business-taal te bestrijden, weerstand tegen te gaan, cul-

tuurconflicten te ondervangen en in te spelen op groepsdynamica. Hiervoor worden de principes, methoden en de tools van Lean gebruikt die hiervoor geschikt zijn. Hierbij bestaat de overtuiging dat de gebruikersorganisatie kwalitatieve informatie oplevert en er anderzijds effectief en efficiënt met de systemen door eindgebruikers (klanten) wordt omgegaan. In figuur 1 is Lean IT grafisch samengevat. Informatie staat dus centraal, maar het verbinden van mensen is de sleutel. Dat klinkt wellicht mooi, maar managers willen ook graag horen hoe het “samenbrengen van de toepassingsgebieden” concreet moet gebeuren. Voor het antwoord verwijzen we terug naar de introductie van Lean in het begin van het artikel: het identificeren en elimineren van de verspillingen en zorgen voor flow! Maar hoe zien die verspillingen er binnen de IT-organisatie er dan uit? In tabel 1 zijn enkele voorbeelden al overzichtelijk op een rijtje gezet. Het terugbrengen van verspillingen gebeurt echter niet vanzelf. Er moet actie ondernomen worden en een traditionele aanpak is daarbij niet de oplossing. De traditionele aanpak die zich onder meer kenmerkt door grote (ontworpen) en geplande events uitgevoerd door enkel specialisten en centraal aangestuurd en gecontroleerd, zorgt onder meer voor de probleemscenario’s zoals eerder genoemd. In plaats daarvan moet er continu verbeterd worden door de inzet van generalistische en cross-functionele teams. De verbindingen die door de cross-functionele teams gerealiseerd worden, leveren hier een essentiële bijdrage aan en zorgen voor meer snelheid en agility in de organisatie. Agility is voor Lean IT organisaties een bijzonder belangrijk aspect, omdat het staat voor de juiste balans tussen efficiëntie en flexibiliteit in de bedrijfsvoering. Het proces en niet de techniek staat, zoals eerder ook geconstateerd werd bij IT, dus centraal.

Agility is voor Lean IT organisaties een bijzonder belangrijk aspect, omdat het staat voor de juiste balans tussen efficiëntie en flexibiliteit in de bedrijfsvoering

18

XR Magazine mei 2011

Laten we eens kijken naar een voorbeeld van deze denkwijze: Cloud Computing. Dit maakt het mogelijk om op aanvraag hardware/infrastructuur en software via het internet als dienst direct beschikbaar te hebben. Een organisatie beslist zelf wat er wanneer en in welke hoeveelheid uit ‘de cloud’ gehaald wordt. Deze nieuwe vorm van dienstverlening neemt voor organisaties bijvoorbeeld de zorg voor voldoende opslagcapaciteit of stabiele software weg doordat het uitbesteed is. Ze krijgen er echter wel


Medewerkers

IT-organisatie

Bedrijfsvoering

Lean Raamwerk Integreren, alignen en synchroniseren Principes Methoden Tools

Output

Effectieve informatie systemen

Kwalitatieve informatie

Uitkomst

Continu verbetering en innovatie van processen

Figuur 1: Model Lean IT Ordina

een nieuwe of belangrijker geworden zorg voor terug: het proces. Want ondanks dat een organisatie zich niet druk hoeft te maken over de systemen of de software wordt zij des te afhankelijker van een goed werkend proces. De organisatie moet in deze nieuwe situatie wel zorgen dat ‘de cloud’ op het juiste moment weet welke behoeften er heersen, anders staat ze alsnog met lege handen. Om die behoeften tussen enerzijds de bedrijfsvoering en anderzijds ‘de cloud’ en eventueel de IT-organisatie af te stemmen, is de juiste informatie over onder meer de prestaties nodig. Hier moet zodoende dus flow zijn van kwalitatieve informatie om de juiste beslissingen te kunnen nemen. Het bedrijf dat het beste in staat is om de IT met de bedrijfsvoering in lijn te brengen en een goed cross-functioneel team op kan zetten, kan de klant het beste tot dienst zijn en zo zijn concurrentievoordeel opeisen. Op deze manier kan er meerwaarde aan de klant geleverd worden met minder inzet: Lean IT ten voeten uit. Veel organisaties zijn misschien nog niet bezig met Lean IT, maar hebben al wel initiatieven genomen om de complexiteit te beheersen en de kwaliteit te verhogen. Moeten die initiatieven dan overboord gegooid worden of juist niet? In de volgende paragraaf wordt daarom ingegaan op hoe de verschillende bestaande frameworks met ieder zijn eigen doel (kwaliteit, effectiviteit of efficiency verhogen, uptime waarborgen etc.) zich verhouden tot Lean IT.

Oude en andere schoenen weggooien? Na het lezen van het eerste gedeelte van dit artikel zou een begrijpelijke gedachte kunnen zijn: “Maar we zijn al bezig met het reduceren van de complexiteit in de organisatie”. Om die reden nemen we enkele van deze grote frameworks onder de loep en leggen we ze naast Lean IT. Veelgebruikte frameworks en standaarden die gebruikt worden om de complexiteit te kunnen beheersen

Hoe is Lean IT in combinatie met andere frameworks voor complexiteitsbeheersing te gebruiken? zijn CobiT, CMMI en ITIL [7]. Ook Agile wordt veelvuldig gebruikt. Door deze frameworks te gebruiken hopen ITorganisaties de complexiteit van IT en de bedrijfsvoering te beheersen. De meeste frameworks richten zich op een specifiek domein van IT en hebben hun eigen focus. Zo richt ITIL zich op het servicemanagement, BiSL op het informatiemanagement en ASL op applicatiemanagement. Veel organisaties kiezen er echter één uit en passen die toe op alle mei 2011 XR Magazine

19


domeinen. Hierdoor gaat het mis doordat ze voorbij gaan aan domeinspecifieke aspecten. Doordat er in de organisaties geen overkoepelend framework is en het lastig is om alle verbeterinitiatieven een gezamenlijke rode lijn te laten volgen mist het de integrale flow van waarde toevoegen naar de klant toe. [7]. Zo kan bijvoorbeeld binnen een bepaald IT-onderdeel een framework zorgen voor een uptime van 99,99%, maar als dat maar van bijzaak is voor de klant en het de organisatie (relatief) veel tijd en geld kost is dat een verspilling die verwijderd moet worden. Ook individuele frameworks kunnen dus een verspilling vormen, maar het tegenovergestelde is ook waar. Want wanneer een framework zorgt voor een goed lopend backup-proces waar de klant voor wil betalen, dan voegt het waarde toe en moet het zeker in het proces gehouden worden. Zo kan Lean IT als overkoepelend framework dienen en bestaande verbeterinitiatieven stroomlijnen om flow in de organisatie te bereiken of te behouden. Om dit nader toe te lichten nemen we Agile als voorbeeld, omdat hierbij het verschil met Lean IT/Software development voor kenners het kleinste lijkt. Toch zijn er kleine verschillen. Zo gaat ook, volgens Jeff Sutherland uitvinder van het Scrum-proces van softwareontwikkeling en medeondertekenaar van het Agile manifest, Lean verder dan alleen Agile: “Het biedt een breder perspectief dat Agile methoden juist in staat stelt om tot bloei te komen.” [4]. Dit komt omdat Lean meer naar het geheel kijkt door de ogen van de klant en niet naar de individuele onderdelen door de ogen van de ontwerper of ontwikkelaar. Bovendien legt Lean, meer nog dan Agile, de nadruk op het terugbrengen van verspillingen door niet teveel te kijken naar welke tools en technieken daarvoor gebruikt moeten worden. Hier gaat het bij Agile beoefenaars nog wel eens fout [4].

niet dat het invoeren van Lean IT alleen maar een organisch proces kan zijn; op specifieke momenten moeten de knoppen duidelijk worden omgezet. Om Lean goed in te voeren moet er dan ook een diep gewortelde wens zijn om te verbeteren. Het simpelweg volgen van een

Het invoeren van Lean kan niet via een ‘big bang’, maar moet gefaseerd en organisch gebeuren blauwdruk van Lean IT is dan niet voldoende. Organisaties die teveel nadruk leggen op de theorie en methoden van Lean zullen dan ook niet de gewenste verbeteringen bereiken. Men moet zich beseffen dat het inzetten van een ‘tool’ niet zo maar tot uitkomst X leidt. Een fundamentele verandering in de cultuur en het goed om kunnen gaan met weerstand zijn basisvereisten. Maar wanneer hiermee rekening wordt gehouden en er een capabel en evenwichtig cross-functioneel Lean IT team wordt ingezet in de organisatie die de afstemming van de bedrijfsvoering met de IT-organisatie realiseert, kan uw wens bij de fontein wel degelijk werkelijkheid worden. Referenties [1] Womack, J. P. and Jones, D. T. Lean thinking : banish waste and create wealth in your corporation. Free Press, New York, 2003. [2] Graban, M. Lean Hospitals. Productivity Pr, 2011. [3] Wills, B. The Business Case for Environmental Sustainability (Green): Achieving rapid returns from the practical integration of Lean & Green. Green Enterprise Movement, City, 2009. [4] Bell, S. C. and Orzen, M. A. Lean IT: enabling and sustaining your lean trans-

Conclusie Nu gekeken is naar wat Lean en Lean IT is, wat de noodzaak voor een Lean IT framework is en hoe het zich verhoudt tot andere vormen van kwaliteitsverhogende frameworks, kan de balans opgemaakt worden. Is Lean IT zonder meer dé oplossing voor uw organisatie? Het zal u niet verbazen dat het antwoord hierop niet eenduidig te geven is. Ja, Lean IT geeft de mogelijkheid om als organisatie effectiever en efficiënter te werk te gaan. Het biedt concrete handvatten om de gebruikersorganisatie en de IT-organisatie samen te laten werken aan het toevoegen van waarde voor de klant waarbij de verspillingen uit het proces gehaald worden. Er kan zo geld bespaard worden en de focus kan worden gericht op innovatie. Is het dan allemaal zo simpel? Nee, zeer zeker niet. Het invoeren van Lean kan niet via een ‘big bang’, maar moet gefaseerd en organisch gebeuren. Dit betekent 20

XR Magazine mei 2011

formation. CRC Press, Boca Raton, 2011. [5] Nu.nl Korpschef luidt noodklok over ICT politie. City, 27 januari 2010. [6] BinnenlandsBestuur, Rotterdamse ICT-projecten al 40 miljoen over budget, 19 april 2011. [7] Van Bon, J. and Rozemeijer, E. Frameworks voor IT Management Een Pocket Guide. Van Haren Pub., City, 2007.

Simon Plasmeijer is werkzaam bij Ordina en is consultant op het gebied van Lean IT.

Anend Harkhoe is werkzaam bij Ordina en is senior Business Consultant en L6S Black Belt op het gebied van Procesverbetering. Bastiaan Slager is werkzaam bij Ordina en is consultant op het gebied van procesverbetering en zijn specialisme is in de telecom sector.


Gratis uw vacature op de XR website? XR Magazine biedt een overzicht van vacatures voor architecten, ontwikkelaars, managers en andere professionals binnen diverse sectoren. U kunt zelf gratis vacatures plaatsen op de XR website. Kijk voor meer informatie op: www.xr-magazine.nl/vacatures


BPMS en ERP

BPMS versus ERP Waarom een BPMS wel het antwoord is

Enterprise Resource Planning (ERP) is één van de meest invloedrijke IT ontwikkelingen van de afgelopen dertig jaar. Er zijn diverse redenen die bedrijven opgeven bij de keuze voor een ERP-systeem: één gestandaardiseerde gegevensbron geeft efficiëntie van dataverzameling, toename van de effectiviteit van de besluitvorming, meer samenhang in de interne bedrijfsvoering en verdergaande samenwerking in de bedrijfskolom met als doel synergie creëren. Daarnaast verwacht men betere ondersteuning middels best practices, procesversnelling en vermindering van doorlooptijden. En als laatste is er een verwachting dat de kwaliteit van processen verhoogd wordt. ERP implementaties zijn in de praktijk kostbaar met een gemiddelde implementatie duur van drie jaar en vereisen aanzienlijke investeringen, waarbij een budget van minder dan 1 miljoen zeldzaam is. Eric de Jonge

Wat is er aan de hand met Enterprise Resource Planning? Wie de vakbladen erop naslaat en volgt, ziet met regelmaat negatieve berichtgeving over ERP. Een voorbeeld: “ERP-systemen verhogen productiviteit niet volgens Lineke Sneller” [1]. Uit onderzoek blijkt dat de financiële opbrengst van een ERP-systeem na drie tot vijf jaar erg tegenvalt. Volgens Computerworld zijn belangrijke

Systeem code gedreven Werken volgens door leverancier vastgestelde functionaliteiten en workflows Lange lead-time voor nieuwe mogelijkheden Geen / nauwelijks integratie met derde systemen Niet geschikt voor applicatie development door inflexibiliteit systeem en hoge aanpassingskosten Missen het onderdeel proces analyse, verbetering en optimalisatie Geen flexibele rapportage mogelijkheden over meerdere systemen en processen

Figuur 1: Complicaties ERP 22

XR Magazine mei 2011

aanmerkingen op ERP-systemen vooral het gebrek aan flexibiliteit, de hogere kosten na implementatie en de complexiteit. En, heel belangrijk: het negeert het belangrijkste bedrijfsinstrument - de mensen, hun kennis en hun relaties.

Complicaties ERP ERP richt zich met name op data-integratie van en best practices voor IT-systemen, waarbij menselijke inbreng nauwelijks in ogenschouw wordt genomen. Een ERP-systeem is in essentie een verzameling van uiteenlopende applicaties met best practices die zijn samengesteld om de gegevenslaag van verschillende processen te integreren binnen bredere processen. Als we ERP willen inzetten ter ondersteuning van de business volgens de laatste inzichten, heeft ERP een aantal complicaties, zoals weergegeven in figuur 1, die weggenomen moeten worden.

Essentiële vraag en antwoord Dé centrale te beantwoorden vraag is: welke IT oplossing is nodig om de business strategie van een bedrijf te realiseren en de taken van de mensen, systemen, partners en klanten optimaal te ondersteunen? Hierbij moet ook aandacht zijn voor de juiste schaalgrootte van de IT oplossing en het stellen van de juiste prioriteiten, om zo maximaal voordeel te behalen.


Complicaties ERP

Eisen IT-Systeem

Systeem code gedreven

Proces opbouw gedreven

Werken volgens door leverancier vastgelegde functionaliteiten en workflows

Werkt volgens door bedrijf zelf in te stellen stappen

Lange lead-time voor nieuwe mogelijkheden

Directe aanpassingsmogelijkheden

Geen / nauwelijks integratie voor nieuwe mogelijkheden

Integratie met alle betrokken systemen door standaard interfaces gebaseerd op standaarden

Geen gelijktijdige orchestratie van systeem als menselijke taken

Volledige orchestratie van alle menselijke en systeem handelingen

Niet geschikt voor applicatie development door inflexibiliteit systeem en hoge aanpassingskosten

Grafische, snelle en adaptieve applicatie ontwikkeling

Missen het onderdeel proces analyse, verbetering en optimalisatie

Gebouwd voor monitoring en vastlegging procesgegevens, analyse en procesoptimalisatie

Geen flexibele rapportage mogelijkheden over meerdere systemen en processen

Monitoring en rapportage over alle systemen in het proces

Figuur 2: Complicaties ERP en eisen IT-Systeem

Om goed antwoord te geven op deze vraag, wordt naar de eisen van business en IT gekeken. Een IT oplossing die de business strategie realiseert, moet: • Efficiënt zijn en de Total Cost of Ownership reduceren; • Gericht zijn op snel leveren en veranderen; • Snel schakelen en aanpassingen tussen business en IT mogelijk maken; • Model gedreven zijn (snelle ontwikkeling, continue verbeteren); • Aansluiten op Service Oriented Architecture (SOA), waarbij hergebruik en manoeuvreerbaarheid essentieel zijn.

worden en teruggekoppeld. Bewaking en sturing vindt vervolgens op basis van deze gegevens plaats.

Eisen IT-systeem/BPMS Om business-IT alignment te realiseren is er een aanpak én IT nodig. Allereerst moeten dan de complicaties van ERP worden weggenomen. Tegenover de complicaties worden de eisen gezet waaraan het IT-systeem moet voldoen, zoals weergegeven in figuur 2. De eisen zoals geformuleerd in figuur 2 zijn allen vertegenwoordigd in een Business Process Management System (BPMS). Het BPMS neemt zo de complicaties van ERP weg. Een BPMS is software waarin eenvoudig alle be-

Strategie en Business-IT alignment Om de business strategie te realiseren worden doelstellingen opgesteld. Daarbij worden ook de belangrijkste op te lossen problemen in kaart gebracht. Het behalen van doelstellingen en oplossen van problemen, of beter gezegd het doorvoeren van verbeteringen, wordt bewerkstelligd in de bedrijfsprocessen en uiteindelijk het werk wat daarbinnen gerealiseerd wordt. Om de strategie waar te maken, is inzet van IT noodzakelijk én is dus business-IT alignment nodig. Dat kan alleen als er steeds de juiste vertaling van strategische doelstellingen wordt gemaakt, die vertaald worden naar de bedrijfs-/werkprocessen. Vervolgens moet dit gemeten

Het BPMS neemt de complicaties van ERP weg drijfsprocessen worden gemaakt, precies zoals gewenst door de verschillende gebruikers, inclusief volledige automatisering van de procesworkflow, prioriteitsstelling en escalatie mogelijkheden. Andere applicaties worden geïntegreerd en op het juiste moment aangesproken. Alle stappen en SLA’s worden bewaakt en gerapporteerd en er is inzicht in de kosten gerelateerd aan elke activimei 2011 XR Magazine

23


Simulatie & Optimalisatie

Systeem naar Systeem Orchestratie

Directory Services

Gegevens Services

Applicatie Services

BeveiligingsServices

Partner Services

= Business gericht

Traditionele IT-Tools

Traditionele IT-Tools

Enterprise Service Bus

Ontwikkeling

Complex Event Processing

Real-Time VeranderManagement

Real-Time analysetools

Proces Choreografie

Proces Modellering & Implementatie

Monitoring

Human Activity Monitoring

Proces Ontwikkeling & Documentatie

Business Event Monitoring

= IT gericht

Figuur 3: Sleutelcomponenten van een BPMS teit, rol of proces. Hierdoor ontstaat automatisch inzicht in waar en hoe procesverbeteringen mogelijk zijn. Een interessant artikel in Computable bevestigt dit, zie “ERP maakt plaats voor BPM op een SOA” [2]. Een uitgebreide uitleg over de componenten die een BPMS bevat, is te lezen in de whitepaper “Het verschil tussen workflow-engines en BPM-pakketten” [3]. Figuur 3 geeft al een helder zicht op de sleutelcomponenten van een BPMS.

voor het beheren en het continu optimaliseren van de activiteiten en processen van een organisatie. De aanpak die ervoor zorgt dat de doelstellingen stapje voor stapje gecontroleerd gerealiseerd worden, is Business Process Management (BPM). BPM [4] is in essentie een gestructureerde aanpak gebruikmakend van methoden, beleid, statistieken en management practices.

Conclusie BPMS en ERP? Uiteraard blijft dan wel de volgende vraag over: als een BPMS de complicaties van ERP wegneemt, wat moet ik dan doen als ik al een ERP-systeem heb? Een BPMS: • Complementeert dan een ERP door het creëren van een “single view” in processen over meerdere groepen / systemen (bijv. klant on-boarding, aankoopaanvragen); • Dekt processen af die volledig buiten ERP-systemen vallen; • Orkestreert activiteiten en processen van begin tot eind, door het aan elkaar “knopen” van activiteiten binnen het proces; • Maakt business processen volledig zichtbaar en verbetert de operationele prestaties; • Is een aanvulling op de bestaande ERP-implementaties of vervangt ze volledig bij kleinschaliger projecten.

ERP geeft diverse complicaties bij de ondersteuning van de business die in de huidige praktijk meer en meer onderkend worden. Door eisen te stellen aan een IT-systeem dat de strategie en doelstellingen van een bedrijf realiseert, wordt duidelijk dat juist het inzetten van een BPMS het antwoord is op die complicaties. Alleen het inzetten van IT is echter niet voldoende; ook een gedegen aanpak is essentieel. Inzetten op het volledig grip krijgen op bedrijfsprocessen en daarmee het realiseren van de bedrijfsdoelstellingen, vereist ook Business Process Management. Referenties [1] ERP-systemen verhogen productiviteit niet volgens Lineke Sneller, Computable, 25-6-2010 [2] ERP maakt plaats voor BPM op een SOA”, Computable, 28-5-2010 [3] Whitepaper: Het verschil tussen workflow-engines en BPM-pakketten, YouGet [4] Whitepaper: Business Process Management in 5 stappen, You-Get

Aanpak BPM en BPMS Zoals aangegeven in de paragraaf Strategie en BusinessIT alignment, is IT én een aanpak nodig. Het IT gedeelte wordt ingevuld door het BPMS. Het BPMS wordt ingezet 24

XR Magazine mei 2011

Eric de Jonge is werkzaam bij You-Get B.V. als Senior Business Consultant. E-mail: edejonge@you-get.com


mei 2011 XR Magazine

25


BPM en SOA

Is meer integratie tussen BPM en SOA wenselijk? Het behalen van betere resultaten dat wil iedereen, daar draait het in feite allemaal om. Helaas bestaan er geen unieke beproefde manieren om resultaten van te voren te kunnen garanderen. Echter zijn er door de jaren heen wel een aantal standaardmethoden (‘manieren van werken’) ontwikkeld die de kans op succes kunnen verhogen. In dit artikel staan dan ook twee sterk aan elkaar gerelateerde methoden centraal. Enerzijds BPM, betrekking hebbend op de beschrijving van ‘het geheel van activiteiten binnen een onderneming’. Anderzijds SOA, wat als methode de opdeling van de IT van een onderneming in ‘herbruikbare onderdelen’ beoogt. Kolja van Horssen

BPM en SOA: een korte introductie BPM en SOA zijn ieder op hun eigen manier gericht op de realisatie van processen binnen een onderneming. Binnen dit kader kan een proces worden gedefinieerd als een serie van activiteiten die een bepaald operationeel nut realiseren via de activering van één of meerdere (handmatige of geautomatiseerde) services. Via een service wordt de (in een proces gedefinieerde) activiteit gerealiseerd. Bijvoorbeeld de activiteit ‘Registreer klant’ in een ‘Verkoopproces A’ wordt gerealiseerd via de service ‘Klantmanagement’.

SOA en BPM worden ingezet om meer efficiency en effectiviteit binnen organisaties te realiseren BPM en SOA zijn twee methoden die worden gebruikt om een concrete verbetering van de efficiency en effectiviteit binnen organisaties te realiseren. BPM biedt een kader waarin bestaande processen en samenhangende activiteiten worden beschreven en waarbinnen verbetering en optimalisatie van processen centraal staan. SOA, gezien 26

XR Magazine mei 2011

vanuit een technisch IT perspectief, richt zich op de rationalisering van applicaties door bestaande en nieuwe functionaliteiten op te delen in herbruikbare services, waardoor deze beschikbaar komen voor gebruik tijdens de realisatie van processen. Om BPM en SOA als methoden voor sturing van een organisatie beheersbaar en praktisch toepasbaar te maken, zijn er voor elke methode meerdere gedetailleerde kennisgebieden beschreven. Deze kennisgebieden geven op specifieke wijze aan hoe een organisatie te werk zou moeten gaan. Binnen het kader van BPM als methode voor processturing kunnen we bijvoorbeeld denken aan kennisgebieden zoals BPMN (grafische notatiewijze), SIX SIGMA (statistische kwaliteitverbetering), BPA (scenario- en analysetechnieken) en BPMS (fysieke proces automatisering). Binnen het kader van SOA als methode zijn er eveneens meerdere kennisgebieden beschikbaar, waaronder SOMA (service analyse- en beschrijving), ESB (integratie met bestaande systemen) en EDA (berichtgeoriënteerde versie van SOA).

Voordelen van integratie BPM en SOA De voornaamste reden om BPM en SOA te integreren is de synergie die er kan worden gerealiseerd doordat BPM en SOA initiatieven elkaar


“De voornaamste reden om BPM en SOA te integreren is de synergie die er kan worden gerealiseerd doordat BPM en SOA initiatieven elkaar kunnen aanvullen.”

kunnen aanvullen. Immers, in een proces (kernbegrip BPM) wordt in principe altijd van één of meer services (kernbegrip SOA) gebruik gemaakt om te communiceren met onderliggende (geautomatiseerde of handmatige) systemen. Tijdens de uitvoering van een ‘Order to Cash’ proces zal bijvoorbeeld op een bepaald moment informatie verstuurd moeten worden via een centrale service naar een geautomatiseerd systeem. Omdat het begrip ‘proces’ (binnen BPM) sterk is gelieerd aan het begrip ‘service’ (binnen SOA) is het zeer waarschijnlijk dat er tijdens aparte uitvoering van BPM en SOA initiatieven dubbel werk wordt gedaan. Dit kan onduidelijkheid en onnodige irritatie tussen teams opleveren. Als er tijdens BPM en SOA activiteiten wordt samengewerkt tussen de verantwoordelijke medewerkers, kan een (handmatige of geautomatiseerde) activiteit in het kader van BPM als service kandidaat worden doorgeschoven als input voor de definitieve SOA service definitie. Bij het maken van een procesbeschrijving (door bijvoorbeeld een Business Analist), zullen proces, bijbehorende activiteiten en te bewerken informatie duidelijk worden, waarna de eerste service versies kunnen worden beschreven door een IT Architect. In het begin zullen kandidaat services nog onderhevig zijn aan wijzigingen,

maar naarmate het aantal beschreven processen toeneemt, zullen ook de mogelijkheden en eigenschappen van een service (bijv. opslaan, verwijderen) toenemen. Het is van belang om te voorkomen dat er op twee aparte niveaus zonder enige synchronisatie dezelfde noties van proces, informatie en service worden gebruikt. Een door BPM en SOA teams gedeelde opslag van proces-, activiteit-, informatie- en servicegegevens kan hierbij veel onduidelijkheid voorkomen en ervoor zorgen dat business (BPM) en IT (SOA) initiatieven op elkaar zijn afgestemd.

BPM en SOA: de praktijk Door de vaak grillige ontwikkeling van effectiviteit of efficiency optimalisatie initiatieven binnen organisaties, komt het vaak voor dat wat samen had moeten starten, op de een of andere manier niet samen is gestart. Op een gegeven moment zijn er hierdoor binnen een organisatie twee groepen apart van elkaar bezig om processen en services te beschrijven en in te voeren zonder dat er samen wordt gewerkt. BPM als methode wordt doorgaans gebruikt door sterk aan de ‘business’ gerelateerde teams die erop gericht zijn de snelheid, kwaliteit en efficiency van processen te verbeteren. De output van dit soort teams, vaak in de vorm van aanbemei 2011 XR Magazine

27


velingen, hebben directe invloed op één of meer bestaande services die worden gebruikt tijdens de uitvoering van verbeterde BPM processen. Als een SOA methode is gekozen als benadering voor de inrichting van de informatiesystemen van een organisatie, dan is het tijdens de aanpassing van services gewenst als er tussen BPM en SOA teams dezelfde service notatie en structuur van de informatiedrager wordt gebruikt (i.e. Factuur bestaat altijd uit Klant en meerdere Factuurregel-onderdelen). Om de door de business gewenste aanpassingen in services zo snel en goed mogelijk door te voeren door IT teams, kan de adoptie van een additionele methode worden overwogen die ervoor kan zorgen dat gedeelde informatie centraal vastgelegd, gedeeld en bijgehouden wordt.

Enterprise Architectuur (EA) als brug tussen BPM en SOA Enterprise Architectuur als methode kan ingezet worden om vaste verbanden tussen BPM en SOA vast te leggen in specifieke richtlijnen en relaties, die worden gedeeld door beide initiatieven. Dit kan eventueel met behulp van ‘on-demand’ diensten zoals Aris Align of EA software zoals System Architect van IBM of The Essential Project. Over EA is al veel geschreven en net als BPM en SOA is het een methode die vele onderliggende kennisgebieden beslaat. Hierbij kan worden gedacht aan bijvoorbeeld Archimate (beschrijving van concepten en onderlinge relaties) en TOGAF (inrichting van specifieke activiteiten). Het bindende karakter van EA komt door de globale beschrijving van relaties tussen onder andere ondernemingdoelen, processen (BPM) die deze doelen moeten realiseren en services (SOA) die de processen ondersteunen.

Enterprise Architectuur kan een overkoepelend kader vormen voor BPM en SOA activiteiten Deze relaties worden tijdens EA activiteiten doorgaans vastgelegd in een metamodel, dat een overkoepelend kader kan vormen voor BPM en SOA activiteiten. Stel bijvoorbeeld dat er op een gegeven moment na een procesanalyse extra informatie moet worden verstuurd tijdens een klantregistratieproces. Wie bepaalt dan hoe deze informatie in een bestaande applicatie wordt opgeslagen? Hoe wordt het begrip klant verrijkt met de nieuwe informatie? Als EA tussen BPM en SOA wordt ge28

XR Magazine mei 2011

bruikt als centrale opslag van gedeelde informatie dan is het aan het BPM team om voorstellen te doen voor aanpassingen; tijdens de uitvoering van de aanpassingen van service interfaces door IT teams gebruiken zij de nieuwe informatiestructuur en hoeven zij niet na te denken over naamgeving waardoor zij zich kunnen richten op een snelle technische invoering van de verandering. Een bijkomend voordeel van een centrale binding tussen BPM en SOA activiteiten, door middel van EA, is dat de rol van EA als innovatieve kracht hierdoor beter naar voren kan komen. Wanneer EA teams fungeren als brug tussen de praktische business georiënteerde wereld en de puur technische IT georiënteerde wereld dan kunnen zij in die rol technische realisaties voorbereiden door verschillende architectuuroplossingen te analyseren en te overwegen. Nieuwe en meer efficiënte technische mogelijkheden voor de realisatie van processen kunnen de flexibiliteit en efficiëntie van de operationele uitvoering van processen doen toenemen. Bijvoorbeeld, in plaats van processen in lokale applicaties te laten uitvoeren via diversen verbindingen, kan ook de gehele uitvoering van processen uit de applicaties worden gehaald en worden uitgevoerd in een externe omgeving door gebruik te maken van (Cloud) oplossingen zoals Cordys Process Factory, Appian of IBM Bluework die in staat zijn processen uit te voeren en verbindingen kunnen maken naar bestaande applicaties.

Integratie van additionele methoden Een verdere integratie van additionele methoden naast BPM, SOA en EA kan een positief effect hebben op het uiteindelijke succes van de operationele activiteiten. Nadat centrale coördinatie door EA als methode een brug heeft gelegd tussen business (BPM) en IT (SOA), kan worden overwogen andere methoden te integreren die bedoeld zijn om op overige gebieden richting te geven. Hierbij kan worden gedacht aan bijvoorbeeld de Value Chain(kernwaarde proces beschrijving), Balanced Scorecard- (doelen en prioriteit beschrijving), CBM (capaciteiten beschrijving), PMO / PMI (programma- en projectmanagement) en RUP / CMMI / ITIL (ontwikkel- en operationele inrichting) methode. Elke methode kan zo een eigen duidelijke plaats en bijdrage hebben voor een meer efficiënte en effectieve bedrijfsvoering.

Kolja van Horssen is consultant op het gebied van Enterprise Architecture voor Newgroupe France.


Poster:

Procesarchitectuur Woningcorporatie Bestuur -– Management -- Beleid Financiële Meerjaren Planning

Product Markt Combinaties PMC’s

Strategisch Voorraad Beleid

Strategievorming Plan-Do-CheckAct

SVB

FMJP

Organisatie Inrichting Structuur & Waarden

PDCA-cyclus

Aankoop & verkoop ...

i t a

Mid Office

Onderhoud

Administratie Contracten

Makelen (verhuren, kopen, verkopen) Woninginspectie Wijkbeheer - leefbaarheid Complexbeheer Individuele woningverbetering (ZAV & WMO)

Klantgestuurd onderhoud Mutatieonderhoud

Back Office

Planmatig & periodiek onderhoud

m r fo

n i a v v

Woningmutatie & huurprijsmutatie (ZAV) Woonruimtebemiddeling / (regionale) woonmarketing Huurincasso

Prolongatie Afrekening servicekosten & stookkosten VVE-beheer Jaarlijkse huurprijsmutatie Onderhoud & overige contracten

Administratie VHE Administratie klantgestuurd onderhoud Administratie mutatieonderhoud Administratie projecten

Ketenoriëntatie

Procesinformatie

Nieuwbouw

BSC, MR, JV

Financieel beheer

Administratie Algemeen

Managen klantcontacten ...

Sloop & renovatie

l n g.

Rol positionering

n i r se

Sociaal beheer Front Office

Vastgoed

KWH, TQM, ISO

Planning, Control & Verantwoording

Stakeholder Management

Kwaliteitsbeleid

Klant/leverancier oriëntatie

Technisch beheer Projectontwikkeling

Informatiebeheer

Versie 2.1 - 2011 Markt oriëntatie

Stuurinformatie

Procesarchitectuur woningcorporatie X-Wonen

. w w

Personeel & Organisatie

Personeelsbeheer Ziekteverzuim

Management Support

Agendabeheer

Facilitair management

Gebouwenbeheer

Dossierbeheer

Sleutelbeheer

Klachtenbeheer

Voorraadbeheer

Planning & organisatie

Inkoop

Formatiebeheer

...

Catering

...

...

Repro & postbezorging

...

...

Bibliotheekdiensten

Inhuur

w

Opleidingsplanning

I&A

Netwerkbeheer

Systeembeheer Applicatiebeheer

AO

Financiële administratie

PR & Communicatie

AO vastlegging

Debiteurenbeheer

Relatiebeheer

Procesauditing

Crediteurenbeheer

Public relations

Autorisatiecontrole

Verslaglegging

Bedrijfscommunicatie

Procuratiebeheer

Cashmanagement

Projectcommunicatie

...

Financiering

Mailings

...

Salarisadministratie

Grafische diensten

...

Bankieren - kasbetaling

Sjablonenbeheer

Databasebeheer Service level mgt. Telefoniebeheer Digitale documenten Workflow management

Organisatie oriëntatie

Operationele informatie

Ondersteunende processen

Het is niet toegestaan om de afbeelding te kopiëren zonder toestemming van de illustrator.

Toelichting op de poster Deze poster is gemaakt door Martijn Videler van VVA-informatisering. De procesarchitectuur is door VVA-informatisering ontwikkeld als praatplaat bij een fusietraject tussen twee Brabantse woningcorporaties. Beide corporaties maakten gebruik van compleet andere applicaties. Het plotten van de verschillende applicaties op deze plaat bleek een handig hulpmiddel om overzicht te creëren. In één oogopslag werd helder welke processen binnen corporatie X en Y door welke applicaties werden ondersteund. Dat was de ist-situatie. Zo’n architectuurplaat met logische ordening zegt toch meer dan een lijstje in Excel, zo werd duidelijk. Van de strategische koers van de nieuwe fusieorganisatie zijn destijds architectuurprincipes afgeleid die onder andere betrekking hadden op (uniformering van) dat applicatielandschap. Dus ook de soll-situatie kon prima worden opgetekend. Later is binnen de gemeenschap van woningcorporaties de eerste opzet voor een referentiearchitectuur gemaakt: CORA. Die procesordening vertoont veel overeenkomsten, maar het betreft een wat andere doorsnede. Bovendien is deze gemaakt met een ander doel: het tonen van samenhang tussen alle corporatieprocessen. En daarin zit ook de kracht van architectuurplaten: voor ieder doel een plaat op maat! Voor meer informatie, zie www.vva-informatisering.nl.

mei 2011 XR Magazine

29


Enterprise Architectuur

Architectuur bij DSM De goede dingen goed doen DSM heeft zich van steenkool via de petrochemie ontwikkeld tot een bedrijf dat zich richt op Life Sciences en Material Sciences. Onderwerpen als open innovatie, samenwerking en kennisdeling staan hoog op de agenda om de nieuwe groeistrategie verder vorm te geven. Dit vereist extra aandacht voor de bescherming van intellectueel eigendom en merknaam inclusief de reputatie van DSM. Ook op het gebied van ICT zorgt dit voor nogal wat uitdagingen en de nodige dynamiek binnen DSM. Enterprise Architectuur zorgt voor een integrale benadering en de juiste fasering. Stephan Hendriks

Architectuur is meer dan ooit een dynamisch vak. DSM is in beweging en de nieuwe huisstijl die in maart (2011) geïntroduceerd is, is daar een duidelijk voorbeeld van. Daarnaast volgen de technologische ontwikkelingen in de ICT markt elkaar razendsnel op. Middelen zijn schaars, dus ten aanzien van ICT services is het van belang de juiste dingen te doen en dit ook goed te doen. Daarbij zorgt Enterprise Architectuur voor een integrale benadering. In dit artikel wordt ingegaan op drie aspecten van een integrale benadering bij DSM: de informatie piramide die zorgt dat initiatieven succesvol zijn en de waarde toevoegt die ervan verwacht wordt, het roadmap proces dat zorgt voor een juiste fasering van projecten en de ICT architectuurconcepten en hun principes die richting geven aan de uitvoering van ICT projecten.

De informatie piramide maakt initiatieven tot een succes Voor de ontwikkeling van de informatie piramide heeft de piramide van Maslow model gestaan. De piramide van Maslow is een hiërarchische ordening van behoeften. Je voldoet eerst aan je lagere fundamentele behoeften voordat de hogerliggende behoeften relevant worden. Dit is rechtstreeks te vertalen naar initiatieven in het bedrijfsleven. DSM ICT heeft hiervoor de informatie piramide ontwikkeld. Succesvolle initiatieven moeten voldoen aan de 30

XR Magazine mei 2011

eisen die in het laagste niveau gesteld worden voordat het op kan schuiven naar een hoger niveau. Governance vormt de onderste laag van de piramide en gaat over leiderschap, organisatiestructuren en processen die ervoor zorgen dat de doelen bereikt worden.

Governance is het startpunt voor succesvolle initiatieven De tweede laag betreft de mensen en de gedragsverandering die nodig is. Vervolgens gaat het om master data, key performance indicators (KPI’s), business processen en controls. ICT-systemen vormen de bovenste laag. Wanneer ICT-systemen geïntroduceerd worden zonder dat aan de eisen in de onderliggende lagen is voldaan, levert dit niet de waarde op die ervan verwacht mag worden. Dit leidt tot suboptimalisatie en daarnaast zijn mensen, master data en processen niet aangesloten. Een voorbeeld hiervan is de introductie van een financieel Shared Service Center. Dit lukt niet met de introductie van een centrale tool, waarbij organisatorisch de verantwoordelijkheden nog steeds volledig bij de Business Groups liggen en er op het gebied van master data geen harmonisatie plaatsvindt.


IT systems Business Processes and Controls in line with Masterdata and KPIs Masterdata and KPIs in line with Governance and People

People in line with Governance and Organization Governance in line with Vision and Organization and the actual objective to be achieved Specific Information Services

Utilities

Information Pyramid Figuur 1: DSM informatie piramide

Een belangrijk onderscheid dat verder gemaakt moet worden is de mate van standaardisatie. In het verleden lag de nadruk binnen DSM op efficiency. Dit zie je terug in de één kernel gedachte.Wanneer er iets verandert, dan wordt dit aangepast in de kernel en dat geldt dan voor alle productieve satelliet systemen. In feite is dit een oud architectuur denken dat onvoldoende rekening houdt met de dynamiek binnen het nieuwe DSM. Het nieuwe architectuur denken brengt efficiency en adaptiviteit in balans. Bepaalde services zoals Finance en Human Resource (HR) zijn uitstekend te standaardiseren. Echter er

zijn ook processen die Business Group specifiek zijn. Zo kan bijvoorbeeld het prospect-to-order proces van CRM per Business Group binnen DSM fundamenteel anders zijn. Dit vereist een architectuur die dat toestaat. Wanneer voor standaardisatie gekozen wordt, dan wordt niet alleen een globaal ICT-systeem geïntroduceerd, maar wordt standaardisatie op alle lagen binnen de informatie piramide toegepast. Bij specifieke informatie services wordt alleen gestandaardiseerd op gebieden waar dit zinvol is, zoals infrastructuur, pc’s of netwerken. Ook wordt gekeken naar best practises die gedeeld kunnen worden

‘Collaboration journey’ Een voorbeeld waar de informatie piramide succesvol wordt toegepast binnen DSM is het op de agenda zetten van collaboration. Een betere kennisdeling leidt tot meer efficiëntie in ons werk en een kortere time to market. Kennis op groepsniveau is een katalysator voor innovatie. De introductie van tools als SharePoint of Messaging vormde de eerste stap om mensen bekend te maken met nieuwe mogelijkheden van samenwerken. Collaboration is echter een reis. Iedere laag binnen de informatie piramide moet aangepakt worden om de daadwerkelijke kracht van collaboration los te maken in de organisatie. Het startpunt daarbij is het opzetten van een governance team om het initiatief te faciliteren op strategisch, tactisch en operationeel niveau. De volgende laag is het meekrijgen van alle stakeholders en medewerkers. Hierna komen master data, business processen en een verdere optimalisatie van de tooling.

mei 2011 XR Magazine

31


en een vliegende start geven voor een specifieke implementatie in een Business Group.

Bij standaardisatie wordt dit doorgevoerd op alle lagen, van governance tot ICT-systemen

over hoe dit gedaan kan worden. Gebaseerd op informatieplannen van de Business Group wordt gekeken wat de gewenste volwassenheid van de ICT mogelijkheden is. Op basis hiervan wordt een ICT roadmap ontwikkeld. Door deze gestructureerde aanpak wordt gewaarborgd dat de business prioriteiten optimaal gediend worden en ICT daarop aansluit.

Architectuurconcepten geven inzicht

We weten nu welke niveaus aandacht vergen om een initiatief succesvol te maken en wat de beste fasering van projecten is. Maar hoe zorgen we nu dat al die verschillende ICT projecten inhoudelijk ook op elkaar afgestemd Een roadmap proces zorgt voor een juiste fasering zijn? Dit is waar ICT architectuurconcepten en hun princiAandacht voor de juiste lagen binnen de informatie pira- pes een belangrijke rol spelen. Concepten en principes mide is belangrijk. Voor de juiste aansluiting op de busi- geven sturing aan projecten en medewerkers. Ze zorgen ness prioriteiten is het ook van belang dit te vertalen in ervoor dat ICT brengt wat vanuit een strategie verwacht een roadmap. Een roadmap zorgt voor de juiste fasering wordt. van projecten. Startpunt daarbij is de strategie van DSM Het fundamentele concept binnen de ICT enterprise aren de innovatie mogelijkheden. De strategie binnen DSM chitectuur van DSM is ‘internet centric’. Door internet wordt vorm gegeven door de Corporate Strategic Dialo- technologie te gebruiken voor de connectie met eindgue (CSD), met daaronder op business niveau de Busi- punten en door te streven naar end user devices zonder ness Strategic Dialogue (BSD). Deze BSD wordt vertaald DSM foot print, wordt ervoor gezorgd dat DSM een open naar de informatie management aanpak. Business Groups bedrijf wordt zodat medewerkers en partners eenvoudig maken jaarlijks een informatieplan wat een vertaling is kunnen samenwerken en overal toegang hebben tot de van hetgeen je als Business Group via de informatievoor- juiste informatie. Het concept internet centric is daarziening wilt bereiken. Het geeft dus richting aan informa- mee cruciaal om de groeistrategie verder vorm te geven, tie management; de manier waarop de business onder- waarin onderwerpen als open innovatie, samenwerking steund kan worden of nieuwe toegevoegde waarde die en kennisdeling belangrijke peilers zijn. met ICT geboden kan worden. ICT denkt vervolgens na De reden dat internet centric een fundamenteel concept genoemd wordt is dat andere concepten hierop voortbouwen. Het tweede ICT architectuurconcept is ‘on demand’. Door services op aanvraag beschikbaar te stellen en af te rekenen, wordt ervoor gezorgd dat services schaalbaar en dynamisch Business Strategy (CSD, BSD) zijn, zodat acquisities en groei eenvoudig onderInformation Plans steund kunnen worden. On demand services zijn in DSM ICT Architecture and Roadmap feite cloud based services, die vaak gebruikmaken van virtualisatie technieken en Implementation internet technologie. Het derde ICT architectuurService Delivery concept is ‘consumerization’. Door de toegang tot DSM data en applicaties ook open te stellen voor applicaties en devices die in de consumentenmarkt gebruikt worden, wordt ervoor gezorgd dat toegang tot informatie eenvoudiger is zodat samenwerking Figuur 2: Roadmap proces 32

XR Magazine mei 2011


Zero DSM-foot-printed end-user devices DSM-controlled Laptop

DSM-controlled Desktop

Non-DSM-controlled Computer

DSM-controlled PDA

DSM-controlled SmartPhone

Non-DSM-controlled SmartPhone

Connectivity Based on Internet-technology

DSM Data Center(s)

SaaS Provider

Internet–resistance

Figuur 3: Visualisatie van het internet centric concept

makkelijker is en de productiviteit van medewerkers omhoog gaat. Dit bouwt weer voort op het internet centric concept, maar stelt de eindgebruiker nog centraler. Het vierde ICT architectuurconcept is ‘design for agility’. Door services dynamisch te maken, wordt ervoor gezorgd dat ze snel en eenvoudig aangepast kunnen worden zodat optimaal ingespeeld kan worden op organisatieveranderingen en de toenemende snelheid van veranderingen binnen DSM.

‘Internet centric’ is een fundamenteel concept omdat de andere concepten hierop voortbouwen Echter het verschuiven van DSM in de bedrijfskolom vereist ook dat bescherming van intellectueel eigendom en merknaam en de reputatie van DSM veel belangrijker zijn geworden. Hoewel dus van de ene kant meer openheid wordt verlangd is er ook een druk om bepaalde informatie juist beter te beschermen. Dat zorgt voor nogal wat uitdagingen en de nodige dynamiek op veiligheidsgebeid. Veiligheid op data niveau wordt bijvoorbeeld steeds be-

langrijker. Veel samenwerkingsinitiatieven gaan dan ook hand in hand met nieuwe initiatieven op veiligheidsgebied. Behalve de vier genoemde architectuurconcepten kent DSM ook een aantal designprincipes die een volgend niveau van detail geven. Elk ICT project ondergaat een assessment om de projectleden bewust te maken van de geldende principes en de toepassing ervan te waarborgen. Het zorgt ervoor dat ICT brengt wat vanuit een strategie verwacht wordt.

Conclusie Enterprise Architectuur is een essentieel onderdeel om te zorgen dat de goede dingen goed gedaan worden. Een integrale benadering is daarbij vereist. Met behulp van de informatie piramide zorgt DSM dat de juiste niveaus aandacht krijgen. Het roadmap proces zorgt voor een juiste fasering van projecten. ICT architectuurconcepten en hun principes zorgen ervoor dat er geen veranderingen binnen de systeem en technologie architectuur uitgevoerd worden waar we later spijt van krijgen en die moeilijk weer te veranderen zijn.

Stephan Hendriks is werkzaam als Enterprise IT Architect bij DSM. www.dsm.com mei 2011 XR Magazine

33


Eenvoud in Architectuur

Complexiteit aanpakken met Domain-Driven Design Zouden Skype, Facebook en Google use case specificaties, TOGAF, DYA of Zachman gebruiken? Of zijn deze megaondernemingen minder complex dan de ondernemingen waar wij zelf werken? Inmiddels is er een hele opleiding voor nodig om alleen al de gangbare architectuurmodellen, modelleertechnieken en bijbehorende tools te kennen en al helemaal om ze te kunnen gebruiken. Deze onnodige complexiteit kost substantieel meer dan dat het oplevert. In dit artikel wordt een eenvoudig alternatief gegeven waarmee vervolgens echte complexiteit, de complexiteit waarmee gebruikers te maken hebben, kan worden aangepakt. Viktor Grgic en Mark van Holsteijn

Complexe modellen Een van de ultieme uitdagingen voor een architect is het grondig begrijpen van de core business van het bedrijf waar hij oplossingen voor realiseert en dit begrip om te zetten in een model dat begrepen wordt door iedereen binnen het bedrijf, van eindgebruikers tot collega architecten. In de praktijk zie je dat systemen vaak ontworpen worden op basis van use case specificaties. Use cases beschrijven individuele gebruiksscenario’s van een systeem zonder de context van de onderneming in oogschouw te nemen. Door bij het ontwerpproces alleen gebruik te maken van use case specificaties groeit de systeemcomplexiteit: op basis van deze specificaties ontstaan er grote hoeveelheden losstaande, technische componenten die op één of andere manier met elkaar samenhangen. De verbinding met het mentale model van de gebruiker raken we onderweg in grote mate kwijt en de middelen (het creëren van het systeem door use cases te volgen) worden het doel. Het gebruik van use cases om een systeem te modelleren is te vergelijken met het creëren van een plattegrond van een stad door middel van een lijst van duizenden routebeschrijvingen tussen verschillende adressen. Geen enkele lezer zal in staat zijn om een mentaal model te vormen van wat hij ziet en het grotere geheel herkennen. Wanneer je de lezer een plattegrond geeft, zal hij snel begrijpen hoe 34

XR Magazine mei 2011

de stad eruit ziet en eenvoudig zijn weg erin kunnen vinden. Sterker nog, de lezer is snel in staat om verbeteringen te suggereren waardoor mensen sneller van A naar B kunnen komen.


Andere modelleertechnieken

Domain-Driven Design

Hogere abstractie modellen worden meerdere malen vertaald tot uiteindelijk een technische implementatie.

Er is sprake van slechts één model waar zowel de business als de ontwikkelaar mee werkt.

Er wordt op een hoog niveau gestreefd naar een ultiem model waar alle betrokken domeinen zich aan conformeren.

Onderkent dat er, afhankelijk van de context, verschillende modellen zijn.

Door vertalingen ontstaan verschillen in taalgebruik.

De essentie is dat er gebruik gemaakt wordt van één eenduidige taal.

De aanpassing van ieder model is specialistenwerk.

Het model is van iedereen, en iedereen mag het model aanpassen.

De implementatie is ondergeschikt aan het model en technische beperkingen worden nauwelijks teruggekoppeld.

Het model en de code zijn één. Interactie tussen ontwikkelaars en domein experts over het model zorgt voor de optimale oplossing.

Hoge mate van standaardisatie en grote hoeveelheid kennis m.b.t. modelleertechnieken.

Modelleertechnieken zijn irrelevant. Gebruik van blokjes en pijltjes op een whiteboard is meestal voldoende. De nadruk ligt op een verzameling patronen.

Eenmaal gemaakt model is lastig aan te passen.

Een domeinmodel in Domain-Driven Design evolueert waarbij na iedere stap een werkend systeem opgeleverd wordt.

Figuur 1: Waarom Domain-Driven Design in plaats van andere modelleertechnieken?

Naast de use case specificaties worden er ook andere technieken en tools gebruikt bij het beschrijven van een systeem, zoals verschillende UML diagrammen, Archimate, Zachman, TOGAF en DYA. Deze modellen richten zich steeds op één specifiek aspect en zijn voornamelijk bedoeld voor intern gebruik door architecten en bij het ontwikkel- en onderhoudsproces. Ze kunnen niet gevalideerd worden door mensen buiten dit proces. Ofwel, wat voor zin heeft het maken van een model als er een hele IT opleiding voor nodig is om deze te kunnen lezen, laat staan te valideren. We hebben iets nodig wat beter op het mentale model van een gebruiker past en systemen tegelijkertijd niet onnodig complex maakt.

Domain-Driven Design Eric Evans heeft een paar jaar geleden een boek geschreven met de naam: “Domain-Driven Design: Tackling Complexity in the Heart of Software” [1]. De belangrijkste pijler in deze aanpak is dat hij zich richt op het gebruik van een gemeenschappelijke taal (ubiquitous language). Deze taal wordt door alle betrokkenen gebruikt; eindgebruikers en ontwikkelaars gebruiken dus dezelfde taal wanneer zij over het systeem praten. Dit helpt enorm bij het verkrijgen van een gemeenschappelijk beeld van het systeem door alle betrokkenen. Het model van het systeem dat zij op deze wijze maken, komt overeen met de echte wereld. Bijvoorbeeld, een entity java object

genaamd “UitgeleendBoek” is een daadwerkelijk uitgeleend boek in een echte bibliotheek. De methode gaat dus zelfs zover dat ook tijdens de implementatie van het systeem gebruik gemaakt moet worden van dezelfde taal. Zo wordt voorkomen dat er kennis verloren gaat en er een verschil ontstaat tussen de taal binnen de IT en de taal in het bedrijf. Het ICT systeem wordt zo een werkend model van de core business van het bedrijf. Dit zorgt ervoor dat ICT in lijn blijft met de organisatie: Het systeem is consistent met het bedrijf. Hierdoor kunnen wijzigingen sneller gerealiseerd worden.

Referenties [1] Domain Driven Design, Eric Evans, http://books.google.com/books?id=7 dlaMs0SECsC&dq=domain+driven+design [2] Nevermind Domain Driven Design, Phillip Calçado, http://fragmental. tw/2010/03/22/nevermind-domain-driven-design

Viktor Grgic is zelfstandig Agile/Lean IT architect en eigenaar van LeanArch B.V. www.leanarch.eu Mark van Holsteijn is Senior Consultant bij Xebia. www.xebia.com mei 2011 XR Magazine

35


Enterprise Architectuur

De Visuele Enterprise Architectuur van BetereZorg Een voorbeeld op basis van Dragon1

Visuele Enterprise Architectuur (VEA) op basis van Dragon1 is voor BetereZorg, een buurtgerichte thuiszorgorganisatie, een professioneel stuurinstrument voor het nemen van strategische beslissingen. Visuele Enterprise Architectuur maakt van BetereZorg een onderneming die beter wendbaar en bestuurbaar is door en voor bestuur, directie en management. Voor medewerkers maakt Visuele Enterprise Architectuur de onderneming aangenamer om voor te werken en klanten ervaren en krijgen een hogere kwaliteit van dienstverlening. Mark Paauwe en Talitha Paauwe-Wijnands

Naar aanleiding van de lancering op 19 mei 2011 van het Dragon1 HBO Studieboek [1] wordt in dit artikel beschreven wat het belang is van architectuurvisualisaties voor bestuur, directie en management. Het is tegenwoordig bijna een basisnoodzaak om de huidige architectuur naast de huidige structuur van het eigen enterprise systeem in beeld te hebben en de nieuwe architectuur van een integrale bedrijfs-/ICT-oplossing, voordat er grootscheeps wordt geïnvesteerd in een ICT-innovatie en bedrijfstransformatie. Dit artikel gaat over het visualiseren van de huidige enterprise architectuur van de voorbeeldonderneming BetereZorg met behulp van Dragon1 [2]. Dragon1 bevat nieuwe inzichten op het gebied van Enterprise Architectuur, met name hoe op een effectieve wijze de architectuur van de onderneming visueel is te maken en daardoor veel meer stuurbaar wordt. Na het lezen van dit artikel heeft de lezer een beeld bij wat Visuele Enterprise Architectuur is, wat Dragon1 is en wat het belang is om de huidige enterprise architectuur van een onderneming visueel in beeld te hebben. In dit artikel is voor een verhalende insteek gekozen om van de voorbeeldonderneming een zo realistisch mogelijk relaas te schetsen.

e-Health bij BetereZorg De directie van BetereZorg, met name de nieuwe CIO, is helemaal in voor e-Health. Op een beurs in Amerika heeft 36

XR Magazine mei 2011

Jacqueline Cordaet daar prachtige toepassingen gezien voor e-consult, e-agenda, e-monitoring en e-zelfanalyse die een zorginstelling voor buurtzorg, thuiszorg en woonzorg vele malen efficiënter laten werken. De technologie waar deze toepassingen uit bestaan zijn qua aanschaf zeer betaalbaar en alles kan worden beveiligd via het internet. Jacqueline ziet het voor zich dat de buurtgerichte teams met een extra paar ogen, oren en handen via internet op afstand hun werk beter kunnen doen. Om zo bijvoorbeeld planningissues en problemen met beperkte handelingsvrijheid door de teams zelf, grotendeels op te lossen. Dit is een mooie kans, denkt Jacqueline om zich te profileren als CIO. Het aantal thuiszorgmedewerkers dat afhaakt omdat ze hun werk niet meer leuk vinden moet omlaag en het aantal cliënten dat niet meer zelfstandig thuis kan blijven wonen, kan ook omlaag. Dat is wat Jacqueline voor ogen heeft. Ze denkt dat het hoofdkantoor gesplitst dient te worden in een sturend en in een faciliterend dienstencentrum, met veel meer verantwoordelijkheid en zelfstandigheid voor de buurtteams, waarbij e-Health een grote enabler is om dit voor elkaar te krijgen. Vol enthousiasme vertelt Jacqueline haar strategische eHealth-visie aan Tom, de voorzitter van de Raad van Bestuur. Hij laat gelijk weten dat het op zich een prachtig verhaal is, maar dat de vorige CIO ook goede ideeën had die uiteindelijk alleen maar geld kosten en niets brachten. ‘We hebben niet eens een fatsoenlijk werkende ICT-


Verkorte Dragon1 definities Enterprise Architectuur Het samenhangend geheel van toegepaste concepten op een ondernemingsbouwerk. Enterprise Architectuur Raamwerk Een classificatieaanzicht van de concepten en principes in de systemen en domeinen van een onderneming. Logisch Enterprise Structuur Raamwerk Een classificatieaanzicht van elementen en regels in de systemen en domeinen van een onderneming. Logische Bedrijven Structuur Blauwdruk Een samenwerkingsaanzicht van elementen en regels in de systemen en domeinen van de bedrijven van een onderneming. Fysieke Informatievoorziening Structuur Blauwdruk Een samenwerkingsaanzicht van componenten, objecten en regels in de systemen en domeinen van de informatievoorziening van een onderneming.

werkplek, we kunnen nog niet thuiswerken, laat staan dat we nu vanuit Amsterdam de hele wereld van zorg kunnen voorzien’, zegt hij. ‘Sterker nog, we moeten bezuinigen, er gaan zeker twee vestigingen dicht en ongeveer 50 medewerkers moeten we laten afvloeien. We moeten nu eindelijk eens de bedrijfsprocessen en de ICT standaardiseren en weer centraal gaan aansturen, voor meer optimalisatie en efficiency. Dan kunnen we eindelijk gaan sturen op kwaliteit en ratio’s. Maar ja, ik weet ook wel dat innovatie randvoorwaardelijk is voor ons voortbestaan, dus Jacqueline, je krijgt één kans om ons op ander gedachten te brengen. Over vier weken plan ik je in op onze heidag voor een e-Health presentatie.’, sluit Tom af.

Over de problemen bij BetereZorg BetereZorg verkeert momenteel in een moeilijke situatie. De thuiszorgmedewerkers ervaren dat ze te veel worden ingepland en te weinig ruimte hebben om met creatieve oplossingen kleine en grote problemen in hun werk op te lossen. Veel tijd van de medewerkers gaat verloren aan het dagregistratie- en planningswerk op het hoofdkantoor. Terwijl juist nagedacht zou moeten worden over de behandeling van de cliënt als de handicaps en beperkingen van de cliënt vergroten. Ook is de verhouding van het aantal medewerkers op het hoofdkantoor versus de thuiszorgmedewerkers uit balans vinden ze. Tegen duizend thuiszorgmedewerkers in het

veld, staan 100 hoofdkantoormedewerkers, en over alles wat in het veld gebeurt, moeten er wel vijf of zes personen op het hoofdkantoor meebeslissen. Wat veel tijd en geld extra kost, maar niet door de cliënt wordt gemerkt in de vorm van extra hoge kwaliteit van dienstverlening, maar wel wordt gemerkt in de steeds hogere kosten, of dat zaken door vrienden en familie moeten worden gedaan - zoals het verschonen van het bed en de cliënt, het toedienen van medicijnen of het behandelen van wonden. De thuiszorgmedewerkers willen de cliënten verzorgen zoals zij ook zelf verzorgd willen worden. Zo organiseert een zelfstandig BetereZorg-buurtteam het liefst zelf of bepaalde cliënten twee of drie keer op een dag worden bezocht als een periode van extra intensieve zorg benodigd is. En krijgt iemand die dat even niet nodig heeft op een dag dan slechts één of extra kort bezoek. Dit allemaal geheel in overeenstemming en afspraak met cliënt. Maar dit moet steeds worden overlegd met het hoofdkantoor en wordt dan soms afgekeurd als maandplan. Het management bij BetereZorg wil omwille van het vergoed krijgen van de dienstverlening strikt toezicht houden op wat er gebeurt, en de buurtteams niet zoveel vrijheid geven als ze zelf zouden willen of als de cliënt wil. Dit probleem is dagelijks onderwerp van discussie. Iedereen bij BetereZorg wil ook graag dat de cliënt voorop staat en de best mogelijke zorg krijgt, maar het gevolg is dan wel dat niet alle handelingen in het lijstje staan van vermei 2011 XR Magazine

37


goede handelingen voor een bepaald zorgabonnement of ziektebeeld. Neem nu de cliënten die afgelegen wonen, geen vrienden of familie hebben, of veel complicaties bij hun ziektebeeld hebben. Thuiszorgmedewerkers willen persoonlijke zorg geven en niet efficiënt ‘servicen’. Maar de medewerkers worden nu in feite wel gedwongen om met het horloge in de aanslag een persoonlijk gesprek te voeren. Hierdoor stoppen ook steeds meer thuiszorgmedewerkers met hun werk bij BetereZorg.

Documenten liggen in de la, architectuurposters hangen aan de muur. Daarom: Visualiseer! De ontwerpopdracht: maak een architectuurontwerpboek Op maandagochtend na een weekend doorwaaien heeft Jacqueline op haar CIO office een bespreking met het architectuurteam. Ze vertelt daar over haar gesprek met Tom. Het architectuurteam heeft vandaag zijn kick-off en bestaat uit jonge enterprise, business, informatie en technische architecten. Na een korte bespreking spreekt men af dat om Jacqueline een wervelende presentatie te kunnen laten houden voor directie en bestuur, de huidige enterprise architectuur op hoofdlijnen in beeld dient te worden gebracht om te laten zien waar de huidige strategie onvoldoende met de huidige onderneming kan worden gerealiseerd. Vervolgens dient aan de hand van de solution architectuur voor e-Health te worden getoond dat a) de impact van e-Health als integrale bedrijfs-/ICToplossing op BetereZorg beheersbaar is en dat b) e-Health een passende oplossingsrichting is voor BetereZorg die bijdraagt aan kostenbesparing en zorgt voor de nodige innovatie1. De architecten geven aan dat zij een officiële architectuurontwerpopdracht voor het in kaart brengen van de huidige situatie willen hebben. Er lopen namelijk een twintigtal business- en ICT-projecten door elkaar heen die niet allemaal een business case hebben of waarvan de opdrachtgever soms een bestuurder, directeur of manager is. Als de huidige enterprise architectuur nu in beeld gebracht wordt gaat dat commotie geven over wat dat betekent voor allerlei plannen en lopende projecten die er zijn. Een ontwerpopdracht zorgt voor iedereen op dit punt rust. Nu zijn er in het verleden al wel verschillende architectuurdocumenten gemaakt, maar die spreken niet aan bij bestuur en directie. Veel documenten, strategische uit38

XR Magazine mei 2011

gangspunten en visies zijn niet vastgesteld. De presentatie van e-Health kan nu goed als aanleiding worden gebruikt om architectuur op een hoger plan te trekken en de toegevoegde waarde van architectuur te laten zien. Want als de presentatie lukt, is met recht te zeggen dat de architectuur inzicht en overzicht in samenhang en afhankelijkheden geeft en dat het ontwerpen en realiseren van e-Health onder architectuur in de organisatie voor beheersbare risico’s en sturing van projecten zorgt. Jacqueline begrijpt het en stelt een ontwerpopdracht op met voldoende mandaat voor het maken van een ontwerpboek, zodat de architecten zich legitiem met bepaalde zaken mogen bezig houden. In de opdracht staat dat de huidige enterprise architectuur en de solution architectuur van e-Health dient te worden gemaakt en dat tevens de vastgestelde documenten worden gebruikt om de baseline van het enterprise architectuurdossier in te vullen. Later in het jaar worden de overige architectuurproducten gemaakt voor de baseline. De geheel gevulde baseline is nodig om als architectuurteam vanuit een zelfde basis, vragen van klanten te kunnen beantwoorden over de architectuur en de structuur van de onderneming en verschillende domeinen/deelarchitecturen in de onderneming. Jacqueline geeft in de ontwerpopdracht ook aan dat we niet architectuur om de architectuur doen, maar dat de architecten echt met de mensen in de organisatie moeten gaan praten, met de leveranciers en met de partnerzorginstellingen.

Wat hebben we in beeld en waar zijn we niet in control? Eerst heeft het architectuurteam met de CIO een workshop gehouden om op basis van wat er al is aan documentatie een paar modellen als vertrekpunt te nemen, zoals een referentiearchitectuur in de branche en een model uit een overheidsreferentiearchitectuur. Maar toch is veel informatie over bedrijfsprocessen, informatiesystemen, softwareapplicaties, platforms, storage en servers niet of nauwelijks beschikbaar of staat überhaupt ergens op papier bij BetereZorg. Er wordt op het gebied van administratieve organisatie wel eens gekscherend gezegd dat het net lijkt alsof er een grote brand heeft gewoed waardoor alle documentatie kennelijk verloren is gegaan, maar dat niemand zich er druk om maakt om die belangrijke informatie inzichtelijk en overzichtelijk op papier te krijgen. Jacqueline ziet het al helemaal voor zich om aan de directie en het bestuur het plaatje uit figuur 1 en figuur 2, wat hebben we in beeld, te tonen waarbij het huidige logische enterprise structuurraamwerk en het enterprise architectuurraamwerk als basis zijn gebruikt. Dat zou de directie toch dienen te bewegen om na de e-Health presentatie een en ander meer in beeld willen te laten


Enterprise Structuur Raamwerk Onderneming

Vraag Medewerkers herkennen zich niet meer in de organisatie

Besturing Identiteit Missie Visie

?

Bedrijven Klanten

Overzicht en eenduidige beheerbron ontbreekt

Kwaliteitssysteem is onbekend en veelal niet gebruikt

Auditsystemen Procesadmin

Regels

Kwaliteitsprocessen

Diensten Bedrijfsobjecten

?

Bedrijfsprocessen

Medewerkers Middelen

Veel dubbelingen en

?

Veel gegevens inconsistent en dubbel opgeslagen

Media Kanalen

het geheel

Clients Servers

?

Gegevens

Kanaalentiteiten

Geen overzicht van Gemeenschappelijke ICT-infrastructuur

BetereZorg

Bedrijfsfuncties

Organisatie Structuren

te hoge kosten + Gemeenschappelijke Informatievoorziening

Services

Risicokosten Ratio’s

Overzicht en afhankelijkheid naar applicaties toe ontbreekt

Producten

Labels

Applicaties

Projecten worden opgestart zonder business case

Wetten

Markten

onbedoeld zelfbouw (maatwerk)

Service

Messages Interfaces

Vraag is onbeheerst

Storingsgevoelige oplossing

Netwerken

Databases

Application Platforms

Apparatuur

Storage Systems

Application Software

Figuur 1: Globaal AS-IS Enterprise Structuur Raamwerk 2011 van BetereZorg

brengen, want in vier weken tijd lukt het nooit om alles te inventariseren en te ordenen. Jacqueline gaat met de ICT-manager praten voor zijn draagvlak om de applicaties in beeld te brengen en met twee bedrijfsdirecteuren voor draagvlak om de processen in beeld te krijgen, met de gedachte dat ze dan beter in control zijn. Jacqueline spreekt af met de ICT-manager en de bedrijfsdirecteuren om aan de hand van de twee raamwerken in figuur 1 en figuur 2, blauwdrukken op te stellen in workshopvorm, waarbij ervaren medewerkers de informatie aanleveren voor de business (bedrijfsvoering), informatievoorziening en ICT-infrastructuur. Aan leveranciers en ketenpartners wordt allerlei technisch inhoudelijke informatie gevraagd. Dit zou dan moeten leiden tot het opheffen van de blinde vlekken qua inzicht en overzicht. Figuur 1 toont vier domeinen die in veel ondernemingen terugkomen. Besturing, bedrijvigheid (business), de informatievoorziening en ICT-infrastructuur. Omwille van eenvoud is ervoor gekozen om niet deze domeinen nog eens onder te verdelen, hoewel dit bij BetereZorg daadwerkelijk wel het geval. In dit structuurraamwerk staat dat bij BetereZorg men met producten, processen, applicaties, kanalen, servers en netwerken werkt of ervan gebruikt maakt. Maar dat met deze logische functionele entiteiten nogal wat mis is. Het ontbreekt aan inzicht en overzicht en ze zijn daarmee in feite oncontroleerbaar.

Figuur 2 laat zien dat er verschillende wijzen van procesmatig werken, ad hoc en standaard dienstverlening zijn en dat op automatiserings- en informatiseringgebied handmatige en automatische oplossingen uit de jaren ‘80, ‘90 en ‘10 door elkaar heen lopen. Een situatie die maakt dat er verre van optimaal wordt gewerkt in de organisatie. Maar tevens een situatie die nu deze eenmaal in beeld is, goed is op te pakken en te verbeteren. Nadat de architecten de raamwerken netjes hebben gevisualiseerd en gedocumenteerd in toelichtingsdocumenten stelt de CIO ze vast en worden ze op het intranet van BetereZorg gepubliceerd. De concepten uit het architectuurraamwerk tonen hoe aan de hand van de conceptnaam hoe de elementen uit het structuurraamwerk worden geacht samen te werken. Alle elementen zijn onder te brengen in concepten. N.B. Binnen een dag na de publicatie op intranet waren er al veel vragen en opmerkingen over wat de betekenis van de raamwerken was, hoe ze konden worden gebruikt, en waar voor elk domein en architectuur meer informatie te vinden is. Dit terwijl de eerder tekstuele architectuurdocumenten ook al jarenlang, hetzij niet-gelezen en onopgemerkt voor iedereen beschikbaar waren.

Inventarisatie met workshops Tijdens de blauwdrukworkshops met business management blijkt helaas dat er veel over de architectuur en mei 2011 XR Magazine

39


Enterprise Architectuur Raamwerk Enterprise Architectuur Klant heeft geen inzage in verdienmodel

Governance Architectuur

Corporate Governance

Transparantie

Business Architectuur

Proces Integratie

Informatie Architectuur

Technische Architectuur

Server Based Computing

Integraal Klantbeeld

Klantgericht werken

Niemand heeft hetzelfde beeld bij een patient

Peer-to -peerkoppelingen

Buurtteams Resultaatverantwoordelijke eenheden

Competentiegericht werken

Spaghetti: Veel is niet gekoppeld of juist onduidelijk in elkaar geklonken Front, Mid, Backoffice opdeling

Daadwerkelijk is hier geen sprake van Xml-based Interfacing Service Oriëntatie

Client applicaties op de server is nog geen SBC

SOAP Messaging

Inloggen gaat nog steeds anoniem 100MB I-net

Client Server Computing

BetereZorg

Alleen in naam zijn ze zelfsturend

Thuiszorg

In principe krijgt de klant via elk kanaal een ander antwoord

Risk Management

Geld verdienen gaat voor klant bedienen

Woonzorg

Ad-hoc werken

Kanaal Integratie

Planning & Control

Compliance

Iedereen voelt zich eigenaar, maar niemand is het echt

Procesmatig werken Afdelingsgericht werken

Planning is niet gebaseerd op keteomkering

File Based Databases

ANSI2 SQL Compliant Databases

SAN

WAN VPN Wireless (Unsecure) LAN

Ethernet LAN

Figuur 2: Globaal AS-IS Enterprise Architectuur Raamwerk 2011 van BetereZorg

structuur van de organisatie niet overzichtelijk of inzichtelijk is. Ook wordt duidelijk dat de verschillende afdelingen anders over dezelfde managementaspecten praten, zoals klanten, producten, diensten, processen en applicaties. Heeft de een het intern gericht over patiënten en budgetten, de ander heeft het extern gericht over klanten en vergoedingen. Maar ze bedoelen wel hetzelfde. Bij de business en ICT spreken ze beide over clients, transacties en services, maar ze bedoelen toch geheel verschillende zaken. Jacqueline noteert op een briefje dat het ontbreekt aan een gemeenschappelijk beeld en begrippenkader en dat met deze workshops dat pas goed aan het licht komt. Ook merkt ze op dat de cultuur in deze onderneming waar ze nog maar pas is, onvoldoende open is. Misstanden worden niet gecommuniceerd en als er problemen zijn worden deze binnen de organisatorische eenheden oplost. Eigenlijk, zo denkt ze, heeft niemand echt het overzicht van wat goed gaat en niet. Al deze toestanden bij BetereZorg leiden onder andere tot het feit dat afdelingen veel werk dubbel doen, op hun eigen manier en ook soms oneigenlijk werk uitvoeren. Bepaalde functionarissen hebben nu een dagtaak aan het uitvoeren van oneigenlijk werk waar ze zelfs specialist in zijn geworden. Bijvoorbeeld een thuiszorgmedewerker die het functioneel beheer doet van het consultsysteem. De bedrijfsdirecteuren zijn er nu ook van overtuigd dat het werk efficiënter gedaan kan worden en men meer 40

XR Magazine mei 2011

klanten tegelijk aan kan met dezelfde bezetting, als het processenmodel veel beter in beeld en gestandaardiseerd zou zijn. Er is een bedrijfsdirecteur die het nu voor zich ziet het plan om mensen te moeten ontslaan niet meer door hoeft te gaan, omdat met omscholing en training deze mensen hun eigenlijke werk weer kunnen gaan doen. Zie figuur 3 voor een bedrijfs-structruurblauwdruk waarin de huidige bedrijfs- en werkprocessen onvoldoende conform het concept procesmatig werken zijn ingevuld.

Lessons Learned De directie geeft verschillende redenen aan waarom dingen in het verleden niet zijn gelukt. De producten en diensten staan niet in 1 catalogus, zodat op dezelfde klantvragen en klantbehoeften soms andere diensten worden geleverd en producten worden verstrek. Ook gaat er veel tijd en geld verloren met het leveren van maatwerk, omdat het dienstverleningsproces niet correct op papier staat, anders dan minimaal wat de zorgverzekeraars en de overheid verlangen. Een ander punt wat de business aanstipt is dat er een nieuwe zorginstelling van plan is om op dezelfde locaties als BetereZorg diensten te gaan aanbieden. Het plan wat nu speelt op de achtergrond bij het bestuur is om een joint venture met de andere organisatie aan te gaan om samen in de gemeenschappelijk gebieden sterker te staan. De eerste gesprekken zijn positief,


Bedrijven Structuur Blauwdruk Bedrijven

(uitsnede van een aantal objecten en activiteiten die onvoldoende op elkaar zijn afgestemd) Inkoopbedrijf Werkproces Activiteit

Verkoopbedrijf

Dienstverleningsbedrijf Werkproces

Werkproces Object

Object

Klant

Patient

Inkoop van middelen

Er is geen eigenaarschap van processen over afdelingen heen. In feite is er geen sprake van procesmatig werken, maar van activiteit / afdelingsgericht werken met veel suboptimalisatie en inefficiëntie op enterprise level tot gevolg. Buurtteams

BetereZorg

Werkproces Object

Object

Object

Vergoeding

Middelen

Object

Budget

Object

Materiaal

Activiteit Zorgverlenen Werkproces

Verbruiker Activiteit Registratie middelen

Activiteit

Activiteit

Activiteit

Registratie patient

Registratie gebruik materiaal

Registratie klant Werkproces

Werkproces

Werkproces

Activiteit

Activiteit

Registratie verbruiker

Uitgave goedkeuren

Activiteit

Activiteit

Activiteit

Administratie van dienstverlening

Zorgopdracht verstrekken

Administratie van dienstverlening

Facilitair (ICT) bedrijf Object Website gebruiker Object Abonnement

Werkproces

Werkproces

Activiteit

Er zijn geen afspraken gemaakt over Registratie webportal wat de overeenkomsten en verschillen gebruiker zijn tussen de bedrijfsobjecten klant, verbruiker, patient en webportal gebruiker. Informatie over personen wordt door de business en ICT dubbel opgeslagen en niet gestandaardiseerd met elkaar gedeeld.

Activiteiten worden alleen afgestemd op de eigen afdeling uitgevoerd en niet afgestemd op het werk op andere afdelingen. Dit zorgt ervoor dat het soms weken duurt voordat een klant geadministreerd staat en dat veel dienstverlening buiten het zicht om op HQ aan een klant door een buurtteam plaatsvindt of dat materialen veel te laat worden bijbesteld en door zelf bestellen dubbele kosten worden gemaakt

Figuur 3: Uitsnede van de AS-IS Bedrijven Structuur Blauwdruk 2011 van BetereZorg

maar betekenen op korte termijn het in elkaar schuiven van processen en ICT. Uit volgende workshops met ICT blijkt dat er veel applicaties zijn (wel 400), bijna 1 per medewerker. Deze applicaties doen soms dezelfde. Informatie tussen applicaties wordt niet of nauwelijks gedeeld, de leverancier bepaalt vaak zelf of applicaties wel of niet kunnen interfacen met andere applicaties. Wat wel blijkt is dat de business er vanuit gaat dat de systemen wel met elkaar kunnen gaan communiceren en dat men zich er niet van bewust was dat er zoveel fouten in de data zitten zodat veel informatie dubbel wordt opgeslagen. Als CIO was Jacqueline zeer verrast om te zien hoe sommige medewerkers in de business nog onvoldoende beeld hadden bij de huidige grote afhankelijkheid van business naar ICT toe. De gedachte dat het werk ‘gewoon’ door kan gaan zonder dat het beeldscherm op de werkplek het doet, is een illusie die in de workshop gelukkig ontkracht kon worden. Overigens loopt er een project ‘het nieuwe werken’ wat voor nieuwe kantoorautomatisering en thin clients gaat zorgen en met server-based computing de applicatie aanbiedt. Alleen heeft dit project de kantoorautomatisering los gekoppeld qua doorontwikkeling van de back office en front office bedrijfsapplicaties. Iets wat tot nu toe onvoldoende inzichtelijk was. Zie figuur 4 voor een informatievoorziening-structuurblauwdruk die de dubbelingen in de applicaties en da-

tabases, het gebrek aan automatische koppelingen en de afhankelijkheden van bedrijfsprocessen en werkprocessen naar de informatievoorziening toe laat zien.

Maak inzichten visueel In de workshops hebben de architecten ervoor gezorgd dat de entiteiten netjes zijn geclassificeerd in concepten, elementen, componenten, objecten en technische producten. Ook hebben de architecten verschil gemaakt tussen de uitgangpunten, randvoorwaarden, doelen en eisen, principes en regels en beleidsmaatregelen. Dit zorgt ervoor dat op de blauwdruk- en de raamwerkvisualisatie duidelijk verschil is te maken tussen strategie, architectuur, structuur en beleid. Links staat in tekst op de platen de strategie, rechts staat het beleid en in het midden de architectuur of structuur, al naar gelang de visualisatie een architectuurplaat of structuurplaat is. Deze scheiding tussen structuur en architectuur maakt ook dat goed is te zien hoe een onderneming werk heeft gemaakt van concepten en principes. Werken ze ook echt volgens de theorie, leveren ze voldoende resultaten en wat zijn enkele eenvoudige verbetermaatregelen om quick wins te realiseren? In figuur 4 staat welke objecten en componenten er zijn binnen de informatievoorziening van BetereZorg, maar ook enkele IV-regels die gelden, zoals de regel dat gegevens dubbel en inconsistent worden opgeslagen. Dit is mei 2011 XR Magazine

41


Informatievoorziening Structuur Blauwdruk Informatievoorziening (uitsnede van een aantal informatieobjecten, applicaties, koppelingen en databases die onvoldoende op elkaar zijn afgestemd) Front office

Vraag

Producten en diensten catalogus

Mid office

Back Office

Zakenmagazijn

Klanten systeem 1

Zakensysteem

Klanten systeem 2

Productenlijst

Klant

Post (gedigitaliseerd) Vraag Familie

BetereZorg

Dienstenlijst

E-mail Persoon

Recept

Call-center

Klanten DB

Relatie systeem

DMS

Apotheek

NAW

Patienten nieuw DB

Website Zorg systeem

CMS Klacht

Patienten oud DB

Bezoek Derden

Balie / Kantoor

Een en dezelfde persoon komt soms op vijf of zes verschillende wijzen voor in de databases, met veel fouten tot gevolg in de communicatie

Contracten DB

Relatie DB

Figuur 4: Uitsnede van de AS-IS Informatievoorziening Structuur Blauwdruk 2011 van BetereZorg

natuurlijk een ongewenste afspraak tussen partijen, maar wel één die impliciet en onbewust is gemaakt en zelfs wordt gehandhaafd waardoor het een principe is geworden. Dergelijke ongewenste regels en ongewenste principes in beeld brengen met VEA voor de directie maakt dat er ook door strategische keuzes daadwerkelijk iets gedaan kan worden aan deze misstanden. De communicatie met apothekers en huisartsen gaat nog soms via de privételefoon en op handgeschreven papier. Waardoor er ook veel mis gaat, verkeerde medicijnen worden voorgeschreven, gekocht of verstrekt, niet de juiste personen hebben contact met elkaar. Zo toont figuur 4 hoe ‘het nieuwe werken’ project geheel los staat van de rest en daarbij een kantoorautomatisering realiseert (Google Mail, Open Office en Alfresco) die los staat qua koppelingen van de bedrijfsapplicaties (SharePoint, Oracle, Windows en Office reporting).

blen of blokkeren. Tevens zijn de beelden te gebruiken als basis om de impact en toegevoegde waarde van een bedrijfstransformatie of een ICT-innovatie te toetsen en te beoordelen. De opgedane visuele beelden dienen bij uitstek als argumenten ter ondersteuning van de te nemen strategische beslissingen. Vervolgens kunnen deze zelfde beelden worden gebruikt als bindende kaders in de ontwikkel- en realisatietrajecten die volgen om het eHealth voor BetereZorg gestalte te geven. Voetnoten 1

In dit artikel zijn de werkwijze en voorbeeldvisualisaties die betrekking heb-

ben op de solution architectuur weggelaten. U kunt dit lezen in het volledige artikel dat gepubliceerd is op Paauwe Research: http://research.paauwe.info

Referenties [1] Visuele Enterprise Architectuur - Dragon1 HBO Studieboek, ISBN: 9789490873073. Download evaluatiekopie van het boek op www.dragon1.org

Conclusie Steeds meer krijgt Jacqueline het gevoel dat het meer dan nuttig was om deze workshops met directie, management en medewerkers van de business en ICT te houden. Zij heeft nu gezien dat Visuele Enterprise Architectuur het strategische stuurinstrument voor bestuur en directie is om in korte tijd een gemeenschappelijk beeld en begrip te kunnen vormen over de huidige situatie en toestanden in de onderneming die het uitvoeren van strategie ena42

XR Magazine mei 2011

[2] www.dragon1.org en wiki.dragon1.org

Mark Paauwe is bedenker van de Dragon1 methode. http://research.paauwe.info Talitha Paauwe-Wijnands is directeur van Paauwe Group. http://www.paauwe.info


Professionals over architectuur Naam:

Drs. Leendert R.E. Hinds

Functie:

Applicatie en Database specialist

Bedrijf:

Hints Company

Leeftijd:

53

Motto:

“Vertrouwen komt te voet en gaat te paard”

Aan welk project werkt u momenteel en welke rol heeft architectuur hierbij? Momenteel werk ik bij een staalonderneming aan de migratie van Oracle 10 naar Oracle11 en aan de migratie van Windows 2003 naar Windows 2008. De migratie zorgt ervoor dat de Oracle databases op aparte databaseservers worden geplaatst. In de huidige architectuur opereren de applicaties en databases op dezelfde fysieke systemen. Dit leidt tot performance problemen op bepaalde tijden. Mijn rol hierbij is die van coördinator. Hoe ziet de nieuwe architectuur van deze ICT-omgeving eruit? De nieuwe architectuur zou er een stuk simpeler uit moeten zien. Met simpel wordt verstaan dat ieder fysiek systeem een aparte functie heeft, namelijk een databaseserver of een applicatieserver. Hierdoor wordt het beheer van de complete omgeving eenvoudiger. Ook wordt het beheer en onderhoud van zowel de applicaties als de databases op deze wijze goedkoper en transparanter. Dit houdt in dat de systeemparameters van de servers specifiek naar de wensen van de applicaties of de databases ingesteld kunnen worden. Welke tips wilt u anderen meegeven om dit soort migratietrajecten tot een goed einde te brengen? Het hanteren van een normale projectmatige aanpak volgens een door het project gekozen methode is wellicht 44

XR Magazine mei 2011

vanzelfsprekend, maar wel belangrijk. Een goede gefaseerde planning is van wezenlijk belang. Daarnaast ben ik zelf geen voorstander van een ‘Big Bang’ invoering; een gefaseerde invoering is hierbij beter. Aangezien de onderneming vaak door moet blijven draaien is het net als een motor vervangen van een rijdende trein. Het geheel stopzetten en vervangen is geen optie. Tevens is een goede samenwerking met de diverse onderdelen in de organisatie, te weten applicatiebeheer, databasebeheer, systeembeheer en de gebruikersorganisatie van wezenlijk belang, evenals de noodzakelijke support van het management. Welke vervolgstappen zijn nog mogelijk in dit migratietraject? Na de implementatie van de databases en applicaties op aparte systemen zal virtualisatie de volgende logische stap zijn. Dat houdt in dat de diverse aparte fysieke systemen plaats zullen maken voor gevirtualiseerde systemen op een beperkt aantal fysieke systemen, waarbij de scheiding in database en applicatie functie nog steeds aanwezig zal zijn. In feite zijn wij dan al een vorm van PaaS en IaaS aan het implementeren. Leendert Hinds is Applicatie en Database specialist en werkzaam bij Hints Company.


Volgende editie van XR Magazine:

Business Intelligence In de juni editie van XR Magazine staat het onderwerp Business Intelligence en Architectuur centraal. Heeft u een duidelijke mening, vernieuwende visie of boeiende praktijkcase over dit onderwerp? Dan zitten de lezers van XR Magazine op uw bijdrage te wachten! Het beschikken over de juiste en actuele informatie is cruciaal voor ondernemingen om te kunnen presteren en innoveren en de juiste beslissingen te kunnen nemen. De vraag is alleen: hoe haal je uit die grote hoeveelheid beschikbare data de noodzakelijke management- en stuurinformatie? Het concept Business Intelligence speelt hierbij een belangrijke rol. Maar wat is BI nu precies? Welke architectuur heeft een BI systeem? Hoe kan BI succesvol worden toegepast? In de juni editie van XR Magazine staan deze vraagstukken centraal. Wij zijn bijvoorbeeld op zoek naar artikelen met de volgende onderwerpen: • • • • • • • • •

De architectuur van een BI-systeem Top 10 BI en Datawarehouse architectuurprincipes Business Intelligence risico’s en obstakels De rol van de BI architect Location Intelligence: Integratie BI en geografisch informatiesystemen (GIS) Business Intelligence en Social Media Visualiseren van data Trends op het gebied van BI, Master Data Management, Performance Management, Datawarehousing en Datamining Praktijkcases over succesvolle toepassing van BI

Bijdragen voor de juni editie kunnen ingezonden worden tot vrijdag 27 mei. Indien u van plan bent een artikel te schrijven stuur dan zo snel mogelijk een e-mail naar redactie@xr-magazine.nl met daarin een globale omschrijving van de inhoud en onderwerp van het artikel. Op deze wijze kan plaatsing van het artikel in het magazine eerder gegarandeerd worden.

Colofon XR Magazine: het online platform en vakblad voor managers en architecten uit het bedrijfsleven en bij de overheid over de praktijktoepassing van Enterprise-, Bedrijfs-, Informatie- en ICT-architectuur, BPM, SOA, ITSM en aanverwante vakgebieden. Op de website van XR kunt u de nieuwste en alle voorgaande edities van XR Magazine bekijken en ook alle edities downloaden. Tevens worden deze edities als e-magazine maandelijks in de vorm van een pdf naar onze mailinglist verstuurd waar u zich ook voor kunt aanmelden. Oplage en attentiewaarde: Steeds vaker zijn de artikelen uit XR Magazine het gesprek van de dag op kantoor! XR Magazine verschijnt 10 keer per jaar en wordt gratis verspreid via e-mail in Nederland en België in een oplage van 3.000 exemplaren. Meer dan 30% van de abonnees bezoekt naar aanleiding hiervan binnen vier uur de XR website en leest het XR Magazine. Het XR website bezoek groeit momenteel elke maand met 25%.

Volg XR Magazine: XR Magazine maakt intensief gebruik van sociale media om nieuwe content zo snel mogelijk te verspreiden. Hiervoor maakt XR Magazine o.a. gebruik van Twitter, LinkedIn, NUjij.nl en RSS-feeds. Hoofdredacteur: Koen van Boekel, 0317 41 13 41, redactie@xr-magazine.nl Advertenties: Afdeling Marketing, 0317 41 13 41, info@xr-magazine.nl Artikelen uit XR Magazine mogen alleen worden overgenomen, gekopieerd enz. na uitdrukkelijke schriftelijke toestemming van XR Magazine. Website: www.xr-magazine.nl

mei 2011 XR Magazine

45


XR.

Kennisdeling over de praktijktoepassing van Enterprise Architectuur

/XR_Magazine_23_2011  

http://www.xr-magazine.nl/sites/default/files/XR_Magazine_23_2011.pdf

Read more
Read more
Similar to
Popular now
Just for you