Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Procesmanagement werkt 'when you are lovin’ IT'

Bij procesmanagement denk ik vaak aan mijn eerste bijbaan bij McDonalds. Daar stond ik zeker twee keer in de week om mijn zakgeld aan te vullen. Een fantastische tijd, waarvan ik veel heb geleerd. Wat me nu nog altijd fascineert is de manier waarop de processen van het bakken en beleggen van de burgers en het vullen van de bekers milkshake tot in de puntjes was georganiseerd.

Procesmanagement werkt when you are lovin’ IT

 Menig it-afdeling zou aan die efficiency van McDonalds een voorbeeld kunnen nemen. It-afdelingen zouden sowieso eens wat vaker hun licht op kunnen steken in andere bedrijfstakken als het gaat om efficiënt procesmanagement. 

Mijn eerste dag bij McDonalds bestond uit het bekijken van een video in de zogenoemde crew-room. Zonder een blik in de keuken te hebben geworpen, werd ik met die video stap voor stap geïnstrueerd over het bakken van hamburgers, niets meer, niets minder. Op dag twee mocht ik aan de slag in de keuken, bijgestaan door een collega die alle stappen nog eens live met me doornam. Omdat ik de video al had gezien, wist ik precies wat er van me verwacht werd. It-medewerkers worden vaak aan hun lot overgelaten bij hun werk op de servicedesk. De kennis die ze hebben van it, wordt als voldoende beschouwd om telefoontjes te kunnen beantwoorden en te registreren in het systeem. Maar zo simpel blijkt het toch vaak niet te zijn.

Brandweer

Ook de brandweer kan inspiratie bieden voor it’ers; hoe groter de brand, des te belangrijker de procedures. Brandweermannen weten hoe belangrijk het is om procedures te volgen. Hoe groter de brand hoe belangrijker het proces; er staan immers levens op het spel. In de it werkt het vaak andersom. Hoe groter het incident, hoe meer uitzonderingen er worden gemaakt. Er zijn in de it-praktijk nog maar weinig organisaties die hun procesmanagement volledig onder controle hebben, laat staan dat ze controle hebben over de integratie tussen de drie ingrediënten ervan, process, people en products. Er worden processen beschreven en middelen klaargezet, maar er wordt weinig tot niets gezegd over wie de processen uitvoert en wie de controle op zich neemt. Daarom vijf tips voor it-managers om van it-processen een geoliede machine te maken:

1. Zorg voor een goede basis door middel van een actuele procedure. De procedures waarmee bij it-afdelingen wordt gewerkt sluiten vaak totaal niet aan op de werkelijke praktijk. Ze zijn ooit eens opgesteld en vervolgens in de la beland. Het regelmatig up-to-date houden van procedures is efficiënter dan eens in de zoveel tijd opnieuw beginnen.

2. Zonder helder doel, geen optimaal procesmanagement. Wat wil je nu precies bereiken? En hoe gaat jouw doel bijdragen aan het succes van de organisatie? Maak het meetbaar en geef daarmee brandstof aan de afdeling.

3. Pas functiescheiding toe; een belangrijk ingrediënt voor goed procesmanagement. De kracht zit namelijk in het scheiden van uitvoering en controle, iets wat de kwaliteit van de dienstverlening direct ten goede komt. Het houdt de mensen scherp.

4. Zorg voor goede en goed ingerichte tooling. Door zaken te automatiseren kunnen veelvoorkomende werkzaamheden en werkwijzen worden gereguleerd.

5. Vergeet de zachte factoren niet. Denk aan betrokkenheid, fun en collegialiteit. Van het werken met processen wordt vaak gedacht dat het vervelend is en remmend, maar niets is minder waar. De lol die ik aan mijn baan bij McDonalds beleefde is daarvan het levende bewijs.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4679798). © Jaarbeurs IT Media.
?

 

Reacties

Op zich waar allemaal, maar helaas lijkt het verhaal weer te willen benadrukken dat het in procesmanagement gaat om strak geregelde procedures. En voor sommige processen is dat wellicht handig (waarschijnlijk dat daarom de hamburgers van mcdonalds altijd even vies smaken ;-), maar in proces management gaat het er juist om dat je een proces gaat gebruiken, zodat het doet wat het belooft. Elke organisatie heeft processen; het is de kunst om ze ook als zodanig te besturen.

En dat hoeft helemaal niet te betekenen dat het een strak, tayloriaans, geregeld geheel is. Een proces is immers nooit een doel; het is slechts een middel voor het leveren van producten, diensten of het oplossen van problemen.

Dus, naar mijn mening, zijn de belangrijkste vragen om mee te beginnge:

- Welke resultaten leveren onze processen?
- Wat beloven we over deze resultaten?
- Welke manier van besturing heeft dit proces nodig om te doen wat het belooft?

Dan zul je zien dat elk proces uniek is en niet allemaal als marionetpoppen gestuurd hoeven te worden, maar bijvoorbeeld gebaat zijn bij meer uitvoerder gedreven sturing. Helaas heeft de leansixsigma hype van de afgelopen jaren deze 'lopende band look' (hoewel dat niet het doel is van deze methodes) op processen wel versterkt.


Efficientie is wat mij betreft het meest over het paard getilde woord in procesmanagement. Wat heb je eraan als je (na je procesverbeter en -automatiseringsproject) heel efficient bent in zinloze dingen?

Gelukkig voor McDonalds denken veel hamburger-liefhebbers daar anders over ;-)



misschien interessant om 25 april a.s. de workshop van Dave van Herpen over Agile Beheer op de Service Manager Dag 2013 in Utrecht bij te wonen?

Het ideaal van de business consultant. Bedrijfsprocessen onafhankelijk van mensen, tayloriaans en met automatisering uitgekiend en volledig geoptimaliseerd. Theoretisch is dat mogelijk, maar je bent nooit onafhankelijk van mensen en daar lopen dit soort processen op stuk.
Bij de MCDonald werkt dit voor de core producten zeer geod, maar omdat de smaak van de consument is veranderd en er andere producten moeten worden aangeboden is de processontwikkeling van koffie schenken, ijsjes, frisdrank, salades nog lang niet optimaal. Dit kan nog wel jaren duren.
Vergelijkingen met ICT zijn altijd lastig omdat er iedere 3 jaar een technologie voorbijkomt die bestaande technologieën doet verbleken en uitrangeert, processen worden nog wel stabiel , maar nooit optimaal. Daarbij verandert direct de vraag bij de afnemers en je hebt een onmogelijkheid gescoord.
Een hamburger is nog steeds een hamburger. In 1994 werd gsm in Nederland geïntroduceerd, 20 jaar later hebben we de kracht van een mainframe uit 1990 in onze hand en kunnen we nog steeds bellen, maar daarnaast nog veel veel meer....

Michiel grappig artikel al steek je wel je nek uit door ons vak met de procedures van McDonnalds te vergelijken.
Je strict houden aan de procedures zoals jij daar geleerd hebt is een goede eigenschap als je in de luchtvaart werkzaam bent (de meeste elende aldaar is het gevolg van afwijken van procedures), maar zoals Willem terecht aangeeft is het ICT vak nog net wat de dynamisch om je daarop vast te willen pinnen.. (waarmee ik meteen een aanval doe op ISO9000 of hie het tegenwoordig dan ook mag heten)

Goed stuk, met plezier gelezen.

Het is ook de kracht van cultuur en DNA waardoor processen strak kunnen werken. Ik geloof heilig in dit soort modellen en kom ze helaas veel te weinig tegen in Nederland.

Strakke processen werken en vaak verschuilen we teveel achter dat we geen robots zijn en andere bla bla.

Standaardisatie zorgt voor schaalbaarheid, verdraagbaarheid lagere kosten omdat je met lagere geschoolde mensen prima uit de voeten komt.

Nogmaal, ik vind dit een goed artikel!

Zeker een enthousiast geschreven artikel. (Ook is het nationale complimentendag.)

Het ideaalbeeld lijkt mij duidelijk. En in het wild kom je af en toe wel iets tegen wat er op begint te lijken en vaak weet je dan precies waar je aan toe bent. Maar persoonlijk ben ik er nog niet helemaal uit of dit werkelijk het ideaalbeeld zou moeten zijn. De paarse krokodil vs de BOFH of de plastic hamburger vs de halfrauwe met paardenvlees gevulde 'american' burger.

In dit verhaal mis ik een beetje het pragmatische aspect. Zorg dat je optimaal gebruik maakt van de sterke eigenschappen van je team. Is dat de onmisbare ik kan alles fixen en 60 uur per week werkende wervelwind die zichzelf voorbij loopt of het 9 tot 5, alle bonnetjes checkende pietje precies.

Processen kunnen een prima hulpmiddel zijn om een gezamenlijk beeld te vormen hoe er gewerkt wordt, en om te kijken waar dat beter kan. Een taal en tool om met een andere blik te kijken, en dingen te zien waar je normaal niet bij stilstaat in de drukte van de dag.

Werken volgens procedures blijkt in de praktijk vaak niet de handigste aanpak. De procedure moet er zijn voor het werk en de werknemers, niet andersom. En dus mensen ondersteunen in hun werk, ipv professionals gaan opleggen hoe ze het moeten doen. Nadruk op het waarom (het doel wat je noemt in punt 2), en de hulpmiddelen (punt 4).

Ik heb wat moeite met punt 3, over functiescheiding. Als ik kijk naar organisaties met agile / lean teams, daar staat daar de samenwerking waarin iedereen een bijdrage levert aan het resultaat centraal. Met name in een cross functional team is de functie onderschikt aan wat iemand kan doen. In agile teams is er ook controle, zelfs meer controle, maar die is niet gebaseerd op functiescheiding. Ik zie pair programming en frequent reviews als een vorm van controle, waarin medewerkers elkaar scherp houden. Met swarming ga je nog een stap verder, en werk je met je team intensief samen om een doel te bereiken. Ook in de dagelijkse Scrum standup "controleren" de teamleden elkaar tav de voortgang en eventuele blokkades. In een retrospectives evalueer je de werkwijze (het proces), en zoek je naar manieren om continu te verbeteren.

Controlen is in agile / lean teams iets wat je doet door rollen, en niet door functiescheiding. En die rollen kun je flexibel invullen. Vandaag ben ik reviewer, en kijk ik kritisch naar het werk van mijn collega. Morgen is dat andersom en heb ik de rol als auteur, waarin mijn collega's feedback geven. Met respect voor elkaar, en oog voor het geheel, en het resultaat!

Als ik met een team werk als scrum master of agile coach, dan ga ik mensen niet controleren. Uiteraard kijk ik hoe mensen dingen doen, en vorm voor mijzelf daarmee een beeld van het proces wat gevolgd wordt. Met mijn kennis en ervaring zie ik zaken die een bottleneck kunnen zijn in de samenwerking, die een risico inhouden dat project / team zijn doel niet haalt, dat de product kwaliteit onvoldoende is, etc. Zeggen dat ze het "niet goed doen" heb ik afgeleerd (ik geef het toe, dat heeft een paar jaar gekost :-) ). Het bespreken van zulke zaken met teamleden is meestal voldoende om een gezamenlijk inzicht te krijgen, waarin we samen kijken hoe het anders kan. Dat werkt veel beter. Als het echt mis gaat, leren mensen uit eigen ervaring, en ook dat is effectiever dan controleren als een politie-agent.

Mijn motto: Denk niet in functies en controleren, maar in rollen, samenwerken en feedback!

De opmerking over punt 3 van Ben kan ik ten zeerste onderschrijven.
Sommige rollen zijn een mengelmoes van meerdere functies. Zo iemand past binnen geen van de functieprofielen, waardoor hij carrieretechnisch tussen wal en schip valt.

Procedures moeten er zijn om het werk te ondersteunen. Wat daarbij vooral belangrijk is is dat de procedures geschreven worden door de mensen die er mee werken. Te vaak heb ik al gemerkt dat procedures etc. bedacht worden uit een theoretische ivoren toren, waardoor ze in praktijk niet passen en niet blijken te werken.
Bijkomend voordeel van het laten schrijven door de gebruikers zelf is dat je ook meteen een groot draagvlak creëert voor je procesbouwwerk en het gebruik hiervan.

Yo! de processen die Michiel beschrijft hebben een heel ander doel dan hier gereageerd wordt. Het gaat niet om ontwikkeling maar om het beheersbaar houden van een organisatie.

Het lijkt wel of er een allergie is tegen vast omleidende processen, voor de kenniswerker kan ik me dat voorstellen, maar in veel gevallen zijn gestandaardiseerde processen zeer effectief en veel mensen voelen zich daar ook prettig bij. Veel werk leent zich helemaal niet voor allerlei rollenspellen en veel mensen zijn daar ook niet geschikt voor of hebben die hele ambitie niet.

Een aantal jaren geleden zocht ik naar een (programmerende) medewerker en ik was op zoek naar iemand met een negen-tot-vijf mentaliteit. Daar werd heel raar naar gekeken, maar uiteindelijk had ik hem wel gevonden. Sommige ontwikkelaars gruwelen van routine werk en jaren op een project zitten, andere varen daar juist wel bij.

Kies het model wat het best bij DNA of de situatie past.

Heren, dank voor jullie uitgebreide reacties. Leuk om te lezen, zeker ook de complimenten! Zoals jullie al goed gespot hebben draait dit artikel niet om McDonalds of haar producten. Daar heeft een ieder zijn eigen mening over. Als NLP Master Coach is één van mijn speerpunten het modeleren van personen of systemen die werken. Ik haal daar de elementen uit die zogezegd "het verschil zijn dat het verschil maakt". Ik zet hierbij mijn persoonlijke mening over het onderwerp even naast me, want deze doet niet ter zaken. Vervolgens transponeer ik die elementen op het onderwerp dat ik wil verbeteren. Zo kom ik op bedrijven als McDonalds en de brandweer. Er zijn er nog meer natuurlijk. De grap is dat alle goede oplossingen dagelijks om ons heen zijn, alleen lopen we vaak met oogkleppen op en zien ze niet. Ik krijg al weer inspiratie voor een volgende artikel :)

Computable Expert
Michiel de Ruiter

Michiel de Ruiter
Cco, MPROOF. Expert van Computable voor het topic Beheer.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×