Archive by Author

Compliance to ISO: the world upside down

The old way of handling ISO standards is built on the idea that complying with requirements would deliver sustainable improvements. It does not. It only nails down the inefficiencies of your practices. Audits normally start at the side of the requirements (i.e. the practices) where they should have started at the other end of the stick: the principles.

These principles should have been laid down in a management system, but they are actually mostly missing. And no ISO standard defines a management system: even 9001 only describes requirements for a management system.

If you look at this traditional approach, you can only confirm that regular ISO auditing is the world upside down. And it does not lead to sustainable improvements.

Turn it around

You now may want to turn this around, next time you start a compliance project: you start at the principles, you define and deploy a management system based on a management architecture, and then you audit the results. Now the audit is simple and only confirms what you already knew: you are delivering your services in a systematic, sustainable way.

The cost of preparing for the auditing is then reduced to a small percentage of what it used to be.

I understand that this may violate the business model of many auditors and tool providers, but it would also open up a new perspective of value creation that would be highly appreciated by their customers, and I’m sure these customers would be willing to pay for it. Such a knife would cut at both sides: value creation in a pure format.

What do you think: is it time to turn this around?

Has architecture taken the wrong turn?

It seems that most architects are now also designers as well as developers, and spend more energy discussing and describing the technology results than discussing the principles and methods that make architecture.

In my world, architecture should start at the beginning, where architecture finds its origin: with principles and methods.

Designers then apply the architectural rules and artifacts to design the infrastructure – be it technology, management, facilities, or whatever they are working on.

Developers then develop the designs into applicable facilities, and service providers make the resulting facilities available to customers, in a sustainable way, to create value.

So many architects seem to have lost connection with the actual delivery of value in the phase of service delivery. Most of what I see is that instead of the principles, the practices attract all attention. I think this will cost us dearly.

Am I wrong? What do you think?

Make Enterprise Service Management (ESM) simple with USM

Service management is managing services.

If you want to deliver services in a systematic way, you’ll need a management system. The scope of the required management system is often a team, a department, or a business unit. Organizations that extend this scope to the entire organization, the ‘enterprise’, are therefore engaged in enterprise service management (ESM) or managing organization-wide services. The management system of such an organization then includes all parts of that organization.

Managing is organizing and coordinating resources to achieve goals effectively and efficiently. These resources are the business resources with which the organization provides its services: the people, the processes and the technology.

The management system of that service organization is what we then call a service management system.

A service management system of an organization that follows an ESM approach is then logically an enterprise service management system (ESM system).

USM: the link of your ESM system

An organization that follows an ESM approach strives for an organization-wide management system for the integrated services of all its organizational units. In order to implement this successfully, that organization must forge all contributing units (the links) into one integrated collaborative system (the chain or network) for all services of the organization. This means that this organization must have a uniform link. And that is precisely what it is lacking in practice.

A chain consisting of all kinds of different links can therefore never be an efficient and effective chain. The question now is: what is the link with which you can forge – preferably unlimitedly – all conceivable chains and networks?

The answer to that question is ‘USM’: USM provides the service management architecture with which you specify a standard service management system for any team involved in the corporate-wide service delivery.

That standard service management system functions as the uniform link with which you can construct an ESM system at will for your own integrated service organization: the LEGO building block for management.

How do you set up your ESM system?

First of all: not by first choosing a tool and then thinking that you are putting together an integrated management system. Practice has taught time after time where this leads: not much good. The logical way is the other way around: if you determine the scope of your ESM system as ‘all components of the enterprise’, you will first have to design each of those components as that one, uniform link with which you want to forge your ESM chain or network.

This means that you first teach the teams involved to work according to one organization-wide, uniform management system: the LEGO building block of management. Only then you can support that chain or network with a shared tool. And if you then think you still need to reorganize the organization, you probably have done something wrong … Organizing is optimizing, but if you already have the policies and the tooling fully integrated, it makes little difference how you set up the organization.

So a smart approach to enterprise service management begins with adopting the LEGO building block that USM provides, then selecting a workflow tool that demonstrably supports the management system, and finally – if still worthwhile – optimizing the organization for the new policies.

ESM versus supply chain and network management

The integral management of the services of all teams within one enterprise is similar to managing many suppliers in a supply chain or network: ESM is still the same. In both cases the question is how we define a link in a system: whether that system is one organization or a network of organizations … the key question is always how we turn it into one well-oiled machine.

In all those cases, the solution is ‘chain technology’: which link can you define to create every conceivable composition? The answer to that question is USM, the standard management system for every service organization, the manager’s LEGO.

If you want to learn more about USM, download one of the free e-books on USM.

If you want to be inspired by ITIL v3 or ITIL 4, learn how you make a success of ITIL 4.

“Service”: 100+ horrifying definitions

“Any idea what a service is?”

Just imagine you don’t have a solid answer to that question. Or imagine that different answers are given within your organization…

How would you respond to the following question:

“And how do you think you will manage your services?”

Anyone who does not have a clear answer to the first question or (as a consequence) to the second question, would do well to think about this subject. But let me warn you – it’s a bumpy road ahead…

Facility Management

In the search for a SMART definition of “service”, we might start with the field of Facility Management, where services should be core business.

IFMA’s FMpedia, the free online glossary of facility management terms, doesn’t even provide a definition of “service”… the only term that approaches it is “Service delivery: The process of getting facilities-related services, such as planning, design, operations, maintenance, and work order processing, to a tenant or customer. See also project delivery.” The IFMA fails here big time.
Perhaps the latest ISO 41000 standard Facility Management will help us. ISO 41011 contains the Facility Management Vocabulary and tells us “Service: time-perishable, intangible activity performed by an entity”. Very incomplete, focusing only at the human interaction. Fail.

Textbooks

Perhaps the textbooks used in FM education will help us out. Take for example the leading textbooks “Facility management” that are used at the colleges of higher education in the Netherlands, for the Facility Management courses:

Service Management, An Integrated Approach [Gemmel c.s., 2013], a leading textbook by the Service Management Centre of the Vlerick Leuven Ghent Management School says “producing definitions of services is not an easy task”. After looking at definitions of various scholars, they conclude with the following definition: “Service: all those economic activities that are intangible and imply an interaction to be realized between service provider and consumer”. This denies services in non-economic environments, or services that are only partly intangible. In short: a very limited definition, and definitely not SMART.
Facility Management [Maas & Pleunis, 2006] tells us “Services are processes and consist of consecutive contacts between customers and suppliers” and “A service is a human interaction that unfolds in the here and now.”. Again a very limited view that says that services are human activities. Not operational. And not SMART.
The Facility Management Handbook [1994] says “Service: Provide support to the organization and its employees, clients and patients in such a way that, given predetermined conditions, they can function optimally.” That sounds nice, but again: not operational, no specific structure, no measurability except an implicit reference to customer satisfaction. Again: not SMART.
Basisboek Facility Management [Drion & Van Sprang, 2015] doesn’t provide a single definition and says “Most facility services are performed in the form of a process and take place continuously.” Not only is that again incorrect (“services are process”), but this definition also is not operational; especially because there are no definitions of those processes provided in the same textbook. The definition focuses on the human activity component of the service. And again: not SMART.

In the Facility Management field, therefore, it is apparently not entirely clear what a service is. That is a remarkable conclusion that I will elaborate on in another blog.

But there are many more definitions. For example in IT, where IT Service Management has a long history. Would any one of the definitions in ITSM indeed be SMART? And what would that mean for your organization? Read on…

So what about IT?

Let’s see if IT textbooks do any better, starting with the popular IT Service Management framework of ITIL:

ITIL says “Service: Delivering value to the customer by facilitating the outcomes that customers want to achieve without ownership of specific costs and risks.” Ever seen a more vague definition? Not operational. And definitely not SMART.

Maybe a framework for Business Information Management does better:

BiSL may offer a solution. To be sure, let’s take the latest version, BiSL-Next: “Service: A means of delivering value to customers by facilitating the outcomes that they want to achieve.” This definition was largely copied from ITIL, therefor again: not operational and not SMART.

Maybe some of the other popular frameworks provide a better answer:

VeriSM says “Service: Fulfillment of a defined consumer need”. Sounds great, but unfortunately very abstract, not operational and definitely not SMART.
COBIT 5’s glossary unfortunately shines in the absence of the term “service”. In the book, however, we do find the following: “IT service: The day-to-day provision to customers of IT infrastructure and applications and support for their use.” That is getting closer – as you might expect from auditors. Concrete components, and a holistic approach. Still limited to IT, but on the right track.

COBIT provides the first indication of a SMART and operational definition.

But what about science?

What does science say about this?

Service systems theory. A frequently publishing professor in that discipline writes the following: “Services are activities or groups of activities performed to produce or facilitate benefits for others.” [Steven Alter, 2 University of San Francisco, USA 2017]. Ough. You would expect something more from scientists … Certainly because there is a very strong school in modern science: service-dominant logic (S-D logic), as a follow-up to a goods-dominant logic (G-D logic). In this line of thought it is stated that “everything” is service, and that the industry/economy is going through a major shift, with goods being offered almost exclusively in a service format. It is all the more astonishing that no clear statement is made about the elementary definition of the term “service”. It only describes the activity component of services. Definitely not operational and not SMART.
S-D Logic then? Let’s see what the godfathers of the S-D logic, Stephen Vargo & Robert Lusch, tell us: “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, 2008]. A rather unfortunate version of the activity-focused definitions we’ve seen before. And still not SMART.

To top it off (and of course that is not allowed, but still) we look for a definition in Wikipedia:

Wikipedia says “A service is defined as non-physical goods in the economy.” Non-physical goods? Think about that … ‘non-physical goods’ … let’s not waste another word on that. Too silly to take serious. And again not SMART.

Perhaps other standards will help?

Perhaps the ISO or IEC standards help us out to get more grip on the definition? Well – if you have the courage to plough through 100 ISO and IEC definitions, please be my guest. These sometime horrifying definitions – provided by an organization that should have a serious track record in terms of standardization…. – include variations like ‘result of activities’, ‘capability’, ‘output of an organization’, ‘product’, ‘activities’, ‘system’, ‘output’, ‘functions’, ‘means of delivering value’, ‘supplies’, ‘beneficial performance’, ‘specific behavior’, ‘software’, ‘information stream, etc. etc. Again: horrifying and unbelievable inconsistent.

Conclusion

All of these resources contain different and sometimes conflicting definitions of ‘service’. And all those definitions are not Specific, Measurable, Acceptable, Realistic, and Time-bound or – and let’s add two more important additional criteria – Manageable and Reportable (SMMARRT).

How is that possible?

That is not so difficult to explain. All the sources mentioned are heavily practice-driven, even the academic sources that might have been expected to be more theoretical. This means that they mainly describe routines based on the experience of a practice that is found somewhere. These practices have emerged and were not designed, certainly not from a clear architecture, which makes them incomplete and insufficiently coherent.

Then what to do?

Every problem has a solution, but we should first and for all follow Einstein here:

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

So we have to look at the problem from a fundamentally different perspective. That can be done by means of the methodical approach of USM (Unified Service Management). USM defines a service management architecture that is built on principles instead of practices.

If we take the relationship between customer and provider as a starting point for a service (everyone agrees on that), then a service always comes down to the following:

A provider makes a facility available to a customer.
The customer uses this facility for his own business.
Using that facility, the customer is supported by the provider.
The facility is always composed of a combination of goods and actions.
The service can be characterized by its functionality (what the user can do with it) and by its functioning (how well that goes), and that applies to both the “facility” component and the “support” component.

This leads to a new and extremely simple definition of service, and the shortest one you’ll ever find:

A service is a supported facility

Service delivery can then be defined as simply as “the provision of a supported facility” (or if you prefer: “the provision and support of a facility”).

And that does lead to a SMMARRT definition of both service and service management…

Just test it…

Apply that definition to a random service, and you will see that this definition is universally correct. Whether it’s about catering, human resources, building management, information provision, fleet management or anything else. The definition consists of service building blocks, included the service management architecture of the USM method (Unified Service Management, or if you prefer: Universal Service Management). It is operational, in the sense that it provides leads for the specification of all components covered in the definition, making it ultimately SMMARRT – as demonstrated in USM.

Do you want to know more?

…about the effects of redefining the concept of service in your own organization, whether that is IT or any other Facility Management discipline, or even your primary business activities?
…about the way you can draft or revise simple and comprehensible SLAs?
…about the way you subsequently make your services much easier to manage or too report?
…about the way you organize your service catalog and your customer portal much tighter?
…about the way you can make your service reporting meaningful?
…about the way you can adjust your tool accordingly?

Then read the free e-book on USM: download it here.

Once you’ve done that, you may want to look one step further. E.g. how to make a success of ITIL 4 (or any other ITIL version), using USM.

You may even want to embark on a two-day USM training, to understand the architecture of service management, so your improvement initiatives consistently contribute to a clear goal and you learn how to deploy any combination of best practices.

After USM you’ll never see Service Management through the same eyes…

[Editorial comment, March 7: one of the responses in the many discussions that emerged from postings on this blog, led me to add the following comment……….. There is only one thing we define as ‘water’, but there are many flavors of it. Nevertheless, water is always H2O. End of story. Whatever ITIL says. Whatever any practice or infrastructure expert says. Ergo: service is service, but there are many flavors. The question I analyzed in my blog is the question “What is a service in terms of its fundamental structure, its ‘H2O’ composition?”. The answer was as simple as the H2O definition of water: “A service is ‘a supported facility’, no more, no less”, a universal definition that can be applied to any context where a provider delivers a service to a customer (the origin of the term service).]

The CIO Office and the PMO are dead… long live the SMO!

A Project Management Office (PMO) is a well-known organizational structure for managing projects. In recent years, Service Management Offices (SMOs) have also been emerging. What is the difference? What is similar? Can the one coexist with the other? And where does that leave the CIO Office?

The management of services requires an overview of all services and supervision of the way in which the services are provided. A Service Management Office (SMO) is a team that deals with that overview and supervision and ensures optimum coordination between the needs of the customer and the achievements of the service organization (‘business-IT alignment’, BITA). The SMO acts as a centralized management team or a Center of Excellence (see the image above this post).

The task of an SMO

The SMO’s main concern is governing the organization’s services – not providing the governance but overseeing the management, in the sense of coordinating the managerial aspects of service delivery. As the separation of duties requires that governance and management are not part of the same team, the governance will reside with another team.

An SMO can encompass strategic and tactical activities, but it can also include the coordination of operational tasks of – e.g. – the Service Desk. With far-reaching outsourcing, the SMO acts as a coordinating demand-supply organization.

The SMO brings together the responsibility for overseeing the service delivery from different perspectives and at different levels. In this sense, the SMO is the binding factor for the coherent governing of that service, at the strategic, tactical and operational levels.

This puts the SMO at the crossroads of governance and operational management.

Such an intersection already exists in the form of the highest rank in the IT service organization: the IT director or the CIO who is accountable for all tasks and achievements of the service organization. With the SMO, the accountable manager is provided with a device that puts flesh on the bones of managing the service. The SMO, therefore, takes over part of that accountability. A RACI then demonstrates in detail to what extent and for what details the SMO is responsible.

Every task area in an organization can set up its own SMO. Combining multiple task areas in one integrated SMO is then the next step to Enterprise Service Management.

The tasks of the SMO potentially cover a broad spectrum of activities:

the service management strategy
the service management architecture
supervising the training of all employees regarding their knowledge of policies
managing the functionality of the workflow tool
initiating improvements in services and in the management system
a wide range of operational tasks of the service manager, the quality manager, the Service Desk and others

The extent to which an SMO actually provides for all these tasks varies per organization. An SMO can therefore also have a limited task, with only part of the tasks listed.

Example. The Contract Management (CTM) process involves setting up and maintaining agreements with customers and suppliers. The most important profile for these tasks is the service manager. That profile can be ‘divided’ into sub-profiles that contribute to the achievements of CTM tasks, e.g. the purchaser profile. A broad SMO includes all these profiles. In a somewhat narrower SMO, the profiles of the purchasers reside with a separate team.

The CIO Office

Part of the service management tasks is often already housed in a CIO Office, not just the strategic part, but also tactical and operational management tasks. The same CIO Office often also houses a number of governance tasks – a risk in itself.

One of the biggest problems with these CIO Offices is the distance to the workplace. A CIO Office has a tendency to get involved in ‘important’ (strategic) matters. These are often issues that fall under project, program, or portfolio management. Or even better: under ‘digitization of the business’ or another fashionable phenomenon. Such a focus on technology change is often at the expense of the core task of IT: sustainably supporting business tasks with the help of appropriate information processing facilities.

An organization that accommodates the tasks of such a CIO Office in an SMO thus establishes the connection between the strategic and the tactical/operational tasks of the service provider. The result is that the organization will be placed more firmly on the ground, and thus better meet the practical needs of the business.

Such a combination comes with a warning: from the perspective of segregation of duties, it is important not to place too many tasks in one hand. Within an SMO, care must be taken not to mix specification and realization of IT services. It is important that the specification of required services stays the responsibility of a team that represents the business, leaving the realization to the SMO. That rule already applied to all other situations and organizational structures, so there is nothing new under the sun.

The Project Management Office (PMO)

Process-oriented organizations that have a Project Management Office (PMO) and want to set up an SMO can integrate the tasks of the PMO into the SMO. After all, project follows process – or rather workflow.

This way a project-based approach is part of the regular process-based approach. Projects do not exist alongside processes but are ways to execute activities in processes. Projects should only be used if the approach adds value, compared to a non-project approach, and as long as the project does not affect the agreed services in a negative way…

The majority of the service organization’s activities is not executed as a project.

Apparently there are criteria to be met before a project approach is selected. We all know what these criteria can be:

high cost
a lot of complexity
many organizational units are involved
etc.

Each organization determines its own demarcation line for selecting a project approach for an activity. All projects fit into the process-based management system of the service organization. The SMO ascertains that the organization’s achievements are aligned with the services that are agreed with the business. Project managers are simply staff from existing teams. An organization that frequently applies projects can then assign the qualified resources to one dedicated team. This team provides project managers upon request, but always within the process-based management system.

The need for a PMO is now gone.

A process-based organization that sets up an SMO therefore no longer needs a PMO. In fact, the focus on services reduces the concept of a project to a useful instrument – to support the services. But the customer and the continuity of services are now core and not the change that is related to projects.

This post is based on USM – the Unified Service Management method. USM enables process-oriented organizations to adopt a thorough service management architecture and a standardized service management system. USM is owned and managed by the SURVUZ Foundation. Details are available on the USM portal.