Monday, November 10, 2008

Understanding Workflow

In the first post, Collaboration Reformation, of this series on collaboration and workflow, I made the statement about the transformation of collaboration from resources to activities. It is worthwhile looking at activities, or more accurately workflow, specifically before moving on to further discussion on collaboration and workflow.

Workflow is essentially a series of discrete actions that when group together produce a desired outcome. The obvious example is a manufacturing assembly line. A series of actions such as screwing on a door and adding an engine are arranged together in a line in order to assemble a car. Manufacturing assembly lines are obvious but don’t become hooked on the assembly line example. Workflow is simply a series of discrete actions performed together to achieve a goal. The goal can easily be the development and roll out of new features for a web service as it is the assembly of a car.

Goals can range from a product or service (say a car or a massage) to something more intangible (say increasing support for a candidate). For most of the post I will focus on the product and service goals but it applies equally to intangibles as well.

Workflow can be broken down into three categories: operational, development and overhead. Operational is the workflow that delivers the goal. Development is workflow that is necessary to create, improve or fix a goal. Overhead is workflow necessary to keep the organisation and group going in order that it can achieve the operational and development workflow. There is overlap between the three categories of workflow and you can represent it as a Venn diagram.

The workflows necessary to complete a goal are unlikely to be fully contained within a single group. A car maker doesn’t make the bolts or wires that go into a car. Toyota recognised this which is why The Toyota Production System works to coordinate workflow in suppliers not only within a Toyota plant.

Each workflow is made up of lots of different actions. Optimising an action without consideration for the workflow de-stabilises the whole workflow and produces counter-productive results. It is no good having one action of a workflow produce more than can be processed by downstream actions. In “The Goal” Goldratt provides a series of good examples of what happens when optimising a single action versus optimisation across the workflow.

In the next of this series, we’ll look at how optimisation can be achieved and look in more detail at how collaboration platforms are a part of this optimisation.

Reblog this post [with Zemanta]