How does BYOD affect BPM?

In this post I'll be looking at the concept of BYOD (or Bring Your Own Device)

BYOD is a concept that, frankly, didn't exist a couple of years ago. Mobile devices were laptops and that was, pretty much, all you could use. You took one to a client (or an affiliate/branch site) and plugged it into the network. It became your mobile desk.

But since the advent of the iPhone and the subsequent boom in smartphone and tablets, the concept of someone 'bringing their own device' to a location is a much more diverse affair. (Of course, 'devices' have been around a lot longer than the iPhone. In the attached picture you can see a Palm Pilot, Apple Newtons, and Treos. But the iPhone - and it's ability to connect outside the device itself, has really pushed this sector forward)

I do a lot of work at the 'offices' of a well know Seattle-based coffee shop and whenever I go there I link into their Wi-fi with both my smartphone and tablet and I can work pretty much seamlessly between the two. I don't need my laptop which stays at home 99% of the time nowadays. I know that this is something that a large number of 'mobile' workers do.

Connie Moore from Forrester wrote an article on the concept of Bring Your Own Technology back in November. In it she stated:

According to Forrester's Forrsights Workforce Employee Survey, Q4 2011, of nearly 10,000 workers worldwide, 53% bring their own technology for work. The rapid growth of mobile BYOT devices within business is reminiscent of Web adoption during the mid-1990s. After early handwringing and resistance, followed by rapid growth and innovation, the Web emerged as an indispensable tool. No one thinks twice now about using the Web for work. BYOT will follow a similar pattern.

What does this mean for BPM?

Issues
As with a lot of 'new, fangled stuff', there are issues to be overcome.

The first issue to be tackled is acceptance.

Connie makes mention of an underlying issue with this concept in many businesses, which is that of security. In regulated firms the concept of allowing a 'foreign' machine to attach to a network is anathema. The RIM Blackberry phones are, pretty much, the only tools that are exempt from this and that's because they are controllable by a central IT function. As someone who previously worked in the highly regulated Pharmaceutical industry I can align with this sentiment.

In more  'open' firms this is less of an issue. I know creative designers who edit video at a remote location on their iPad using the LogMeIn app on their home PC and running renders on their work servers. For them this is a case where the BYOD concept has made them more productive and able to work in places they would never have been able to do so before (This particular instance occurred when the employee in question was sitting in a vehicle service reception waiting for his car to have some work done on it!)

Growth factors
A lot of this BYOD expansion has been brought about by increased usage of 'The Cloud' and associated applications. Companies like Dropbox and Evernote have pioneered the ability to produce something in one location on one machine and have it instantly available on all machines at any location. Application developers are linking in to this ability by designing connections to these apps (and others) in their products. This very post you are reading was started on my PC at home, continued on my iPad in a remote location and  finished back on the laptop at home, all through the use of Dropbox and apps that connect to it. The ease with which these tools are now integrated into many peoples lives means that their use in a work environment is bound to increase. Wouldn't it be nice to be able to work on a document at your desk, save it to the cloud and continue work on it on the train home in an evening via Dropbox or some other Cloud application? I can see this becoming something that is more prevalent as time increases.

BPM and BYOD
The BPM world needs to understand this and incorporate it into their workflow.  Many workflow automation tools use email as a way of notifying users that tasks are awaiting their attention within the tool. In normal situations the user would sign on to the app, process the task and sign out. This is fine if you are in the office, but what happens if you want to use your commute, or time at a coffee shop, or a spare ten minutes after the kids have gone to bed, to process these things on your phone or tablet? If the security of the company is set up to inhibit access to your network from non-approved hardware this, effectively, rules that out.

For reasons we have discussed earlier this is something that will work differently depending on the sort of business you are working on. Highly regulated industries will have to work on finding some sort of alternative to doing this. Some of the less regulated industries will probably look at this and understand that there are benefits to allowing user devices on their network. Either way, this is not something that can be ignored.

Summary
BYOD is here to stay. The 'phablet' (phone and tablet in one device) is widely rumoured to be the next big thing. As the adoption of tools like these increases (my parents now have iPhones and iPads!), companies engaged in BPM need to look at this and understand what are the synergies and benefits of allowing BYOD.

Allowing people to use their own devices (if they want) to do things they might not, otherwise have done, can only be a benefit.

Are you allowing BYOD in relation to BPM? What are the results?

Photo Credit: Jamais Cascio via Compfight cc
.

---

Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.

---

All information is Copyright (C) G Comerford
See related info below

Shadow IT - Good or Bad?

In a recent post about ‘shadow processes’ I mentioned how they are apt to be a result - in some cases - of departments running their own IT functions to try and bypass the inefficiencies of the proper IT department.
Well, the Harvard Business a review has published an article on Shadow IT and it hits the nail on the head quite succinctly in this regard.


If I may quote the opening passage as an example: Five years ago, “shadow IT” efforts were the dirty little secret of organizations. An impatient marketing or finance manager would, on the sly, secure some extra budget money and hire a contractor to build a little database that tracked mailing addresses or top-line financials. Slowly but surely, as the little database grew bigger and bigger, the manager would wedge the cost into her operating budget. Other managers might take notice and started building their own databases.

To my mind this encapsulates the key problem with IT departments in the business. They are not responsive enough to the needs of the end users.

Of course there are numerous reasons why this can be so:

• The need to a manage and maintain existing legacy systems
• The need to appropriately manage funding by prioritising the most important requirements.
• Long lead times of larger projects diverting resources from being more responsive

These are just a few of the reasons that shadow IT functions exist.
But the most telling item in the HBR article relates to the concept of ‘departmental IT’. What they are saying is that shadow IT has now come into the open, been acknowledged by the business as viable and valuable to the end user community, and is being named as a separate function within the business.

Does anyone else feel as worried about this as I do?

The Big Issue

“But why shouldn’t the departments have their own IT function if the central IT function isn’t providing what they need?” you may ask.

There are numerous reasons but let me just pick on a couple of key ones.

1. Legacy maintenance. I once worked on a project which was tasked with identifying all the systems that needed to be replaced by a single ERP implementation worldwide. It took the project team about fifteen minutes to identify the centralised, IT-managed, legacy systems that were in place across the 40 affiliates worldwide. It took another six months, and many thousands of dollars, to identify all the local shadow IT implementations of Access databases, Excel spreadsheets and local portals that had spring up in the local affiliates. It also added a considerable amount of time, effort and money to the ERP project to understand and replace these with functionality in the implementation. This is the Enterprise Architecture issue.
2. Processes. By definition if you have implemented some sort of shadow IT system in your business then you will have modified, updated, or created some process to include the usage of the resulting IT system. This process will - by definition - not be part of your centralised process world. It will not be audited properly and it may not be the best way of doing the work.

So looking at these two items, it becomes apparent that shadow IT as a concept is not something that should be encouraged.

However, if I am a salesman out in the business trying to sell something to end customers and that lack of IT support for my needs is becoming a hindrance, I can fully understand how it is that I might try and put some sort of Shadow IT function in place to help me achieve my goal. Unfortunately while is will solve a short term goal it will create longer term problems.

In my book The Perfect Process Project, I talk about having a single owner for a process across the enterprise. The reason I say that is because having multiple owners will result in process changes that optimise the process for a specific section but sub optimise it for the whole process. If your purchase-to-pay process cuts across procurement, Accounts Payable and General Ledger, each one of these will try and optimise the process to make their life easier whilst not being cognisant of the effect such optimisation might have on the other parts of the process. Such sub-optimisation across the process will result in lower efficiencies and - hence - higher costs.

Shadow IT suffers from the same problem. You may - as a local sales manager - be optimising your IT functions to best leverage your budget and increase your sales, but any increased profits you are raising as a result of this, will likely be absorbed into the increased infrastructure and maintenance costs of having that unauthorised IT implementation there. This may not manifest itself until someone comes to upgrade or replace your systems (as in the above example), but it will always be there.

The Solution

So how do we deal with this issue? Human nature is going to keep causing people to do their own thing in order to try and improve their own situation. The key is education and reinforcement.
If you can make an affiliate or department head accountable for the increased costs as a result of shadow IT (or sub optimised, local processes), rewarding him or her for staying as close as possible to the company line, then human behaviour will be influenced by the reward system. Good managers get paid better than bad managers,
But the flip side of this is that you also need a mechanism whereby the local managers must have a way of highlighting local needs that are not being dealt with by a central solution. This is applicable to both shadow IT and localised processes. There has to be a prioritisation process to decide where scarce IT budgets are going to be focused. If the money doesn’t go your way, the incentive to not do it yourself is managed by the reward system for aligning with centralised directives.

Summary

Nobody wants to have inefficient systems and processes in place. Everyone wants to be set up in the best possible way to allow them to succeed. But sometimes the success of the overall entity must take precedence over the success of the constituent parts.

---

Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.

---

All information is Copyright (C) G Comerford See related info below

Silo thinking - It's still bad!

The most popular post on this blog (by a long way) is one entitled "Silo thinking and why it is bad...". It was written back in January of 2010 and appears to consistently get the highest number of views of any post I have written. Obviously I'm looking at it thinking "Why is that?'

Sure, it's a well reasoned, thoroughly researched treatise on the nature of the silo mentality in organisations, along with accurate and incisive commentary on how to get around it. (At least in my own mind it is...) but there's obviously something more than that.

 So what?

I think it's because it hit a nerve with a large number of the readers of this blog (over 4,500 last month - thank you!), and it is apparently something that everyone can identify with.

The first paragraph read:

"When everyone in an organisation is organised and works around the concept of individual functions or departments. This encourages introversion and also decreases efficiency"

I believe this to be as true now as the day it was written. The beauty is that it isn't just a process thing but a company wide thing.

The main thrust of that post relates to how a process is usually optimised to run as well as it can within a single department (or silo) and as such is not optimised to run as well across other departments or silos. I'm sure you've heard the tale of the manufacturing process which created some sort of metal engineering device. At the first department responsible for the manufacturing they put together the main three components of the device - the hub, the sprocket and the flange. They then boxed these up and sent them across to the next step where the electronics were added. The first thing this department did was remove the flange that had been added in the previous step. Then they fitted their electronic wiring & circuits and refitted the flange.

This sounds like an apocryphal tale, but it does illustrate quite graphically the ability of two departments working in the same company and producing the same product to - effectively - be working against each other. The first department had an optimised sub-process that meant it was efficient enough to be able to manufacture and construct the three main parts of the assembly, and - without reference to any further parts of the process - they were able to make themselves as efficient as possible. Across the whole of the process, though, this silo mentality was having an adverse effect.

I was reminded of this recently when working on a guest post for Squawkpoint.com which covered the topic of 'Who owns your processes'. In that post I mentioned that the process owner wants to be

 the person who has the ability to make a change to the process that effects multiple parts of the business. 

It we take the example given above it means that we want to be able to make the first step of the manufacturing process slightly less efficient whilst, at the same time, making the overall process more efficient. Having someone owning the individual parts of the process (silo'd) does not allow that to happen.

The other point I mentioned in the original post was that reward plays a large part in this. It has been proven in survey after survey, and experiment after experiment, that people generally tend to focus on the things that will reward them the best. If I am a department boss and I tell my workers "Your annual review and associated compensation is based on your ability to process 1000 widgets per day come hell or high water" you can bet that my employees will be focused on finding ways to process 1000 widgets per day. If it means that they have a way of doing this which is optimal for their own department but sub-optimal for the rest of the widget manufacturing process then that's not their fault.

This is how silos occur.

The solution is - obviously - to reward and recognise people based not on their own individual performance, but on the company performance as a whole. The correct statement should be "Your annual review and compensation is based on the company as a whole being able to produce 1000 quality widgets per day come hell or high-water". The approach is still the same - the employees how to find a process which works in their best interests - but the end result is different - you finish up with a process optimised for the whole process rather than one which is optimised for individual departments.

It is my opinion that - despite the interest in the original post from nearly two years ago - there still appears to be a large amount of silo thinking happening in organisations.

Am I right?



 .

---

Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.

---

All information is Copyright (C) G Comerford
  See related info below

Silo thinking and why it is bad...

(This is my top-read post ever on this blog. Since it was written I've had additional thoughts on the silo mentality which I have added to this post)



I want to send some time discussing the topic of 'Silo Thinking' today

What is Silo thinking?
When everyone in an organisation is organised and works around the concept of individual functions or departments. this encourages introversion and also decreases efficiency

Lessons Learned - Why do we never learn the lessons?

Image via Wikipedia

I've worked in companies in the past who insist on performing "lessons learned' exercises after each of their projects. This is an excellent idea.

When each project has finished, the team gets together and dissects what went wrong, what went right and what they would do differently the next time. The points are noted down and documented in a "lessons learned' document.

I remember after we had implemented a particular financial system (Which I came in on the back end of, I might add) we sat around the table and came up with the following points:

• Better communication of objectives
• Keep the users informed. Often!
• Identify Early Adopters and use them to move the project forward
• Build great buzz to get the project excited
• Allocate budget for celebrating success.

....(The list went on and on)

My initial thought on reading these was that they were all pretty valid and all pretty obvious. In fact I would go so far as to say that they were all common sense. (But as readers of this blog will know, I regularly remind them that 'The problem with common sense is that it isn't that common!')

Let's skip forward now about 5 years. The company had taken a decision to replace their multiple financial systems with a single, global SAP implementation. The project started and had been progressing for about 18 months. I spoke to one of the local folks who was working on it to understand what they were doing and how they were getting on. In the space of about 20 minutes I found out the following:

• Senior management had changed their minds 5 times about the objective of the implementation
• Nobody in the proposed user community had any idea what was happening with the project
• They were not involving early adopters or people who were anxious to be involved, instead they were using mostly internal project people to get this going
• Nobody had a good word to say about the project
• Budgets were so tight nobody could afford to even buy branded pens or mugs let along have a team dinner to celebrate when something was implemented. Moral was quite low.
  

About this time I started to remember the lessons learned from the previous financial implementation and I dug out a copy of the document. When I matched the problems the SAP implementation was having with the problems the previous project had I could see a very close similarity.What it meant, in reality, is that despite the fact that we had identified and documented the lessons learned from the previous project, NOBODY HAD, IN FACT LEARNED THE LESSONS. Which got me thinking: Why?

I was obvious that there were problems in the way this company ran projects. They were repeating the same problems over and over again without understanding why. They were also wasting time on capturing lessons learned as they obviously had no intention of referring to these lessons in future. Or maybe it was something a little simpler than that. Maybe it was simply the fact that there was no process to integrate the lessons learned into future projects. The documents were created and filed, but at no point in the project initiation processes was any further reference made to the previous documents. The effectively fell into a black hole never to be referenced again.

Another simple case whereby a small lapse in process had resulted in wasted time, effort and money.

I wonder how many 'lapses' like this exist in your organisation...?

BPM: "A Matter of survival?" - I think so (and so does Gartner)

"For struggling companies, business process management is a lifeline that helps them survive by reducing and avoiding costs in this volatile and turbulent economy." So says Gartner - one of the leading business research organisations in the world ("It's a Matter of Survival: Use BPM to Drive Out Costs", 12 March 2009, Elise Olding, Gartner RAS Core Research Note G00165528).

I totally agree. In today's cost conscious environment there are only a few guaranteed ways of reducing your costs or increasing your bottom line. One is to reduce staff - the option nobody really wants to do. The other is to become more effective and efficient with what you already have.

So follow the Gartner advice:

• Gain a competency in BPM now.
• Before you wield the cost-cutting axe, construct a high-level
  business process model to understand the impact of head count and
  resource cuts across the enterprise so that you do not decrease process
  efficiency and inadvertently drive up costs.
• Use BPM to manage your business case justification and measurement processes.
• Identify processes where costs may be high and there is not a focus
  on measurement. Target one of these processes for your first or next
  BPM project, and demonstrate tangible results.

These four options are actually incredibly straightforward to do although they are shrouded with mystery, misinformation and misunderstanding ("The 3 Mis's"). That isn't to say they are easy though. It presupposes a commitment at senior management level to becoming better at what you do and to creating an appropriate BPM capability.

Let's look at some of these in a little more detail :

Gain a competency in BPM now. The world of BPM is deemed to be complicated because it encompasses such a large area of specialisation. There is enterprise strategy, process modeling and analysis, process execution, decision management, Six Sigma, process governance and goodness knows which other buzz words - all of which muddy the waters. The fact of the matter is that BPM is a little like the Wizard of Oz - it seems bigger and more important than it is, but in fact there is a little man behind the curtain who is controlling everything. Of course it helps if you have someone who has done this before working with you (Hint, hint - a small consultancy you may be aware of), but the key is make sure you have someone senior who is looking after this and has responsibility for making this happen. A BPM competency could be as simple as having one individual in the organisation who has an overview of every project you are doing to ensure there are no 'silly' overlaps, duplications or mis-communications from a process point of view. Or it could be a whole department who have had specialist training on BPM methodologies, Enterprise Architecture, modelling notations, decision management and supporting tools. The key point here is to make this someone's job and hold them responsible for making it happen.

Before you wield the cost-cutting axe, construct a high-level business process model to understand the impact of head count and resource cuts across the enterprise so that you do not decrease process efficiency and inadvertently drive up costs. Common sense, I would say. But as we all know, common sense isn't that common. This, basically, is a long way of saying 'look before you leap'. Don't think that removing the most inefficient part of your business will immediately slash your costs, because often it won't. There are linkages between all parts of your busienss - whether you think there are or not. As a result removing one part of the support infrastructure - such as, say, an inefficient department (think 'Customer Support Group') might, indeed, cut down your overhead. But at what cost? Perhaps the work performed within that department updates other parts of your customer information and as such removing it will leave gaps in your data and understanding. These gaps manifest themselves as problems later on in your process - problems which will inevitably take longer (and cost more) to fix than you saved by canning the department. Use something plain and simple to document your high level business. Start with brown paper and post-it notes if you want. Transfer this to (eugh!) Visio for a pretty picture (or even worse, Powerpoint). But whatever happens ensure you capture key information about the process: Inputs, outputs, responsible roles, work performed, and measures. When you've finished take a look and try to understand simple things such as "Does all the output from process A go somewhere else?" If it doesn't, why are we producing this? "Does all the input needed for process B come from somewhere else (in the right format to be used)?" If it doesn't, then what part of the process should be in place to make this happen? A simple model of your business (even at a high level) will ensure you have an overview of the impact of removing or changing one part at the expense of the others.

Use BPM to manage your business case justification and measurement processes. This relates, primarily, to identifying those parts of the business which would merit being shut down (or, contrarily, those which are marked for shut down but which shouldn't be). A review similar to the one mentioned above will provide you with some valuable data to help you understand the key impact of a shut-down decision. Imagine being able to go into your CEO with some valuable BPM-sourced information which will tell him or her that the decision he or she is about to make regarding shutting down the internal market research department is wrong. With appropriate data you can prove that this decision might come back and bit him or her on the butt within 6 months because data from that department feeds directly into the marketing function and effects targetting of marketing dollars (as an example). There are other examples where this would be apropriate. The key here is to make the decision on the basis of a gestalt view of the business rather than just a narrow, money based view of a single department.


Identify processes where costs may be high and there is not a focus on measurement. Target one of these processes for your first or next BPM project, and demonstrate tangible results. What you don't know about your processes may be costing you money. I think this is very much linked with the second recommendation. If you have followed that recommendation and documented your business processes (even at a high level) this is the opportunity to identify high-cost processes. It involves doing a little more work (or getting someone in to do the work for you) and digging a little deeper. But at the end of the day it then becomes a strict mathematical equation to understand which process costs you more, or which ones do not have the appropriate level of measurement. Target these processes and put together a small, focused, project to solve the problem. It will reap dividends.

Summary:

As Elise at Gartner says "BPM can be a powerful tool that plays a critical role in the survival
of your company — it can reduce costs, ensure compliance, avoid mistakes and create the visibility needed to manage processes as assets to your enterprise." Who am I to argue?

I would encourage you to read the Gartner report, understand the detail held within it and read it in context with the advice offered here. It is possible that the thing that is stopping you from looking at BPM in your organisation might not be barrier to entry at all. In these days of reducing income and increasing costs, can you really afford not to look at ways to increase efficiency?

---

Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

What the heck is BPM? Really!

Image via Wikipedia

I'm spending quite a lot of time at the moment on Linked In. Specifically I'm looking at some of the group discussions going on there. One in particular caught my eye.

It was entitled "What do you think Business Process Management is?" and was started by Steve Towers (the instigator of the particular group I was looking at). Whilst it was a blatant attempt at gathering data for his organisation, the resulting comments were quite insightful and interesting.

Without going into detail (and there is quite a lot of detail relate to this including some quite heated discussions between a couple of individuals) the short answer is 'nobody knows'

That's right, nobody is able to provide a single, commonly accepted, and understood definition for Business Process Management that everyone can align behind it. I myself commented that it could be

A capability?
A buzzword?
An acronym?
A framework?
A fad?
All of the above?
None of the above?
Some of the above?

In fact the truth is that it is all of the above. And more. It is becoming pretty much all things to all men. In fact one commentor even mentioned that he thought it was about time to think about calling it something else (which I think is rather premature as it effectively means that though we can't define what something is we can redefine what something is called. Huh?! We might as well rename it 'Throat-Warbler Mangrove'* even though we have no idea what it is.)

I do see this as both a blessing and a curse. The problem with having something tightly defined and buttoned down is that it doesn't allow the ability to expand and become useful in different ways. After all a bird which has long thin pointy beak can only pick small insects to eat whereas one with a larger, curved beak can eat flesh, fruit and grains as well as being useful to defend when attacked by other predators. The same happens with something like BPM: If we define it to mean one thing and one thing only, when the market changes (as indeed it will) we then have to look at other definitions. This is the same thing that happened with BPR. It was defined to mean one thing and, as businesses evolved, they needed something else to cover the capability they were looking at. This is when BPM evolved.

Unfortunately, as you can see, we are now in the situation where we have moved to the other extreme. BPM is now so loosely defined that we cannot, effectively pin it down to mean anything in particular. A vendor will define it in one way. A user will define it in another. A consultant will define it in a third. In fact Garther themselves have recently changed the definition of their magic quadrant contents for BPM so even they are looking at this differently. This lack of focus is starting to affect the niche as a whole and needs to be brought under control.

Hopefully the BPM Nexus as a concept will try to start putting down some foundation work for this in the near future with the BPM Accord. Feel free to join in and influence this if you want. The more the merrier.

*Thanks to Theo Priestley for the 'Throat-Warbler Mangrove' reference

Related articles by Zemanta

• Process...The Key to Success (georgevanantwerp.com)

What happens if you win the lottery? (or 'The Single Point of Failure')

Recently I did some work with a small distribution company operating from the South of England and Belgium. We looked at their general process set-up in an attempt to understand exactly how well they were organised to manage and improve their processes capability.

I was working with their head financial person who, it appeared, wore many hats. She was responsible for running the whole financial department, approving expenses, managing suppliers, creating monthly reports and even helping recruit and train new employees. It seemed that every question I asked about how the company operated appeared to come back to this single individual.

Alarm bells started ringing in my head immediately for many reasons. As an ex-auditor this situation was prime for an exploitation of 'segregation of duty' control failures. With a little bit of application this single individual could raise a phony invoice from a 'new' supplier, approve the invoice and pay the money directly into her own bank account. A little bit of judicious accounting or an unfortunate 'lost document' or two would leave her tracks completely covered and enable her to continue this for some time.

However this wasn't what worried me most. The fact of the matter was that she was a single point of failure in the company. I asked her the question "Who would take over your role and run this company if you won the lottery and left the next day?". There was no answer to this question. (Actually the question I used to ask in this situation was "How would the company cope if you got run over by a bus?" but this is now deemed to be politically insensitive..) The real answer to this question is that companies will, generally, cope, but their efficiency and effectiveness will suffer in the short to medium term, as will their customer service and, more importantly, their financial situation. Imagine if one individual knows the bank account details, the cheque book locations, the outstanding creditor balances and the key contact numbers at creditor organisations, and then all this information is lost. As bills fail to get paid creditors will start to withdraw lines of credit, causing cash-flow problems. This can lead to further inability to pay creditors and staff and, ultimately, lead to the companies failure. Granted this is an extreme example, but it can happen.

I've come across situations like this before and they are usually a result of rapid expansion in a smaller company where the supporting back-office infrastructure growth hasn't matched the rest of the organisation leaving small groups of people (or single individuals) with lots of knowledge and power. For the companies it is usually easier just to rely on the key individuals rather than to bring in and train additional people to help spread the workload. The results (as we've seen above) can be disasterous.

If we translate this situation into a process one, what we efeectively have is a very human-centric process where multiple workflows route through a single individual. This individual performs key decision making as well as holding knowledge of key business rules (and business relationships). The impact of removing this knowledge is easily imagined.

So how can we make sure this never happens?

1) Ensure every individual in the organisation has a back-up. This person has the same access, information and span of control and can take over the role in an emergency
2) Regularly hand responsibility over the the back-up individual to ensure they can cope with any issues that may arise
3) Re-design your business processes to allow multiple processing routes rather than channeling everything through a single person.

Now look at your own internal processes and imaging what would happen if everyone there were replaced by someone else in the organisation. Would your company survive? If it wouldn't, where are your single points of failure in the process?

Find them and fix them.

(Photo courtesy of Sergis Blog. Released under a Creative Commons Attribution licence)

Building the Business Case for Process Management

It's a sad fact that in today's business environment, 'The ROI' is generally king.

Unless you can provide a compelling business case for business process management you are unlikely to be able to gain any credence or acceptance for that. And when I say a compelling business case this refers to a quantifiable positive impact on the company's bottom line.

Unfortunately, like 'quality' as a concept, business process management (not Business Process Management) is something that everyone can agree to in principle, but which tends to fall down when actual figures are produced.

The problem is the nebulous nature of the topic. It is much easier in a business to look at something concrete - such as a manufacturing site building being created, or a new CRM application being added - than it is to look at 'a process capability', and justify it on a dollar (or Pound Sterling/Euro/Yen) basis.

Don't get me wrong, it's very easy to quantify the cost of doing something. This is created from adding up training costs, software installation and maintenance costs, consultancy costs etc. and arriving at a bottom line figure. What's more difficult is arriving at a figure for savings.

Although that's not always the case.

Take, for example a manufacturing line that is experiencing issues with rework. Each piece of rework is costing the company an amount of money. By recognising the process issue behind this and resolving it with process improvement it is easy to arrive at a cost saving. But not all businesses are like that.

I'm working with an organisation at the moment who have just received venture capital to allow them to expand. Their VC's have mandated a tripling of turnover within 3 years as a result of the cash injection. Obviously that can't be achieved purely by increasing business, costs have to be decreased too. This is a case where managing and understanding the processes has to play a part.

But I can't build the business case.

The reason I can't build the business case is that I can't know what I need to know about the company until I've been in and seen it ,and I can't go in and see it until the business case has been created to allow me in there. It's Catch-22.

So how can we solve the problem? How can we build a business case for process management that focuses on tangible items a CEO can understand?

Let me propose a couple of suggestions:

1) Identify a recognised need for understanding and managing your processes. Let's say, for example, that you were looking to outsource a section of your organisation. Understanding the processes that are supported by that part of the business would enable you to be better prepared to handle outsourcing discussions. Understanding exactly where the responsibility is passed to the outsourcing company and exactly where it comes back to your organisation has to give you a financial advantage.

Assign a notional value to each 'transaction' (i.e. if the outsourcing company is managing your Accounts Receivables, divide the cost of outsourcing your AR department by the number of transactions dealt with in a year and this will give you a notional value per transaction. If you don't know how much the outsourcing is going to cost you, use the cost of your AR function from last year). Divide that figure by the number of 'steps' or 'handoffs' each transaction goes through. This will give you a notional cost per process step. Now realise that each time a transaction has to go through one of these steps it is costing your company $x. Now look at the amount of rework that is being performed at the moment. Multiply that by the notional dollar cost and this will give you the amount that bad process is costing. It is generally all bad process that causes things like that to happen.

2) Identify a target saving. Assume that at present you are in an organisation that has an overhead of $xM. Target a particular saving against that which you would like to come as a result of process improvement (say $0.25M) This will give you the top line of the business case. You can then start to understand the bottom line of the business case by identifying the factors mentioned earlier (training costs, software installation and maintenance costs, consultancy costs etc). Subtract the two and that's your business case. The downside of this is that it is not always feasible to assume that the target saving can be achieved through process improvement. Sometimes the figures are just outlandish!

The benefit of this type of proposal is that once the initial costs have been saved, the capability that has been implemented to identify and improve processes can be applied to other parts of the business at a very small incremental costs. This is a key differentiator between process improvement projects and other types of projects: Once the capability has been created, it can be applied to other parts of the organisation with minimal incremental cost.

Summary

I answered a similar question recently on Linked-in which was asking how to convince a CEO to subscribe to Enterprise Architecture. My reply to that was quite simple: "Take your nearest competitor and analyse what advantage they would have over you if they could make strategic decisions and implement them in half the time you do. Then ask your board why you wouldn't put in something that would enable you to do that. EA can enable you to do that" Maybe the business case for process management is along the similar lines "Take your nearest competitor and analyse what advantage they would have over you if their processes were slick, streamlined and manged efficiently Then ask your board why you wouldn't put in something that would enable you to do the same with your processes"

Sometimes it just needs someone to show the leap of faith in starting the ball rolling.

---

Reminder: 'Doing Business Process Work in your organisation - A white paper' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this free download.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

The Value of Process Driven Architecture

Being a process person and an ex-enterprise architect (Check out my Linked-In CV for more details), I was very interested to read Aristo Togliatti's article on the Value of Process Driven Architecture.

Aristo is referring to the intersection of process management and SOA where the architecture around understanding and governing processes must be robust enough to physically drive the change rather than being passive. It's the difference between documenting what the process is and using the process to drive change.

I've blogged about this in the past when discussing the linkage between documenting processes and managing processes and this article summarises it very succinctly.

I am also very pleased to see mention of the need to have appropriate governance in the form of a process owner, something else I have been extolling in this blog.

Take 5 minutes to read this if you have time. It's well worth it

Forrester Reports on BPM

Our good friends at Forrester have released a free report called 'The EA View: BPM has become Mainstream" by Ken Vollmer. It is a wide ranging but quite detailed report summarising research and surveys carried out at the back end of last year.

It's worth a read if you have the time.

However, it does fall prey to a couple of the things that are personal bugbears for me when it comes to processes and BPM

1) It surveys what people are currently doing rather than what is the right way to do things. In an environment where many different people are doing things different ways, and in a maturing market, there will always be different ways of doing things, some right, some wrong. A report like this does not include any recommendations on which is the most effective way of doing things, rather what current people are doing. How am I supposed to know if I'm doing things the best way in that case? For example it mentions that the top two most widely used BPM vendors are IBM and Microsoft. Now the last time I looked, both of these companies where in the operating system/ software business and one of them was in the hardware business. Are they really the best companies to use for BPM work? Maybe the are (and this is said with no prejudice at all towards these two companies), but just because they are the biggest doesn't necessarily mean they are the right ones to use. (Interestingly it was mentioned that on average each respondent to the survey was using 3.5 BPM vendors. Another interesting statistic)

2) It talks about metrics giving details of which metrics are used to measure BPM success. From my post on Comerford's Three Laws of Metrics you will no doubt remember that I said (amongst other things) "Metrics for the sake of metrics are a waste of time". Looking at the Forrester list I see that the top 4 items were Process cycle times, customer satisfaction, risk reduction and process error rates. Of these four I, personally, feel that process error rates and cycle times are metrics for the sake of metrics. Why would you want to measure the fact that your process is producing a number of errors? Does it matter? (Of course it matters, but the question is what percentage of the processes are producing errors? That's a more useful measure). Cycle time is also another misleading entry. Why would you measure the fact that your process cycle is now 45 minutes? So what? A more effective measure would be cycle time reduction. 'My cycle is now 70% quicker than previously'. That adds value and that's the sort of thing that would look good on a management dashboard. Interestingly enough 5% of major companies over $1b revenue were not measuring their BPM success

As I mentioned earlier, this is worth a few minutes of your time to read and digest.

But as with all 'survey based findings' take the results with a pinch of salt.

Why your process project will fail

Here's the problem with most companies when they try to implement business process management.

Nobody owns the processes.

If nobody owns the processes then nobody owns the management of them, nobody has accountability for them, therefore nobody cares if they don't work correctly.

Now don't get me wrong: the project manager owns the project, the business sponsor sponsors the project, and the project team members do the work, but when the project has been implemented and the folks have moved onto the next big thing the company is left with a set of (hopefully) well defined processes which work well but which nobody has the job of looking after.

I'm not saying that nobody is concerned about the processes, however. For example there will be somebody in the customer service department who will be looking at his objectives for the year and seeing that he has to manage customer complaints within a set period of time, and therefore he will do whatever he can to get this done. This may involve circumventing 'difficult' parts of the process (such as reviews or approvals or paperwork) or even creating sub-processes that help him work more how he wants to work rather than how the process was designed. And because nobody at a more senior level has been given responsibility for that process, that's how it will continue to be handled until suddenly all the parts of the process have been altered from their original design and now the whole (gestalt) process doesn't work.

So what went wrong? Governance!

Historically in companies (especially large companies) different parts of the organisation evolved along their own lines into what they felt was the best way of doing things. Finance did things their way, Manufacturing did things their way, Sales and marketing did things their way. Everything was fine because each part of the process evolved to work alongside the other parts. But at the end of the day Manufacturing were responsible for Manufacturing processes, Marketing were responsible for Marketing processes and Finance were.. well, you get the idea.

With the advent of business process re-engineering, or BPM or just plain process modelling, the demarcation lines between the different functions became less and less obvious. As we start to look at product life cycles, the functional view of processes no longer worked. Suddenly a single 'business' process starts to cover multiple 'functional' areas. Manufacturing and Marketing needed to to start working together and be part of the same process.

Which is where the problems started. Or rather, this is where a lack of governance caused problems to start appearing. Who owns a business process that covers Product Development, Manufacturing, Marketing and Sales? Who is held ultimately accountable - in their performance objectives for the year - for ensuring that the different functional silos work together on the process?

If you are in this situation now and cannot answer that question then your process improvement project will fail. The unfortunate thing is that even if you can answer that question, your process improvement project may still fail because the wrong person may be in that role or the supporting governance process to enable her to do that may not exist.

Process governance is all about managing expectations and arbitrating between different factions. It needs someone with senior level responsibility (ideally at a global level in a multinational organisation) who has the authority to say to several different functional areas 'No, this is how you will do it'. It needs a set of governing processes which can manage requests for change in a business process, and it needs representatives from all the affected areas to be included. If you miss even one of these things you will find it very difficult to get appropriate governance implemented.

That's not to say that it has to be a big, complex process, or that it needs to add a large overhead to the running of the organisation. At it's very basic you get all the players involved to review a proposed change, define what impact it will have and either approve or reject it. Majority rules. The more complex implementations of this are run by committee's with representatives from each area who negotiate the changes with each other. It can be as simple or as complex as you wish

But at the end of the day you need to be able to ask and answer the following questions

1. Who is the process owner for this overall process within the business


2. How do I get this process changed?

If you can answer these two questions you are probably well on your way to having good process governance.