What’s your poison – business process or services ?

When we are looking at our customers journeys, should we focus on business processes or services ? I’ll declare my hand straight away in favour of services, and attempt to justify my position in this article.

You may reasonably claim that the terms “process” and “service” are often used quite loosely and interchangeably. However, in the domain of business modelling and despite both being concerned with abstracting value-adding activity from implementation-specific constraints, I believe that the terms do have a sufficient number of different attributes associated with them to be considered independent, although very closely related.

The focus of a business process is transformation. A process takes inputs, performs operations on them and produces outputs. A business analyst will tell you that the inputs must equal the outputs – it’s a classic test of process design that nothing new can be introduced in a process transformation.

For a worked example of a process transformation (the example is in relation to developing a strategic plan) click here

The focus of a service is delivering value to the service user. ITIL defines a service as “a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.”
We might simplify this to “doing something for somebody that they value“.

So immediately we see that one of the major differences between a process and a service is in the focus: the focus of a business process is transformation, while the focus of a service is customer value.

I hold that the concept of services is a lot easier to grasp than business processes: everyone knows what we mean by terms such as good service, efficient service, a service counter, but few could tell you what an efficient business process is. So services provide a common language – a meeting ground, for business users, managers, business analysts and IT professionals. As we take a closer look at services, this ease of use becomes even more apparent:

– it’s easy to draw up a list of services that their organisation provides to their external customers and internally (we call this a service catalogue)
– the notion of service standards or service level agreements is very common for example “next day delivery” for a courier service
– we understand that a service contract specifies what I need to give you as the service user and what you will give me, for example handing in a completed expense claim and getting the money reimbursed
– a little thought takes us into other facets of servies such as quality of service (often abbreviated to QoS), covering areas such as service availability and performance; and channels of delivery, for example, over the counter, or via the internet.

A lot of the recent interest in services has come from the IT industry, with its focus on enterprise architecture and service-oriented architecture (SOA). However there is a growing group of people, whose role encompasses bridging the gap between IT and the business, and who advocate explcitly applying the principles of service orientation at the business level.

I hope that I’ve tickled your interest in service orientation enough to be receptive to further discussion, and this will be the subject of future blogs. The JISC Flexible Service Delivery programme has encompassed service orientation at both business and IT levels, and this InfoNet site provides the wider context for its adoption.