Archive by Author

Architect, blijf bij je leest!

Architecten zijn in de praktijk vaak bouwers, ontwikkelaars. Dat zijn dan dus slagers die hun eigen vlees keuren. Waarom beperkt een architect zich niet tot zijn primaire rol: het ontwerpen en beheren van een set regels en richtlijnen die bijdragen aan consistente resultaten? Die architect kan dan vervolgens bewaken dat die uitgangspunten goed worden gevolgd dóór de bouwers en dat zij het beoogde resultaat op een verantwoorde manier bereiken. In plaats daarvan zie ik veel architecten zélf de specificaties van het bouwwerk opstellen én uitwerken. Als ik dit aan een architect voorleg, is de reactie vaak: er is niemand anders die dan de principes volgt. Maar moet je dan toch zélf gaan bouwen? Is het medicijn dan niet erger dan de kwaal?

Nu kan ik me heel goed voorstellen dat het veel zelfbeheersing vergt om je te beperken tot die architectenrol. Het is voor architecten domweg heel erg verleidelijk om je met de uitvoering te bemoeien: dáár gebeurt het immers… Maar functiescheiding is al eeuwen de meest effectieve interventie voor controle. Juist door uit zijn eigenlijke rol te stappen, haalt de architect het vloerkleed onder z’n initiële taak vandaan.

Voor ‘enterprise architecten’ geldt dat in nog sterkere mate. In de eerste plaats is 99 procent van deze architecten helemaal niet bezig met enterprise architectuur, maar met enterprise informatiesysteem architectuur. Daarmee kapen enterprise informatiesysteem architecten een compleet vakgebied. Daar kan ik nog mee leven als ze een lichtend voorbeeld zouden stellen voor de architecten van andere taakgebieden. Maar kijk eens hoe ze de wereld modelleren. Vanaf midden tachtiger jaren is er een vloedgolf van ‘enterprise’ architectuurmodellen over ons uitgestort, die – op een enkele uitzondering na – vooral werden gekenmerkt door vlakken- en lagenmodellen met aspecten-assen. Die aspecten varieerden mét het model. Had een auteur een nieuw aspect bedacht, dan werd dat aan zo’n as toegevoegd, en húp… weer een nieuw model.

Kijk maar eens naar PRISM, Zachman, SABSA of naar TOGAF. Gelukkig waren er ook uitzonderingen die geen aspecten-assen hanteerden maar structuur-assen. Dat begon in 1993 met het Strategic Alignment Model (SAM), van Henderson en Venkatraman. Dit model werd de basis van duurzamere architectuurmodellen, die ook structuur-assen hanteerden. Denk aan het in ons land veel gehanteerde negenvlaksmodel: een duidelijke combinatie van twee structuur-assen.

In dat licht is het weer verbazend om te zien hoe de Nederlandse overheid voor haar referentiearchitecturen nou juist een vlakkenmodel presenteert dat tóch weer een aspecten-as bevat (check de NORA-site). Dat dringt vervolgens door in de van de NORA afgeleide referentiearchitecturen in tal van andere branches: denk aan de GEMMA, de ZIRA, de HORA, de CORA, DIZRA enzovoort. Wanneer leren we het nou eens een keer? Aspecten – de speeltuin van veel architecten – zijn nooit de grondslag voor duurzame oplossingen.

Des te wranger is de conclusie dat het nou juist de architecten van deze wereld zijn die ons hiervoor hadden moeten behoeden.

Deze blog verscheen ook in ICT/Magazine.

PadBK – de nieuwe pandemie

We doen het allemaal. Jij doet het. Je buurman doet het. Je collega’s doen het. Je familie doet het. Je adviseurs doen het. Je hebt het zelfs op school van je docent geleerd. PadBK – Poetsen aan de Buiten Kant. We doen het al decennialang. Wereldwijd. Je mag het met recht een pandemie noemen.

Met de komst van ITIL en andere best practice frameworks hebben we drie decennia lang geleerd om vanuit de praktijken van anderen onze organisaties en werkwijzen in te richten. Een heerlijke markt voor leveranciers, met slechts één smaak: best practices. Niemand die nog uit zichzelf éérst begint aan de binnenkant. PadBK.

Met de komst van de Enterprise Architectuur modellen hebben we vanaf de zeventiger jaren geleerd om vooral op basis van aspecten te denken, en niet op basis van structuur. En dan ook nog wisselende combinaties van aspecten, die in de toevallige belangstelling van de auteur van dat model stonden, denk aan Zachman of TOGAF. Een nieuw EA-model bedenken was dan niet moeilijk meer: je bedacht gewoon een paar andere aspecten, en – hup – weer een nieuw model. PadBK.

Met de komst van de referentiearchitecturen hebben we ook geleerd de praktijk van een branche als uitgangspunt te nemen. Met de komst van de Omgevingswet moet de VNG nu het hele GEMMA-‘procesmodel’ van de gemeenten herzien. PadBK.

Met de komst van verbetertechnieken zoals SixSigma en Lean hebben we geleerd om  vooral de uitvoering van onze werkzaamheden efficiënter te maken – denkend vanuit die uitvoering. PadBK.

En als we een rapport moeten schrijven of een serviceovereenkomst moeten opstellen, dan gaan we keer op keer een eerste concept becommentariëren, aanvullen, aanpassen, bijsturen, enzovoort, totdat het in de ogen van iedereen álles bevat wat nodig is, en een onleesbaar dik document is geworden. De Nederlandse overheid moet dan een landelijk project (‘Direct Duidelijk’) starten om de burgers te laten begrijpen wat die ambtenaar nou eigenlijk wilde zeggen.

Het is dus een pandemie. Eentje waar de meesten zich echter totaal niet van bewust zijn. Je wordt er immers niet zichtbaar ziek van… De ziekte heeft zelfs symptomen die voor menigeen wel prettig zijn: je verdient er vaak een goed-belegde boterham mee. PadBK.

Waarom is het dan tóch een ziekte? Omdat al dat Poetsen aan de Buiten Kant niet bijdraagt aan het thema waar tegenwoordig iedereen de mond vol van heeft: waardecreatie. We zijn druk met van alles, maar het draagt netto maar bar weinig bij aan het beoogde doel.

Is er dan een vaccin? Jazeker. En dat kun je zelfs in je eigen keukentje brouwen. Gewoon niet Poetsen aan de Buiten Kant, maar beginnen bij …. Het Begin. Het recept? Simpele, logische uitgangspunten nemen, en dan consequent daaraan vasthouden zodat je efficiënte en consistente resultaten bereikt. Probeer het eens. Het is even wennen, maar dan héb je ook wat.

Deze blog verscheen ook in ICT/Magazine.

Framework mapping – a toy for consultants

And here it comes again: a long discussion on LinkedIn on the mapping of practice-based frameworks. Meaningless. Waste of time. A toy for consultants. And never a conclusion.

There’s no dispute on the value of those practice-based frameworks (in this case ITIL4 and COBIT and IT4IT). They all provide valuable inspiration. But the idea that mapping these frameworks would ever deliver anything but just another framework is quite naive.

And yes – it will keep the consultant off the streets, as they will always have some new details to ignorant customers, or some new technologies to incorporate in the framework. But it never delivers a sustainable solution.

The fallacy here is that this mapping only involves two derivatives. And mapping of a derivative is only meaningful if you map it to a source. Mapping 2 derivatives therefore is only meaningful if you map these to the same source.

The whole exercise of mapping ITIL4 to ITIL v3 or to COBIT or to IT4IT or to any other practice-based framework is therefore a waste of time – or a toy for consultants. Have you ever seen a sustainable solution that resulted from such a mapping? I haven’t… it only delivered another framework….

The most revealing comment in the LinkedIn discussion that caught my eye was this one:

“It’s complicated 😉 “

And that’s the only conclusion that I’ve ever seen from this kind of mapping.

Tool selection: blindfolded or new spectacles?

A few days ago, the LinkedIn group [ITIL & ITSM tools] showed an interesting post:

“I am looking to replace the existing ITSM tool being used in my organization. Looking forward for some suggestions.”

As can be expected, several group members came up with the usual response. They named their favorite product. Except for two comments, everyone seemed to ‘just answer’ the question – as usual. This is exactly the reason why organizations want to replace their tools again and again. They think about the problem “from the tool” instead of “from the goal”. Even the two commenters that asked for the requirements – instead of just naming a product – were at risk of falling for the same trap. Imho, these answers will not really help the issue of the organization, which (I hope) is “finding a sustainable solution for supporting our daily work in delivering our services”.

It’s not about the tool!

A more sustainable answer might take a different approach because the tool itself is far less important than the management system that it is supposed to support. Without the information about that management system, any answer would simply miss the point.

Navigating blindfolded

Unfortunately, most organizations are rather unaware of this: they do not have an explicit management system at all, so they’re just ‘doing their best’. Most likely, they use guidance from best practices as their main strategy. These organizations are doomed to work ineffectively and inefficiently, never reaching a high level of maturity. It’s like they select their tooling blindfolded.

New spectacles

Organizations that do understand what their management system looks like, can easily find a simple and cheap solution for the initial tooling question. They see clearly what support is needed, and what the product requirements actually are. They can avoid the pitfalls of the usual offering from tool suppliers (i.e. complexity based on a modular offering) and create a simple and cheap solution.

Organizations that are not already fully aware of their management system’s role, may want to use some new spectacles, so they see more clearly and avoid the usual pitfalls. With new spectacles, they can learn that their service management tool should not require more than 2 modules, supporting only 8 standard workflows, to deliver the actual support they need. Seeing through these new spectacles could save them a lot of effort, time, and money, but above all: it could seriously improve employee satisfaction.

New thinking

These new spectacles are based on the new thinking of USM – the Unified Service Management method. USM is complementary to the usual approach of adopting and adapting best practices from popular frameworks. USM is based on principles, offering an organization the opportunity to lay down a solid and sustainable fundament below all the practices they select, adopt, and (hopefully) adapt to fit their management system…

Following that approach is opposite to what happened in the LinkedIn group. With USM, you think first and act later, a strategy that seems to have been lost throughout the tooling industry, or at best – is largely limited to thinking about a set of technical requirements.

New spectacles for a better future

If you want to try and see how these new spectacles also fit your organization, you may start with attending a free online introduction: a 2-hour workshop, demonstrating how the new thinking of USM simplifies your challenges and provides you with a simple but very effective management system. Once you’ve done that, you may find your way into the free resources that the SURVUZ Foundation makes available for user organizations, providers, trainers, and education institutes, and you may see your future much clearer.

Why user errors are not incidents

Case 1: A user reports “I lost my password, can you reset it for me?”

Case 2: A user reports “I lost the key to my locker, can you get me a new one?”

Case 3: A user reports “I made an incorrect entry in application X, and now my data is corrupted, can you fix that?”

Numerous internal and external service providers treat these cases as incidents, as failure reports. They perform the required actions, register the request as a failure, and report on it neatly in service reporting.

Why is this wrong? The failure is fixed, right?

The fallacy

Every request from a customer/user can be traced back to a wish, an RFC, an incident, or a service request (or it is communication within a previous call). The nature of the request determines the interaction type, within the context of the agreed service.

The assumption to handle the above cases as incidents is based on the perception:

  1. that the customer is entitled to support
  2. that there is a failure in the functioning of the facilities made available
  3. that there is, therefore, a shortcoming in the actions of the service provider
  4. that the service provider must therefore repair the situation at his own expense

In all three cases, point 1 will be answered positively, otherwise, the service provider should not have taken action at all. In all three cases, however, point 2 fails, and as a consequence also points 3 and 4 fail.

After all, there is no failing of a facility: on the contrary, they function as agreed. The user cannot get into the secured application or the locker – and that is exactly the intention. In case 1 and case 2, the service agreement apparently contains an agreement about security. Unauthorized users are not allowed to access secured resources (the application, the locker). Thus, the facility is functioning correctly and therefore there cannot be a failure.

Both cases are therefore examples of user errors, as is case 3.

The Solution

In all three cases, the user wants to be supported. To ensure that this happens, the right to this support must first be agreed upon. This is done in the service agreement, the SLA.

As soon as it is agreed in the SLA that a facility will be secured (cases 1 and 2), the customer and supplier must also agree on what happens if the user makes an error (i.e. losing the key). The solution is simple: the supplier should provide additional actions (“provide additional password/key”). The costs for these extra actions should then be laid down in the SLA. Logically, the customer will have to pay extra because the customer causes the extra actions.

The same applies to all other user errors. Customers and providers must agree in the SLA which support the provider will provide if the customer makes an error that leads to extra effort and how the extra costs will be settled.

Practice shows that numerous user errors are registered and handled as incidents. Those situations detract from a proper customer-provider relationship and lead to errors in the provider’s performance evaluation and in service agreements.

Those who follow the simple logic of the USM management system can easily discuss those situations in service negotiations, and then handle them easily and correctly.

If you want to learn more about a simple, systematic, and methodical way of solving issues like these, you’re invited to a free online workshop. The SURVUZ Foundation now provides these workshops on a regular basis (2 per week), to cope with the overwhelming interest for the new thinking of USM for Service Management Architecture, and for Enterprise Service Management. A workshop takes 2 hours and is a very intensive activity. Starting times will be alternating 09:00 CET (to accommodate the eastern hemisphere) and 15:30 CET (to accommodate the western hemisphere).

If you want to catch up on what you didn’t learn at school, 2021 is the year to do so. As we aim for small groups to foster discussion in the interactive workshops, registration is required. You can register at the USM Portal.