Want to Drive Process Transformation? Start Bottom-Up

Adopting a bottom-up ‘service orientation’ perspective can make things easier for business process reengineers, developers and users.

This approach sees the enterprise as an interconnected group of services requesting and delivering work to each other and encourages managers to start talking to other teams, functions and departments.

Rather than wholesale re-engineering or that one-size-fits-all approach pushed by vendors, service-orientated architecture implements pragmatic tools at the work-group level and focuses on improving existing organizational structures.

To get started, you’ll want to make sure you’re doing an analysis of the system as it actually is. Going after an ‘ideal system’ without first knowing what currently happens will only lead to arguments you can’t win.

Define the Boundaries of Your Service

You’ll want to think in terms of services rather than departments or functional groups: look at the way you work, the activities involved, who your customers are and how the work flows.

Analyze demand and capability by asking what work is requested of their service and what is their performance for delivery. This can sometimes be difficult in a complex knowledge work environment.

Describe work item types by answering the following questions:

• What are your sources of work requests? (Who makes requests and how? For example: email, call, comment in a meeting?)
• Are there different business or technical issues that cause some work items to have different work flows?
• Do some work item types have different dependencies?
• Do some work item types require different skill sets to complete?

For each work item type:

• Make columns -- arrival rate (how many per day/week/month etc.)
• Understand demand -- random, seasonal, burst (large batches), planned or unplanned, anticipated or not. Can you refuse the work? What are customer expectations? ASAP? Should you drop other work? Does other work take priority? What kind of scale, complexity or granularity?
• Model the work flow -- what are the steps the work goes through to get completed?

Metrics:

• What is the overall duration from request made to you and acceptance or delivery after completion?
• How long does each step take? Are there delays after work has finished one step before it starts the next?
• How frequently is finished work sent back, such as customer returns, test failure, or other defects?
• How many items are delivered ‘late’?
  
  

Start Designing the System

You might see different work types essentially go through the same work flow and treated the same, while others may go through the same work flow, but are treated differently -- for example, they always get put aside for other more urgent work.

Now that you see the work flows think of steps to remove, combine, or add for better tracking of dependencies. Propose these changes in a visual way to help others within your service boundary, and also to convince your customers.

It’s important to involve others in starting any improvements to make sure you’re not missing something, passing burdens onto others, and to get the most support for the best solutions.

Guest post by Kintone partners and management consultants Shinka Advisors.