“Out of the Box” (OOTB), is a phrase often coined by ITSM toolset providers and by customers implementing a new tool.
We often get asked by customers to review IT process maturity. Our assessment methodology covers not only the core ITSM processes, but the underpinning IT Service Management (ITSM) tools, organisation structure, governance and suppliers involved in the IT operating model.
We also help customers with their ITSM tool selection project, helping to define requirements, engage with service providers and manage the selection and procurement processes. Read our Top 10 tool selection tips and tool implementation considerations for more advice on these areas.
When looking at the ITSM toolset, we often find:
- Customers “version locked” into a toolset that they are unable to upgrade due to the extensive customisations they have undertaken.
- Customers who have moved to a new toolset, only to configure it an identical way to their current toolset, therefore replicating the issues that caused them to move to a new toolset on their new toolset!
To overcome these challenges, customers moving to a new toolset often state unequivocally, “We will adopt an Out of the Box configuration”.
Read on to discover:
- Does an “Out Of The Box” configuration really exist?
- What does it look like?
- What does it mean to your processes and ways of working?
Configuration or Customisation?
All ITSM tools will require a level of personalisation and initial configuration, to load base data such as locations and users, as well as to create business rules, such as resolving team assignment rules, prioritisation, risk assessment and service targets. By “configuration” we’re referring to the configuration of organisation’s processes workflows into the toolset.
It’s also important to differentiate Configuration from Customisation. Customisation refers to the introduction of new features to the toolset, which are generally unsupported by the vendor, and achieved through coding of new capabilities within the toolset’s back-end systems.
What does an “OOTB” configuration mean?
OOTB makes assumptions about a number of ITSM tool capabilities:
- The basic workflows contained within the toolset will be adequate to meet the needs of the organisation
- The organisation will be following generally accepted best practices in ITSM, such as those described in ITIL. In most organisations this is true, however, I have come across some cases where the organisation have created their own process models which are not closely aligned with the ITIL ideals
- If the OOTB workflows differ from those currently used by the customer, they will be able to easily adopt them, and adapt existing processes and ways of working to OOTB model
- The organisation will be able to bring about the relevant cultural changes necessary to ensure adoption of the new processes, particularly where these affect end-users
It is true that the basic workflows provided by the service providers within their toolsets are fairly simple in nature. These might meet the needs of some customer environments but will require further configuration if they are to meet the needs of organisations with any level of process or organisational complexity.
Examples where configuration would be required are in the areas of technical and business approvals for changes and requests. Commonly, the logic behind this workflow is complex and will seldom be met by a one-dimensional approval model commonly found in many tool’s OOTB configurations.
So, should we ignore claims of OOTB configuration by toolset vendors?
I think a level of pragmatism is required. I think it is delusional to expect a fully OOTB implementation as a level of configuration is inevitable. However, this shouldn’t prevent prospective ITSM toolset customers looking for implementation accelerators, such as process models, data models and templates. These should be implemented where it is possible to do so. It is vital that these are understood as a base-level of configuration, which will be adapted over time, to meet the needs of the organisation. After all, the barrier to the implementation of many ITSM toolset is adoption by its users. This will only be exacerbated if the users are presented with a toolset that does not adequately reflect existing ways of working, or worse still, represents a step backward, or fails to facilitate the automation of common tasks.
I strongly believe that tools automate processes. Tools should not exert too much influence over processes and ways of working. We should configure tools to automate processes as much as possible, but not at the expense of adoption and usage of the tools.
Once implemented, ongoing evolution of the toolset is inevitable. However, care must be taken to ensure appropriate change control over the toolset, to prevent customisations being implemented which introduce version-locking issues, over complication and high maintenance overhead.