Development

Procesmanagement
Robotarm

Weg met de wachtrijen in IT

Wat kunnen we leren van de procesindustrie?

robot arm © CC-BY 2.0 - Flickr PEO ACWA
21 maart 2017

Wat kunnen we leren van de procesindustrie?

Het fileprobleem is niet op te lossen door één knelpunt aan te pakken. Dat geldt ook voor IT. Door de grote afhankelijkheid van informatietechnologie kunnen IT-calamiteiten catastrofaal zijn. Het IT4IT-framework is een lichtpuntje. Kenmerken van het voortbrengingsproces in de procesindustrie worden vertaald naar IT. 

Waar heeft de professionalisering van de IT ons anno 2017 gebracht? Overal backlogs en to-do-lijsten omdat er nu even geen tijd, geld of capaciteit beschikbaar is.

Portfoliomanagement definieert projecten die volgend jaar misschien aan de beurt komen. Ontwikkelteams hebben te maken met productbacklogs. Architecten moeten reviews uitvoeren waar ze niet aan toekomen. Wachtrijen van releases die gepland en uitgerold moeten worden. Change requests worden geprioriteerd en komen op het planbord te staan. Voor storingen worden workarounds bedacht voordat ze worden opgelost. Overal wachtrijen en achterstanden.

Als één van die achterstanden echt pijn doet, komt er een gerichte actie. Tijdelijk extra inzet om dat ene project eerder uit te voeren of belangrijke changes versneld door te voeren. Extra geld komt beschikbaar voor externe IT’ers. Het fileprobleem laat zich echter niet oplossen door één knelpunt aan te pakken. Versnelde doorstroom op onderdelen leidt tot nieuwe knelpunten op andere plaatsen. Achterstanden blijven en verplaatsen zich.

Ook IT is als een fabriek aan te sturen.

Sinds jaar en dag probeert de IT-afdeling het voortbrengingsproces van strategie tot operationele werking te beheersen met behulp van frameworks, modellen, methoden en technieken zoals Scrum, CMM, Prince2, TOGAF, Archimate, TMAP, BABOK, ITIL en BISL, gericht op één of twee onderdelen van de voortbrengingsketen. Met het streven naar kostenbeheersing (meer doen met minder mensen) zijn daardoor de wachtrijen en achterstanden alleen maar groter geworden.

Procesindustrie

Wel hebben IT’ers de laatste jaren vooruitgang geboekt met kortcyclischer denken en werken. Een agile aanpak speelt sneller in op veranderingen. Microservices en containers zijn technologische representanten daarvan. Met DevOps reduceert men backlogs tussen ontwikkeling en beheer. Portfoliomanagement aan de voorkant en operationeel beheer aan de achterkant doen nog nauwelijks mee en dat geldt ook voor processen rond life-cyclemanagement van IT-diensten, IT-financiën en control op informatiebeveiliging en compliancy. Hoe stuurt men productieprocessen van andere vakgebieden aan? In de procesindustrie is er evenals in de IT sprake van een voortbrengingsproces met grote variatie aan voort te brengen producten en diensten. Sinds tientallen jaren geldt dat calamiteiten in de procesindustrie catastrofaal kunnen zijn. We spreken van ontploffende fabrieken, milieurampen, doden en gewonden. Ongeplande stops en overload (lees: backlogs en achterstanden) kunnen de oorzaken zijn. Het realiseren van een hoge mate van voorspelbaarheid van gedrag van processen en systemen is daarom absoluut noodzakelijk. Onderzoek leert dat er vijf kenmerken van het voortbrengingsproces in de procesindustrie zijn die de voorspelbaarheid vergroten (zie kader).

Voorspelbare processen

Vijf kenmerken van voorspelbare processen in de industrie:

• Sturen op waarde

Alles is erop gericht om het voortbrengingsproces de verwachte en geplande waarde te laten opleveren, binnen gestelde kaders op het gebied van volume, kosten, kwaliteit en veiligheid, zowel voor de processtappen als voor  het proces als geheel.

• End-to-end-management

Het voortbrengingsproces wordt end-to-end beschouwd en ingeregeld. Het ontstaan van overload van gevaarlijke stoffen tussen de onderdelen is inefficiënt, schadelijk en zelfs gevaarlijk. Zaken kunnen ontploffen.

• Automation

Overgang van het ene procesonderdeel naar het andere is volledig geautomatiseerd. Er zijn geen handmatige handelingen.

• Standaardisatie

Het gebruik van een beperkte verzameling van protocollen, werkwijzen en componenten waarvan de werking bekend en gedocumenteerd is en die gemakkelijk reproduceerbaar of vervangbaar zijn.

• Monitoring & control

Het hele voortbrengingsproces wordt nauwlettend gemonitord. Zowel door geavanceerde meetsystemen als door hooggekwalificeerde operators die de processen in de gaten houden. In geval van dreigende calamiteiten kunnen ze ingrijpen.

IT-calamiteiten in administratieve organisaties waren tot voor kort op z’n hoogst ernstige ongemakken. Dit is anno 2017 anders. Vanwege de grote afhankelijkheid van informatietechnologie kunnen IT-calamiteiten evenzeer catastrofaal zijn. Persoonlijke levenssfeer en veiligheid staan op het spel. Er worden grote financiële risico’s gelopen.

Een veel gebruikt bedrijfskundig model voor analyse en ontwerp van het voorbrengingsproces van producten in de industrie is het zogenaamde Value Chain model van Michael Porter uit 1985. Veel fabrieken zijn met Porter in de hand opgebouwd en omgebouwd. Bedoeling van dit model is om het productieproces als geheel én alle transformatiestappen in dat proces waarde te laten toevoegen aan de business. Succesvolle sturing op waarde wordt bereikt door standaardisatie van bedrijfsprocessen en door het creëren van maximale beheersbaarheid en voorspelbaarheid.

Fabriek

Tot voor kort werd de Value Chain van Porter door IT’ers afgedaan als irrelevant voor het IT-voortbrengingsproces totdat enkele jaren geleden de ontwikkeling van het IT4IT-framework begon. Jarenlange verzuchting van IT- en businessmanagers kreeg gehoor. Porters gedachtegoed werd vertaald en uitgewerkt naar de IT waarin uiteindelijk het voortbrengingsproces zo veel mogelijk geautomatiseerd zou moeten worden. Vandaar de naam IT4IT. Opvallend is dat de vijf kenmerken van het voortbrengingsproces in de procesindustrie terugkomen in het gedachtegoed van IT4IT, namelijk sturen op waarde, end-to-end-management, automation, standaardisatie en monitoring & control.

Pas na standaar­disatie en automation ontstaan de voordelen.

In februari 2015 schreef Rob Akershoek, een van de grondleggers van IT4IT, een artikel in AutomatiseringGids met als titel Blauwdruk voor managen nieuwe IT over de integrale IT-managementbenadering van IT4IT. Hierin beschrijft hij de waardestromen van IT4IT:

1. Strategy to Portfolio (S2P): Vertalen van strategie en businessplannen naar een portfolio van IT-diensten.

2. Requirement to Deploy (R2D): De werkstroom vanaf het definiëren van eisen en wensen naar het uitrollen van een IT-dienst.

3. Request to Fulfill (R2F): De werkstroom van het aanvragen van een IT-dienst naar het activeren en/of leveren daarvan.

4. Detect to Correct (D2C): De processen die ervoor zorgen dat een IT-dienst aan de verwachtingen blijft voldoen.

In AG Connect van oktober 2016 werkte dezelfde auteur een belangrijk aspect van IT4IT uit, namelijk automation, in het artikel Digitaliseer je bedrijf, begin bij IT. Hij benadrukte de ambitie van IT4IT om naast het conceptuele gedachtegoed van end-to-end IT-management ook met concrete oplossingen én tooling te komen. Zo zal automation niet alleen toegepast moeten worden bij continuous delivery maar ook bij portfoliomanagement, architectuurreviews, requirementanalyses en beheer. Dit kan alleen als er ook sprake is van vergaande standaardisatie op alle fronten.

Aan de macht

De vraag is nu waar we staan over een aantal jaren. Gaan IT-fabrieken kortcyclische IT-diensten produceren op basis van herbruikbare bouwstenen? Agile ontwikkeling, continuous delivery, herbruikbare microservices, cloudservices en software defined datacenters/networks wijzen die kant op. Als IT4IT z’n ambities waarmaakt, is dat een ferme stap in die richting. IT’ers zijn over een aantal jaren vooral hooggekwalificeerde procesoperators die het productieproces in de gaten houden én er zijn er veel minder dan nu. Businessmanagers zijn dan aan de macht want zij bepalen welke IT-diensten welke waarde moeten leveren. Dan is de IT eindelijk volwassen.

Meer control op IT: de praktijk

Een middelgroot bedrijf in de farmaceutische industrie besloot eind 2015 de transitie in te zetten naar agile werken en een transformatie naar een cloudinfrastructuur en een hoge mate van uitbesteding aan leveranciers/partners. De beslissing was vooral ingegeven door gebrek aan control van de eigen IT-afdeling en de daardoor ontstane achterstanden in uitvoering van projecten en afhandeling van changes en incidenten. Doordat men zag hoe andere bedrijfsonderdelen met het management van industriële processen omging, werd men geïnspireerd om zaken anders op te lossen. Uitgesloten van de uitbesteding werden governance, informatiemanagement, functioneel beheer, architectuur en security. Men wilde zelf de regie in handen houden.

De transitie liep niet zonder slag of stoot. Agile ontwikkelteams liepen al gauw tegen lange wachttijden op. Vooral bij het testen waren de vertragingen voelbaar. Scrum-teams leverden functionaliteit op waarmee testers aan de slag moesten gaan. Echter, door capaciteit- en prioriteitsproblemen ging dit vaak mis, waardoor releases niet tijdig opgeleverd konden worden. Het werk stapelde zich op.

Het bedrijf had zich al gericht op end-to-end-management door de focus op regie bij het uitbesteden. Als gevolg van de geschetste problematiek pakte men ook standaardisatie en automation op. Na een succesvolle pilot werd geautomatiseerd testen volgens standaardprocedures ingevoerd. Vooral de regressietesten (het testen of de ongewijzigde delen van software nog goed werken) lieten zich goed automatiseren. Dit had direct positieve gevolgen en de wachttijden werden snel kleiner. Voorwaarden voor succesvolle introductie van geautomatiseerd testen waren:

• Goed beschreven scripts (user stories en use cases).

• Goede werkafspraken met alle disciplines in  het Scrum-team.

• Betrokkenheid van testers in de gehele sprint.

• Definiëren van een goede testaanpak: vooral functioneel gedreven en adaptief aan het proces van het Scrum-team.

Voordelen

Een belangrijk leerpunt uit de praktijk was dat maatregelen om de IT-processen beter en efficiënter te doen verlopen, in samenhang met elkaar moeten worden genomen. Zoals bleek in dit bedrijf was het richten op end-to-end-management in combinatie met de focus op regie, niet genoeg. Pas nadat standaardisatie en automation werden aangepakt, kwamen de voordelen.

Lees meer over Development OP AG Intelligence
1
Reacties
Anoniem 21 maart 2017 13:19

Komisch dat laatste voorbeeld. Men ging uitbesteden omdat "De beslissing was vooral ingegeven door gebrek aan control van de eigen IT-afdeling...." en een van de wensen omdat te bereiken was "Men wilde zelf de regie in handen houden." Wat is het nu: konden ze het zelf niet of dachten ze werkelijk dat je de regie uit handen kan geven? Mijn adagium is nog steeds: "Shit kunt je niet uitbesteden".

Overal een zeer interessant artikel, alleen heb ik deze al vaker gehoord. Alles moet geautomatiseerd worden. En ik ben blij hoor data banale zaken als installeren van de meeste ICT-Infrastructuur componenten geautomatiseerd kunnen en dat groten delen van het ontwikkelproces tegenwoordig ook steeds beter gaat. Zelfs de omarming om beide grote deelgebieden (ICT-Infrastructuur en software ontwikkeling) elkaar gevonden hebben in DevOps.

Maar..... wat al in het artikel duidelijk naar voren komt: standaardisatie is key! En wat schetst mijn verbazing: op elk gebied binnen de ICT komen er steeds meer smaakjes bij: aan de ene kant ingegeven door start-ups, die ook een graantje willen meepikken en zelfstandige ontwikkelaars tot grote conglomeraten die weer een nieuw idee hebben. Zolang de grote partijen en de vele kleintjes eromheen zich kapot concurreren, zal er van echte standaardisatie niets komen. Gevolg: nog meer tools om de enorme diversiteit van verschillende platvormen, dataformaten en werking aan te kunnen.

Heel leuk om de procesindustrie te betrekken, net zoals ICT-architecten zich graag vergelijken met de bouwarchitecten. Maar ook in de procesindustrie heeft men beperkingen. In Born gaan ze een model BMW in elkaar zetten over een jaar. Daarvoor hadden ze toch zeker een paar duizend man personeel voor nodig. Hoezo compleet geautomatiseerd: en besef de auto industrie is het verst daarin. Oorzaak: niet bereikbare plaatsen tijdens het assemblageproces en te fijngevoelige handelingen kunnen nog niet door een robot worden uitgevoerd.

En ja het model van Porter geldt nog steeds en daar zijn hele bakken aan procesmethodieken op los gelaten, van TQC tot Lean Six Sigma toe. Hoewel zeker in slecht functionerende omgevingen een waardevol tool, op het moment dat een bedrijf lekker draait, wordt het steeds lastiger om te verbeteren. Waarom: de factor mens. Mensen acteren niet als robots die je compleet autonoom kan "programmeren". Dat is vaak de wens van de gedachte van veel leidinggevende, maar getuigd van weinig realisme. Overigens personeel gaat en komt, dus de kwaliteit van je personeel is zeer tijdsafhankelijk en je hebt niet altijd de keus uit de beste werknemers.

Het belangrijkste argument, waarom het heel moeilijk en lastig is, dat al die methodieken en tools de suggestie wekken dat een organisatie (hoe goed die op "papier" ook in elkaar steekt) niet als een Zwitsers uurwerk tikt. Redenen daarvoor zijn dat het bestuur van de organisatie vaak oneigenlijke eisen stelt (het wordt ook genoemd in het artikel : beperking op mankracht, budget, middelen en tijd).

Ik denk daarom dat organisaties niet moeten mikken op het best haalbare resultaat in termen van pure winst, maar kijken naar het meest optimale resultaat in termen van personeel, budget, middelen en tijd. Daar zal in het algemeen voor de korte termijn een mindere winst uitkomen, maar op langere termijn een veel kwalitatievere winst. Ga je voor de korte termijn: gooi al die methodieken en modellen in de prullenbak, dat zijn dan alleen maar potentiele showstoppers. Besef wel: geen krokodillentranen als je na verloop van tijd met lege handen staat.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.