Archive by Author

Een universeel managementsysteem voor DevOps en ESM

Organisaties die DevOs hanteren zien zich gedwongen een oplossing te vinden voor het beheer van elk van hun (vele) DevOps-teams. Hoe ziet een universeel managementsysteem voor zo’n DevOps-team er dan uit? En hoe voorkom je dat DevOps de ESM-boot mist?

DevOps is een organisatiestructuur met een bijbehorende werkwijze die steeds meer in zwang is bij agile ontwikkelteams in de informatievoorziening. Dat zijn vaak teams die een scrum-techniek hanteren voor het kortcyclisch ontwikkelen van nieuwe IT-functionaliteit. Een product owner vertegenwoordigt de belangen van de stakeholders, een scrum master ondersteunt de werkwijze. DevOps brengt daarbij dan de betrokken stakeholders samen in één team.

Zo’n DevOps-aanpak heeft twee belangrijke voordelen: [1] het benut de kortcyclische ontwikkeltechnieken van scrum, en [2] het verbetert op een gestructureerde wijze de vaak gebrekkige communicatie tussen stakeholders in de IT: de ontwikkelaars die gericht zijn op verandering (‘Dev’), de beheerders die gericht zijn op continuïteit en stabiliteit (‘Ops’), en de business die gericht is op het benutten van de potentie van IT.

DevOps-teams kunnen nog gebonden zijn door een gemeenschappelijk platform waarop de ontwikkelde voorzieningen draaien, maar ze kunnen ook een volledige domeinscheiding doorvoeren (zie onderstaande figuur). Elk DevOps-team is dan feitelijk een onafhankelijk serviceorganisatie, die een eigen productieomgeving beheert voor de beschikbaar gestelde voorzieningen, en een eigen deel van de business ondersteunt.

Ze leiden tot nauwe contacten tussen business, Dev en Ops, en tot snelle aanpassingen van de IT-ondersteuning.

Maar leidt dit ook tot betere dienstverlening? En op de meest effectieve en efficiënte manier?

Waar in de klassieke aanpak een IT-organisatie er naar streefde om één gezicht te trekken naar de business, heeft DevOps vele gezichten: elke squad heeft een eigen gezicht. Die squads kunnen dan nog in tribes gesorteerd zijn om per business-domein enige samenhang te bewerkstelligen.

Om verdere wildgroei tussen DevOps-teams te voorkomen grijpen organisaties vervolgens toch weer naar uniformiteit en standaardisatie. Dat heeft immers zo z’n voordelen: het voorkomt dat ieder DevOps-team z’n eigen wiel gaat uitvinden. Er ontstaat in DevOps-organisaties dus behoefte aan een verticale binding tussen de verschillende horizontale DevOps-teams. Dat noemen we chapters. Die kunnen we indelen naar bijvoorbeeld de aard van werkzaamheden (denk aan een chapter Testen) of naar de aard van technieken (denk aan een chapter Tooling).

Als dat nog niet voldoende samenhang en uniformiteit in de prestaties van DevOps-teams teweeg brengt kunnen we nog een derde interventie plegen: met guilds brengen we squad-leden samen op basis van hun expertise, kennis of specialisme. In hun guild kunnen ze dan samenwerken om weer wat meer standaardisatie van methoden en technieken te bereiken. Een guild is daarmee een soort van special interest group, een expertisecentrum, bijvoorbeeld rond het thema requirements management, of rond architectuur of het gebruik van documentatiesystemen.

Al deze interventies in de oorspronkelijk squad-structuur moeten weer worden gemanaged. Net als ‘vroeger’… Wat hebben we met al deze inspanningen nu eigenlijk gewonnen?

Het antwoord op de laatste vraag is weer terug te voeren op de eerstgenoemde twee voordelen: betere communicatie in een kortcyclische ontwikkelstraat.

Maar had datzelfde effect niet op een andere, universeler manier kunnen worden bereikt?

Wat al deze interventies, van tribe tot chapter en guild teweeg brengen is uiteindelijk immers niet meer dan optimalisatie door middel van standaardisatie. Feitelijk is deze DevOps-structuur (ook wel het Spotify-model genoemd) niet meer dan een poging een gestandaardiseerd managementsysteem per squad te bereiken.

Maar als dat de onderliggende driver is voor de hele set interventies, had een DevOps-organisatie dan niet beter meteen naar een standaard managementsysteem kunnen gaan kijken? En dan niet een managementsysteem waarbij de ontwikkeling van IT-producten centraal staat, maar een managementsysteem waarbij dienstverlening centraal staat? Een retorische vraag…

DevOps-teams zijn kleine IT-fabriekjes, en dus IT-dienstverleners. Daarmee kunnen ze uitstekend gebruik maken van de kennis die in de afgelopen decennia is opgebouwd over dienstverlening. En dus ook van het universele servicemanagementsysteem dat kan worden ingericht met de Universele Service Management methode (USM). Onderstaande figuur illustreert dit op eenvoudige wijze.

Herhaalde USM-toepassing in een DevOps organisatiestructuur

Het uniformeren van een squad-managementsysteem lijkt dus eenvoudig. Maar hoe zit het dan met de integratie tussen IT en andere facilitaire taakgebieden?

Enterprise Service Management

De DevOps-organisatiestructuur was al langer bekend onder de naam serviceteams, maar DevOps voegt daar de bijbehorende agile houding, gedrag en cultuur aan toe, met technieken en instrumenten. Waar DevOps echter niet in voorziet, is de expliciete integratie tussen IT en andere taakgebieden, in een Enterprise Service Management benadering (ESM). En dat is toch echt de toekomst. IT en de andere facilitaire taakgebieden integreren steeds meer met elkaar en met de business. Er gaat geen ziekenhuisdeur meer open zonder een pasje. Met IoT wordt alles aan elkaar geknoopt.

Wie nu focust op een techniek waarbij IT weer centraal staat, mist de ESM-boot.

Het onderkennen van het probleem leidt ook hier weer tot het benoemen van de oplossing. Elke DevOps-squad kan immers haar managementsysteem afstemmen op het uniforme USM-managementsysteem. Datzelfde geldt voor alle andere facilitaire teams. USM levert voor alle serviceorganisaties het universele managementsysteem, of dat IT of gebouwenbeheer is, catering of personeelszaken, beveiliging of fleet management. En daarmee borgen we dat er een eenvoudig ‘clickable’ bouwwerk van uniforme managementsysteem-bouwblokken ontstaat.

Kennis

Wil je ook gebruik kunnen maken van die USM-architectuur bij het verbeteren van de bestuurbaarheid van je serviceorganisatie, voor DevOps of ESM, of voor een combinatie van beide? Wil je leren je tooling daarbij slimmer af te stemmen op die integrale benadering? Geen probleem. Dat leer je in twee dagen in de USM Foundation training. Daarna kun je het zelf toepassen in je eigen DevOps- en/of ESM-aanpak, zonder dure consultants te hoeven inzetten. Het enige dat je nodig hebt is kennis. Kennis van een eenvoudige, universele aanpak die alle voordelen van DevOps combineert met de wens om een organisatiebrede, geïntegreerde ESM-doelstelling na te streven.

Versie 2 van het boek “De USM-methode” is sterk uitgebreid t.o.v. versie 1, en meer toegesneden op het ondersteunen van hbo-opleidingen in ICT en Facility Management.

“Enig idee wat een service is?“

Stel je voor dat je geen strak antwoord hebt op de vraag wat een service is. Of dat er binnen jouw organisatie verschillende antwoorden op deze vraag zijn. Hoe reageer je dan op de volgende vraag:

“En hoe denk je dan dat je jouw services gaat managen?”

Wie geen duidelijk antwoord heeft op de eerste vraag, doet er goed aan eens over dit onderwerp na te denken. De tweede vraag is immers van immens belang. Dat gaat echter nog wel wat hobbels opleveren…

Laten we er om te beginnen eens een paar leerboeken op naslaan. Vinden we daarin een SMART definitie van ‘service’ (of ‘dienst’)? Neem bv enkele van de leidende leerboeken die worden ingezet op de Nederlandse hogescholen, bij de opleidingen Facility Management:

Definitie 1 – “Diensten zijn processen en bestaan uit volgtijdelijke contacten tussen afnemers en leveranciers”, en “Een dienst is een menselijke interactie die zich in het hier en nu ontvouwt.” [Maas & Pleunis, 2006].
Daar kun je niet zo veel mee… niet alleen deels onjuist (services zijn processen), maar ook nauwelijks aanknopingspunten voor het managen van services. Niet SMART.
.
Definitie 2 – “Zorg dragen voor dusdanige ondersteuning aan de organisatie en haar medewerkers, cliënten en patiënten, dat deze, gegeven vooraf gestelde condities, optimaal kunnen functioneren.” [Handboek Facility Management, 1994].
Dat klinkt mooi, maar opnieuw: geen aanknopingspunten, geen specifieke structuur, geen meetbaarheid behalve een impliciete verwijzing naar Daarmee krijg je geen grip op services. Niet SMART.
.
Definitie 3 – “De meeste facilitaire diensten worden in de vorm van een proces uitgevoerd en vinden continu plaats” [Drion & Van Sprang, 2015]
Dat is niet alleen deels onjuist (‘proces’), maar ook deze definitie geeft geen kwantificeerbare aanknopingspunten voor het managen van services; zeker omdat hetzelfde leerboek geen definities ván die processen geeft. Niet SMART.

In het vakgebied Facility Management is het dus niet helemaal duidelijk wat een service is. Dat is een opmerkelijke conclusie, waarover in een andere blog meer.

Laten we vervolgens eens kijken of het in ICT-leerboeken beter is geregeld. Neem bv ITIL:

Definitie 4 – “Waarde leveren aan de klant door het faciliteren van de uitkomsten die klanten willen bereiken zonder eigenaarschap van specifieke kosten en risico’s.” [Glossary ITIL 2011] Ooit een vagere definitie gezien? Niet SMART.

Of kijk naar een paar frameworks die daar tegen aan leunen:

Definitie 5 – BiSL. Laten we voor de zekerheid de modernste versie, BiSL-Next, nemen: “A means of delivering value to customers by facilitating the outcomes that they want to achieve. A service comprises an (1) offer from one party to another, between whom a (2) relationship exists; an (3) engagement between both parties, (4) interaction (or service act) between parties, and results in (5) output and (6) outcome for both parties. When ‘service’ is used to designate a combination of products and services, service is defined as anything that can be offered and provided to a market that might satisfy a want or need.”
Deze definitie is letterlijk uit ITIL overgenomen, en biedt wel enige aanknopingspunten voor het managen (interactie, klant-leverancier), maar smoort weer in een aanduiding van een vage “output”. Niet SMART.
.
Definitie 6 – VeriSM. De definitie van service luidt hier “Fulfilment of a defined consumer need”.
Prima, maar alweer zo abstract dat er geen aanknopingspunten in zitten, behalve impliciet in de vorm van het begrip klanttevredenheid. Niet SMART.
.
Definitie 7 – COBIT5. De definitielijst van COBIT5 schittert helaas door afwezigheid van de term ‘service’. In het boek vinden we echter wel de volgende definitie van ‘IT service’: “The day-to-day provision to customers of IT infrastructure and applications and support for their use.”
Dat komt al dichter in de buurt – zoals je van auditors mag verwachten. Concrete componenten, en een holistische benadering. Nog wel incompleet en beperkt tot IT, maar op de goede weg: COBIT levert de eerste ondersteuning van een SMART definitie.

En wat zegt de wetenschap hier dan over?

Definitie 8 – “Services are activities or groups of activities performed to produce or facilitate benefits for others.” [prof. Steven Alter, University of San Francisco, USA, 2017]
Oef…. Van wetenschappers zou je iets meer verwachten… Zeker omdat er een zeer krachtige stroming in de wetenschap opgeld doet: service-dominant logic (S-D logic), als opvolging van een stroming van goods-dominant logic (G-D logic). In die S-D logic stroming wordt gesteld dat eigenlijk ‘alles’ service is, en dat de industrie/economie een forse shift doormaakt, waarbij goederen bijna uitsluitend nog in een service-format worden aangeboden. Het is dan des te fnuikender dat er geen heldere stelling wordt ingenomen over de elementaire definitie van het begrip ‘service’. Niet SMART.
.
Definitie 9 – Van de godfathers van de S-D logic, prof. Stephen L. Vargo & Robert Lusch: “In S-D logic, service is defined as the application of specialized competences (…) through deeds, processes, and performances for the benefit of another entity or the entity itself”. [Vargo & Lusch, universities of Hawaii and Arizona, USA, 2008]
Jammer. Nog steeds niet SMART.

Om het af te ronden kijken we (en dat mag natuurlijk niet, maar toch) in Wikipedia:

Definitie 10 – “Onder een dienst verstaat men in de economie niet-fysieke goederen.” [Wikipedia]
Niet-fysieke goederen? Denk daar eens over na… niet-fysieke goederen… laten we daar maar geen woorden meer aan vuil maken. En al helemaal niet SMART.

Conclusie

Al deze hulpbronnen bevatten verschillende en soms tegenstrijdige definities van een “service”. En al die definities zijn niet concreet genoeg om Specifiek, Meetbaar, Acceptabel, Realistisch, Tijdgebonden – en laten we daar nog twee belangrijke extra criteria aan toevoegen – Bestuurbaar en Rapporteerbaar te zijn.

Hoe dat komt?

Dat is niet zo moeilijk te verklaren. Alle genoemde bronnen zijn sterk practice-gedreven. Dat betekent dat ze vooral werkwijzen beschrijven vanuit de beleving van een praktijk die ergens wordt aangetroffen. Die praktijken zijn dan weer ontstaan en niet ontworpen, al helemaal niet vanuit een eenduidige architectuur, waardoor ze incompleet en onvoldoende samenhangend zijn. dat beeld treffen we helaas overal in het werkveld van de IT en de rest van facility management aan.

En hoe moet het dan wel?

Elk probleem heeft de oplossing in zich. Daarbij geldt tegelijkertijd een belangwekkende uitspraak die aan Einstein wordt toegeschreven:

“We cannot solve our problems with the same thinking we used when we created them.”

We moeten dus op een andere manier naar het probleem kijken om het op te lossen, maar het moet wél over het object van dienstverlening gaan. Dat leidt tot het volgende.

Als we de relaties tussen klanten en leveranciers als uitgangspunt nemen voor een service, dan komt die service altijd neer op het volgende: een leverancier stelt aan een klant een voorziening beschikbaar, waar die klant voor zijn eigen business gebruik van kan maken, en die bij dat gebruik door de leverancier wordt ondersteund.
De voorziening bestaat uit een combinatie van goederen en gedrag.
Daarmee is een service eenvoudig te definiëren als “een ondersteunde voorziening”. Een kortere definitie zul je nergens tegenkomen. Dienstverlening is dan net zo eenvoudig te definiëren als “het leveren van een ondersteunde voorziening” (of als je wil: “het leveren en ondersteunen van een voorziening”).
Die service is dan te karakteriseren door z’n functionaliteit (wat de gebruiker er mee kan) en door z’n functioneren (hoe goed dat gaat), en dat geldt voor zowel de component ‘voorziening’ als voor de component ‘ondersteuning’.

En dat leidt wél tot een SMART-BR definitie van zowel service als dienstverlening… In USM is dat in één plaatje weergegeven (klik op de figuur voor een vergroting).

Wat levert dan dan op?

Als je zo’n SMART-BR definitie binnen de organisatie vastlegt, dan heeft dat tal van consequenties voor verbeterinitiatieven:

De definitie leidt onmiddellijk tot een verbetering van de afspraken over de dienstverlening. Door de afspraken in het format van die definitie onder te brengen zul je zien dat een SLA meteen helderder wordt en begrijpelijker voor de klant. Een tweede effect op de afspraken is dat de SLA meteen korter wordt: alle redundantie kan er uit worden verwijderd. Bovendien gaan alle SLA’s volgens dezelfde structuur ingedeeld worden, waardoor ze meteen leesbaarder worden.
Alle communicatie met de klant/gebruikersorganisatie kan worden verbeterd. Het wordt nu duidelijk welke interacties met dat klantdomein kunnen worden onderscheiden, en welke vorm van ondersteuning voor die interacties geldt. De alom voorkomende verwarring over begrippen zoals change, incident, service request en klacht is daarmee meteen van de baan.
De CMDB kan beter worden ingericht: de eenduidige definitie van een service leidt tot een structuurverbetering van alle services en alle informatie die daarover in de CMDB wordt opgeslagen.
De servicecatalogus (‘PDC’) en het klantportaal kunnen in lijn worden gebracht met een eenduidige definitie van de service en met de SLA-structuur die daar op is afgestemd.
De servicerapportage wordt nu snel in lijn gebracht met de verbeterde afspraken in de SLA’s.
De samenwerking tussen medewerkers, interne teams en externe toeleveranciers wordt verbeterd, omdat iedereen nu een SMART-BR specificatie van die service hanteert.
etc….

De definitie van de service heeft verregaande consequenties, maar dat had de goede verstaander natuurlijk al lang begrepen.

Toets dat maar!

Pas die definitie maar eens toe op een willekeurige dienstverlening, en je zult zien dat deze definitie altijd klopt. Of dat nou over catering, personeelszaken, gebouwenbeheer, informatievoorziening, of fleet management gaat. Dat komt omdat de definitie bestaat uit service building blocks, die in een architectuur zijn opgenomen: de servicemanagementarchitectuur van de USM-methode. Architectuur gaat namelijk verder dan alleen technologie: ook management kan onder architectuur worden gedefinieerd.

Meer weten?

Wil je meer weten…

over de effecten van een herdefinitie van het begrip service in jouw eigen werkomgeving, of dat nu ICT is of een ander taakgebied van Facility Management?
over de manier waarop je daarmee simpele en begrijpelijke SLA’s kunt opstellen of reviseren?
over de manier waarop je je services vervolgens veel eenvoudiger aanstuurbaar maakt?
over de manier waarop je vervolgens je PDC/servicecatalogus en je klantportaal veel strakker kunt inrichten?
over de manier waarop je ook je servicerapportage betekenisvol kunt maken?
over de manier waarop je je tool daarop kunt afstellen?

Neem dan eens deel aan een USM Foundation. Daar leer je in twee dagen de architectuur van dienstverlening te doorgronden, zodat je verbeterinitiatieven aan een helder doel bijdragen. Of lees het USM-boek.

Na een USM-training kijk je nooit meer op dezelfde manier naar servicemanagement…

On ITIL, VeriSM, IT4IT, ITCMF, practices and principles…

Although the interest in ITIL is declining on a global scale, AXELOS (the owner of ITIL) is still acting as before: a new version of ITIL will be launched in Q1 2019 and this new version is ready to support you in coping with the “Fourth Industrial revolution”. Quite a statement. And it’s now again identified with a number (‘4’) instead of a year (‘2019′) – something they said they wouldn’t do again…

This new ITIL version is “best practice” again, instead of just “good practice”. As AXELOS says: “Research has confirmed that ITIL remains best practice for the ITSM industry“. They know this, even before ITIL 4 has been developed and published.

This means that the announced update of ITIL was postponed at least half a year. The core elements will remain the same and all current certifications will continue to be recognized. This implies that ITIL 4 will only cover extensions. The new version says it will include practical guidance on how practices such as DevOps, Agile and Lean are associated with ITIL. But wasn’t that the claim that was already made by VeriSM, half a year ago?

And have they learned from the past? AXELOS now says they have a “Team of Lead Architects” instead of just one Lead Architect. That sounds like a reward system for the involved individuals: “I am a Lead Architect for ITIL, hire me”. And instead of a select team of senior experts, they now have “The ITIL Development Group”, covering more than 2,000 members and they’re asking for even more. Ever tried to produce a book with more than 100 participants? I can assure you that this either leads to one hell of a job, or to ignoring their contributions. Unless they simply don’t contribute, of course. AXELOS claims to already have a group of participants of >2,000, so that may explain part of the delay. Anyway, the new approach yells ‘practice’ all over.

And what about IT4IT?

Launched in 2015 by the Open Group, based on the HP & Accenture repository, it delivered a full-blown practice-based framework, like the ones we know from ITIL and COBIT. Was IT4IT the next threat to the IT market? The horribly complex ”reference architecture” seems to emphasize the vendor business model of complexity once again. Announced as a “game changer” at its launch, it is hardly heard of any more. More on IT4IT: here.

And what’s happening to VeriSM, in the mean time?

VeriSM was launched at the end of 2017, as an alternative approach, based on existing “best practices”. It immediately created a series of books, consultancy profiles, training programmes and exams – completely analogous to the business stategy of AXELOS, but with a set of business partners that was chased away by AXELOS in it’s effort to boost ITIL turnover with just one exam partner. After an overwhelming flood of attention in the first months of 2018, it seems to slow down a bit now, as people are asking the big question “what help does VeriSM bring me as a practitioner?”. The answer seems to be more in terms of “understanding how to approach and apply various existing best practices”, than in terms of providing specific support that wasn’t already covered elsewhere. This actually holds a promise of a bit more “principle” than the traditional practice-based approaches, but unfortunately VeriSM doesn’t deliver the solution with that promise: it remains with a high-level analysis of options to be used for a service management architecture, but it doesn’t deliver the architecture itself. Read more on VeriSM.

And IT-CMF, the product of the Innovation Value Institute?

Offering an integrated management toolkit, covering more than 30 management disciples, with organizational maturity profiles, assessment methods, and improvement roadmaps for each, this academic product may be considered a well-kept secret. It’s used within large organizations, it’s very practical, and it leans on more than just best practices. But again, IT-CMF offers predominantly practice support, be it on a more strategic level than the frameworks I mentioned above. Read more on IT-CMF here.

Practices or principles?

All of these frameworks still lean heavily on practices. Promoted by consultancy firms and supported by tool vendors, they illustrate a focus on where the current problems are felt, i.e. where their money is made. Solutions are always fitted into terms of provider offerings, not in terms of organizations learning to manage their own business in better ways. This approach is predominantly executable.

This is opposite to recent strategies followed in the Netherlands, where methods are gaining traction. These methods support principle-based strategies that aim for improving the control capabilities of organizations, by stimulating a self-learning path based on the understanding and application of management systems that follow a clear service management architecture. These approaches are predominantly learnable and they enable a well-considered application of a wide array of practices (from the popular frameworks).

These methods are still low in volume, as they do no provide an easy business model for supporting vendors: the focus is on improving the customer’s capabilities, and the result of that strategy is likely to end the provider’s turnover rather sooner than later. Nevertheless, more and more organizations are adopting these method-based approaches, as they obviously add value in a much simpler and more sustainable way than the traditional complexity-based offerings of the “ITIL industry”.

The method-based approaches have some very critical benefits over the traditional practice-based approaches:

The organization invests in its own capabilities, climbing up the value-based maturity ladder.
The level of control is accelerating, enabling the organization to save themselves better and better.
Services can better be aligned to customer’s requirements, as the organization is more in control of its own service delivering capabilities.
Tools can better be aligned to operational requirements, as the organization is more in control and it has more of a service management architecture in place.
It saves the organization “a bundle”, as they don’t have to hire or buy external resources at the traditional level any more.

It may be clear that – as long as vendor strategies are the dominant forces for innovation of service management strategies – only customers that have strong leadership in place, will be able to profit from these method-based strategies.

Een betere SO (SLA) leidt tot tevredener klanten en betere bedrijfsresultaten

Serviceovereenkomsten (SO’s) leiden nog steeds tot voortdurend ‘gedoe’ tussen klanten en leveranciers. De oorzaak is vaak gelegen in de gedateerde structuur van die SOA en het gebrek aan afstemming tussen de beleving van de klant en de denkwereld van de leverancier. Dat kan eenvoudig worden gerepareerd in een revisie-sessie van één dagdeel.

Overeenkomsten over de dienstverlening kenmerken zich al decennia lang als de bron van veel ongenoegen in klant-leverancier-relaties. Rapportage die het gevolg is van die overeenkomsten bevestigt dan alleen maar de kloof die tussen klant en leverancier is ontstaan. Deze situatie leidt niet alleen tot veel gedoe, maar ook tot slechtere (bedrijfs)resultaten van de leverancier.

Maturity

Zulke ‘slechte’ SO’s zijn vaak ontstaan in een jarenlange ontwikkeling van teksten, die een soort van eigen leven zijn gaan leiden, en waar niemand meer echt gelukkig mee is. Die teksten zijn dan ontstaan in een ontwikkelingsfase waarin de leverancier vaak nog sterk op infrastructuur ingesteld was, terwijl de organisatie intussen hoger op die maturity-ladder staat, en een meer klantgerichte houding heeft bereikt.

Blok aan je been

Zulke SO’s zijn contra-productief en vormen een blok aan het been van zowel de leverancier als de klant. Maar hoe kom je daar van af? De SO-teksten zijn vaak ‘in steen gehouwen’, en werken door in andere documenten, in de servicecatalogus, in de selfservice portaal, in de rapportage en in de tool. Wil je die effecten mee kunnen nemen in een eenvoudige aanpak, dan kun je je geen vergissingen veroorloven.

Duurzame oplossing

Een aanpak die tegelijkertijd eenvoudig, effectief, goedkoop én duurzaam is, is gebaseerd op de methodische aanpak van Universeel Service Management (USM). In één dagdeel leren betrokkenen daarmee niet alleen hun eigen services helder te (her)definiëren, ze leren meteen waarom dat op eenvoudige wijze kan, zodat ze die aanpak ook op andere SO’s kunnen toepassen. Daarbij worden de consequenties van een servicedefinitie in aanpalende documenten en structuren in beeld gebracht, en wordt meteen duidelijk hoe je langs deze weg meerdere services kunt combineren in één geïntegreerde servicedefinitie. Zo kan ook het serviceaanbod van een Shared Service Center helder en gestructureerd worden vastgelegd.

Neem actie

Heb je ook last van achtergebleven SO’s, en wil je die SO’s een krachtige upgrade leren geven? Neem contact op met Inform-IT, Kenniscentrum voor Servicemanagement, en leer in één dagdeel de voordelen van een methodische werkwijze o.b.v. USM te benutten.

Zelfsturende teams: vrijheid in gebondenheid

Wetenschappelijk onderzoek levert een flinke nuancering van de hype rond zelfsturende teams. Reinier Kist en Japke-d. Bouma stelden in NRC al genadeloos aan de kaak waarom zelfsturende teams vaak niet werken. Alle jubelverhalen over zelfsturing hebben steeds betrekking op nogal bijzondere situaties, waarin zelfsturing inderdaad positieve effecten oplevert. Maar de gedachte dat het daardoor overal zou werken is een volslagen misvatting.

Of zoals Mark Idzinga het zei: “Zelfsturende teams. Een schip zonder kapitein, zeg maar. Dat kan natuurlijk een hartstikke leuk experiment zijn. Maar niet mijn keuze als ik de oceaan over moet.

Een paar dagen geleden postte ik een korte opmerking over een zeer lezenswaardig artikel van Sander Denk over zelfsturende teams. Een paar dagen laten was die posting al 8.000 keer gelezen, tientallen keren geliked, en ontspon zich een boeiende discussie. Een typisch geval van ‘een zenuw geraakt’…..

Deze waarneming past naadloos in een trend die ik al jaren waarneem in organisatieverander-land: de focus moet op ‘de mensen’ liggen. Ik ben het daar fundamenteel mee oneens. Die focus moet namelijk op de mensen liggen, nadat de focus eerst op de organisatie van het werk heeft gelegen. Wie dat verzuimt komt van een koude kermis thuis. In de bekende trilogie People-Process-Technology is dus sprake van een verkeerde volgorde. Dat had moeten zijn: Process-People-Technology. Gelukkig is het in alle gevallen ‘PPT’, dus we kunnen over een paar jaar het verschil onder het vloerkleed vegen…

Als je een organisatie wil opzetten, dan begin je niet met de mensen, dan begin je met te bedenken wat voor organisatie je wil inrichten (een accountantskantoor of een kruidenierszaak), daarna zoek je daar de beste mensen bij, en ten slotte geef je die mensen de beste middelen die je je kunt veroorloven. Process->People->Technology.

Om de één of andere reden vinden de meeste organisatieveranderaars die volgorde heel vervelend: ik zie de meesten er met een grote boog om heen lopen. Ze focussen liever op ‘de mens’.

“De fase van het procesdenken hebben we al lang achter ons gelaten” zeggen ze dan…

Ze kunnen daarmee heerlijk schuilen in de schier ongrijpbare problematiek van het bijsturen van complex menselijk gedrag. Dat verhaal is gemakkelijk te verkopen aan managers die het zelf ook niet weten, en je kunt er dus een prima boterham mee beleggen. Maar het helpt niet echt om probleem van disfunctionerende organisaties blijvend aan te pakken… En de ware, eenvoudige betekenis van ‘proces’ is bij de meesten niet eens ingedaald.

Wie niet bij het begin begint, zal zich blijven herhalen.

Er zijn ruwweg twee benaderingen te onderscheiden in organisatieverandertrajecten:

de zienswijze dat mensen centraal staan, dat alles bij die mensen begint, dat alle aandacht erop gericht moet zijn om mensen optimaal te laten functioneren
de zienswijze dat de prestatie van mensen centraal staat, dat die prestatie geborgd moet worden, en dat het daarbij van belang is dat mensen daar optimaal aan bijdragen

In de eerste zienswijze zie ik organisaties die zonder architectuur, zonder fundament voor hun werkwijzen, vaak maar wat aanklooien onder het mom van ‘zelfsturing’, met het gevolg dat de organisatie als los zand aan elkaar hangt, met een eilandencultuur vooral lokale suboptimalisatie bereikt, inconsistente werkwijzen ‘hard codeert’, en het middenmanagement alle gelegenheid geeft om hun eigen belang hoger te stellen dan het organisatiebelang.

In de tweede zienswijze zie ik organisaties die duidelijke taakstellingen en werkwijzen als uitgangspunt nemen, en daarna de bijdragen van mensen daarin optimaliseren, dus vrijheid in gebondenheid.

Het verschil in aanpak heeft alles te maken met de nog immer voortdurende battle tussen Anglo-Amerikaans en Rijnlands denken, en met het moderne verafschuwen van de Tayloriaanse denkwijze.

Ik ben er echter van overtuigd dat in dienstverlenende taakgebieden, waarin de afhankelijkheid van de geleverde diensten groot is (in casu het grootste deel van de Nederlandse markt) zienswijze 2 aanzienlijk betere resultaten oplevert dan zienswijze 1, mits er een verstandige keus is gemaakt voor een service management architectuur (SMA).

Service Management Architectuur: een set van regels en richtlijnen voor het organiseren en besturen van serviceorganisaties, die er toe leiden dat je in de toekomst consistente beslissingen kunt nemen.

Zelfsturing staat voor “een andere manier van organiseren”, waarin doel en betekenis, maatschappelijke verantwoordelijkheid, gelijkwaardigheid en medemenselijkheid centraal staan (quote uit de stream rond die posting). Zelfsturing staat diametraal tegenover het rationaliteitsdenken van Taylor.

Maar is het wel zo zwart-wit?

Stel je een dienstverlener voor die aan een klant een dienst levert, waar die klant volstrekt van afhankelijk is voor z’n voortbestaan. Denk bijvoorbeeld aan een doorsnee leverancier van het type “ICT-afdeling”. Een storing van 24 uur in die ICT kan tot een faillissement leiden, of levens kosten. Wie kan mij garanderen dat met zelfsturende teams de continuïteit van die dienstverlening 100% gedekt is? En hoe is dat dan wel geborgd? Het enige antwoord dat ik daarop ken heeft toch weer alles te maken met regels en richtlijnen waarbinnen die zelfsturende teams vrij mogen acteren. Vrijheid in gebondenheid dus.

Die prestatiegarantie is steeds meer van belang in complexe productieketens en -netwerken. Als er een schakel uitvalt omdat een team – door z’n zelfsturende effecten – verzuimt de geplande bijdrage te leveren, kan de keten zomaar breken. We zijn tegenwoordig steeds meer bezig om taken te verbijzonderen. Er wordt daardoor steeds meer ‘op afstand’ gezet in complexe sourcingstrategieën. Wie het onder dergelijke omstandigheden nog aandurft een team in een keten op te nemen, waarvan je niet precies weet wat dat team presteert… die neemt wel heel grote risico’s.

Wanneer heb je dan iets aan zelfsturing?

Zelfsturing kan uitstekend werken in situaties waarin prestaties beoordeeld worden op creativiteit, of op empatisch vermogen, en ongetwijfeld in nog veel meer situaties. Het wordt een stuk minder als ‘de ander’ sterk afhankelijk is van jouw prestatie, in bijvoorbeeld technische omgevingen. In dat laatste geval grijpen we naar standaardisatie en vaak naar mechanisatie en automatisering, waarmee de voorspelbaarheid van de prestatie wordt geborgd. Zolang er sprake is van mensenwerk zal in zo’n geval vrijwel altijd worden gegrepen naar regels en richtlijnen.

Als daarbij zelfsturing een geschikte werkwijze lijkt om tot de optimalisatie van de bijdrage door teams te komen, dan is daar vanzelfsprekend alles voor te zeggen. Wie daarmee echter de borging van de prestatie onderuit haalt, maakt meteen een eind aan de vrijheid die de betrokken mensen hadden verkregen. Uitbesteden, saneren, ontslag en meer van dat soort maatregelen liggen dan al snel op tafel.

Uiteindelijk is de afhankelijkheid van de geleverde (en verwachte) prestatie doorslaggevend in de ruimte die zelfsturing kan krijgen.