Get those processes out of your socks!

Last summer I was building some sand castles with my son. At a certain moment I looked down and there, at the bottom of my skinny white legs, I saw two size 12 feet, doing their best to get burned in the sun.  As I have those feet quite a few years now, I wasn’t really surprised by that view.

But suddenly my toenails drew my attention. Ten toenails that I’ve had all my life. I never thought about ‘m consciously.  Because they never caused any problem.  And that made me write this “Procesje”.

Toenail wise, I’m lucky.  So now and then I cut my toenails when I take a shower. And when I feel them stinging in my shoes very sporadically, I might give them some attention.

But I’ve heard other horror stories.  Unguis incarnatus, Onychauxis, or removal of a nail without any sedation.  Brrrr. 

Nice Emiel, but what has this toenail-talk to do with processes?  Quite a lot I think, because;

• Processes originate during the birth of a product or service.

•  After that, processes will keep  growing. Unnoticed.

• This often goes together with a decrease in Process awareness.

• Processes only get attention when they “hurt”.

• That’s why it might be smarter to check the condition of your process so now and then.

The birth of a process

Like we get our nails at birth, a process is born at the launch of a product or service. Because, as you know, a process is a means to deliver a product or a service.  A product or a service that hopefully solves the problem of a customer.

At the birth of a process, a lot of things need to be taken care of. Think about answering (and implementing the answers) the following questions.

• What needs to be done (workflow)?

• Who are capable to do that?

• What supplies are needed for that?

• What information is needed for that?

• What supporting tools do we need to acquire?

• To what rules of third parties do we need to comply?

And then it’s time to get to work. That’s the most important of course. As long as processes are not executed, customers are left empty handed.

Processes continue to grow

After a first process launch, you often see that attention to the original process design decreases.

Of course the work is done.  And when something is not going so well, you might see some adjustments. People leave, people come.  Maybe some citizen developers add some fields on an electronic form.

In short; in a drive to help customers, several aspects of a process keep growing. Possibly unrelated and unseen.

Process Awareness disappears

As long as process keep growing and nothing bad happens, I’ve seen often that also the process awareness in organization disappears.

People are just doing their jobs and the people who were part of the “birth or the process” might be gone already. That’s just what happens in organizations.

Is that bad? As long as things go well, who am I to say that you need to be process aware?

But unwanted things can happen

Suddenly customers start to complain. Suddenly the market seems to be more interested in your competitor’s products or services. Employees get sick. Some kind of inspection knocks on your door. The auditor doubts if he should prolong your ISO certification. And some shareholders are not so happy with the financial results.

Things start to hurt. What to do? Restructure? Fire people? Cost savings?  Panic!

Strangely enough, I’ve seen the above happening quite some times. So, wouldn’t it be smarter to get your processes out of yours socks so now and then? To trim them a little bit when they are not hurting yet?

Check your processes so now and then

Probably nothing new you would expect from a process freak, but regular process checks can prevent panic actions like the above, I think.

Like I expressed in my story about BPM cycles, checking processes can happen on different levels.

1. On Strategic level where you check the usefulness of the process (so, actually the product or service)
2. On Process design level where you check if the process performs as designed
3. On Casemanagement level, where the progress of all cases in the process is checked
4. On Case level, where the progress of an individual case is checked

Applying all levels brings peace in processes

Setting up all these levels of “process checks” isn’t easy.  Many times I’ve seen it been limited to level 2, where so now and then the performance of a process is audited.

I know it’s not my business, but I think a little more attention can prevent you from improving useless processes. Or from being too late because you start improving when customers already decided to call your competitor.

Al these levels of “checks” together is what I would call “Managing by process”.  I think it will create peace in processes:

• Reassurance for a customer that her/his case gets individual attention

• Reassurance there is enough flexibility to manage all cases currently in the process

• Reassurance that  when a change of the process design is needed, you don’t keep on tweaking the process ad hoc. 

• Reassurance that your processes deliver useful products or services

So, get your processes out of their socks before they start to hurt. 

Happy processing!

Effectiveness, Productivity and Efficiency; just a more with less discussion?

You would not expect it in 2017, but during my process work I still run into discussions on the difference between effectiveness, efficiency and productivity. And of course what of those three is the goal of process improvement efforts. 

To explain how I see these terms, I always use my kitchen garden as an example.  I thought it would be nice to share that story. 

Effectiveness: Delivering the right result.

So, I have a kitchen garden in which I grow several vegetables. Although it’s just for fun and relaxing, I have some kind of goal in mind. 

My goal is to provide my family with fresh vegetables for 3 months per year.

That's what I could call my desired process result and goal: sufficient vegetables for 3 months per year.

And it seems to work. My way of working and allocation of resources are effective; I get the desired result out of my proces(ses).

That's what effectiveness of processes means to me: The processes deliver what I promise. 

Efficiency: Same result with less effort

In my opinion, efficiency is about the amount of time, money (or more general: resources) you use to deliver the desired process result.

For the ease of this story, I will only look at money and time as resources (most things can be reverse engineered to these two).

The most time of my gardening is spent at the beginning and the end of the season: at sowing and harvesting, but I did some calculations and on average I spend 12 minutes per day.

On seeds I spend around 20 € per season. I get water from the pond across my street, so that’s for free. And on fertilizer I spend 25 €.

For me efficiency is about “getting the same result by using less resources”.  So, delivering 3 months of vegetables stays the result.

But when I only have to spend 11 minutes per day on that, my efficiency has improved.

Or assume I can get fertilizer cheaper. In that way I can reach the same result with spending less money. Efficiency improved.

Improvement in Efficiency: The same amount of vegetables by using less resources.

This also makes clear that “being efficient” is a weird term. I think efficiency is about comparing two ways of working with each other, where one can be more efficient than the other.

Productivity: More result with the same effort.

To me, productivity means getting more out of the same resources. In this case that means I keep spending 12 minutes per day. And keep spending 45 € on seeds and fertilizer.

But assume it is better fertilizer or I bought a better breed of seeds. Or maybe I have improved my watering technique. Or maybe I’m just lucky with the weather.

In that case it might be possible that I can produce vegetables for 3 months and one week.

With investing the same time and money, I got a better result. Of course I assume that one week of extra vegetables has value for me.

Productivity: more vegetables for the same time and money.

More with less?

More with less. I hear it quite often when organizations want to “improve” their processes.  That should mean becoming more efficient and more productive. Could that be possible?  I think so.

Just some ideas:

§  Because of a better digging technique, the soil can hold more water, which makes the carrots grow better and more carrots are produced.

§  I can harvest seeds that I can use next year instead of buying them

§  I was lucky and got a bargain on fertilizer

Finally I will have more vegetables at less costs. How could I call that; producient?

Besides the things I cán change, the weather has a big influence on my crop. You can be lucky or not. So maybe I will invest in a green house. Talking about investing…

Few things come for free; return on investment

Sometimes I’m lucky and I get an improvement in efficiency or productivity “for free”.

For example when I get a discount on fertilizer or when the weather is good.

But most of the time, improvement needs an investment.

If I want to spend less time, that could be possible by working smarter, but not seldom that also needs investment in things like machines or other tools.

In that case it’s smart to take a look at return on investment.

I told you I walk to the pond across my house to get water. I use the biggest buckets I have, but still it takes quite some time. On average 6 minutes a day (less on rainy days, more during hot times). Those 6 minutes are half of the total time I spent every day. 

So, I found a secondhand water pump of good quality. It came with enough hose to cover the distance from the pond to my garden. I agreed with the seller to buy it for 80 euros. Of course I need to set it up. I practiced that and I can save 2 minutes a day by using it.

In fact my spare time is free, but assume I can ask 30 euro per hour as a freelancer, the pump saves me 1 euro a day.

That means I can earn the pump back in 80 days. That’s less than the 3 months I spend on my garden each year. So, the pump paid back within one season.

And I assume I can use the pump for a few more years. What would you do?

Eat your veggies!

(Numbers in this story are made up. For easy calculating. )

Why do you have processes?

“Why do you have processes?”

“To model them”

This conversation really happened during a workshop. It made me sad.

That made it a trigger to spend, in all my assignments, some more time on explaining the terms process results and goals.  Which to me are the essences of a process.

Goal, results, process….what are you talking about?

Process results and process goals. I often talk/tweet about them.

To me they are two naturally separated aspects of a process. Sometimes that raises questions. That’s the reason why I spend some words in this blog to explain what I mean.

Maybe the confusion comes from the fact that different words are used for the same things, which is quite common in Process country.

If that’s the case, then we’ll know that and solves the confusion. hopefully. 

First of all; processes are a means, not a goal

Every organization has processes. Whether or not they are performing well, they're just there.

Processes are the means to deliver products or services that (hopefully) solve the problem(s) of customers.

And that brings me to what I call the process result; the “tangible” result of a process.

Process results

Like in many of my stories, I will use the simple example of a pizzeria, with focus on the “Deliver pizza” process.

What’s the concrete result of this process? You can, for example, find out by answering questions like:

• What's the reason a customer asks the pizzeria to execute this process? 
• What's 'the thing' the customer wants to pay for?

And indeed,in this case that’s “a delivered pizza”. That’s what I call the tangible process result.

Just like the process “Grant permission” delivers (in the positive flow) “a granted permission” and the process “Hire new employee” has “a hired employee” as process result.

Not that concrete for every process

It’s not always so straightforward as in the pizza example, because you will find different types of processes in Process country. Not for every type of process a concrete result can be defined so easily.

Some processes just start with a problem to be solved, like (in healthcare) “I have been suffering from headaches for 3 weeks now”.

There are also processes where the result is defined at the start of a case. For example, when someone wants to let build something very customized.

In those processes, “Defining the desired process result” probably will be one of the first steps.

A good process starts at the end

Looking back to the first paragraphs of this article, I realize I started from the wrong end in the Pizza example. I said that a process is a means to deliver a result. So, that desired result should have been my start.

What problem does the process result solve?

From a more strategic point of view, it might be a good idea to start to understand what really makes customers happy. Then it’s often needed to look beyond the concrete process result and try to get clear what problems you want to solve for your customers.

In the example of the pizzeria that could be something like “Customer is hungry, doesn’t want to leave the house and is not able or willing to cook”.

A “delivered pizza” can solve this problem.  And the pizzeria collected and combined all the resources to execute a process that delivers this result.

That’s why I like to start at the end. To determine why a process result is really needed. This also prevents me from spending time at “useless” processes.

Useless processes?

“Pizza baked” sounds quite resultish, but it’s not the result customers call (and pay) the pizzeria for. It’s an in-between product/milestone to finally get to the “pizza delivered” result.

The advantage of thinking about the process result is that you don’t spend time on “vague processes”; processes of which nobody can tell what problem they solve.

But, the customer is hungry, so let’s get back to the “Delivered pizza” result.

There are millions of pizzerias (even in my small town there are 7) that deliver the same process result. Why is it that some pizzerias attract different customers than other pizzerias? Why are they all able to earn a living?

I think that’s caused by how customers expect a process to perform. And that brings me to what I call the process goal; the promise about the process result.

Goal; promises about the process result

As said, a process is a means to deliver a result.

To be able to design that process, you have to be clear on what you promise about that result; the process goals. And that can be more than one promise.  

For customers:

•  “Pizza delivered” within 35 minutes

Or more promises:

•  “Pizza delivered” within 35 minutes and warmer than 70 degrees.

Or very ambitious:

•  “Pizza delivered” within 35 minutes, warmer than 70 degrees, tasty and never more expensive than 10 Euros.

So, the process goal is what you promise about the process result. This can be a promise based on time, costs or quality.

This combination of process result and connected goals, define how the world sees your pizzeria. Fast? Cheap? Tastiest in town?   

Process goals are dependent on “who you want to be”

What you promise about a process result is depending on how you want customers see your organization. In fancy books this is probably called something like vision, strategy or proposition.

In Pizzaworld, you’ll see differences, of course. The big chains that might aim for “fast and standardized” and the more traditional pizzerias that want to offer “quality and a taste sensation”.  Although “tasty” is in the eye of the beholder.

Proposition has influence on process design

A proposition has its effect on what you promise about a delivered pizza. So also on the design (and hopefully execution) of the process.

In situation 1 (fast and standardized) delivering pizza is turned into an efficient production line process, where every executor has a little standardized task in the process. This serves the goal of creating a pizza that always has the same size and taste and will be delivered in a predictable time!

In the second situation it might be possible that the owner of the restaurant will execute all the steps in the process by herself and will put all her experience and love in the pizza.  This will probably take more time and might be more expensive.  But that’s what customers of these types of pizzerias are willing to accept.

If life was that easy...

In everything I wrote so far about process result and goal, I made one big assumption: the paying customer is the only stakeholder of the “deliver pizza” process.

In a Process Fairy Tale this might be true. And yes, solving a problem for a customer should be the main focus of a process. But, if you only do things that “add value” for the customer, you might end up in jail or go bankrupt.

Because, sticking to the law and sending invoices; does that add value for the customer?

So be aware that the customer is not the only stakeholder of a process.

More stakeholders

For sure, without a pizza eating customer, the “Deliver pizza” process isn’t needed at all.  But in the context of making clear the process goals, it’s always good to acknowledge there could be more stakeholders of a process.

Think about the Pizzeria’s owners that want a margin of more than 40% on each delivered pizza.

Or some kind of government agency that is responsible for food safety can have some hygiene requirements for the process.

In that case making a process “Lean” isn’t an easy task. Because when designing a process you have to take all these above requirements and goals into consideration.

Think about an extra step to measure the temperature of the pizza. Or a process rule that states that a delivery car is not allowed to carry less than 4 pizzas to prevent that the margin gets too low.

It’s these kinds of things that make a process feel “unleaner”

Process result and – goals; should I really care?

All the above is not that shocking. Luckily. But, is it important?

What is important? There are more important things in life, but in the context of process management I think it matters. Because executing processes that solve nobody’s problem is fooling yourself.  It helps me to get a clear view on the reasons to design a process for. And execute, of course.

And that assures me that I do something to help others with useful process results.

Besides that; I think a shared (process) goal is a minimal prerequisite to collaborate on cases in a process.

And of course, when you are a one-man-business, you probably do the whole process on your own. You are very clear about your process results and –goals and it’s probably communicated well with your customers.

But when talking about processes in which different players contribute to the process result, I think making clear the process result and -goal is the least you can do for all of the stakeholders.

Make it clear!

And let’s make that the conclusion of this story. Processes have a result with goals attached to that.

Or better; you promise something to your customer and like to design and execute your processes in such a way you can deliver that promise.

So, I prefer making those process results and goals very clear. So that everyone is aware and can contribute to a better process design.

And yes, when you make something clear it’s possible someone will not like it.

But there’s probably a fitting process result for everyone ;-)

I wish you useful processes!