I love it when customers do all our work

Customer Journey; that's an hipster thing, isn't it?

Can you remember when the Customer Journey became a hip thing? 3 years ago? 5 years ago? 

Anyway, doesn't matter. But, when it suddenly became "the next big thing" in Processistan, I remember myself thinking "What have all these organizations been doing before they started thinking about the Customer Journey?"

Didn't they care about their customers? Did they really cause the customer a lot of trouble and effort to buy their products or services? I don't hope so. For their customers. 

Customer Journey; that isn't some standalone thing, is it? 

Besides that, it also surprises me that the Customer Journey is often seen as something separate from a process (that some even call "Internal process"). I think that is strange. Very strange. 

Most processes just have more executors. And  the customer is not seldom one of them. And in these days of digital-everything and co-creation, I think that will increase more and more.

That's why I think the Customer Journey is just part of any process. Not some separate thing. 

I might be sounding like some smart process consultant now, but in the old days I also made the Customer Journey an after thought.  Or no thought at all. 

Back in the days, when I was helping organizations to draw some process models on their walls (before doing it on windows became cool), we labeled the activities of the customer as a "black box" because "how can we know what the customer is doing?"

Indeed, we probably don't know what the customer is doing in his/her free time. But in the context of the process you're talking about, I think you must know what the customer has to do. That's just part of the process design, isn't it? 

Wouldn't it be unfair to not think about the effort and tasks you'll bother your customers with? 

Then it's about answering questions like

• What information (or other supplies) does a customer have to provide to us?
• In what way do we want (read: must) the customer to provide that information? 
• When and how is customer informed about the process for his/her case and what is the effort to get that information?
• What does a customer finally have to do to get the product or service?

Customer Journey; just a member of the big process family? 

I don't like non-saying consultancy terms like "End-to-End" or "Customer-to Customer", but of course I hope that processes are executed to solve problems of customers. 

And that can be anything:

• I'm hungry
• I would like to buy a house and I don't have enough cash 
• My car is broken and I planned to leave for a road trip tomorrow
• I want to save some money so my kids can go to university
• I want to get rid of that headache
• My printer isn't working 

And probably there are many organization who would love to allocate their resources to solve those problems. And make a few bucks with that. 

That makes the Customer Journey everything you, as a customer, have to do or provide to make those organizations execute their process to solve your problem. 

And when you've been in line for 2 hours, wondered why all the fields on that web form are mandatory, or had to send 3 documents with "missing information", you might know, that journey can easily turn into a traffic jam. 

But, as customers have the power these days, within seconds your service will appear on 129 review websites or you will be bashed on twitter and facebook. 

That's why I can imagine that looking at the Customer Journey is quite hip. But if I had to say it (and I know, I am not), I would take look at it in a little larger context.

Because a Customer Journey is not the whole deal, I'm afraid. 

Customer Journey; isn't that only a small part of the Customer Experience? 

You can design a relaxed Customer Journey as possible, but if you screw it up in the rest of the process, the, another cool marketing term, customer experience, will not be that fantastic.

It's (unfortunately still) not seldom that the different aspects of a performing process are designed, analyzed or improved separate from each other. And then I'm not talking about the customer journey or "internal process" only, but also about other process aspects like:

• Information management (on different levels)
• People and their skills needed to execute (parts of) the process
• Software and Facilities to support the execution and coordination of cases in the process
• The way the process is managed (task based, goal based)
• Law and compliance involved in the process
• <and you can probably name some more> 

And besides the aspects mentioned above, I would definitely not forget that a process has several stakeholders.

The customer for sure, but also the process owning organization, employees and possibly law or certifying parties.

And they all have their own journey. And all those journeys blended together; that's what I would call a process. 

Have a safe journey! 

I have to confess; I really hate technology

I spend most of my time in BPM world. I even provide training for a vendor of BPM software. This might make you think I definitely must be crazy about technology.

Absolutely not.

And that’s not because I am an old grumpy man or I don’t understand it, but when I think back; as a child I never cared about game consoles, remote controlled cars or Lego technics.

Instead, I preferred wandering through the woods to learn about the usefulness of nature, helping at the farm or playing soccer on the streets.

Years passed by and now I’m an old kid.

But still I don’t care about technology. I can easily get annoyed by the next hallelujah article about the next Silicon Valley start-up (with, if you have to believe other articles, employees who can’t pay their rent) that came up with the next app that solves the same “problem” as 20 similar apps.

Or take all that speculating and scaremongering about the impact of robots, artificial intelligence, blockchain or virtual reality. 

I think I can spend my time better than worrying about that.  

And that’s what I do, most of the time; not worrying. But, doing what really makes me happy. And, for example, that is spending my time on my hobby-profession of construction and renovating.

So, a few weeks ago I decided to spend the money I made with mapping processes for companies who don’t want to do it themselves. I treated myself and my family by building a patio in my garden to sit and relax when I come home from another tough day in the BPM center of Excellence.



Building a porch is a little bit like a process where it is smart to do the steps in a specific order, so I started with pouring the concrete foundation to place six nice and big Douglas beams upon.












Of course I wanted those beams to be leveled correctly, so I borrowed my friends’ self-leveling rotary laser. Beep, Beep. Everything leveled perfectly. Which gave me a good base to continue building.  

To construct the walls, a lot of planks needed to be cut the right size. Luckily I own a professional miter saw, so that job was done in no time.

Putting the timber on the roof could be a more time consuming job, because I chose to use a lot of small planks. But the nail gun did a good job and I could finish it in a few hours.

I decided to make the roof water resistant with EPDM, some kind of rubber. I never worked with that material, but it turned out to be a piece of cake. Some glue on rubber and roof. Wait a few minutes, unfold the rubber and done!

Because my girlfriend saw it on one of those hipster lifestyle television shows, she wanted a lounge set in the new porch. When building it, I was really happy with my light weight, but powerful, cordless screw driver. And those torx screws; I love ‘m!

When I’m working on those projects, so now and then my thoughts go to my late granddad. He was a carpenter in heart and soul, so I think I must have inherited some genes from him.

As a kid, I spent hours watching him work. Quality was his middle name, but man o man, his work needed a lot of effort most of the time. Sawing by hand, screwing by hand (and not with torx screws, but just the old flatheads) and mixing concrete by hand. Respect.

Nowadays all those tasks go much easier, because of….technology!

So, actually I don’t hate technology at all. I love it as long as it helps me. As long as it helps me to execute my processes and delivering the desired results.

Probably technology only interests me when it is applied in processes, I “bond with”.

That might be the reason why I always click away from the next fintech story; I just am not interested in processes in the financial industry. The results of those processes just aren’t things that make my head turn. But when I have to believe Linkedin, luckily there are enough people that do like those processes and the technologies supporting them ;-)

Personally I am, among others, more interested in health care. So, technologies to improve health care processes; bring them on!

So, isn’t it about technology, but about the processes (actually their results) in which you are interested or think are important?

When you are interested in certain types of processes and what problems those processes solve for customers, I think you are automatically motivated to improve those processes.

And that might be caused by the fact that, in the end, processes themselves are just a means. A means to deliver a result.

As I told you, I love building things (the process), but the desired process result was the porch.

All the steps I took to build it, were probably the same my granddad would have done 50 years ago. The why? and what? of the process didn’t change.

But the How? did. Because I used modern tools, the process went faster at certain points or did cost less effort or money.

Whether or not using all those tools made the quality of the end result better, is a thing I am not sure about. I think that has more to do with how well you are able to apply all those tools and materials. Good old craftsmanship.

Technology. I have to confess; it can be cool. At least, if you apply it in useful (opinions may differ about that) processes

Maybe that is why I never got really excited about BPM systems “in general”. Sure, the technology might be cool, but it only makes sense in the context of a real process.

And often it is applied in processes that do not really excite me ;-)

How processes can be designed and supported by technology might differ from process to process and I like to help organizations in finding that match,

But there are things I even like more. Tonight I will attend a welding course. Yeehaa!

All our processes can be unique. As long as they fit into our Workflow Management System.

Fortunately more and more organizations become aware that "managing by process" isn't about making nice process manuals, or implementing a workflow management system. More and more they start to realize it's about getting the right level of grip on your processes: Execute, Monitor and (when needed) improvement of processes. 

Most organizations have more than one process and what I see so now and then is that, in the drive of executing and improve these processes, the "one size fits all" method is applied. 

Think about trying to use a traditional workflow management system for a process that isn't suitable for this structured way of managing it. Or using Six Sigma techniques, where these statistical methods don't add much value to serving the (process) customer. 

How is that possible, you think? For sure it is caused by the 'hypification" of some methods or technologies and solutions. Unfortunately that can lead to disappointment when it doesn't seem to work for your unique process.

You could call me old process fashioned, but I still think you need a proper understanding of what is going on in your processes and what you need to manage and improve them.

A straight through (oh, not in your organization?) like "paying invoice"; I'm pretty sure you can buy some kind of tool to do (or at least support) this.

But, a primary process that works with different types of customers, unstructured data and stubborn highly educated people; that's a different kind of process.

That's why I'd like to start with a process oriented view on an organization to determine the characteristics of these processes from there.

I'm pretty sure you will realize quickly that not all processes are the same and have the same demands.

Just like people. 

Our processes are very flexible….….in doing useless things

These days, many business related stories seem to be about our fast changing world. Although I still have the same haircut as 20 years ago, I assume there must be some truth in that.

Translated to process management you might hear terms like flexible, adaptive or agile.  It all has to do with being able to change what you do. When necessary. 

Probably you might hear or use other terms, but I always use the terms flexible and adaptable, to explain that there are different levels of change when we talk about processes.

 

Flexibility and Adaptability are not the same

BPM is about getting the right level of grip on processes.  Some think that grip means ‘standardization’ or ‘force’ all cases into a predefined path.  

If your processes have to deliver the same result for 20 years with no variations, this might sound ok, but that’s hardly the case in any business these days.

So, ‘right level of grip’ can also mean flexibility and let executors in the process have more control on what should happen instead of predesigning everything.

And that’s what this little story is about, because there are 2 levels of flexibility in processes that get mixed up sometimes,  I think (as said, some might use different terms for it):

Flexibility in executing a process for one case (called a process instance)

The Adaption of a process to a changing environment (changing the process definition)

 

Never forget; Processes are about delivering results (about which you promise something)

As you might know; I often use the metaphor of traveling because a trip has a lot in common with a process. Both have a destination.  In a process that’s called a result (product, service or solved problem).  And that’s the thing to start with I think, because you always have to be aware a process is a means, not a goal.

A process is a means to deliver a result.  The result is what counts; the process is only the thing that brings you there.

Back to travel; assume I am in Berlin and my desired destination is Amsterdam.

So Amsterdam is my result, but to be able to design a good process, I must also define what I promise about that result. That’s what I’d like to call the goal.  That might be getting there fast, cheap, shortest route, least produced CO2,  etc.

Based on this result with goals, I can design the characteristics of my process (plan my travel). 

 

Flexibility; being able to change during the execution of a process

Assume the travel can be made by train or by car. You can imagine both offer different flexibility to the traveler.

If I designed a ‘train process’, the execution will be quite standardized and not really flexible. The train will bring me there fast, but if something happens (tree on the track) I am not able to take an alternative path because I, as executor, am not in charge of the process (the train driver is).  

So when everything is predictable during executing, such a process is OK and reliable.  

In software, (traditional) workflow systems can support these types of processes.

When more flexibility during execution is needed, using a car might be a better idea.  I, as executor, am in the lead.  I can decide to take another road in case of traffic jam. I can speed up if I like (taking the risk of not being compliant with laws anymore).  Of course, in real life there will be boundaries , but it is more flexible to reach my result.

In software, case management systems might be a better support for these kind of processes.

And is software really important in that?  Maybe, but mostly are empowered, result aware, employees supported with useful information to base their actions on.

So flexibility is about the way to take alternative paths in a current process design (getting in Amsterdam fast).  In that case, the result is more important than executing a standardized process.

 

Adaptability; being able to change your process design.

Above is all about flexibility in a current process design.  But assume my processes were always designed to bring me to Amsterdam fast. But nowadays I want to get there cheap (it’s still crisis…) .  So, the environment changed. Can my processes adapt to that?

So adaptability is about being able to create new process designs. It’s not about the non-flexibility in execution a process, but about being able to design new processes.  

If travel must be cheap now, but my processes keep on delivering ‘fast’ they will be running out of sync with my environment.

Back to my travel to Amsterdam. Assume I designed the current process by leasing a very fast (but quite expensive) Bugatti Veyron for 6 years.  I can get there fast in a flexible way.

But now, because of changed circumstances, I want to get there cheap.  Unfortunately, my process is ‘stuck in the lease term’ , which means I cannot adapt easily (for example by buying a fuel economic diesel car).

And that is what adaptability is about; being able to get rid of my old process and develop new process designs.  Talking about software again; you can imagine that if your current process is ‘hidden’ in billions lines of code, how fast can you change your processes? 

 

So standardization and flexibility are just ways to execute and manage a current process.

Adaptability is about being able to change processes so they keep on fitting the wishes of their stakeholders.  

So even very flexible processes might deliver things nobody wants because they are not adapted.

Happy processing!

If you mix up means and goals, you will get fabulous soccer...

...but still might lose every game. 

So, what does process management have to do with soccer?

Besides traveling, sometimes I use the metaphor of playing soccer to explain terms like process, process result,  process manager, process owner, process improvement, etc.

The most obvious is executing of the process: playing a soccer game. But processes shouldn't be executed for fun (at least, in companies), so the result of this process is a ‘played soccer game’.  No doubt this will be fun and healthy, but this doesn't automatically mean you will win.

With this I’d like to explain that there is a difference between the process result (game played) and the goal attached to that (winning, I assume).  In business you might see that many organizations deliver the same result, but what they promise about it, might be very different. That’s depending on your strategy (do I want to be fast, cheap, flexible, the best in quality, etc.) and of course what your customers expect about the process result.

And then we are at process again, because, in the end, a process is ‘the thing’ that delivers what you promise.

So, to do what you promise, a process has to be executed. And that’s just daily business, because every company has processes. That doesn't mean all companies have a clear process focus or that those processes perform well, but processes? They must be there.

Talking about process performance; to make a process perform, several aspects of a process design should work together.  

The most obvious in soccer are the players on the field. They are the process executors. They might have different roles in the process (forward, defender, free kick taker or goalkeeper). Besides the players a process needs other enablers like a system to play (workflow), equipment, information etc.

The coach of the team can be seen as the role of process manager. He or she is watching the game and has indicators to see the performance. Main indicator will be the score, but in soccer they are collecting many types of information these days. (S)he continuously checks if the game (in process terms I’d like to call this a case) is on track to the desired outcome.

When this doesn't seem the case, the process manager can change things, trying to improve the process during the game. Think about substitute players, moving players, defend more, take a risk by making some fouls, etc.

To me that’s the core of Business Process Management; being aware that processes happen on the play field and not in the locker room (like creating process models or discussing processes ‘in theory’). Being able to act before the case is finished. A game can only be won on the field.

An important role in this must be played by the players on the field (employees). If they know what is expected out of the process and know how they can act to improve process performance, you don’t need endless improvement projects; the process is improved during the game.  I like this kind of empowerment.

Sure Emiel, but one important thing to remember is that not all process executors are the same. Some have a natural sense for improvement, while others don’t care and just do their job. And there are even players who need very strict instructions from their coach.

So being able to adjust things during the game is very dependent on the people in the process. So, maybe they need some coaching in that.  

Also, some processes are so predefined/standardized that adjustments during the game are not possible anymore; once a case is started it will be executed as agreed upon.  In that case you can only tell if the process performed well, after the game is finished.

And when, after playing several games the team is not high on the ranking, the process design itself might not be as good as hoped, and a structural change might be needed. You could say this is the responsibility of the club owner (the process owner). He can decide to buy new players, fire the trainer etc. But these are structural changes and for sure will cost lots of time and money. And aren't they a little too late?

But, despite all the continuous improvement talks, in many companies process improvements are still done this way. Is that bad?  At least it’s bad luck for the customers who were still served by the old process definition. It’s really depending on your industry and your customers how agile your processes should be.

Adjust on the field or complain in the locker room? I’d like the first option, but as said: are employees capable of taking this role? Are they empowered to act? Do they know how to act?

I am a true believer that BPM is daily business and to do this as best as possible you need several roles. To me the most important roles are the executors and the process manager. They make it happen for your customers. By the way, these roles can be played by anyone. A player can be the coach too. Or the process owner can also be a player.

So, on of my first steps for every company thinking of 'doing something with processes' would be educating everyone on the basics of BPM, so they have a clear understanding how they can contribute to make your processes do what they promise.

On the field by preference. 

Happy processing!

I always model my processes in scale 1:25....

...so they fit on one page.

Thousands of articles, white papers and books have been written (but also read?) about process modeling. One extra won’t hurt, will it? And when you’re lucky, you probably will not learn anything new. 

Modeling processes; who doesn’t do it?

Process modelling. It seems the first and most appealing thing companies do when they start doing 'something with processes’. 

And yes, I’ve done it a lot in my, so called, career. But after all the consultancy fees enabled me to buy a second  and third house, a few sports cars and a boat I never use, I thought that time has come to start discussing the value of it. Process modelling is a means, so don’t do it without a goal.

So, very often I run into discussions about pro’s and con’s which I most of the time like to trigger with some quotes I regularly post on my www.procesje.nl blog.

<Advertorial>

For those who can understand Dutch, I even combined them all in a little booklet:http://www.procesje.nl/procesmodelleren.pdf

<End of shameless Advertorial>

And those quotes are not meant to make people angry or to play the funny guy (although…). I use them to make people reconsider their process modelling efforts. 

Because, in general, process modeling will take up a lot of time, effort and money. So, please make it worth it!

Before even touching a mouse, spend money on a BPMN book or grabbing some sticky notes, I would ask myself; why should we model our processes? Why make nice pictures (you know it’s a little more than that) of the work we do in our company each day?

If that question is answered in your company, it means that you are very clear on the reason for modelling your processes.  But for those who aren’t, what could be those reasons?

I’ve seen many reasons why companies modeled their processes. 

Tell me how to do my job

Some model their processes, so they can be used as some kind of working instructions. Finally they will be converted to nice process manuals on the intranet. 

And everyone goes back to work.

Because working; that’s what people do. Organizations have processes, but people have jobs.  And as a real process (I don’t like to use the non-saying term ‘end-to-end’) can cross many people and jobs, a manual of a process is not automatically a manual of someone’s job. It might be a manual of many jobs. Do you think people can easily find the information they need?

So, although intentions (enable your employees to do their job well) might be good, I think there are better ways for working instructions than process maps. And that also has to do with the possibilities of technology, these days.

For example; I like to work on my motorcycle. When I need an instruction on how to change the spark plugs, I don’t take the manual, but I grab my phone and search on YouTube.  

It starts with viewing one movie, but in the comments I usually find better tips and finally I am able to change the spark plugs. Besides that, I also found an online store to get them cheap and have some new friends to go for a ride.

So with all the online sharing these days (even within the boundaries of your company), I think the value of process mapping for working instructions is close to zero.  You could think of using it for some kind of decision diagrams, but that’s not a process.

So, are working instructions still provided in your organization, or are employees responsible for it themselves? And, if they are provided, what’s the format they come in?

This is the way we comply!

Unfortunately we seem to live in the compliancy and  age, so I also see processes are modeled for these compliancy issues.

Companies, so also their processes, have to be compliant with all kinds of regulations, certification, standards etc.

That is why some model their processes to make clear how they think they meet these compliancy requirements.  I would say that is just theory. You are compliant in real life, not in a model.

To check if theory meets practice, all kind of (internal) audits are done. To me, compliancy is a symptom of too much regulation and fear, so wouldn’t it be much cooler that everyone just behaves well (like the guys at fifa), so we don’t need this compliance terror anymore?

I hear you thinking: dream on, Emiel! 

But, if compliance is really needed, why do it plastic style? With models? Wouldn’t it make more sense to implement ways of working that just are compliant? Implement your processes, don’t model them.  

Process Improvement

Talking about changing the way of working; the reason that is most mentioned for process modelling: improving processes. Who doesn’t have a process improvement project these days?

(Did you notice, this article is 800 words on its way and I didn’t use the word Lean yet)

Whether or not modelling processes might be useful for process improvement, the first step I often see missed is a clear understanding of the need for improvement.  

As processes are ‘the things’ to do what you promise, it is never a bad idea to take a look at how they perform. I think it should start with understanding of what promise a process has to fulfill and facts about the performance of a process.

Why would you improve processes that are doing well?  Or even worse; why spend time on improving useless processes?

Should process improvement start with modeling the as-is process? I don’t think so. I would start with understanding the as-is performance of that process. Why start improving a process without knowing if it performs or not?

But, I have to be fair; modelling (as-is) processes is still done a lot. And many times I wonder if that delivers what is expected of it. 

Those workshops (I agree; they are fun to do and when well done, they can be helpful) cost a lot of time, employees seem enthusiastic at first, but when nothing comes out that can disappear very easily.

And yes, I know all the arguments.  Like, you cannot tell what to improve if you don’t know the current situation. And sure, it is good to know what causes bad process performance, but is a process model really a good view of the current situation?  The current situation is what happens now, so in fact, when modelling, you are always talking about the past.  How we DID it. Once upon a time.

But one thing is more important I think; what are you actually modeling when you are making a model of a process?

Let’s take a car design point of view. When you want to design a car, you might start with a sketch. This ‘model’ is a small 2d version of the car. But it shows you what it will look like in real life. Maybe a little later a full scale 3d model will be made. With the help of this model you understand how it looks, can do wind tunnel tests etc. And that might be really useful before start building the real car.

Look in the dictionary for ‘model’. You’ll probably find something like ‘on a small scale’. Like the model of the car.  But is a process model a process on a small scale?  Not really, I think.

Most of the time, it’s just a set of agreements of how to represent the several aspects of a process. Blocks for activities, arrows for the order between them, diamonds or circles for decisions, a ‘curly block’ for documents, a hat for an executor, etc.

And people probably can understand what the model means, but is that the same as understanding the process?  Or understanding what causes bad process performance?

Because that what was what we were talking about; improve a process because it doesn’t deliver what we want. So does a process model tell you what is broken?

Not very often it does. And I think the reason for that is that a process model misses one important thing of a real process; the dynamics of execution.  Processes are most of the time modeled with one case in mind. But in real life many cases might run through the process.

In real life operation, cases will probably also have effect on each other. If an employee is working on one case, the other cases must wait. Or the office is closed on Saturday and Sunday. Or customers keep on sending the wrong information. You don’t see that kind of dynamics of real life in a process model.

A step forward in this could be making use of process mining. In the ‘animations’ of process mining, you see all the flowing cases projected on top of the process model. You see where cases flow smoothly, what routes are taken most often or where cases get (actually it’s ‘got’) stuck.

And when you are lucky and the log files, where process mining is based on,  contain more data, also information about processing time, waiting time, throughput time etc. can be seen.

And that might give you a better idea about process performance, but be aware those are still symptoms of bad process performance. It’s like playing back your gps/satnav, not a tool that tells you how to make your car faster. You know something went wrong, but what is the cause? And, more important; how to fix it?

And besides that, it’s the past. It shows how fast you have driven. It’s too late to brake now. But of course it can be very useful for improving the process in the future. To prevent you from making the same mistakes.

And this ‘past thing’ brings me to what I wrote in earlier posts; customers only care about the process you execute for them, not what you will do better in the future for other customers. They want to be served; on the play field. Not afterwards in the locker room.

So how can process models be brought closer to real life?  I’ve been thinking about this and found it hard to find an answer.  I think the first thing to be aware of is that most processes are (maybe not as well as needed) already executed at this moment.

So, modelling those processes would not be my start. The first thing I would try to achieve is to set up some kind of monitoring of cases.  Making everyone aware what’s going on in the process.

To bring this into practice, I once printed a picture with the milestones in a process, put it on the wall and used sticky notes for each case to make clear what the status of each case was.

Of course this needed some discipline and was not very ‘digital’, but employees had a good overview and got more and more engaged to improve when they saw visualized what type of cases caused troubles.

You could call it manual monitoring. Might sound stupid and inefficient, but it met it goals. 

But you are right;  these days there are many tools that can connect to the systems that are used for execution and show the status of cases in monitoring style. Some are even capable, with the right data of course, to do some predictions about the progress of a case. It’s based on fact of the past, but ok; it’s all in scale 1:1!

So my first start would be to make clear for process players what cases are in the process at this moment, what’s their status and whether or not they are on track. In that case they know what is going on in the process. Process manager is a role, not a position.

And as I truly believe that executors are the ultimate source for continuous process improvement, they should be coached on what aspects make a performing process, so they can initiate change when needed.

And is I said at the beginning of this story;  that’s no rocket science. To me bringing process monitoring and after that, analysis and improvement to the work floor is the most logical thing to do. Because it’s all about serving customers. And customers are not served by mapping processes. They are served by executing them (the processes, I mean).  

In the end process management is about bringing those processes to a good end. And executing those processes is the least you can do for that, I think.  

Oh yes, I was discussing the value of process models and most of the times models are far from execution.

But as you probably know, technology has improved last years, so in many BPM suites modelling can become execution. So what you model becomes some kind of workflow system real time. It’s cool technology, but, as you can imagine,  not suitable for all types of processes. Not all processes can be managed workflow style. But again; it’s on the play field, so might be a good start.

Besides that; a process is so much more than an automated workflow (actually it’s caseflow, because work doesn’t flow, cases do). Do you have capable  people?  Where does the information come from?  How is the process managed? etc.

Tools definitely can help to improve how you execute and manage your processes, but always be sure it suites the way you would like to execute the processes.

To summarize; Process modeling definitely has its value, but also be aware of its drawbacks.

There are many reasons to take a look at your processes. But, a process is not a process model, so always ask yourself if it can help you to achieve what you would like. Never forget; in the end your customers are only served by executing processes, not by modeling them. 

So, If you still think you need to model your processes (as working instructions), please call me.  I’ve seen a cool motorcycle that I want to buy.

Happy processing !