On Designing Systems & Process

September 17, 2010

My thanks to Eric Brown, who graciously accepted a guest post of mine on his Technology, Strategy, People and Projects blog.

The post does a brief comparison of business processes with personal time management.

As individuals, things can fall through the cracks, ditto for business.

As individuals, rework and lost time can occur, again ditto for business.

Add Eric’s blog to your regular reading!


I was recently talking with the president of a SMB, and during that conversation he mentioned some technologies he was thinking about implementing to improve some of his internal processes.

It is a constant refrain.

Prize Ribbons

Technology Takes Last Place

Technology should be a distant last place in your considerations.

Technology is a tool that can be used by people.

A tool used by people to generate business results by following business processes.

Read these two reviews by John Caddel, and Bob Sutton referencing the same study on improving medication processes in hospitals. To quote Mr. Caddel;

I’ve seen both these situations in action: the ability of front-line personnel to understand and fix problems with the processes they use, and the effectiveness of often-overlooked simple and low-tech solutions.

The SMB Takeaway

Technology tools can help standardize, they can help speed up existing business processes. But if those processes don’t even exist right now. Don’t think (or let vendors convince you) that a software tool will be a magic bullet that can do it all for you.

You can get updates to this blog by clicking the RSS icon on the Home Page!

Photo Credit bunchofpants via flickr

The Definition Of Insanity

November 19, 2009

Can be defined as doing the same thing, the same way every time, and expecting the results to change. (try W. Edwards Demings’ red bead experiment!)

Building a process oriented business is not a set it and forget it operation. It is defining and monitoring the desired outcomes. And identifying that if a desired outcome does not happen, that you have an opportunity for improvement.

In other words, if the desired outcome fails, what can we do to reduce the risk that it will fail next time?

In talking about process, you need to look specifically at what breaks. You need to look at the why, and the how of what went wrong. Is it a people problem? A process problem? or a system problem?

(within the context of ITIL I give some samples starting in this post titled; ITIL And The SMB Part 3; Incident Management)

Although please note that you do not need to go the ITIL route to become more process oriented.

It can be easy to overlook;

When something fails, there is an associated cost. That cost could be rework, lost time, maybe even lost business. Costs can be soft as well, for example, reduced customer satisfaction.

As an example of improving process efficiency, the large package delivery companies load their trucks in a first-in, last-out manner based on the drivers delivery route. This simple step reduces the amount of time finding the correct packages for offload at each stop, and reduces the risk of missing something. And of course missing packages can negatively affect customer satisfaction.

The More Things Stay The Same

When you start building a process oriented business (not just as an IT function) there are two critical pieces to start with;

1) Define the optimum outcomes. A process is nothing without a business outcome. This defined business outcome is also the measure that you can use to improve and monitor your processes.

2) Continually monitor and improve your processes. There are always opportunities for improvement. There is an old saying in music, that the spaces between the notes are just as important as the notes themselves.

The SMB Takeaway

Like the spaces between the notes, process optimization often comes hidden in the areas as work migrates from one individual or group to another.

Improving them, or identifying why something did not work, you need to understand – you need to look at the what the why and the how of what you are trying to perform.

Was it a person error? a process error? a system error?

You can get updates to this blog by clicking the RSS icon on the Home Page!

A very humorous look at how process improvement initiatives fail by Andrew Baker at CIO Zone

Let me quote his introduction;

I started writing this blog intending to call it “Successfully introducing process improvement” but thought the opposite approach much more fun

Now you just pop on over there and read the rest!

You can get updates to this blog by clicking the RSS icon on the Home Page!


You have just reached the stage in your business where you are looking at an Enterprise class software tool for some portion of your organization. You have found that sticky notes, Microsoft Excel and plain old E-Mail are not cutting it any more.

You are looking for a tool that will reduce the amount of time that some piece of work or process takes, maybe you want to increase customer satisfaction, possibly even just track sales or service processes more efficiently because you have a huge mass of receivables greater than 90 days, most of which is because the invoice only went out 15 days ago. (It takes time to sort those shipping things out right?)

So you take the plunge looking for some tool that can help speed up the Call to Cash cycle and improve your cash flow, the bottom line, and hopefully make coffee in the morning. Maybe you really do not care if you have to run this program yourself, or pay a subscription fee and run it from someone else’s computer servers, in other words, Software as a Service (Saas)

However, while you are signing the cheque, consider this; When moving to a software tool designed to improve or support a part of your business, that software and its vendor makes the critical assumption that you have optimized your internal processes, or are planning to optimize them. Of course, your sales representative may have forgotten to mention it, or at least just tied it into a 15 minute long operational efficiency spiel that left your eyes glazed over.

In general it does not matter which process or which tool, this assumption can be the one thing that makes



or breaks what you are trying to do. Failure in looking at how you perform these tasks can either make your software tool fail completely, or be so twisted out of shape that many of the benefits you hoped for will just never happen.

The Old Process

Here is a real world example (this example will demonstrate a process as well, we can call it the Service Process). A number of years ago I assisted an organization that serviced a particular type of machinery. This machinery was located all over North America, some of it was under warranty, some under various levels of maintenance service contract, and some was just time and materials billing.

The organization had grown steadily and here was the service Process in the way we always do it around here.

1) A customer called for service, contact information and other details were captured by someone on a standard telephone message slip.

2) The message slip was then pinned to a cork message board and eventually taken by a second person who looked up billing and maintenance contract details – if details were missing or needed clarification, return phone calls would be made.

3) The message slip then went back to the cork message board to be picked up by a third person who looked up available service representatives in the customers region and then passed on the service call information.

4) The service representative performed the service, then on a weekly basis sent service slips back to head office via courier. These service slips included parts used, time spent etc.

5) The service slips would then be compared to the machines warranty, contract or billing status for an invoice to be sent, parts inventory updated, etc.

In this service process, at least 4 individuals have touched the service call for various lengths of time (time X salary) with no revenue. Invoicing and inventory control is not even possible until the slips are in and validated, affecting inventory costs, stock-outs, as well as the billing and receivables.

The New Process

Now, the software tool that this organization wanted to implement would do the following; (this would be the new service process)

1) A customer calls for service, the contact information automatically pulls all warranty, maintenance contracts or other billing material from a central database. The database presents all service representatives in that region and shows if they are already engaged on a job site or free for the service call. The free service representative gets assigned the call and is automatically notified electronically via e-mail to a cellular phone or PDA type device.

2) The service representative completes the service, and via any web browser updates the electronic service slip – including parts used, time worked etc. (backup old paper slips can still be sent weekly)

3) When the electronic service slip is completed, parts inventory is updated – invoice or warranty paperwork is generated automatically, and is ready to print and mail.

So this new process removed excess non-revenue generating touch points, improved customer satisfaction by getting service on site faster, alerted the organization of inventory issues, and has the invoice ready to go before the service representative is even out of the building!

The concept of this type of process improvement can seem simple, to see the benefit when written down like this seems to make sense. But unless you realize that this assumption is there – the “we always did it this way” beast will likely knock it off track.

The Broken Process

In the above example – need you ask?

The organization mentioned above wanted the new software tool, not to implement the “new service process” – only to automate the old service process! In other words the only tangible benefit that the software would provide would be to replace the standard telephone message slip with an electronic message slip! There would still be the same 4 individuals manually looking for contract information, or service representative availability, etc.

Trying to automate a broken process in this way will have a negative impact on cost justifying this type of tool purchase. The benefit of optimizing a process is taking the hard look at the “way we always do it around here” and seeing where that “way we do it” can be changed to reduce time, reduce non revenue generating work, and speed up results.

So before you sign that cheque, have you already looked at the “way we always do it around here” beast? Or are you willing and able to look at it? If not, you might be better off just buying more telephone message slips.

UPDATE: Another post and link on this topic is located in this Don’t Automate Chaos

Photo Credits: brent danley and Atlantic Archives

Mill Work

Mill Work

You can subscribe to this Blog by clicking the RSS feed icon on the home page!