procesmanagement

Inhoud Stel, je koopt een huis uit de jaren ’30. Het is je absolute droomhuis, maar er moet nog wel flink wat aan verbouwd worden. Uiteraard heb je hiervoor het benodigde budget bepaald en een tijdsplanning gemaakt. Om binnen scope te blijven kan een blauwdruk van het huis enorm helpen. Nu wil het geval dat er tot jouw grote teleurstelling geen blauwdruk van het huis voorhanden is. Om te zorgen dat je weet waar water- en gasleidingen of elektriciteitskabels lopen en je deze tijdens de verbouwing niet per ongeluk raakt, zul je met speciale meetapparatuur in kaart moeten (laten) brengen waar kabels zich bevinden en misschien zelfs hier en daar een muur open moeten breken om te zien waar leidingen lopen. Als gevolg van het ontbreken van de blauwdruk kan je de verbouwing nooit binnen je scope realiseren en raak je enorm achter op het budget en de tijd die je dacht nodig te hebben. Ondanks dat besluit je om – voor de verbouwing – overzicht te krijgen en een blauwdruk te maken van je huis. Uiteraard kost dat extra werk en tijd, maar vijf jaar later blijkt deze investering haar vruchten af te werpen als er een lekkage ontstaat. Een blik op je blauwdruk helpt je namelijk snel en gemakkelijk te achterhalen waar de lekkage vandaan moet komen, zonder dat je hiervoor muren hoeft open te breken. En dat geldt ook voor het bedrijfsleven. Door je bedrijfsprocessen vast te leggen in een blauwdruk van je organisatie in het Mavim platform, ben je in staat om sneller en eenvoudiger in te spelen op risico’s (zoals een lekkage in je huis), is de organisatie transparant (kun je als het ware door de muren heen kijken) en kun je incidenten voor blijven. Door processen, systemen en mensen met elkaar te verbinden en te borgen kan je goed inspelen op veranderingen (zoals de verbouwing van je huis).   Door: Léon van der Windt Lees hier hoe je in 10 eenvoudige stappen een procesblauwdruk van je organisatie kunt maken 

Inhoud In het eerste deel van deze serie hebben we de focus gelegd op Service-integratie vanuit noodzaak, voordelen en randvoorwaarden. In het tweede deel zijn we nader ingegaan op de meest essentiële veranderingen in de werkwijze van de dienstverleners en positionering van dienstverlening ten opzichte van klanten, gebruikers en ondersteunde bedrijfsprocessen. In dit derde deel wordt ingezoomd op veranderingen in beleving en ervaring van klanten, gebruikers en dienstverleners.   Wat is service-integratie waard voor een organisatie? Het meest in het oog springende effect van service-integratie voor klanten en gebruikers, wat als positief zal worden ervaren, is dat de zoektocht naar de juiste servicedesk weg valt. Klant en gebruiker worden na de integratie van servicecentra, helpdesks en andere loketfuncties per definitie nooit meer van het kastje naar de muur gestuurd met hun melding. De waarde hiervan voor de organisatie wordt door de afzonderlijke dienstverleners vaak gemakkelijk en schromelijk onderschat. Alleen al het feit dat gebruikers voor hun meldingen niet hoeven te shoppen en na hoeven te denken waar ondersteuningsvragen gemeld kunnen worden geeft grote besparingen in tijd. Tijd die gebruikers kunnen blijven besteden aan het uitoefenen van hun taken binnen bedrijfsprocessen. Om de waarde van alleen al dit aspect tastbaar te maken kan worden gerekend met een simpele formule. Aantal meldingen op jaarbasis vermenigvuldigd met het percentage dat eerst bij een verkeerde serviceorganisatie wordt gemeld, de verloren tijd door contact met de verkeerde serviceorganisatie en een gemiddeld uurtarief levert al snel een serieus bedrag op. En verkeerde contactmomenten tellen dubbel. Het is zowel verloren tijd van de gebruiker als van de medewerker(s) bij van de verkeerde serviceorganisatie. Een tweede waarde wordt gevonden in de manier waarop afspraken over dienstverlening worden gemaakt met een enkele geïntegreerde serviceorganisatie. Zoals in het vorige deel benoemd, wordt de dienstverlening rechtstreeks gerelateerd aan de veerkracht in het ondersteunde bedrijfsproces: Line-of-business (LOB) dienstverlening. De business-owner heeft nog maar één enkele gesprekspartner over diensten, dienstverlening en dienstenniveaus die nodig zijn om zijn of haar businessproces goed ondersteund te krijgen, in plaats van met elke dienstverlener afzonderlijk.   Een relatie heeft meerdere kanten Een bredere waardebepaling begint met een nulmeting bij de klant, gebruiker en dienstverleners met de vraag welk gemak en last men ervaart bij gescheiden serviceorganisaties. En hierbij graag ook de uitnodiging om een optimale ondersteuningsvorm te beschrijven gezien vanuit het ondersteunde bedrijfsproces. Hierbij kunnen meer aspecten worden meegenomen dan alleen de waarde uitgedrukt in tijd en geld. Bijvoorbeeld emotie, frustratie en verstoorde relaties. Want die ontstaan nu eenmaal in meer of mindere mate als meldingen frequent bij de verkeerde serviceorganisatie(s) terecht blijven komen. Naarmate meer klanten en dienstverleners worden bevraagd, in bijvoorbeeld een tevredenheidonderzoek aangevuld met interviews, ontstaat een goed beeld van de totale waarde. En van de wederzijdse verwachting(en). Verwachtingen kunnen vertaald worden naar veranderpotentieel voor de geïntegreerde serviceorganisatie.   En wat verandert er dan operationeel? Een belangrijke tegenwerping vanuit afzonderlijke dienstverleners is dat door service-integratie minder meldingen direct in de eerste lijn kunnen worden afgehandeld. Voor de minder volwassen dienstverlening is dat inderdaad zo omdat er minder sprake is van gestandaardiseerde meldingen met bijbehorende werkinstructies, die door generalisten in de eerste lijn kunnen worden afgehandeld. Is de beperkte volwassenheid en standaardisatie in de eerste lijn dan een reden om te wachten met service-integratie? Nee! Service-integratie leidt er juist toe dat de meest volwassen dienstverlener in de groep een duidelijke voorbeeldfunctie krijgt en daarmee de groei van de anderen bevordert. Voor gebruikers is, voor het laten afhandelen van meldingen, het procentuele verschil van directe afhandeling voor en na service-integratie niet of nauwelijks merkbaar. Een gebruiker doet een melding en kan dan altijd al twee soorten ondersteuning onderscheiden. Het kan meteen aan de telefoon worden geregeld of de dienstverlener komt er later, al dan niet op locatie, op terug. Service-integratie verandert niets aan die twee mogelijkheden. Geen enkele individuele gebruiker doet in zijn eentje zoveel meldingen dat het merkbaar is dat een lager percentage niet direct in eerste lijn wordt afgerond. Een andere ontwikkeling, die volledig los staat van service-integratie, leidt wel merkbaar tot minder afhandelingen in de eerste lijn. Technische innovaties zoals bijvoorbeeld cloud-technologie, Computing Everywhere en Computing Anytime leiden tot meer gebruik van self-service en minder persoonlijk contact met servicecentra. Hierdoor ervaren gebruikers minder directe afhandeling in de eerste lijn. Dit houdt geen verband met het wel of niet doorvoeren van service-integratie. Wat voor gebruikers en klanten positief merkbaar is als gevolg van service-integratie is soepeler afhandeling van complexe meldingen bij dienstverlening die van meerdere ondersteunende disciplines afhankelijk is. Afzonderlijke ondersteunende partijen hebben voor integratie de ruimte om naar elkaar te verwijzen en daarmee de afhandeling te vertragen. In een situatie waarbij de betrokken dienstverleners zijn geïntegreerd onder een enkele aansturing is de verantwoordelijkheid bij voorbaat eenduidig en helder.   Service-integratie is een middel, geen doel op zich Net als in de tijd zonder service-integratie zijn snelheid en kwaliteit van dienstverlening essentieel in het creëren van waarde. Standaardisatie is hierbij een groot goed. Standaardisatie van dienstverlening en dienstverlener. Standaardisatie bepaalt in grote mate de volwassenheid, voorspelbaarheid en betrouwbaarheid. Met standaardisatie worden immers de doelmatigheid en doeltreffendheid geborgd. Voor vaker voorkomende meldingen zijn de contactmomenten geprotocolleerd via een script om gericht benodigde informatie beschikbaar te krijgen, behorende bij de betreffende melding. In een relatie van een dienstverlener met een particulier wordt nog altijd veel 'geslikt' waar het gaat om wachttijd en oplostijd, maar in de ondersteuning van een professional gaat er kostbare tijd verloren. Wachttijd en oplostijd zijn voor een gebruiker feitelijk allebei wachttijd en brengen per definitie bedrijfsschade met zich mee. In kosten, imago, tot wellicht zelfs wanprestatie. In zowel de ‘oude’ situatie als de nieuwe is het managen van wachttijd voor gebruikers een belangrijke succesfactor voor gebruikerservaring. De scope voor de dienstverlening voor of na service-integratie verandert niets aan dat mechanisme en bekende stuurmiddelen hiervoor blijven onverminderd toepasbaar. Bijvoorbeeld via dynamische allocatie van de capaciteit in de telefoondienst op basis van actuele wachtrijgrootte of wachtrijhistorie. Door het mechanisme van standaardisatie integraal toe te passen op alle dienstverlening wordt de waarde ervan verveelvoudigd.   De veranderende serviceorganisatie(s) De beleving van individuele dienstverlenende medewerkers verandert door integratie van dienstverleners met verschillende niveaus van standaardisatie en volwassenheid. Met name in de eerste lijn. Was men eerder nog niet gewend aan een grote mate van standaardisatie, dan ervaart men op basis van meldingen uit de ‘andere’ diensten na enige tijd de kracht en het gemak van werken volgens werkinstructies als een verbetering. Ook al gaat er een stuk vrijheid verloren om zelf steeds te mogen bepalen hoe werkzaamheden worden verricht. Medewerkers die juist al gewend zijn aan een hoge mate van standaardisatie ervaren de ‘terugval’ op basis van meldingen uit de ‘andere’ diensten en zullen hun nieuwe collega’s stimuleren en helpen dezelfde mate van volwassenheid te realiseren.   Geen ‘hullie’ en ‘zullie’ meer. Iedereen dezelfde doelstelling Het basisplan voor de geïntegreerde serviceorganisatie is in overleg met de klant(en) ontstaan op hoofdlijnen. Elke serviceorganisatie levert diensten en producten aan de gebruikersorganisatie. Met mede verantwoordelijkheid voor de doelstelling van de gebruikersorganisatie, geen eigen doelstelling. Dit vereist resultaatgerichtheid en klantgerichtheid, bezien vanuit het ondersteunde bedrijfsproces. Dit gaat over houding, gedrag en cultuur. Een gebruiker stelt een vraag aan de serviceorganisatie. In de communicatie wordt initieel geluisterd naar de gebruikersvraag, waarbij in een vraag- en antwoordspel tussen ondersteuner en gebruiker duidelijk dient te worden wat de gebruiker wenst aan ondersteuning en wat de serviceorganisatie kan leveren. Dit impliceert dat de dienstverlener zich moet laten meenemen in wat er aan ondersteuning nodig is, met een prestatie die voor het ondersteunde bedrijfsproces 'verdraagbaar' is. Specifieke productkennis is hierbij niet bij voorbaat vereist. De klant heeft immers een functionele vraag. Het siert de dienstverleners die de ambitie tonen om zoveel mogelijk vragen in de eerste lijn snel te kunnen oplossen. Dus de vraag herkennen en meteen kunnen afhandelen. De grotere scope van diensten na service-integratie maakt dat de ‘generalist’ in de eerste lijn niet alles meer kan overzien en ‘uit het hoofd’ kan afhandelen. De kracht en volwassenheid van een skilled-helpdesk zitten dan niet meer in parate kennis van de specifieke medewerker, maar in de beschikbaarheid van gestandaardiseerde werkinstructies. Gemaakt door specialisten, toepasbaar voor generalisten. Des te meer meldingen via gestandaardiseerde werkinstructies kunnen worden afgehandeld, des te effectiever de ondersteuning wordt.   Geïntegreerd gereedschap Een belangrijk facet van Service-integratie is het gezamenlijk gebruik van dezelfde ondersteunende Service Management systemen over de verschillenden ondersteunende disciplines heen. Doordat de procesmatige werkwijze in de dienstverlening is geüniformeerd, kan worden volstaan met een enkele functionele toepassing voor alle dienstverlening. Belangrijk hierbij is te onderkennen dat de uniforme werkwijze leidend moet zijn, maar dat beperkingen in de mogelijkheden van een gekozen Service Management systeem beperkend kunnen werken op de mogelijke werkwijze. Procesmatig beheer is weliswaar het toverwoord, maar feitelijk is voor elk type melding een goede workflow bepalend voor de kwaliteit van dienstverlening. Workflows leggen een logica over de processen heen, met opeenvolgende taken en activiteiten om zo zeker mogelijk tot een goed resultaat in de afhandeling te komen. Helaas is niet elk bekend Service Management systeem in staat goed workflow management te faciliteren. Ongeacht of taken, bevoegdheden en verantwoordelijkheden dan met behulp van een zuivere RACI–tabel eenduidig belegd kunnen worden, als de ondersteunende middelen het niet faciliteren gaat het links- of rechtsom ten koste van de kwaliteit van dienstverlening. Reden te meer om de keuze voor een Service Management systeem weloverwogen te nemen, waarbij prijs niet het belangrijkste argument is. Goedkoop is al snel duurkoop.   In het volgende deel Tot zover de beleving van betrokkenen bij service-integratie. In het vierde deel van deze reeks zullen we nader ingaan op de positionering en toepassing van een IT Service Management tool en de veranderende rol van het management bij Service Integratie.    Over de auteurs en hun bronnen Edwin Charité heeft 25 jaar ervaring in Service Management en is als consultant werkzaam voorPaphos Group in Amsterdam.Jeroen van de Ven heeft ruim 25 jaar ervaring in automatiseringsland. Systeembeheer, applicatie beheer, informatie analyse, projectmanagement, service management en lijnmanagement zijn de gebieden waarin hij zijn ervaring heeft opgebouwd. Momenteel is hij als hoofd MICT Technische Services werkzaam binnen het Jeroen Bosch Ziekenhuis in ‘s-Hertogenbosch..Ronald Vendel heeft ruim 35 jaar ervaring in de it-dienstverlening. Hij begon zijn loopbaan in 1980 bij Unisys als applicatieontwikkelaar en vanaf 1999 was hij commercieel verantwoordelijk bij een leverancier van documentmanagementsoftware. Sinds 2004 is Ronald werkzaam bij Mavim en als manager Business Solution Development betrokken bij het gehele klantenportfolio als ook vele partners van Mavim. Zijn focus ligt op het ontwikkelen en bieden van nieuwe toepassingen met Mavim, geavanceerde software die wordt ingezet bij zo’n duizend organisaties wereldwijd, over de as van thema’s zoals 'proces- en kwaliteitsmanagement', 'business en it-alignment' tot 'enterprise transformation'. Basis voor dit artikel zijn de volgende (inspiratie-)bronnen: ISM is een product van Servitect Veranderkrachtmodel, Ten Have Theory U, Otto Scharmer “Thinking in Promises”, Mark Burgess PDCA, Deming “De zeven stappen van effectief leiderschap”, Stephen R. Covey Theory of Constraints, Goldrath “Beheer van informatiesystemen”, Prof. Dr. Ir. Maarten Looijen 4-fasenmodel, Hardjono Deze artikelen zijn te vinden als expertverslagen op computable.nl.   Lees ook de volgende delen in de reeks Economy of Scope in Service Management: Deel 1: Economy of scope in service management Deel 2: Dienstverlening begint niet voor niets met "dienst" Deel 4: De manager als voorbeeld van het 'not invented here' syndroom

Inhoud   Zoals iedereen die ooit een huis heeft gebouwd begrijpt, biedt een blauwdruk je de basis en beste kans op het succesvol bereiken van jouw doelstelling. Ook in de bedrijfswereld kan een blauwdruk een effectief instrument zijn. Een blauwdruk van je bedrijfsprocessen helpt jou en je collega's om inzicht te krijgen in het verloop en de duur.  In het boek getiteld “The Power of Business Process Improvement” reikt Susan Page tien eenvoudige stappen aan die je kunt gebruiken bij het maken van je eigen proces blauwdruk.   Maak een procesinventarisatie — De eerste stap is het inventariseren van al uw processen. Hoewel deze handeling misschien eenvoudig lijkt (wellicht denkt u alle processen al te kennen), helpt het vergaren van een visuele lijst om alvast na te denken over de prioriteit van elk proces. Leg het fundament — Stap twee helpt je bij het ontwikkelen van het toepassingsgebied. Op dezelfde manier waarop je aan een plan begint voor de verbouwing van jouw huis, moeten er voor een procesblauwdruk kaders worden vastgesteld. Teken de blauwdruk — Het maken van de blauwdruk impliceert begrip van waar overdrachten tussen afdelingen voorkomen. Bij deze stap moet je de informatie (output) uit de vorige stap toepassen door in kaart te brengen welke afdeling of individu verantwoordelijk is voor welk deel van het proces, van begin tot eind. Maak een schatting van tijd en kosten — Voordat doelen voor procesverbetering worden gesteld, is een nulmeting van cruciaal belang. Hoe lang duurt het verloop van processen en wat kost dit momenteel voor jouw organisatie? Deze stap definieert de parameters die worden gebruikt voor de verbetering van de doelstellingen. Controleer de proces blauwdruk — Vanaf dit punt is het waardevol om feedback te krijgen van betrokken collega's om ervoor te zorgen dat je nieuwe blauwdruk de realiteit weerspiegelt. Deze stap helpt ook om de nodige ondersteuning van belanghebbenden te verkrijgen. Pas verbetertechnieken toe — Een gestructureerde aanpak voor het verbeteren van bedrijfsprocessen met behulp van methoden zoals: afschaffing van de bureaucratie, evalueren van waarde toevoegende activiteiten, elimineren van overtolligheid, vereenvoudigen van rapporten en formulieren, verminderen van de cyclustijd en automatisering toe te passen. Door dergelijke verbetertechnieken nauwkeurig toe te passen op elk proces, zorg je ervoor dat al je processen bedrijfswaarde opleveren. Creëer interne controles en statistieken — De volgende stap is ontworpen om je te helpen de voortgang te monitoren. Het instellen van interne controles helpt om hulpmiddelen te creëren voor het verhogen van de effectiviteit, de efficiëntie en het aanpassingsvermogen van het bedrijfsproces. Bedrijfsprocessen zijn, zoals veel andere dingen, vaak onderwerp van menselijke fouten. Daarom is het essentieel om interne statistieken te ontleden en het proces zo veel als mogelijk te automatiseren. Doe een proeftest — Op dezelfde manier waarop een gratis 30-dagen test is bedacht om je kennis te laten maken met een product zonder hiervoor grote investeringen te doen, zal een proeftest voor jouw nieuw ontworpen bedrijfsprocessen helpen bugs op te lossen en ervoor zorgen dat het procesresultaat aan jouw vereisten voldoet, voordat je de voorgaande manier van werken overboord gooit. Voer de verandering door — In dit stadium worden de vernieuwde processen uitgerold. Deze stap vereist dat je de juiste informatie richting de juiste mensen communiceert. Zonder deze stap, is het nieuwe proces bijna gegarandeerd te mislukken. Streef naar continue verbetering — Dit is de onderhoudsfase. Hopelijk zijn de nieuwe processen succesvol ingevoerd. De laatste fase behelst het creëren van een mentaliteit waarbij procesverbetering als een doorlopend fenomeen wordt beschouwd, dat voortdurend evaluatie vereist om continue doeltreffendheid en efficiëntie voor de organisatie te garanderen. Hebt u ooit met succes een proces blauwdruk vastgelegd? Bekijk hier de praktijkcase van Kuwait Petroleum waarbij een complexe ERP-implementatie de aanleiding vormde voor het in kaart brengen van een procesblauwdruk

Inhoud Voorheen betekende ‘technology push’ dat de techniek vooropliep en de klant of gebruiker het nauwelijks kon bijbenen: hij remde de snelheid van de ontwikkelingen omdat zijn adoptievermogen te gering was. Tegenwoordig is het omgekeerde aan de orde: nieuwe technologie maakt de klant of gebruiker nog hongeriger, hij adopteert snel en wakkert de push verder aan. Zie hier de uitdaging voor het management, dat moet acteren in deze dynamische context waarin snelheid en innovatie het verschil maken. Bovendien heeft het management intern te maken met de nodige uitdagingen (tijd, geld, bestaande infrastructuur, verandervermogen) die nopen tot het maken van keuzes en stellen van prioriteiten. Om aan te sluiten op almaar versnellende ontwikkelingen is het noodzakelijk de planningshorizon op strategisch niveau hierop aan te passen. Agile is het sleutelwoord. ICT speelt in de dynamiek een cruciale rol. Op het gebied van functionaliteit, snelheid en integriteit. Maar ook de ontwikkelingen voor de techniek onder de motorkap gaan snel en hebben veel impact (bijvoorbeeld cloudtechnologie of security). Genoeg reden om de besturing van groei en innovatie aan te laten sluiten bij de voorlopersrol die ICT hierin met agile voortbrengingsmethoden heeft opgeëist. Agile betekent wendbaar en deze duiding is de spijker op z’n kop. De meeste agile methoden zijn het bekendst vanwege hun toepassing binnen applicatieen softwareontwikkeling. Er wordt gewerkt met iteraties, kleine opzichzelfstaande projecten die steeds iets bruikbaars opleveren. Teams zijn multidisciplinair en het eigenaarschap is geborgd in de rol van de product owner. Voorbeelden van agile methoden zijn kanban, scrum en het Scaled Agile Framework.   ICT-besturing Veel organisaties hanteren – nog steeds – voor het besturen van ICT het robuuste negenvlaksmodel (van Rik Maes) of varianten daarop. Het model lijkt vanwege zijn eenvoud en praktische bruikbaarheid de tand des tijds glansrijk te doorstaan. Het kent drie lagen en drie kolommen waardoor negen vlakken ontstaan. De lagen betreffen strategie (richten, scope 3 tot 5 jaren), tactiek (inrichten, scope 1 tot 3 jaren) en operatie (verrichten, scope tot 1 jaar). De drie kolommen representeren het businessdomein, het informatievoorzieningsdomein en het technologiedomein. Maar hoe bruikbaar is het model nu nog, gelet op de eerder beschreven uitdagingen waar bedrijven voor staan? Past een strategische scope van 3 tot 5 jaar, of een tactische planningshorizon van 1 tot 3 jaar nog wel? De indeling in de drie genoemde horizontale lagen roept associaties op met de bekende watervalmethode. Op strategisch niveau worden voor een langere termijn domeinen benoemd, die ‘onomkeerbaar’ zijn en dus rigide worden doorgegeven aan het tactische niveau, de waterval volgend. Op dit niveau worden vervolgens nieuwe applicaties ontwikkeld die passen binnen de strategische domeinen. Ook applicatieontwikkeling zelf is veelal langs de route van de waterval gelopen. Als reactie op deze traagheid en onomkeerbaarheid zijn agile methoden zoals bekend tegenwoordig gemeengoed geworden.   Agile en het negenvlaksmodel Als we de agile methoden projecteren op het negenvlaksmodel dan zien we in eerste instantie toepassing binnen vlak 5, waar softwareontwikkeling plaatsvindt. De tactische planningshorizon verkleint hierdoor sterk: van 1 tot 3 jaar naar maximaal 3 maanden of zelfs 3 weken of 3 dagen! Multidisciplinaire teams met vertegenwoordigers uit de business, klanten en ICT-specialisten doen de agile-olievlek uitbreiden naar vakken 4 en 6 op tactisch niveau. Wie het boek The Phoenix project door Gene Kim, Kevin Behr en George Spafford heeft gelezen begrijpt dat iteraties ook direct en snel in productie genomen kunnen worden. Er zijn bedrijven die duizenden ‘deployments’ per dag realiseren. Vertaald naar het negenvlaksmodel betekent dit een uitbreiding van de agile-olievlek naar het operationele niveau, vlakken 7, 8 en 9. De agile-benadering neemt snel toe en werpt zijn vruchten af. Het lijkt erop dat alleen de strategische, richtende laag zich nog aan dit agile-geweld moet aanpassen.   Agile werken in de strategische, richtende laag De traditionele strategische planningscyclus voor bedrijfs-, informatievoorzieningsen ICT-strategie past niet meer bij de tijdshorizon op inrichtend en verrichtend niveau. Strategieontwikkeling wordt kortcyclischer: herijking en bijsturing eens per 3 maanden is eerder aan de orde. Natuurlijk is er een richtpunt op de meerjarenhorizon maar ook die is ernstig aan verandering onderhevig. Dit betekent een aanpassing in het strategisch planningsproces voor organisatie en instrumentarium. Een goede en bewezen aanpak om dit te organiseren is een of meerdere ‘radarteams’ te vormen. Radarteams zijn multidisciplinaire teams die voortdurend de markt van technologie-aanbod, de klantbehoeften en gedrag van concurrentie scannen. In ‘sprints’ van 3 maanden doen ze aanbevelingen over het implementeren van nieuwe toepassingen. Zowel waar het digitaliseren van het primaire en ondersteunende processen betreft, maar ook aangaande toepassing van nieuwe ICT-technologie onder de motorkap. Ook het instrumentarium op het strategisch kortcyclisch niveau zal veranderen. Zo bieden geavanceerde simulatietechnieken de mogelijkheid om effecten van toepassing van digitalisering te voorspellen en te kwantificeren. Bijvoorbeeld: hoeveel extra callcentercapaciteit is er nodig na de introductie van een app voor het afsluiten van een autoverzekering? Een ander instrument is het zogeheten digitaliseringsambitie-grid. Dit grid is het resultaat van een per sprint uit te voeren scan en is vooral bedoeld om de gehele organisatie betrokken te houden bij de ontwikkelingen. De scan speelt in op het feit dat, ingegeven door snelle ontwikkelingen, de digitaliseringsgraad en prioriteiten voortdurend verschuiven. In het grid worden, als uitkomst van interviews en workshops, alle primaire en ondersteunende processen geplot in een diagram met op de assen de digitaliseringsgraad en prioriteit. Idealiter zijn deze in lijn met elkaar op de diagonale as. Met name voor de processen in het vierde kwadrant rechtsonder (hoge prioriteit, lage digitaliseringsgraad) is er werk aan winkel. De resultaten uit de scan zijn dan richtinggevend voor de opdrachten aan product owners in het tactisch en operationele domein.   Van langetermijnbeleidsplan naar kwartaaldashboard Het negenvlaksmodel blijft als ordeningskader prima bruikbaar voor ICT-besturing. Door toepassing van agile methoden, in eerste instantie op de tactische en operationele lagen, wordt wel de cyclustijd drastisch verkort. Daarnaast is het traditionele onderscheid tussen business en IT aan het verdwijnen. Dit vereist vervolgens aanpassing van de werkwijze op strategisch niveau, door ook hier agility te introduceren. Door op dit niveau voortdurend de markt te scannen op de bruikbaarheid en toepasbaarheid van technologische ontwikkelingen en hierover met een kwartaalfrequentie aanbevelingen en implementatievoorstellen te doen wordt strategievorming agile. Het strategisch denken wordt sneller en kortcyclischer, maar ook spannender met een grotere kans op fouten of verkeerde inschattingen. Echter, waar staat geschreven dat management en directies geen fouten mogen maken? Drie jaren wachten tot een volgende strategische herorie?ntatie of een strategieontwikkeling met een doorlooptijd van 6 maanden zijn echt geen optie meer. Management zou zich daarmee loskoppelen van de tactische en operationele agile werkelijkheid. Bij dezen nemen we dus afscheid van documenten getiteld ‘Informatiebeleidsplan 2016 – 2019’ en omarmen het digitale en dynamische dashboard ‘Q3 -2016: implementatieaanbevelingen radarteam digitale trends en ontwikkelingen’.Auteurs: Henk Stienstra en Remko ZuidgeestMeer weten over agile werken? Lees hier meer over 'de weg naar continue verbetering'

Inhoud   Een procescultuur waarin zorg voor proceskwaliteit centraal staat, is essentieel voor organisaties die hun wendbaarheid en effectiviteit wensen te vergroten. Zo’n cultuur dient ook als brug tussen strategievorming en -uitvoering. In dit artikel vindt u 15 aandachtspunten voor de ontwikkeling en onderhoud van een fundamentele procescultuur.    1. Houd het einddoel in zicht Een procesgeoriënteerde organisatie neemt het doel dat gerealiseerd moet worden (innovatievermogen, concurrentiekracht, product- of prijsleiderschap, etc.) als leidraad voor inrichting en monitoring van processen.   2. Benoem een proceseigenaar Procesmanagement mist vaak glamour waardoor het lastig wordt een procesbeheerder aan te wijzen die de verantwoordelijkheid op zich neemt. Empowerment is essentieel.   3. Definieer procesrichtlijnen De grondbeginselen hiervoor zijn te vinden in procesverbeteringsbenaderingen zoals Total Quality Management (TQM), Six Sigma, Lean, ISO-normen of het Toyota Productiesysteem.   4. Strikte monitoring en bekrachtiging Eenmaal vastgesteld dienen de richtlijnen verinnerlijkt te worden om ze te veranderen in gewoontes. Dit wordt ondersteund met training en opleiding. Procesaudits dienen voor de borging van resultaten.   5. Identificeer koplopers Net zoals bij culturele processen in de maatschappij zijn er ook bij organisatorische processen ‘early adopters’ die voorop lopen en die als rolmodel dienen voor gedragsverandering.   6. Begeleid nieuwe organisatieleden Nieuwkomers hebben een open houding en zijn derhalve sterk vatbaar voor verandering. Benadruk al van meet af aan het belang van procesdenken voor het succes van de organisatie.   7. Procesdoelrealisatie is onderdeel van prestatiebeoordeling Het toekennen van beloningen en erkenningen is zeer bevorderlijk voor een cultuur van procesgerichtheid.   8. Continue ondersteuning van de procescultuur Het vestigen van een succesvolle procescultuur neemt vele jaren in beslag. Het vergt continue investeringen en aandacht van het prioriteiten stellende topmanagement.   9. Communicatie is essentieel Het kweken van een fundamentele procesgerichtheid in alle lagen van de organisatie is ook een kwestie van PR: de ‘hearts and minds’ van de organisatieleden moeten gewonnen worden.   10. Stuur het proces aan met een team Dit team komt regelmatig bij elkaar, stelt prioriteiten, coördineert activiteiten, analyseert knelpunten en bediscussieert de vooruitgang in het procesresultaat.   11. Houd ontwerp en uitvoering in balans Hoewel een zekere mate van scheiding tussen ontwerpen en uitvoeren van processen gewenst is, is het ook belangrijk mensen tussen deze beide disciplines te laten rouleren.   12. Feedbackmechanismen en betrokkenheid De eigenaren van de diverse processen moeten resultaten met elkaar kunnen delen. Deze terugkoppelingen bevorderen de creativiteit en vergroten de betrokkenheid bij het proces.   13. Cultiveer ‘procesgemeenschappen’ Deze groepen, die als platform dienen om de diverse procesverantwoordelijken uit de hele organisatie of alle businessunits bij elkaar te brengen, zijn cruciaal om het procesdenken en de procesresultaten te verspreiden (kennisdeling).   14. Creëer een ‘procescentrum’ Een procescentrum is een plek waar alle informatie m.b.t. de belangrijkste organisatieprocessen wordt getoond, waardoor deze processen bij iedereen in de organisatie kunnen beginnen te ‘leven’.   15. Innovatie door middel van procesmanagement Voorwaarde voor innovatie is dat processen op orde zijn. Even belangrijk is het om na te gaan of kleine, incrementele procesveranderingen voldoende zijn om aan omgevingsvereisten te voldoen of dat een radicale verandering noodzakelijk is. Bron: sigmaonline.com / processexcellencenetwork.comBenieuwd hoe Arcadis haar transformatie reis naar een uniforme manier van werken faciliteert? Lees hier de klantcase. Meer weten over het vertalen van uw bedrijfsstrategie naar concrete acties en projecten?Bekijk hier de factsheet.

Inhoud Agile wordt vaak gezien als alleen maar programmeren en niets documenteren. Documentatie lijkt het ondergeschoven kindje. Onterecht, zeggen Nicole de Swart en Rini van Solingen. De rol van documentatie verandert, maar zij is niet overbodig. Vijf misverstanden over agile en documentatie. Veel organisaties stappen over op agile systeemontwikkeling om sneller software te kunnen ontwikkelen en sneller te kunnen reageren op nieuwe vragen uit de markt. Snelheid en wendbaarheid worden gezien als cruciale randvoorwaarden voor de toekomst. Kort-cyclisch leveren van werkende en geteste software staat daarbij centraal. Documentatie lijkt dan al snel het kind van de rekening te worden. Voor je het weet start de volgende sprint en is er geen tijd om te documenteren wat er in de vorige is opgeleverd. Dit voedt het misverstand dat het in agile alleen maar gaat om programmeren zonder te documenteren (zie kader). Dit vooroordeel lijkt ook bevestigd te worden door de tweede regel van het Agile Manifest, waarin werkende software boven uitgebreide documentatie wordt gesteld. De waarheid is genuanceerder. Ja, agile stuurt meer op directe resultaten en producten dan op tussenresultaten en documenten. Ja, documentatie wordt gezien als ondersteunend en niet als leidend. Ja, met een agile werkwijze is doorgaans minder documentatie nodig. Maar nee, agile betekent niet alleen maar programmeren en niets documenteren. Agile is focussen op het leveren van zoveel mogelijk waarde, iedere sprint opnieuw. Ook ten aanzien van documentatie wordt daarom een kritische houding verwacht. Niet als vanzelfsprekend alles documenteren, maar bewust afvragen waarvoor die documentatie nodig is en of er geen betere alternatieven zijn.   Twee soorten documentatie De behoefte aan documentatie verandert bij agile werken. Om dit toe te lichten is het nodig onderscheid te maken tussen documentatie ten behoeve van het voortbrengingsproces (vooraf nodig voor het bouwen van de juiste software) en systeemdocumentatie (die achteraf samen met de software wordt opgeleverd). In agile wordt de eerste soort documentatie, voor het voortbrengen van de software, voor een belangrijk deel vervangen door rechtstreekse interactie tussen het ontwikkelteam en de gebruikers. Alle betrokkenen zijn hierbij aanwezig en er worden alleen korte statements, via user stories, vastgelegd als geheugensteun. Daarnaast is in agile via intensieve samenwerking binnen multidisciplinaire teams de informatieoverdracht tussen de teamleden geregeld. Hierdoor is er tijdens het voortbrengingsproces ook minder behoefte aan documentatie. Een duidelijk voorbeeld van documentatie ten behoeve van het voortbrengingsproces is requirementsdocumentatie. Traditioneel werd die documentatie regelmatig ook gebruikt als systeemdocumentatie, die beschrijft wat er is gemaakt. Dat lijkt efficiënt, maar hoe gedetailleerd de requirementsspecificaties ook zijn, het wil niet zeggen dat de uiteindelijke software er ook aan voldoet. Het gevolg is dat de documentatie later weer aangepast moet worden. Dat is niet alleen dubbelwerk, maar ook foutgevoelig en bovendien is er aan het einde van het project meestal te weinig tijd. Kortom de betrouwbaarheid liet nog al eens te wensen over. Systeemdocumentatie blijft echter ook bij agile belangrijk. Deze documentatie wordt alleen niet eenmalig aan het einde gemaakt, zoals we dat traditioneel gewend waren, maar iteratief opgeleverd. Elke twee weken als er een nieuwe versie van het systeem uitkomt, is er ook een bijgewerkte set van de systeemdocumentatie. En hoeveel werk kan dat zijn, als het maar over twee weken gaat? Daarnaast kan de systeemdocumentatie ook minder uitgebreid zijn dan in traditionele projecten. Dat komt door de stabiele samenstelling van agile teams. Ze blijven namelijk langer bij elkaar dan alleen de duur van een project. Een dergelijk team ontwikkelt niet alleen nieuwe software maar blijft deze ook zelf onderhouden. Uiteindelijk stelt zo’n team de systeemdocumentatie dus voor zichzelf op. En niet, zoals we traditioneel gewend waren, voor anderen die het systeem in beheer nemen en die niet bij de ontwikkeling betrokken waren.   Toegevoegde waarde De toegevoegde waarde van documentatie zit hem in het overbruggen van tijd (dingen onthouden) en/of het overdragen van informatie aan mensen die niet aanwezig waren. Het gaat dus om kennisborging. Vaak wordt vergeten dat documentatie niet de enige manier is om kennis te borgen. Men gaat er impliciet vanuit dat als iets niet gedocumenteerd is dat dat dan tevens betekent dat die kennis verloren gaat. Maar dat is niet waar. Kennis zit immers in de hoofden van mensen en niet in documenten. Kortom, door agile werken verdwijnt de toegevoegde waarde van (traditionele) documentatie voor een belangrijk deel. De beweging naar multidisciplinaire en stabiele agile teams zorgt ervoor dat kennisoverdracht minder via documenten verloopt. Maar eigenlijk was dat altijd al een misverstand. De gedachte dat wanneer iets ‘op papier’ staat, gelijk zou staan aan ‘in de hoofden van mensen zitten’, was altijd al schone schijn. We zien in de praktijk, dat ondanks de populariteit en successen met agile werken, er tegenkrachten ontstaan die juist sterk sturen en leunen op documentatie. SLA’s, uitbestedingscontracten op basis van fixed scope, outsourcingspartners die alleen bouwen op basis van specificaties, beheerafdelingen die uitgebreide documentatie eisen, voorbereidingsteams die zeer ver vooruitlopen op de agile teams, een ‘uw vraagt/wij draaien houding’ bij ontwikkelteams, RFC-processen et cetera. Vooralsnog ligt het punt waarop alles en iedereen agile werkt nog ver in de toekomst. In de tussentijd zal er nog steeds behoefte zijn aan (te) veel documentatie.Auteurs: Nicole de Swart & Rini van Solingen, Automatiseringsgids

Inhoud Agile en Scrum zijn gemeengoed. Zelfs multinationals stappen erop over. Maar past dat wel? Agile is toch juist bedoeld voor kleine organisaties? Volgens Henk Jan Huizer, Martin Vodegel en Rini van Solingen wordt het schalen van agile vaak verkeerd begrepen. Zij beschrijven acht aandachtspunten om agile toe te passen op grote schaal. Scrum toepassen is niet meer bijzonder. Agile als begrip en Scrum als meest gebruikte aanpak zijn inmiddels mainstream. Ook grote organisaties gaan volop met agile aan de slag. Soms in een enkel project of met een paar teams, maar tegenwoordig veel vaker op grote schaal. De vraag hoe je agile doet op grote schaal is daarom erg actueel en wordt steeds vaker gesteld. Agility op grote schaal is een systematische en gestructureerde poging om een groot aantal teams agile met elkaar te laten samenwerken. Natuurlijk volgens dezelfde principes die aan de basis liggen van agile in die team. Veel Scrum-teams hebben, wil dus helemaal niet zeggen dat er op grote schaal agile wordt gewerkt. Als het namelijk op overkoepelende schaal niet goed is geregeld, dan komen de resultaten niet sneller en wordt het geheel niet beter. En het gaat uiteindelijk om die snelheid en wendbaarheid voor de klant. Sommige organisaties spreken zich bijvoorbeeld trots uit dat ze meer dan 250 Scrum-teams hebben. Als die teams niet goed op elkaar zijn afgestemd, dan blijft de impact van deze teams voor de klant beperkt. Er zijn misschien wel 200 teams te veel.   Integratie De eerste vraag in grote organisaties is hoe men de teams zodanig inricht dat ze zelfstandig kunnen werken. Doordat het bestaande IT-landschap vaak sterk verzuild is en bestaat uit vele losse applocaties, is de eerste neiging om de nieuwe agile teams te plotten op de bestaande systemen. Een enkel team krijgt dan de verantwoordelijkheid over één enkele applicatie of één component. Een team kan dan zelfstandig de planning en uitvoering doen op die applicatie, en de product-owner prioriteert het werk voor dat team. Zodoende is agile opschalen in grote organisaties vaak het verdelen van teams over systemen. Echter, de waarde voor de klant zit in de combinatie van deze systemen. Zodoende is men vaak zonder het door te hebben, een waterval van procesfasen aan het vervangen door een waterval van teams. En dan duurt het nog steeds maanden voor een nieuwe dienst of feature bij de uiteindelijke klant terechtkomt. En hoe agile is dat? Het is van het grootste belang bij agile op grote schaal vanaf de allereerste dag de focus te leggen op het integratievraagstuk over teams heen: om zo kort mogelijke ketens van teams te maken die warde leveren voor de eindklanten. Het concept van 'end-to-end value' en 'value streams' helpt daarbij. Oook schalingsraamwerken kunnen helpen. Zo introducteert SAFe (Scaled agile Framework) bijvoorbeeld het concept 'release train'. Daarin zit het zelfstandig en snel leveren van waarde aan eindklanten door een beperkte hoeveelheid teams geborgd. Dit vereist wel aanpassingen in de organisatie die verder gaan dan bestaande teams met Scrum te laten werken.   "Vaak vervangt men een waterval van procesfasen door een waterval van teams"   Ontschalen Men is al snel aan het schalen. De dynamiek van schaling treedt al op als je met een paar agile teams aan de slag bent. Zeker in grote organisaties waar veel afhankelijkheden aanwezig zijn. Agile werken 'verknipt' namelijk een organisatie in kleine zelfstandige teams. Daardoor is het noodzakelijk om actie te ondernemen: om planning en resultaten weer bij elkaar te brengen. Wat het meest essentiële is, klinkt heel tegenstrijdig: 'ontschaling'. Ontschaling is een doorlopend streven om de behoefte aan agile op grote schaal te voorkomen. De complexiteit in het IT-landschap moet daarom omlaag. Alleen dan kan een situatie tot stand komen waarin een beperkt aantal teams gezamenlijk, elke twee weken, waarde voor de klant kan opleveren. Agile op grote schaal vraagt dus feitelijk niet om opschalen maar om ontschalen. Hoe moeilijk dat ook is. Alleen wanneer grote organisaties in staat zijn om, ondanks hun omvang, zeer frequent software te releasen, pas dan is agile op grote schaal echt gelukt.   Aandachtspunten bij het schalen van agile Schaal door focus te leggen op directe klantwaarde. Voorkom een focus op interne processen en interne bijdragen van teams. Neem daartoe value streams als uitgangspunt. Dat is namelijk de dimensie waarlangs klanten merken dat er iets verandert. Laat product-owners vanuit de business helpen bij het definiëren en prioriteren van de value streams. Zij hebben namelijk vaak het beste inzicht. Vereenvoudig het IT-landschap. Het opzetten van complexe schalingsconstructies met veel rollen en processen komt vaak door het omzeilen van het echte probleem: de noodzakelijke versimpeling van een complex IT-landschap. Een belangrijke reden voor het gebrek aan snelheid zit vaak in een sterk versnipperd IT-landschap vol afhankelijkheden. Dat is op zichzelf niet zo verrassend: Conway's law uit 1967 leerde ons reeds dat de architectuur van een IT-systeem een afspiegeling is van de organisatiestructuur. Sterk verzuilde organisaties hebben zodoende ook de neiging om sterk verzuilde IT-landschappen voort te brengen. En die zijn doorgaans niet erg wendbaar. Een vereenvoudiging van het IT-landschap begint vaak bij een vereenvoudiging van de organisatie zelf. Start met continuous delivery vanaf het begin. Bij agility op grote schaal heeft men vaak de neiging om het integratievraagstuk uit te stellen vanwege de complexiteit. Men begint dan met agile werken op teamniveau, waarbij elk team deelproducten oplevert maar de integratie over de teams niet of laat gebeurt. Continuous delivery zorgt ervoor dat integratie vroeg en vaak plaatsvindt. Continuous delivery is voorwaardelijk om met agile op schaal te kunnen werken. Elke ontwikkelaar moet binnen een uur feedback vanuit een automatische integratietest krijgen om integratieproblemen vroegtijdig te kunnen oplossen. Daarnaast is de continuous delivery een katalysator voor eenvoud. Het is namelijk ondoenlijk om sterk verkleefde en complexe oplossingen met continuous delivery aan te pakken. Tijdens de implementatie van continuous delivery gaan teams automatisch aan de slag met vereenvoudiging van de architectuur. Gebruik een schalingsaanpak niet als blauwdruk. Pas bijvoorbeeld SAFe niet klakkeloos toe. Maak liefst een eigen schalingsmodel dat past bij de eigen situatie, de klanten, systemen en bekende knelpunten. Het Spotify-model werkt perfect voor Spotify. Het kopiëren van de schalingsoplossing van een ander werkt alleen als het probleem en de context identiek zijn en dat helaas maar zelden het geval. Maak ook niet de fout om denken en doen te scheiden. Als bijvoorbeeld SAFe wordt gebruikt, zorg er dan nog steeds voor dat de experts uit de teams meedoen op programma- en portfolioniveau. Zorg dat de basis op orde is. Als teams veel onderlinge afhankelijkheden hebben, is het zaak dat teams betrouwbaar opleveren. In een keten van bijvoorbeeld vijf teams, waarbij elk team 80% van de planning haalt, bestaat de kans dat de keten niets oplevert. Bij elke sprint kan er namelijk één team zijn dat een cruciaal onderdeel niet op tijd klaar heeft, waardoor het eindresultaat niet werkt. Teams moeten dus in een schalende organisatie sterk voorslebaar zijn en proactief afstemming zoeken. Daartoe is het cruciaal om product-backlogmanagement goed op orde te hebben. Het is namelijk in de praktijk gebleken dat de meest voorkomende bron achter onvoorspelbare teams ligt in het ontbreken van een goed uitgekristalliseerde product-backlog. Maak onderscheid tussen waarde- en componententeams. In de ideale situatie is elk team in staat om zelfstandig waarde voor de klanten op te leveren. Dan beslaat het team een complete value stream. In veel gevallen lukt dit echter niet en wordt om uiteenlopende redenen gewerkt met teams die een of meerdere componenten onderhouden en ontwikkelen. En al die componenten moeten dan weer geïntegreerd worden. Maak onderscheid tussen twee soorten teams: waarde/featuretemas en ondersteunende/componentteams. De eerste teams ondersteunen een value stream of een feature voor klanten. Zij leveren dus zelfstandig klantwaarde. Daarnaast kunnen er ook ondersteunende- of componentteams zijn. Zij zetten componenten of applicaties klaar die door de waarde/featureteams gebruikt kunnen worden. Vergeet niet de governance aan te passen. De aanwezige governance past zelden bij grootschalig agile werken. Deze governance is namelijk een verankering van de oude verzuilde organisatie. Als een organisatie agile op grote schaal wil toepassen, dan moet de governance worden aangepast. Meestal vraagt dit om rigoureuze aanpassingen, die niet op voorhand helder zijn. Het is daarom raadzaam de governance stap voor stap te (her)ijken. Installeer een 'Scaling Master'. Voorkom grote discussies en variëteit aan oplossingsvarianten. Maak iemand verantwoordelijk om het opschalen van agile te leiden. Dit is een tijdelijke rol gedurende het inrichten van grootschalig agile werken. Het invullen van die rol helpt bij het maken van een keuze en het snel doorvoeren van de benodigde veranderingen. Deze Scaling Master moet natuurlijk wel een expert zijn op het gebied van agile op grote schaal, hij moet alle boeken hebben gelezen en alle trainingen hebben gevolgd.       Auteurs: Hank Jan Huizer, Martin Vodegel en Rini van Solingen

Inhoud Misschien komt houvast en verbinding uit een onverwachte ICT-hoek: procesarchitectuur. Maar: “Een positieve toepassing van procesarchitectuur richt de focus op waar het écht om gaat: samen het beste resultaat leveren aan de samenleving.” De gemeentelijke context is sterk in beweging. Veranderingen komen in hoog tempo op gemeenten af en niets lijkt meer zeker of maakbaar. Volgens Hjalmar Hamoen, adviseur procesmanagement bij de gemeente Emmen, is het de procesarchitectuur die juist daarin houvast kan bieden. Onder meer door in bedrijfsprocessen een betekenisvol hulpmiddel te bieden voor het geven van inzicht en samenhang en diverse vormen van samenwerking te bevorderen, met als doel om toegevoegde waarde te leveren voor de samenleving. “Bij veel mensen roept architectuur het beeld op van een dwingend keurslijf, waarbij processen gelijkgesteld worden met procedures. Dat is vreselijk jammer, omdat juist een positieve toepassing van procesarchitectuur de focus richt op waar het echt om gaat: hoe kunnen wij gezamenlijk – nu en in de toekomst – het beste resultaat leveren aan de samenleving.” Eind juni is een vernieuwde versie van de GEMMA procesarchitectuur opgeleverd. Het belang is daar wat Hamoen betreft vooral het bieden van een positief perspectief op ordenen, ontwikkelen en veranderen. “Een dynamisch en flexibel hulpmiddel dat inzicht geeft om, samen met betrokkenen, het goede gesprek te kunnen voeren over de inrichting er van, zodat in specifieke situaties een passende oplossing geboden kan worden. Een gezonde balans tussen maakbaarheid en onzekerheid.” De gemeentelijke veranderingen zijn groot. Niet alleen is, onder andere door de drie decentralisaties in het sociaal domein, het aantal processen (en daarmee het aantal producten en diensten) toegenomen, maar ook is de rol die gemeenten zich toe-eigenen, veranderd. Dat erkent ook Harco van Hees, ICT-adviseur bij de gemeente Tilburg. “Zo zijn gemeenten meer faciliterend en ondersteunend dan voorheen, maar niet meer automatisch als hoofdverantwoordelijke.” In de nieuwe architectuur is juist naar dit soort ontwikkelingen en processen gekeken, maar ook naar mogelijkheden om meer te standaardiseren. Van Hees zegt daarover: “Standaardiseren helpt bij de ontwikkeling (en keuze) van onderliggende ICT-systemen en helpt ook om het bruikbaar te laten zijn voor andere gemeenten of voor partners. Bijvoorbeeld als er sprake is van ketensamenwerking.”   Verschillende inzichten Janny Bodd is adviseur procesmanagement bij de gemeente Arnhem. “Als gemeente hebben wij in 2012 gekozen om een procesgerichte netwerkorganisatie te zijn en in de loop der jaren hebben wij al veel processen uitgewerkt.” Dat het allemaal wat lang heeft geduurd, heeft volgens Bodd met name te maken met verschillende inzichten en achtergronden van de deelnemers. Harco van Hees heeft ervaren dat niet alleen de diversiteit van de groep af en toe de snelheid van het proces in de weg stond, maar ook dat aanvankelijk de stip op de horizon nog niet duidelijk was. “Bij de start was er nog sprake van een zoektocht. Zoeken naar verbeteringen ten opzichte van de oude procesarchitectuur en punten waarop deze uitgebreid kon worden. Ook de afstemming tussen de drie werkgroepen was af en toe een uitdaging.” Om een goede afstemming te realiseren is in het proces een beroep gedaan op een bedrijfsarchitect. “Op een gegeven moment was er de behoefte aan ondersteuning van iemand met diepgaande expertise op architectuurgebied, iemand die alle waardevolle brokstukken die door de gemeenten werden aangeleverd kon samensmeden tot één geheel.” De architect had dus de spilfunctie. “Hij is erin geslaagd om de essentie van ieders inbreng te behouden en te vertalen naar een consistent geheel, passend in de bredere architectuur van GEMMA.”Auteur: Frits de JongBenieuwd hoe u Mavim in kunt zetten om onder architectuur te kunnen werken? Lees hier meer! Of wilt u weten hoe u architectuurmodellen kunt uitwisselen tussen architectuurtools onderling? Vind hier meer informatie over Mavim en ArchiMate!

Inhoud   Treacy & Wiersema kwamen ooit met de driedeling Operational Excellence – Product Leadership – Customer Intimacy. Een verstandige onderneming is of goed in standaardisatie, of in het leveren van superieure producten of in klantspecifiek maatwerk. Veel organisaties kiezen vanaf de jaren 80, aangemoedigd door efficiëntiedrang, schaalvergroting, risicomanagement, compliance en vooral natuurlijk Taylor en MBA-studies voor operational excellence. IT vanaf de jaren 90 al helemaal, daartoe in 2003 nog extra aangemoedigd door Nicolas Carr: IT doesn’t matter. En dus werken we steeds meer in strak georganiseerde processen en leveren we gestandaardiseerde producten en diensten. Dat heeft tenslotte grote voordelen. Gestandaardiseerde processen maken de onderneming gemakkelijk benaderbaar, voorspelbaar, betrouwbaar, betaalbaar, controleerbaar, planbaar, en in zekere zin ook nog eens sneller. Allemaal dingen die passen bij operational excellence. Maar die gedetailleerde processen hebben ook nadelen. Ze maken de organisatie star, het proces zelf pas je niet zo gemakkelijk aan. Processen hebben de neiging dingen te diskwalificeren. Dingen die niet passen in het proces. In processenland is het bon ton om 20% van van alles en nog wat te diskwalificeren, met een verwijzing naar de 80-20-regel. 20%! Als dat maar niet net je concurrerend vermogen is. Processen zorgen voor een vaste, generieke kwaliteit, maar wel van het type McDonald’s. McDonald’s heeft wereldwijd meer dan 33.000 restaurants. En nul koks. Kwaliteit wordt gegarandeerd door het proces, daar zijn geen vakmensen voor nodig. En McDonald’s levert goede hamburgers. Maar als je een keer ècht lekker wilt eten…  Bij de Librije (3 Michelin-sterren) leveren ze een heel andere kwaliteit. McDonald’s levert hamburgers, de Librije een fantastische avond met heerlijk eten. Daar word je van begin tot eind met veel aandacht behandeld. En het eten is heel bijzonder. Een bijzondere mix van customer intimacy en product leadership. Daar betaal je ook naar, de Librije is, zacht gezegd, niet goedkoop. Bij de Librije hebben ze ook wel processen, maar die zijn veel minder strak. Kwaliteit wordt gegarandeerd door aandacht en perfectiedrang van gedreven vakmensen. Die kunnen ook veel beter reageren op veranderingen in hun omgeving. Als je bij McDonald’s een hamburger zonder augurk wil, moet je die er zelf afhalen. Bij de Librije kun je in overleg bijna alles aan je maaltijd veranderen.  En zo komen ondernemingen meer en meer in de greep van de McDonaldisering. Afdelingen moeten we zo veel mogelijk voorspelbaar, goedkoop en stabiel houden. Wel de 80, niet de 20. Afdelingen moeten goede, generieke kwaliteit leveren, maar dragen alleen nog maar bij aan het concurrerend vermogen van de onderneming dor middel van kostenbesparing. Maar dat kunnen ze in grote delen van de wereld, de BRIC-landen voorop, beter dan wij in West-Europa. De onderneming heeft steeds vaker niet alleen behoefte aan goedkope en degelijke kwaliteit, maar ook aan onderscheidende. Het McDonald’s-gedeelte helpt de kosten laag te houden, maar de onderneming heeft de Librije-kwaliteit nodig om de inkomsten te verhogen. En dan zijn processen ineens niet meer genoeg. Dan wordt, net als bij de Librije, vakmanschap belangrijk en aandacht en gedrevenheid. En dat is, zacht gezegd, niet goedkoop. Dat kost dure tijd van dure mensen. Maar daar krijgt de onderneming wel wat voor terug. Vakmanschap kan complexiteit pareren. En een gedreven vakman kan, met mandaat, snel reageren op de dynamiek van de omgeving. Dat levert de onderneming wendbaarheid op, een groot goed in deze wereld. Met een operational excellence strategie, goedkoper leveren dan de rest, kun je maar beter niet in West-Europa zitten. Als je toch in West-Europa wilt blijven, moet je je meestal onderscheiden door de kwaliteit van je producten en het aanpassingsvermogen van je dienstverlening. De strategie moet minstens een paar product-leadership-componenten hebben en een paar customer-intimacy-eigenschappen. En waarschijnlijk stellen die Librije-eisen aan de onderneming.  Natuurlijk moet een heleboel ondernemingen een stukje McDonald’s overhouden. Dat is in de meeste gevallen precies dat stuk, dat je maar beter kunt uitbesteden. Maar de toekomst van de onderneming hangt af van dat andere stuk van de organisatie: Het Librije-gedeelte. Mensen die de onderneming heel goed kennen en die oplossingen of oplossingsrichtingen bedenken, waar anderen, managers voorop, zelf nooit aan zouden denken. Mensen die iets kunnen maken waardoor de onderneming zich kan onderscheiden van haar concurrenten. Mensen die oplossingen zo snel kunnen doorvoeren of oplossingen zo gemakkelijk aanpasbaar kunnen maken, dat die snelheid de onderneming een voordeel geeft op haar concurrenten.  Bij het McDonald’s-gedeelte vraagt het topmanagement van de onderneming periodiek vooral naar de kosten, bij het Librije-gedeelte kunnen ze niet wachten tot ze weten wat de baten zijn, voor de onderneming en voor de strategie. De onderneming van de toekomst heeft nog wel processen, in het McDonald’s-gedeelte, maar heeft vooral ook uitstekende, gedreven en gemandateerde vakmensen, in het Librije-gedeelte. En het management zorgt voor een goede balans tussen McDonald’s en de Librije. Net als ik het thuis doe. Bij mij thuis geldt: Hoe beter het gaat, hoe vaker ik in de Librije eet. Voor de onderneming geldt: Hoe vaker we in de Librije werken, hoe beter het gaat… Auteur: Bart Stofberg, organisatieveranderaar bij Quint Wellington Redwood

Inhoud   Royal IHC is actief in de scheepsbouw en daaraan gerelateerde bouw van specifieke, meestal hoog-technologische, modules. De groep bestaat uit vier afdelingen: Dredging, Mining, Offshore en Technology & Services. Gezamenlijk draaiden ze een omzet van 1 miljard euro in 2011, met een drieduizendtal medewerkers wereldwijd. Met een geschiedenis van 300 jaren valt IHC zonder twijfel buiten de gemiddelde leeftijdscategorie van ondernemingen. CEO Dave Vander Heyde schetst de context waarbinnen zijn firma de jongste jaren evolueerde. In 2005 werd de afdeling Scheepsbouw van de firma IHC Caland (nu SBM Offshore) afgesplitst via een leveraged management buy-out. Die afsplitsing gebeurde net vóór een lange periode van baggergedreven hoogconjunctuur. Het resultaat was een grote instroom aan orders, met een betere kapitaalstructuur en liquiditeits- en schuldenpositie als gevolg. Nieuwe activiteiten werden opgestart, via de aankoop van technologiebedrijven en de creatie van aparte afdelingen. Met het ondernemerschap hoog in het vaandel kreeg elke afdeling veel vrijheid om zichzelf op de markt te positioneren. Die decentrale structuur zorgde voor een stabiele, organische groei, maar vandaag resulteerde dat ook in een lappendeken aan systemen, processen en procedures, verdeeld over een veertigtal ondernemingen. Er zijn ter illustratie vandaag vijf verschillende gespecialiseerde ERP-systemen in gebruik, die momenteel weinig of wat moeizaam met elkaar communiceren.One IHC Voor de realisatie van de toekomstige groei van alle IHC-activiteiten werd midden 2012 een groot integratieproject gelanceerd, onder het motto ‘One IHC’. De doelstelling is het uniformeren van alle processen, procedures en het lappendeken aan systemen. Van het huidige decentrale ondernemerschap wil IHC met de term ‘uniformisering’ dus evolueren naar een ondernemerschap ingekaderd door een centrale sturing, en dat zonder afbreuk te doen aan de operationele activiteiten tijdens die omschakeling. “We kijken naar een geleidelijke evolutie, géén revolutie, want de dagelijkse activiteiten mogen niet stilvallen”, aldus Dave Vander Heyde. De uitwerking zal gebeuren via onderverdeelde subprojecten: ‘One Finance’ en veertien verschillende domeinen. Als eerste in de planning staat alvast een grote uitdaging: ‘One Process’, zijnde de gelijkschakeling van de businessprocessen ondersteund door, idealiter, één ERP-systeem, met unieke mastergegevens.Het project en de rollen  Voor elk domein werd een beperkte werkgroep opgericht, bestaande uit een projectleider die de eindverantwoordelijkheid draagt, een senior user, een beperkt aantal projectteamleden en eventueel een transversale expert. IHC koos bewust voor de combinatie van een projectleider met een senior user. De senior user werkt als klankbord voor de andere leden van de werkgroep. De interne of externe expert, die deel kan uitmaken van verschillende werkgroepen, brengt van zijn kant de gevraagde expertise en zorgt voor de kwaliteitscontrole van de deliverables. Om het overzicht over de 14 deeldomeinen te bewaken, werd een externe programme manager aangesteld. Op die manier worden mogelijke wrijvingen vermeden en vertrekt men bij de analyse van een blanco blad, losgekoppeld van eventuele historische aspecten. De programme manager heeft drie specifieke taken: het beheren van het overzicht en interacties van de werkgroepen, de dagelijkse aansturing en vooral ook de bewaking van de uniformeringslijn en daaromtrent sturing geven aan de werkgroepen.De wensen van de mensen Het valt op dat ICT niet of nauwelijks vertegenwoordigd is in de werkgroepen, uitgezonderd uiteraard bij de expliciet ICT-gerelateerde werkgroepen. “We willen immers in eerste instantie geleid worden door de wensen van de mensen, zonder beperkingen vanuit de invalshoek van ICT”, aldus Dave Vander Heyde. De taak van de werkgroepen is het omschrijven van de huidige situatie, de behoeften, de wijze waarop daaraan voldaan kan worden met bijbehorende planning, een kostenanalyse en ten slotte, in een breder kader, de potentiële opbrengst en het risicoplaatje voor IHC. Het is absoluut niet de bedoeling om het wiel opnieuw uit te vinden! Dave Vander Heyde vat zijn instructies naar de werkgroep als volgt samen: “Evalueer en kies. Indien nodig, optimaliseer. Pas als het echt niet lukt, verzin dan iets nieuw.” Om de veertien dagen rapporteert de werkgroep haar voorstellen aan de Programme Board, die op haar beurt verder rechtstreeks rapporteert aan de Board of Directors. Die board wordt geleid door de CFO en bestaat uit de programme manager, de business change manager en een senior user. De aanwezigheid op dit niveau van de twee laatstvernoemden toont de grote aandacht die geschonken wordt aan de menselijke factor binnen het gehele project. De doelstellingen van de Programme Board zijn, naast het evalueren van de voorstellen, de algemene communicatie, planning en voortgang van ‘One IHC’. De Programme Board krijgt twee weken voor haar beslissing om het voorstel van de werkgroep te aanvaarden of niet. Een eventuele weigering gaat altijd gepaard met duidelijke richtlijnen ter verbetering. Wanneer een aanvaard voorstel een strategische impact heeft, gaat dat eerst nog naar de Board of Directors voor een finale goedkeuring. Zij hebben vier weken om te beslissen. Het spreekt voor zich dat de aanwezigheid van de CFO in beide organen de discussies vergemakkelijkt.Blogging binnen het bedrijf Met veelvuldige periodieke besprekingen en een heldere communicatie naar alle medewerkers is het de bedoeling om de bewustwording en het draagvlak te vergroten, nog voor de daadwerkelijke wijzigingen plaatsvinden. “We laten de geesten binnenshuis langzaam rijpen om hen te laten meegaan in onze wandeling in een nieuwe richting”, aldus Dave Vander Heyde. Omdat de communicatie van essentieel belang is, trok IHC een externe communicatiemanager aan op deeltijdse basis. In nauwe samenwerking met de interne business change manager werd ervoor gekozen om de formele communicatie op een enigszins informele manier in te kleuren (bv. door het gebruik van cartoons) en ook hedendaagse internettechnieken te gebruiken. Via periodieke blogposts, waarop iedereen commentaar kan geven, worden de medewerkers geïnformeerd over de voortgang van het project. Filmpjes, interviews met directieleden, waaronder dat van de CFO, periodieke rapporten, opiniestukken, … worden online gezet op het intranet van de firma. Vooral de jongere medewerkers gaan daar enthousiast op in en via hen genereert die uitwisseling van informatie wel degelijk de beoogde interacties.What’s next? Een dergelijk grootschalig, allesomvattend project en de diversiteit aan activiteiten van IHC impliceren dat er maar twee keuzes zijn inzake de benodigde onderliggende ERP-oplossing: maatwerk of een basisplatform met interacties. “Een gigantisch maatwerk zou een verkeerde keuze zijn met betrekking tot het totale kostenplaatje”, volgens Dave Vander Heyde. De andere optie lijkt derhalve aangewezen, zijnde het opzetten van een systeem gebaseerd op de grootste gemene deler, samen met goedbedachte en werkende interacties van en naar de verschillende niche-satellietsystemen. Begin 2013 zal ‘One Process’ uitgetekend zijn, de blauwdruk van alle huidige en toekomstige processen waarbinnen alle methodes en instrumenten moeten vallen. Dat zal dus als fundering dienen voor de overige domeinen. Daarnaast zal er een shortlist van potentiële ERP-softwareleveranciers opgesteld zijn. In de daaropvolgende maanden zal er één leverancier gekozen worden, waarmee het gefaseerd uitrollen per gekozen domein in gang getrokken wordt. Dave Vander Heyde gelooft immers niet in een big-bangaanpak: “Dat is onrealistisch.” De bedoeling is om na elke opstart een minimum aan wijzigingen te hebben voor de medewerkers, dankzij de opzet, het voorbereidende werk en de permanente communicatie. “Change management is het belangrijkste, gevolgd door een vlotte implementatie en acceptatie van de medewerkers”, aldus Dave Vander Heyde.Inzetbaarheid en luchtkastelen Door te kiezen voor een opzet met een senior user binnen elke werkgroep vangt IHC twee vliegen in één klap. Enerzijds wordt daarmee het dilemma van inzetbaarheid opgelost. Bij grootschalige en belangrijke projecten worden meestal de meest capabale medewerkers ingezet om alles tot een goed einde te brengen. Helaas beschikt dat type medewerkers per definitie over weinig tijd. Bij IHC is de senior user echter géén projectleider, maar vervult die een adviserende rol. Daardoor hoeft hij/zij niet altijd aanwezig te zijn binnen de werkgroep en verliest hij/zij geen tijd met alle klassieke projectmatige opdrachten, zoals het opstellen van een planning voor vergaderingen, rapporteren, beschrijven etc. Anderzijds bestaat er altijd het risico dat werkgroepen, in hun enthousiasme, zelfstandig welbepaalde ‘luchtkastelen’ gaan bouwen, zijnde het bedenken en beschrijven van onrealistische of onnodige functionaliteiten. Zoiets brengt veel tijdverlies, onnodige interacties en frustraties met zich mee. Met zijn/haar ruime ervaring werkt de senior user daar als validerende klankbord. Hij/zij zal ervoor zorgen dat iedereen zich wel degelijk bewust is van de daadwerkelijke behoeften en implicaties tijdens de besprekingen.Auteur: Martin van Wunnik, FD Magazine