Archive by Author

The wrong end of the stick: rules vs. principles

ICT regulators and controllers tend to follow a rule-based approach. Although – if asked – they soon enough admit that they actually don’t believe it is the right approach. They would love to see their target audience being so well organized that they can stand up to any test. They know that a rule-based approach starts at the wrong end of the stick. But still – they always start at that end. Makes you wonder why….

Healthcare

Healthcare institutions are increasingly facing tough demands in the field of information security. In practice this is often expressed in terms of ISO27001 controls. Dutch healthcare regulators use a local standard, NEN7510, which is almost identical to ISO27001. In 2010, the regulators decreed that all healthcare institutions had to meet a subset of 33 controls, out of the full set of 125 controls in NEN7510. This NEN standard was recently updated to follow ISO27001:2013, but the set of controls used for healthcare institutions is still largely the same.

In their audits, the regulators didn’t demand hard scores, instead they emphasized that the organization should rather be able to show that they were systematically working towards a better score on the selected controls. In fact, the regulators stimulated the institutions to improve their quality in a methodical way, so that they would improve their assessment score in the next audit. In practice however, they are still auditing against the same set of controls. This approach is now stimulated even further, because the full set of NEN7510 requirements was recently promoted to law for any healthcare organization using the unique citizen registration number in their systems.

Finance

This approach is very similar to what is currently happening in the financial world: in the Netherlands, that sector is also sampled by means of a (self) assessment. The supervisor in this case is the Dutch national bank (De Nederlandsche Bank, DNB), and the controls they use are derived from COBIT, enriched with guidance from ISO27002. But the situation is essentially the same: a control-based approach (rule-based) does not lead to the desired result. Instead, banks, pension funds and insurance companies should turn to a quality management approach that produces the desired information security assurance inside-out.

In the mean time, healthcare institutions have learned to achieve at least maturity level 3 (CMMI), with a methodical approach based on the ISM Method, within a year, and level 4 is within reach shortly after. Not by following a rule-based approach, but by means of gradual improvement. “Old wine in new bottles, PDCA, been there, done that….”. The standard response. But when you look at the daily practice of our most elusive experts, with all the certificates you can think of on their wall, they always start on the rules end of the stick, using best practice guidance from sources like ITIL, COBIT, ASL, BiSL, and other frameworks. Hey, and why not? Nobody ever got fired for hiring an ITIL consultant, or a COBIT consultant, or ….

Dot on the horizon

The essence is that the road to information security is not walked by trying to start at the controls end of the stick – whether there are 33 or 125, they still represent tricks. And the real trick is that you should turn it around: if you manage to teach the organization an integrated and systematic way of managing their work, you are leading them to a dot on the horizon.

“If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.”

This is ‘ancient wisdom’, words spoken by Antoine de Saint Exupéry. Each seriously educated expert must have heard that line before. Nevertheless, consultants are taught to apply best practices to their clients, and they honestly believe it’s the best they can do for them. But best practices are the result of (hopefully) a systematical approach that can (hopefully) be replicated in the environment of their clients. And you cannot start with results when improving the structure of an organization: you cannot start at the wrong end of the stick. They should focus on finding the approach that delivered these practices, and then replicating these practices by using that approach – or at least by teaching the organization to work with the approach.

Dots on the horizon will be changing all the time, but walking the road to the horizon will largely stay the same.

The method

The method Dutch organizations have learned to use is the ESM Method – Enterprise Service Management, developed in 2005. ESM is a method to get in control of any type of service organization, or any combination of service sections in an organization. The information management domain has proven to be a very grateful domain for ESM, because organizations had to gain ultimate control over their IT services, as a result of the ever growing dependency on IT. The IT specific application of the generic ESM Method was called the ISM Method: Integrated Service Management. In practice, ESM was applied to various other service domains, including the “business information management” domain (where it is labeled FSM – Functional Service Management), and to combinations of IT and other service sections (e.g. medical technology, education), where the term ISM or ESM was used.

In IT organizations, the ISM Method focuses on the management system (the engine), and on the turnaround the management and staff need to make to adopt a systematic approach to their work. In a standard ISM introduction project it takes 13 weeks to get all (existing) instruments in place in a fully standardized project, and then 6-9 months are spent teaching the organization to apply the method and to get used to a systematic step-by-step improvement approach. External consultants can coach the organization through this project, but a do-it-yourself approach is also often used, based on the book The ISM Method.

The results of the ISM Method are attracting lots of attention: organizations can achieve improvement goals (like ISO27001 or COBIT controls) in shorter times and at lower cost then before – and the results are lasting. Tool providers, consulting organizations, game developers, and trainers in the Netherlands are now adopting the method to create a new market; one with a much better cost/benefit ratio for their customers.

The big turnaround

The major advantage of starting at the other end of the stick is that you invest in an efficient and effective systematic approach, that can be applied again and again in a cyclic improvement strategy – as Shewhart and Deming taught us half a century ago. The new IT world is full of that approach, but only as long as it concerns technology: SCRUM, LEAN, DEVOPS…. It’s about time the management consultants join the bandwagon and pick up what Eliyahu Goldratt wrote down on the Theory of Constraints.

And following a rule-based approach is not what Goldratt, Deming and Shewhart meant.

In the Netherlands, the first finance organizations now work on their management system from a systematic inside-out approach, starting at the other end of the stick – even though their regulators confront them with rules to be followed and controls to be achieved – preferably by the letter, if you believe your auditor. Within a year they grow 2 levels on a 5-level maturity scale. Their road is the same, even though their dot on the horizon will differ.

Banks, insurance companies, pension funds, hospitals, nursing homes, care clinics, most of them still need to make the big turnaround to a systematically assured quality management. Luckily, they all aim for the same (improvement) and they all can use the same trail to their dot on the horizon following a standardized methodical approach that saves time, money, and worries. But the biggest advantage lies in the simplicity that it buys you. If your ‘inside’ is put together well enough, it doesn’t matter much what stick they use to measure you.

ITIL, or rather ITSL, or even ITSML?

Should ITIL change its name from IT Infrastructure Library to IT Service Library? Or should the M for Management be added to it, to cover ITSML, IT Service Management Library?

The statement that ITIL would only be about infrastructure management and used by infrastructure service providers is a fundamental misunderstanding. ITIL has been about service management from day 1. It describes practices and – to some level – processes and generic procedures that are commonly used for delivering IT services. And yes – there has been a focus on the IT component of the services for some time, but it has always been in the context of service management. So the I for Infrastructure, in ITIL, is no more than a historical artifact from a time that the difference wasn’t perceived so heavily.

In the Netherlands some competing – or rather complementary – frameworks were developed, reusing ITIL practices: ASL and BiSL. The ASL framework – the Application Services Library – added guidance for the specific domain of application management, copying a lot of generic content from ITIL. This again illustrates ITIL’s lack of focus on technology and infrastructure, and emphasizes that it has always been a service management framework. ASL adds value to ITIL, adding guidance on application management, but it also overlaps with it and it doesn’t cover the full extent of ITIL’s primary domain: IT services. Both ITIL and ASL are based on best practices, and require an implementation management method. The Dutch also provided that: the ISM method – Integrated Service Management – a generic method to implement ITIL and ASL guidance, in a standardized way with a predictable result.

Another Dutch framework, BiSL (the Business Information Services Library), also added value to the scope of ITIL by providing guidance on what we now use to call “business information management”, a domain that is only very partially covered by ITIL. This framework originates from a specific view that is unique for the Netherlands. I’ve visited many countries and always inquired the way people look at this domain, but I’ve never found it in any country but the Netherlands. It is based on the Separation of Duty principle in the information domain, as first applied by prof. Maarten Looijen in the late eighties. If you want to learn how this principle had led to the domains where ASL, ITIL and BiSL are finding their positions as best practice frameworks, describing activities in the various domains, I advise you to read the SAME Model (free download). Once you understand the nature of the two domains, you can immediately see the value and the position of the three frameworks mentioned above:

ITIL describes the service management practices of an IT service provider in the information supply domain
ASL describes the service management practices of an IT service provider in the information supply domain focused on application management
BiSL describes the practices of a service provider in the information demand domain.

In spite of this historical head start, the third domain is still not completely professionalized in Netherlands. It still lacks well known organization structures that deliver easily understood contributions to the information services in an organization. Most of the support for this domain – like in the supply domain – is limited to best practices. And best practice frameworks act as reference models rather than implementation methods. So this again requires an implementation management method to bring the guidance alive and working consistently. As can be expected, The Dutch provided that too, in the FSM Method (Functional Service Management), similar to the ISM method.

So the elements seem to be there to profit from the valuable guidance in ITIL and its companions. But shouldn’t we first rename ITIL to ITSM or even to ITSML?

SLA or BLA? Or would you prefer ISA?

A posting in one of the many ITIL groups at Linkedin said “Service Level Agreement vs. Business Level Agreement. There is an new trend where for definition of value and benefits of ICT for business is considered BLA instead of SLA. In other words measuring of ICT performance by real business achievements and goals fulfillment. What’s your views and experience on this area?”

The question illustrates how IT organizations still deliver technology “services” instead of business values. And they all talk about business IT alignment, customer focus, etc….

Some of the responses even said that you should never agree on a BLA at all, only use an SLA according to ITIL. That only confirmed my statement that most IT organizations are still technology focused, and haven’t mastered the services level, let alone the customer level.

The initial question in the forum is justified. ITIL simply doesn’t cover this, and we need better practices. But practices should always work within a conceptual model of reality. That’s where this goes wrong.

The initial question could easily be answered with “BLA is what the SLA should have been all the time“. But then you only say that ITIL practices are not really current best practice. And on itself, that doesn’t help you any further.

Imho, a much better approach is this:

information support for business processes is a responsibility domain
to gain control over such a domain, separation of duty is the most elementary instrument
this leads to 2 separated domains. Let’s call them Information Management (IM) and IT management (ITM). Adding the term ‘business’ would be meaningless, because we already confirmed that all was created on behalf of ‘business’.
the chain of command runs from left to right in these domains: Business => IM => ITM
the BLA should cover the relationship between Business and IM; the SLA should cover the relationship between IM and ITM.

You now have three separated domains with very clear responsibilities that can be managed in a systematic way.

The described approach is very common in the Netherlands, although only few organizations really have their IM and BLA in place.

In the Netherlands a standardized systematic approach is available in the form of the FSM Method. It supports the application of a Dutch standard set of best practices: BiSL. FSM is a standardized method for designing and improving IM organizations. The BLA is defined in the FSM Method as the ISA, the Information Service Agreement. The SLA is what ITIL defined as such, but in this model the SLA is limited to the relationship between IM and ITM. Note: the “who” is not relevant here. Whoever executes the responsibilities, be it an internal team or an external provider, doesn’t change the nature of the responsibilities.

Tools to support the management of IM organizations can easily be made available, as they fully resemble the tooling for the ITM environment, or any other service domain. And we have many hundreds of tools that compete in the “red ocean” of the ITM domain, even a huge number of open source tools.

The BLA, or rather the ISA, should indeed cover meaningful business terms for the information support that is delivered. But that requires quite a higher level of “value maturity” than most of the providers have in practice. In fact, only very few will even have slightly approached this level in their practice. There’s still a long way to go if we want to deliver real information value to “the business”.

More info:

the SAME Model describes the three domains. Free download at the ISM Portal
the FSM Method is document only available in Dutch, but there is some documentation in English. FSM fully aligns to ISM (dedicated to the ITM domain), so the ISM bookok actually covers this to a large extent

ITIL process templates – a contradictio in terminis?

On a regular base, I run into people looking for “ITIL process templates”. In fact, if you Google for that, you can find an entire market for that product. I still am kind of surprised that this is even possible. Aren’t they all making a fundamental mistake?

ITIL is a set of practices (it says so on page 1). Practices are the results of processes, aplied by people, using products, describing how services can be delivered. So – if you’re looking for a process model, you should look for something that is beneath ITIL.

The ITIL books do offer content that approaches process descriptions, but you can’t create a solid process model from these components, as they also contain procedure and work instruction details.

Overlooking this, it seems that you’ll have to choose from these alternatives:

You apply what you can find in ITIL, and accept the fact that these are not really processes. The inefficiency that comes with it is then accepted.
You develop your own process model, then map selected ITIL practices to these processes and create your management system.
You adopt a process model that is already developed; then you map selected ITIL practices to these processes and create your management system. Watch out! Several companies are offering “ITIL process templates”, which is a contradictio in terminis. They actually offer workflow-like descriptions that belong in option 1.
You adopt a management system that contains a predefined process model; then you target selected ITIL practices with the management system.

Organizations that want to follow a process-based management structure should spend serious time on designing their management system. Sadly, most organizations still follow the common option 1, which is one of the main reasons why they get the traditional result that comes with most ITIL projects.

But hey – nobody ever got fired for hiring an ITIL consultant 😉

SSC versus MDSU: Shared Service Centers versus Multi-Disciplinary Service Units

A phenomenon I’m regularly running into is the SSC, the Shared Service Center. It is an initiative based on the desire to profit from the economy of scale, when two or more organizations are sharing some common, comparable services in a single organization unit. We see this for instance with small municipalities that are confronted with upscaling initiatives: they more and more tend to create SSC’s for their IT services, often as a first step towards an upcoming merger. We also see it for facility management, e.g. in industrial compounds, where energy, heating, and network facilities are set up and shared between organizations of very different nature.

In terms of economy of scope, I now see more and more initiatives within a single organization. E.g. in hospitals, we now see the ‘merger’ of various disciplines into what I tend to call MDSUs: Multi-Disciplinary Service Units. In hospitals, these MDSUs can combine disciplines like IT, facility management, and medical technology. All of these disciplines are similar in terms of being supporting service disciplines. The scope of these initiatives is in practice often limited to disciplines that tend to have similar cultures, being very much aware of their nature as a ‘supporting act’. Other in fact supporting disciplines like Finance or Human Resource Management are still keeping this off, continuing their existence as isolated silos. In time, we may see these disciplines join the bandwagon, once the others (the first movers) have proven the positive effects of their initiatives.

What are the most appealing benefits of these initiatives? Well, first of all, they share costs. This means that the initiative is cutting cost. Which, on itself, would be a good thing. But at least as important: they standardize their activities by accepting the fact that they are very similar. This stimulates standardization, which is one of the most effective and well-known ways to improve performance (for operational excellence). Third, and most important, the initiative improves the one and only goal of its existence: the customer experience.

Customers (users) benefit because they now do not have to take responsibility any more for differentiating their support issue between the various involved disciplines. They can simply call a single support number and explain what they want. The call often is picked up in a support unit that is responsible for the first contact, the one we tend to call help desk or service desk. We already were getting (slowly) aware of the fat that for IT services we actually shouldn’t bother the user with the task to differentiate between change request, incident calls or service requests (in ITIL terms), because these three were actually only representing our internal efficiency as service providers. I’m now seeing that this phenomenon is going to expand into other disciplines: the MDSU acts with a SPOC (a single point of contact) for various supporting disciplines.

The biggest lesson to be learned from this: all of these supporting disciplines have one and the same structure for managing their individual services, and their services can be combined for reasons of economy of scale as well as economy of scope. They can all use the very same help desk tool (“service management tool” if you prefer), to manage their activities and their services, and profit from service management principles they’ve developed during their existence. Which again opens a great opportunity for saving cost and improving quality the very same time.

This is where standardization offers its maximum benefits. It’s good to be living in the Netherlands, where we can experiment with these developments and improve “service management” to deliver the best possible benefits for the customer!