Inbedden van DevOps in de organisatie

Inbedden van DevOps in de organisatie
 
Het gebruik van DevOps voegt als hulpmiddel waarde toe aan organisaties. DevOps-inzichten helpen de kloof tussen development en operations te overbruggen, maar het vraagt een goede voorbereiding. Een visie op het gebruik van DevOps is nodig, aansluitend op de strategie en doelen van de organisatie; de IT dient de business te ondersteunen. De volgende vragen komen naar boven: Heeft DevOps alleen invloed op IT of raakt het de gehele organisatie? Welke organisatieverandering moet je doorvoeren? Welke cultuur en gedrag is er nodig voor DevOps?
 
 
DevOps spitst zich toe op IT-servicemanagement en op het verbeteren van de demand-supply-relatie. In hetgeen hiervoor nodig is, de juiste cultuur en attitude, zit de crux. De nadruk ligt op communicatie, samenwerking en integratie. Hieraan ontbreekt het in menig organisatie. Veel leveranciers van IT-services worstelen met de vraag: Hoe moeten we DevOps in de praktijk inzetten? DevOps dient in ieder geval te resulteren in een hogere klanttevredenheid. Dat DevOps zich alleen op softwareontwikkeling richt is een misvatting. De scope is IT-servicemanagement (de combinatie van IT-technologie, mensen en processen) waar software wel onderdeel van is. De vraag is: Hoe kunnen organisaties de principes van DevOps eenduidig en herkenbaar inbedden zodat ze de juiste resultaten bereiken en de business toegevoegde waarde bieden? Het is zinvol om eerst de organisatorische inrichting onder de loep te nemen, en daarna de DevOps-practices en -technieken te implementeren. In de praktijk is de werkrichting (nog steeds) voornamelijk andersom. Het inrichten van DevOps heeft sowieso organisatorische consequenties. Allereerst dient de DevOps-filosofie gemeengoed te zijn (people fac tor) en dient de organisatie (performance factor) er klaar voor te zijn. Dit betekent niet dat perse de organisatiestructuur (de hiërarchie) wijzigt, maar het heeft wel consequenties voor de manier van samenwerken, de organisatorische scope van nieuwe projecten/services en dus ook voor verantwoordelijkheden. DevOps kan het beste worden beschouwd als een ‘mindset’ en in mindere mate als een organisatiemodel of raamwerk. DevOps vereist een andere manier van denken en werken. Om dit in een organisatie te introduceren is verandermanagement nodig.
Positionering DevOps
Muren zijn verhinderend
Rondom de informatievoorziening (IV) zijn eilandjes gebouwd en daartussen muren gemetseld; deze beperken de performance als geheel (figuur 1) . Een grote uitdaging is het effectief laten landen van nieuwe of gewijzigde IT-services vanuit de ontwikkelomgeving (development) naar de exploitatie-/productieomgeving (operations). Enerzijds levert development projectproducten op die niet gereed zijn om als IT-service in beheer te nemen en anderzijds ondersteunt operations de ontwikkelomgeving onvoldoende bij het voorbereiden van deze IT-services. Als gevolg hiervan ondervinden serviceproviders in de praktijk veel knelpunten bij transitie en inbeheername. Transitie van nieuwe of gewijzigde IT-services blijkt in de dagelijkse praktijk versnipperd over vele afdelingen en processen (en zelfs meerdere organisaties), zonder veel samenhang. Een juiste organisatorische keteninrichting biedt de basis voor een succesvolle transitie. Het ontwerpen en plannen van de IV-functie en het vervolgens ontwerpen en plannen van de benodigde IT-services vindt in de regel op een gestructureerde (projectmatige) wijze plaats. Dit speelt zich af in een ontwikkelomgeving (development), waarbij op basis van de informatiebehoefte een informatieoplossing wordt gekozen. En separaat een exploitatieomgeving (operations) waar de uiteindelijke informatieoplossing, als onderdeel van een informatiesysteem, beschikbaar wordt gesteld voor gebruik. Figuur 1 geeft deze IV-regelkring weer. Hierbij is er onderscheid tussen:
• De ontwikkelomgeving (development), waarbinnen de informatieoplossing wordt gekozen en vervolgens wordt ontwikkeld en geïmplementeerd in een exploitatieomgeving.
• De exploitatieomgeving (operations), van waaruit het uiteindelijke informatiesysteem (de informatieoplossing) beschikbaar wordt gesteld voor gebruik en wordt gemanaged en onderhouden.
Figuur 1. Gebruik DevOps-mindset om muren te slechten
 
De vraag is hoe de DevOps-mindset en -inzichten een rol spelen in het optimaliseren van deze regelkring. Daarvoor is het nodig om het DevOps-concept IT-overstijgend en als onderdeel van de waardestroom te zien.
De meeste grote organisaties hebben de integratie van development en operations hoog op hun agenda staan. Er wordt steeds meer voor de DevOps-aanpak gekozen. Maar de DevOps-werkwijzen worden helaas te vaak vanuit een IT-perspectief uitgerold. Het blijft dan hangen in sub-optimalisatie. Alleen als je DevOps vanuit de waardestroom-optiek inzet, komt de waarde ervan tot zijn recht.
Waardestroom
Bij de term DevOps wordt vaak gedacht aan de kloof tussen development en operations, maar een andere belangrijke relatie wordt daarbij over het hoofd gezien: de relatie tussen business en IT (business IT alignment). Deze bepaalt namelijk in grote mate de gewenste DevOps-inrichting en parallelle ambitie. Als de business een flexibele (agile) IT-serviceprovider verwacht, dan worden hiermee eisen aan deze IT-serviceprovider gesteld. De verwachting van de business bepaalt het ambitieniveau van de inzet van DevOps. Dit gaat van het inzetten van een DevOps-transitieteam om de samenwerking tussen development en operations te stroomlijnen, tot het verregaand automatiseren van releases en de monitoring hiervan, waardoor development en operations feitelijk integreren. Het gebruik van Lean IT maakt dit mede mogelijk.
Lean IT
De integrale Lean IT-aanpak richt zich op het maximaliseren van waarde voor de klant door het minimaliseren van verspilling. Lean IT gaat over het ontwikkelen en managen van de IT-omgeving, die bijdraagt aan het maximaliseren van de klantwaarde door het minimaliseren van verspilling. Lean IT gaat ook over het continu verbeteren van de te leveren IT-services. Er gelden twee kernwaarden: vertrouwen en samenwerking.
Development en operations zijn in dit opzicht belangrijk om gezamenlijk waarde toe te voegen. Lean IT biedt een uitstekend ondersteunend kader voor een gestructureerde aanpak van de afstemmingsproblematiek tussen de business (demand-organisatie) en IT (supply-organistie), waarbij afstemming tussen development en operations als voorwaarde geldt.
Bij Lean IT gaat het in het bijzonder om het creëren van klantwaarde. Dit is alleen haalbaar als de gehele organisatie bereid is om de Lean-filosofie te ‘adopteren’. Vooral voor een interne traditionele IT-afdeling is dit een lastig proces. De hedendaagse rol van een regieorganisatie (richting en opdracht geven aan de informatievoorziening en de IT-ondersteuning) is hierbij een belangrijke factor, zeker als het gaat om ketenintegratie. Lean IT vraagt een integrale ketenbenadering (met als doel ketenintegratie) en in lijn daarmee een alomvattende aanpak over alle units en bloedgroepen van de organisatie heen (systeemdenken). In figuur 2 is de samenhang te zien tussen een regiefunctie (demand) en een IT-serviceverlenende organisatie. Development en operations zijn belangrijke onderdelen van de organisatiebrede waardestroom, waardoor toepassing van DevOps-inzichten de hele keten mede helpen verbeteren.
 
Figuur 2. Positionering development en operations in de demand- en supply-keten en organisatiebrede waardestroom
 
Demand-supply
De demand-organisatie heeft te maken met allerlei business-/klantwijzigingen, vaak zelfs op dagelijkse basis. De supply-organisatie is vaak overbelast en daardoor is er maar al te vaak sprake van gedrag dat wordt omschreven als reactief crisismanagement. Constante verandering, wisselende prioriteiten, nieuwe releases en upgrades en de noodzaak om bestaande en opkomende technologieën in balans te brengen en te houden. Dit draagt allemaal bij tot een onhoudbare mix van complexiteit, beweeglijkheid (motility), duurzaamheid (sustainability), beperkingen (constraints), onzekerheden (uncertainties) en risico’s. Om het voorgaande te doorbreken dient de demand-organisatie direct betrokken te zijn bij de DevOps-inzet en als deelnemer in een eventueel DevOps-team. De demand-organisatie definieert hierbij wat de belangrijkste waarden zijn, en de ondersteunende DevOps-werkwijzen en daaraan ondersteunende IT-processen worden door de supply-organisatie ontwikkeld en gemanaged om deze waarden te leveren.
Ketenintegratie
Voor een effectieve inzet en gebruik van DevOps-concepten is een totaalvisie op de gehele keten noodzakelijk. DevOps is een manier van werken die de tegenstrijdige belangen binnen een organisatie bij elkaar laat komen. DevOps is dus veel meer dan processen en techniek/ tooling; voor het slagen van DevOps in organisaties is het belangrijk de koppeling te leggen met de organisatiedimensie (performance factor) en de gedrag- en attitude-dimensie (people factor). Door de uitvoering binnen afdelingen in onderlinge samenhang te regisseren worden zowel de effectiviteit als de efficiency vergroot.
DevOps en organisatieverandering
Organisatievormen
In relatie tot het DevOps-kader worden drie organisatievormen onderkend (figuur 3) . Structuurdenken is het denken in afdelingen en organogrammen, ook wel aangeduid met silo-gericht denken. Zie de linkerkant van figuur 3. De vertica le aansturing via directie en managers speelt hierbij een belangrijke rol. Afdelingen zijn uitgegroeid tot groepen met een eigen werkwijze en een eigen cultuur. De afstemming van de werkzaamheden vindt plaats via het managementteam.
Figuur 3. DevOps in de organisatie-inrichting
 
In de jaren 80 van de twintigste eeuw is het procesdenken toegenomen. Zie het middenstuk van figuur 3. Procesdenken richt zich op de com municatie tussen medewerkers, terwijl een te realiseren resultaat zijn weg door de organisatie vindt. Niet de formele structuur, het organogram, maar de manier waarop medewerkers met elkaar samenwerken staat centraal. Niet de eigen afdeling, maar het te realiseren resultaat geeft hierbij richting aan de werkwijze. De wijze waarop IT-services bij veel organisaties worden geleverd, is nauwelijks te handhaven omdat de huidige complexe IT-processen niet optimaal ingericht zijn op de roep vanuit de business om snelle en flexibele IT. Door een (overwegend) silo-gedreven manier van organiseren zijn IT-processen onnodig complex, is de prestatiemeting onoverzichtelijk, zijn houding en gedrag van medewerkers intern gericht en is tooling te sterk gericht op de individuele technologie. Dit staat haaks op de wens vanuit de business waar men in toenemende mate snelle levering van nieuwe functionaliteit wil, het snel verhelpen van incidenten, korte communicatielijnen, en IT van hoge kwaliteit. Er is dus een mismatch tussen de traditioneel ingerichte IT-serviceprovider en de business. Het is daarom tijd om de opzet van IT-serviceproviders fundamenteel te heroverwegen. In bovenstaande ontwikkelingen kan de DevOps-aanpak een rol spelen, zie rechterkant figuur 3. In een (virtueel)
DevOps-team worden medewerkers van verschillende units ingezet. Deze afdeling overstijgende inzet komt zowel vanuit de business, development als operations. De samenwerking heeft als doel resultaten te halen, door oplossingen flexibel en snel te implementeren, zonder complexe en niet-waardetoevoegende processen.
De rol van DevOps
DevOps is ontstaan vanuit de noodzaak om het leveren van IT-services behendiger te laten plaatsvinden, in plaats van de twee betrokken partijen (de ontwikkelaars en de IT-professionals) als silo’s (separate lijnafdelingen) te zien die elkaar dingen doorgeven maar niet echt samenwerken. De aanpak is erop gericht dat IT-ontwikkelprojecten en IT-servicemanagement (verantwoordelijk voor de exploitatie van IT-services) geïntegreerd en (bij voorkeur) geautomatiseerd samenwerken met de juiste vertegenwoordiging vanuit de demand-organisatie en er sprake is van (permanente) multidisciplinaire teams. DevOps wil silo’s doorbreken en geautomatiseerd samenwerken in de keten.
DevOps in context
DevOps dient ondersteunend te zijn aan andere door de organisatie gebruikte best practices en raamwerken. De DevOps-mindset kan organisatiebreed ingezet worden, maar er dient ook een raamwerk te zijn dat kaders stelt en handvatten geeft dat de scope van DevOps overstijgt. Voorbeelden hiervan zijn ITIL 2011 Editie en COBIT5. Een organisatie die processen gebaseerd heeft op ITIL kan dan ook prima de DevOps-inzichten adopteren en gebruiken; het sluit naadloos op elkaar aan. In ITIL is er de Service Transition levenscyclusfase, juist om de daaraan voorafgaande fase Service Design en de daaropvolgende fase Service Operation met elkaar in verbinding te brengen (figuur 4) . Voorwaarde is wel een strategisch kader en een cultuur van continue verbetering.
Figuur 4. Indicatie positionering DevOps en best practices in de waardestroomfasen

In de praktijk blijkt dat met een Agile-aanpak veel aan snelheid en flexibiliteit wordt gewonnen, vergeleken met de watervalontwikkeling. Een groot voordeel is dat de gebruikers voortdurend zelf ‘sturen’ op de door hen gewenste functionaliteit en dit ook snel terugzien in productierijpe resultaten. Het snel in productie nemen van functionaliteit(en) en tegelijkertijd ook de impact en frequentie van incidenten beperken is een volgende stap. Hierdoor beschikken gebruikers ook snel over deze functionaliteiten. Op dit punt wordt vanuit een ontwikkelomgeving een ontwikkelde informatieoplossing geïmplementeerd in een (operationele) productieomgeving, van waaruit de exploitatie plaatsvindt. Waar Agile zich primair focust op de klant en op (IT-)vernieuwing, spitst DevOps zich toe op IT-servicemanagement en op het verbeteren van de demand-supply-relatie Het generieke doel van DevOps is dat met Agileprincipes nieuwe of gewijzigde IT-services van hoge kwaliteit worden opgeleverd, die voldoen aan de managementnormen. De IT-services worden (zonder veel overhead) in kleine releases, gecontroleerd in productie genomen (nieuwe en onderhoudsreleases door elkaar) met een minimum aan verstoringen. Een groot voordeel is dat ook de managers onderdeel zijn van de ontwikkelteams en zorgen voor kennisoverdracht en het toepassen van de managementnormen. Komt hiermee het ITIL-raamwerk te vervallen? Absoluut niet. DevOps is als aanpak en concept te positioneren binnen het ITIL-raamwerk. In figuur 4 is aan de pijlen tussen de vijf ITIL-levenscyclusfasen te zien dat er terugkoppeling (feedback) respectievelijk betrokkenheid (involvement) is tussen de verschillende fasen. De DevOps-context sluit naadloos aan op de beoogde doelstellingen van de ITIL-fasen Service Design, Service Transition en Service Operation.
Het grote verschil in DevOps ten opzichte van andere (management)aanpakken en best practices is dat DevOps kan worden beschouwd als een manier van denken, een mindset. Een inbedding of gebruik van DevOps kan prima worden uitgevoerd bij een organisatie die al verschillende modellen en processen in gebruik heeft. De focus daarbij ligt op het verbeteren en het optimaliseren op basis van kwaliteit en klantwaardering. De meerwaarde van DevOps zit in de wijze waarop het in de praktijk wordt toegepast.

Een praktische start

In de praktijk blijkt volledige inbedding van DevOps-inzichten voor veel IT-serviceproviders een brug te ver. Een stapsgewijze verandering kan het beste kleinschalig beginnen met de inzet van een transitieteam (figuur 5) . In de initiële fase van een DevOps-(volwassenheids)traject helpt een transitieteam de kloof tussen development en operations te verminderen. Dit kan een afdeling zijn, naast development en operations, maar het kan ook een virtueel team zijn met verschillende bloedgroepen, waar ervaring in de samenwerking wordt opgedaan.
Figuur 5. Transitieteam slecht de muur tussen development en operations
 
Zoals eerder aangeduid staan er tussen ontwikkeling en beheer ‘muren’. In de dagelijkse werkzaamheden ervaart men een kloof en blijft de juiste implementatie van hetgeen is ontwikkeld onderbelicht of achterwege. In een evolutionaire benadering biedt het zogeheten transitieteam veelal verlichting. Dit (virtuele) team pakt transitietrajecten, inclusief inbeheername, professioneel op en het zorgt voor een adequaat transitieproces vanuit ontwikkeling richting beheer. Het team gebruikt bijvoorbeeld de ITIL best practices uit de levenscyclusfase Service Transition (maar ook uit Service Design en Service Operation). Service Transition is hierbij zo ingericht dat het de gehele bouw(samenstelling) en implementatie voor zijn rekening neemt. Service Design ontwerpt en ontwikkelt deelproducten die Service Transition zonder aanpassingen als basis voor de samenstelling van changes/releases en implementatie van de eindproducten gebruikt. Service Operation ontvangt uiteindelijk kant-enklare producten, die het dagelijkse beheer zonder problemen opneemt. Dit alles vanuit een gemeenschappelijke teamverantwoordelijkheid.
In het team acteren (deeltijd) medewerkers uit development-en operations-afdelingen en bij voorkeur ook vanuit de business, waardoor nauwer samen wordt gewerkt. Conform ITIL 2011 Editie is het transitieteam vooral gericht op de organisatorische transitieaspecten, zoals de services, processen en mensen. Het team speelt pas een rol wanneer de servicecatalogus wijzigt. Alle nieuwe IT-services en grote wijzigingen aan een IT-service worden via Service Transition door het transitieteam begeleid voor implementatie binnen beheer. De organisatievorm met een transitieteam, als afdeling binnen development of operations, of als virtueel team, kan een eerste stap zijn naar een DevOps-ideaalmodel. Dit is een suboptimale oplossing maar wel een die voor veel IT-serviceproviders haalbaar is. Door het transitieteam kan de complexiteit uit DevOps worden gehaald.
DevOps en de medewerkers
Gedrag en attitude
In de voorgaande paragrafen is verduidelijkt wat consequenties zijn voor de wijze van organiseren.
Zijn we net van structuurdenken naar procesdenken geëvolueerd, nu gaat het om teamdenken. Eigenlijk is dit een logisch vervolg op het procesdenken. Het gaat om de navolgende twee basisfactoren:
• De harde kant die te maken heeft met het verbeteren van processen: de werkstructuur.
• De zachte kant die te maken heeft met het aanpassen van de organisatiecultuur.
Deze twee factoren zijn belangrijke uitgangspunten van Lean IT. In lijn hiermee dient een groot deel van de verantwoordelijkheid op het operationele niveau te liggen. Het managementteam speelt vervolgens een actieve rol als sponsor, maar dient wel te beseffen dat de daadwerkelijke verbeteringen en verantwoordelijkheden binnen het operationele lijnmanagement, en in het bijzonder bij de medewerkers op het operationele niveau ligt. In veel gevallen zijn dit al aanwezige procesmanagers. Dit vraagt in veel supply-organisaties een forse omslag in managementstijl en cultuur. Supply-organisaties die veel waarde hechten aan de organisatiestructuur, of waarbij de medewerkers veel waarde hechten aan de positionering binnen de organisatiestructuur, dienen er rekening mee te houden dat dit veel vraagt van de wijze van aanpak, de communicatie en de ambitie. De veranderkracht van een supply-organisatie (als IT-serviceprovider) is van groot belang. Het gaat over slagvaardigheid en het hebben van de juiste competenties.
Succesfactoren
Het succes van DevOps is voor een groot deel afhankelijk van menselijke factoren en een omslag in de cultuur. Dit naast een belangrijke, aanvullende factor: communicatie. Het DevOps-concept is een totaalvisie op de gehele keten, van het starten van het ontwikkelproces tot en met het in productie gaan. Het is een manier van werken die de tegenstrijdige belangen van ontwikkelaars en technische specialisten binnen een organisatie bij elkaar laat komen. De werkwijze is, zoals het acroniem al wel doet vermoeden, niet alleen voor ontwikkelaars en operationeel medewerkers (developers en operations). Het is bedoeld om multidisciplinaire teams te faciliteren, zodat ze de verantwoordelijkheid nemen voor het resultaat en de toegevoegde waarde voor de business. DevOps is een multidisciplinair fenomeen waarbij geldt dat geen enkele IT-vaardigheid belangrijker is dan de andere. Om problemen te voorkomen zijn alle vaardigheden nodig. Wanneer teams worden gebouwd rond medewerkers die zowel de rol van bijvoorbeeld ontwikkelaar, tester als system administrator aannemen, worden bijzondere teams gebouwd.
Lean management
Lean management zorgt ervoor dat verbeteringen in de processen binnen een organisatie in een beheersbaar, gesynchroniseerd tempo verlopen en gericht is op het leveren van klantwaarde. Klantwaarde wordt bereikt door mensen, processen en technologie; in die volgorde. Ook bij DevOps heeft de kern van de problematiek te maken met de afstemming en overeenstemming tussen de bedrijfsdoelstellingen en de IT-eisen van de organisatie. De traditionele manier van managen geeft in ieder geval geen enkele garantie voor de juiste aandacht of ondersteuning. Indien er namelijk geen concrete actie wordt genomen op het veranderen van de wijze waarop de teams, processen en medewerkers worden gemanaged, dan slaagt ook het ‘invoeren’ van DevOps hoogstwaarschijnlijk niet. Het vereist de juiste ondersteuning en het juiste leiderschap om de medewerkers te stimuleren mee te werken aan, en mee te denken over de continue verbetering van DevOps-teams, de aanpak en de ondersteunende IT-processen die echt waarde toevoegen voor de klant. De benodigde managementaanpak om dit te bereiken betreft Lean management. Hierbij wordt gebruikgemaakt van diverse hulpmiddelen en technieken om het doel, het leveren van waarde aan de klant, aan te laten sluiten op de processen en de medewerkers. Hulpmiddelen en technieken zijn op zichzelf nog niet effectief; alleen met de juiste mentaliteit (mindset) van alle betrokkenen in de organisatie hebben de hulpmiddelen en technieken pas echt effect. Maar om de mindset van de medewerkers én hun managers op hetzelfde niveau te brengen, vergt veel investering. Bij voorkeur wordt een startpunt voor een transformatie vastgesteld. De bepaling van het volwassenheidsniveau is hierbij behulpzaam en geeft een afgebakend startpunt voor verandering.
Automatiseren
Om een hogere volwassenheidsfase te bereiken dient men zover te zijn dat een groot deel van de relatie tussen development en operations wordt geautomatiseerd. Let wel: dit is geen doel op zich maar een hulpmiddel. DevOps is geen technische methode maar een mindset. Om de hoog geauto-matiseerde relatie heen dient een effectieve PDCA (plan, do, check, act) plaats te vinden waarin de DevOps-cultuur gemeengoed is. In DevOps is een aantal kernaspecten bijeengebracht:
1. Continuous integration (continue integratie): Dit verwijst naar het integreren, bouwen en testen binnen de ontwikkelomgeving. Continuous delivery bouwt hierop voort en betreft de laatste benodigde fasen voordat inzet naar productie plaatsvindt.
2. Continuous delivery (continue levering): Dit verwijst naar het in staat zijn om frequent implementaties te doen, of te kiezen om dat niet te doen. Dit is meestal gebaseerd op de voorkeur van de organisatie om met een lager tempo te implementeren.
3. Continuous deployment (continue inzet): Dit verwijst naar iedere wijziging die door de pijplijn gaat en automatisch in productie wordt genomen op het moment dat deze klaar is. Dit resulteert in veel implementaties per dag. Voor continuous deployment geldt als grondslag continuous delivery. Continuous deployment is de volgende stap van de continue levering en dient dan ook het doel te zijn van de meeste bedrijven die niet worden beperkt door wettelijke of andere vewreisten. Het gebruik van continuous deployment dient in ieder geval gebaseerd te zijn op de bedrijfsbehoeften.
Continuous delivery is een randvoorwaarde voor het gebruik van DevOps. Pas wanneer er sprake is van (automatische) continuous delivery kan erop worden vertrouwd dat wijzigingen waarde leveren voor de klant, binnen een korte tijdspanne nadat de wijziging wordt vrijgegeven (figuur 6) . De voorwaarde ligt in een organisatie die hier ook klaar voor is, met de juiste cultuur en het juiste gedrag.
Figuur 6. Ontwikkeling integratie development en operations in de vier delivery pijplijn-omgevingen
 
Job ten Hagen (job@tenhagen-consulting.nl) is interimconsultant en eigenaar van Ten Hagen Consulting.
Hij is in 2015 DevOps gecertificeerd via het DevOps Institute. Hij heeft meer dan twintig jaar ervaring als consultant in het ontwerpen en verbeteren van (IT-) organisaties en processen bij klanten. Hij is expert in informatie- en servicemanagement (demand-supply) en gecertificeerd in het toepassen van best practices. Zorgt als adviseur en verandermanager op een initiatiefrijke en analytische wijze voor ontwerp en transformatie van organisaties en processen.
Jan Heunks (jan.heunks@keyresult.nl) is trainer/ consultant en associated partner van Key Result. Hij is meer dan 25 jaar (in)direct betrokken binnen ver - schillende organisaties om performance-vraagstukken vanuit verschillende invalshoeken te bekijken. Brengt als gecertificeerd informatie-, project- en (business) servicemanagement-expert op adequate wijze veranderingen of verbeteringen aan in een demand-supply en/of in een regieorganisatie en zorgt daarmee voor meer grip op projecten en processen.
 
Literatuur
Kim, G., Behr, K. & Spafford, G. (2014). The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.
Heunks, J. (2014). Lean IT, Theorie en praktijk van Lean in een IT-omgeving. Van Haren Publishing.
Hagen, J. ten (2012). Designing and transforming IT organizations. TSO.
 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

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

Stel uw vraag