As you know, we build a lot of sales processes, here at Ballistix.  You may not know that we build almost as many customer-service teams, inside-sales teams, pre-production teams and even small project teams (in knowledge-based environments).

The work we do in these non-traditional (for us) environments is very gratifying and, often times, generates enormous payback for our clients.

So that just started me thinking.  Can I generalize from our approach to the sales environment — and from the work we do in other environments — to come up with a general approach to process improvement?  My plan is not to write the book on process engineering (others have done that); rather, it’s to provide a step-by-step method that you can implement with your notebook computer in one hand, a coffee in the other, and look of gleeful masterly in your eye!

Here’s that method; in five simple steps.

1. Define the goal and necessary conditions

What is the goal of this environment?  And what are the conditions that must be met in order for your achievement of that goal to be valid?

Sadly, answering these questions does not really power you forward.  However, they must be answered because the answers provide the context required to answer all the other questions you’ll encounter as we work through this process.

So, if you’re building a customer service team, your goal might be to: resolve customer issues rapidly.

Necessary conditions might include: the maintenance of sufficient protective capacity to ensure resolution times are within customer tolerances and the avoidance of unnecessary expenditure.

Nothing too fancy here!  Just the basics.

2. Map it

This is the fun bit.

You’ll need a copy of Microsoft Visio (Google: Visio free trial) or a sheet of graph paper and writing implements.

The trick here is knowing what to chart.  You want to map a high-level workflow only.  You’ll know if it’s high-level because:

  1. You’ll only need three symbols (an activity box, a state (input/output) circle and a connector (line)
  2. The workflow will be linear: no loops or recursions
  3. Everyone involved will complain that it’s too simple

Here’s an example of what the finished result will look like.

[click image to view full size]

2. Division of labor

You saw this one coming!

As part of creating the workflow, you should consider division of labor (who does what?).  You can see in the image above, that each role as been assigned a swim-lane.

Generally speaking, you’ll multiply productivity by:

  1. Eliminating multitasking
  2. Having specialists perform work that corresponds with their expertise

However, you need to balance the theoretical productivity improvements with some practical concerns:

  1. The possible cost of additional personnel
  2. The multiplication in process complexity as the number of hand-offs increases

Here are the general guidelines I use:

  1. Split activities that are obviously dissimilar (technical drawings and booking flights, for example)
  2. Split activities that are performed in the field from those that are performed in the office
  3. Split pure telephone work from clerical work (for example, rather than having clerks chase the pre-requisites required for their work, have a dedicated phone person who manages pre-requisites)
  4. Split work that requires high-level decision-making from pure-vanilla work

More importantly, you should consider which resource in your team is likely to become the constraint (bottleneck) as volume increases.  You should focus your attention here first.  For example, if you are processing mortgage applications and you have a person with specialist knowledge who has the potential to be a bottleneck, consider routing all plain-vanilla work (and phone work, etc) around this person.

Also, bear in mind that some people are specialist generalists.   In other words, they add value by being across a lot of stuff!  Managers fit into this category — as do customer-service representatives.  So be careful not to kill the goose that lays the golden egg.

4. Centralize scheduling

It’s here that you earn your keep!  If there’s one defining characteristic of EVERY process we build at Ballistix, it’s that we always have a dedicated process coordinator.  A person whose sole responsibility is to coordinate the workflow — but who is not actively involved in any of the core activities within the workflow.

I would go so far as to suggest that you don’t have a process until you have a person who’s sole responsibility is to keep the wheels turning day after day.

In our traditional (field) sales environments, this person is the sales coordinator.  A person who sits behind each salesperson and who operates essentially as that person’s Executive Assistant.  In an inside environment (customer service, inside sales, pre-production, etc), we’re more likely to have one person coordinating a larger team.  In many cases, this person will also take responsibility for pre-requisite management (see earlier discussion).

Here are the activities a coordinator would typically perform:

  1. Chair daily (or twice-daily) work-in-process (WIP) meetings
  2. Determine case (job) and task priorities
  3. Overview the general operation (flow) of the environment
  4. Ensure data integrity (accuracy and currency) in your CRM and/or ERP
  5. Manage management-information system (see next section)

In most cases we recruit young, smart, sassy graduates to fill coordinator roles.  Generally, you don’t want an engineer in this role.  In fact, it’s better to retain an engineer to design the environment so as to ensure that you don’t need an engineer to coordinate it!  Of course the design of a robust environment is exactly the subject of this article.

5. Management-information system (MIS)

You know what they say: if you can’t measure it, you can’t manage it.

Well, I wish they wouldn’t say that.  This maxim is often interpreted as an exhortation to measure everything.  And if you measure everything, you’re measuring nothing.

What I mean is that no data is bad, but too much data is just as bad.  What we need is information.

Eli Goldratt defines information as the answer to the question asked … and I like that!  It means that rather than starting with measurements, we should start with questions.

Here are some questions that I think should be answered in every environment:

  1. When should I release work to the team (if you release work as it appears, the team will certainly multitask itself into a total logjam within days!)?
  2. What completion date should I quote for this case (and be confident that it will be delivered on time)?
  3. When must I expedite a case to ensure its on-time completion?
  4. When should I avoid the temptation to tamper and leave well alone?
  5. What is the load on all team members?
  6. When the flow is disrupted, what is the most common cause of that disruption?

Now, obviously, this list is not exhaustive but these answers are, to my mind, the critical ones.  So, do you think the standard reports in your ERP or CRM are designed to answer these questions for you?  Of course not!  Those reports are designed to satiate the noisy measure everything brigade.

So, you need to build your own MIS.  Two ways to do it:

  1. A physical, production-style buffer board
  2. A fancy, electronic business-intelligence system that generates real-time reports from the data sitting in your CRM/ERP’s data-store

Let’s talk about the first option.

You want a board that represents time and capacity (we’ll just work with two dimensions for now!)  We’ll track time on the horizontal access with TODAY on the far left and X-DAYS on the far right (where x is the maximum lead-time of a healthy case).  So time moves from right to left — just like you’re on a train, looking out the window. The vertical axis is designed to limit the number of cases that can occupy any one time-slot.

The coordinator creates a magnetic card for each job.  Each card contains the list of tasks within the workflow.  Cards also have stickers attached — where each sticker indicates a pre-requisite.  At regular intervals the coordinator moves all jobs one time-slot to the left — to indicate the passage of time.  Additionally, stickers are removed as pre-requisites are collected and tasks are checked as they are completed.

We would generally complement the buffer board with an Excel workbook that auto-generates the cards — and that enables the coordinator to track the completion dates of key milestones so that we retain a rudimentary history of jobs once they leave the board.

Here’s an example of a client’s buffer board.  Pretty? No.  Effective? Definitely!

[click image to view full size]

So how about the second option?, I can hear you asking.  Can’t it be electronic?  We so like electronic.

Well, yes it can and, in some environments (high volume, high complexity) it has to be.  But electronic costs real money.  And another disadvantage of electronic is that it tends to be less visible — less accessible.  We resolve this in some environments by displaying key metrics on plasma screens … but now we’re talking even more money!

To create an electronic MIS, you build the reports in Excel (our drug of choice), Crystal Reports, Cognos or similar.  You then integrate the reports with the data from your CRM or ERP (or often both).

Of course, with electronic, if you can dream it, you can do it … but this tends to create as many problems as it solves.

Following are some samples of some of the prettier reports that our clients’ MIS’s contain.

[click images to view full size]

The best advice I can give you with respect to the design of the MIS, I’ve left until last.

Don’t start by designing the reports, start by designing the WIP meeting.  That’s right, determine the questions that you must answer, in what sequence to have a fast, productive, daily (or twice-daily) WIP meeting and then design your MIS to deliver the necessary data in exactly that sequence.

These five steps cover a lot of ground, but I think they’ll provide a valuable framework for your next process-improvement initiative.  If you’d like me to fill in some gaps, use the comments link at the start of this article to ask questions.