Service management systems are IT's online face to the business. Sure, enterprise apps and personal productivity tools may be how users get their jobs done, but when someone in sales or marketing has a problem or needs something, they turn to the IT service system for satisfaction.

They're often disappointed, leading to dissatisfaction with IT in general and widespread use of informal systems. Left unchecked, this unfriendly face can lead to elevated service resolution costs, extended cycle times, and frustration within IT itself, all the while leaving end users convinced that IT isn't a suitable business partner.

Meanwhile back in IT, a process-based revolution has been declared. ITIL succeeded in defining IT service management processes in standard fashion, while shining a light on the need to become process-based. Activity-based approaches, ad hoc approaches, and disconnected silos are now properly frowned upon.

At the executive level, CIOs know all this and also know that their ongoing costs in rigid 20th century service management systems are a disproportionately expensive part of their portfolio. Expensive, unfriendly and rigid is hardly a formula for success, especially for a system that literally defines IT in the minds of the vast majority of IT's customers.

This untenable situation has led to the increasingly widespread adoption of cloud-based IT service management (ITSM) offerings. These 21st century services help with the cost issue and are superficially helpful in presenting a friendlier face to the business. But they often suffer from rigidity and a failure to embrace true process automation.

The better approach is to orchestrate IT service management, whether delivered via SaaS or on-premises. Orchestrate? This means to automate ITSM processes in a way so they become transparent, configurable and connected. Orchestration leads to dramatic improvements in cycle time, compliance, adaptability and accountability.

And friendliness. Because a friendly face that fronts a flexible and accountable IT operation is a vital precursor to IT success.

Process-driven
Processes are the connective tissue of enterprises. IT service processes - in particular - connect users to support, support to operations, and ops to apps.

IT service processes are often disjointed. This may be because they start off small and then need to scale, or because they can't flexibly adapt to shifts in the business. Whatever the reason, disjointed processes are hard to speed up, hard to audit, hard to improve, hard to scale and hard to modify.

Orchestrated processes are automated, transparent, configurable and connected. Orchestration leads to dramatic improvements in cycle time, compliance, adaptability and accountability.

World-class IT service - like any world-class service operation - must be process-driven. It cannot function effectively as a set of related activities. Rather activities must be directly linked, triggering action from resources on a demand-driven basis.

The requirement to be process-driven has direct implications for the architecture of an Orchestrated Service Management system. An OSM system must be first and foremost a process automation system, pulling work items through a process in an intelligent manner.

This contrasts with the architecture of traditional ITSM systems - both on-premise and from the cloud - which are fundamentally designed as systems-of-record, with rudimentary alerting and state change capabilities sufficing for process automation.

A true process-driven system is built around a workflow engine. In the case of OSM, the ideal architecture marries a core workflow engine with more classic system-of-record capabilities, such as deep lookup and item tracking. The latter is important for CMDB purposes in particular.

Classifying ITSM Systems
Four of the five characteristics described below drive down an Orchestrated Service Management (OSM) system's total cost of ownership. These include attractiveness (by readily increasing adoption), trustworthiness (by supporting process improvement), ITIL out-of-the-box (by working right away), and most especially DIY flexibility (by slashing the cost of ongoing adaptability).

However, the primary defining characteristic of Orchestrated Service Management systems is that they are process-driven.

Given that the characteristics of OSM systems are that they are inherently low TCO and that they are process-driven, we can compare and contrast them with other classes of ITSM systems.

The three classes of ITSM systems other than Orchestrators are widely used today, mostly as legacy applications. Toolkits such as Lotus Notes or BPM platforms allow the creation of at least rudimentary ITSM functionality, albeit at the price of high TCO. Behemoths such as ERP-like help desks suffer from not being process-driven and from high TCO. Ticket Takers are also off-the-shelf products from an earlier era. Though inexpensive, they are not process-driven and so provide limited value-add.

Cloud-based systems generally sit between Behemoths and Ticket Takers, offering relatively low TCO at the expense of limited flexibility and poor process automation.

DIY Flexibility
Things change. Level 2 support moves from Chicago to Dallas or to Bangalore. A key application gets sent to an outsourcer, or brought back in from an outsourcer. A division of the corporation gets divested, or acquired. A new executive decides to adhere to ITIL at a higher level, or to pursue Lean strategies, or both.

Changes should be easy to instantiate in an ITSM system, even if it is cloud-based. Flexibility isn't enough, since the cost, risk and time required to change the workflow; data model and reporting of the system are typically too high to support the level of change that most organizations experience.

What's needed is flexibility that a non-technical administrator can drive on her own. Think of it as Do It Yourself Flexibility. This DIY approach parallels the DIY movement in other areas of the endeavor, allowing a person who is knowledgeable about what he wants to accomplish to get it done without having to retain a specialist.

For a process automation system like Orchestrated Service Management, DIY Flexibility requires in practice a visual composition environment to make changes to workflow rules, the UI, forms and data, etc.

The litmus test for DIY Flexibility is the avoidance of procedural code or scripting. If an editor must be opened to alter procedural code or script, the cost, risk and sophistication required to make a change skyrockets.

Further, system design must be maintained in the database by the system. Thus the workflow, data model and UI are all perpetually updatable, as are ongoing changes made by the DIY administrator.

Importantly, this visual composition and metadata management approach allows for easy upgrading to future versions, avoiding the huge upgrade costs endemic to traditional ITSM systems.

Conclusion
The ITSM system should not be a major financial component of any CIO's portfolio. The fact that it is so in so many shops is a relic of the ERP economics of legacy systems. At the same time, the ITSM system should advance the cause of making IT a friendly and supportive partner to the business.

Orchestrated Service Management - whether delivered from the cloud or on-premises - provides a new approach to ITSM that addresses this challenge by marrying a process-driven architecture to low TCO. CIOs who want to focus their energies and budgets on revenue-generating and cost-reducing initiatives for the business would be remiss to not seize this opportunity.