Progress. It is inevitable.

I was reading an article recently on the progress being made in the manipulation of electronic data on film sets ( I know, right...). In particular the article was talking about how the current methods of dealing with digital film are something that vary between films, film-makers and equipment. In effect many high-profile film-makers are creating brand new workflows for each of their films depending in who they are working with and what equipment they are using.

The new breed of digital cinema cameras (Alexa, Red, Sony, Black Magic) are all slightly different in the way they deal with the pixels. As a consequence they all need to be dealt with in a slightly different manner once the scene has been shot. There is a world of work that might need to be done to take the electronic data stored in a (sometimes proprietary) storage device and turn that into something that can be accessed by an editor on an NLE (non-linear editor), such as Final Cut or Premier Pro. On top of this the storage and processing needs are becoming increasingly large. Consider the recent film The Hobbit which shot 3D scenes at 4k resolution at 48 frames per second, and compare that with, say Skyfall that shot on the Arri Alexa on 2D at 24 frames per second with a frame size of a little over 1080p. To put it another way each second of The Hobbit needed almost 16 times as much storage as Skyfall. That's a huge amount of data to be manipulated.

Added to this is the fact that "The Hobbit" shot on Red Epic cameras which use a different proprietary format to the Arri Alexa used on Skyfall, and you have a completely different workflow needed to deliver the bond film than the Middle-Earth tale.

Is this a good thing, though?

Let's go back and look at things as they were before digital cameras arrived. Someone would buy some celluloid film, rent a camera (several types were available but they all did exactly the same thing), expose the film on set, send it to someone like Technicolor to be developed, and edit using the footage sent back from there. It took a day or so for the footage to be developed, but everyone went through the same process. Sure, there were permutations you could follow (Janusz Kaminski famously 'flashed' the film stock on Saving Private Ryan prior to shooting to help create the Beach- bypass look which gave it it's distinct appearance. It also locked the film-makers into a specific look throughout the movie), but the process was, essentially, identical the world over.

Then we got to the stage where digital effects need to be inserted into these movies. It involved an extra couple of steps to make this happen. The exposed celluloid was scanned into a computer whereby the scenes needing digital effects (i.e. a dinosaur inserting into the scene) could be manipulated on a computer. Thereafter the finished scene would be printed back on to celluloid and edited into the film with all the other scenes.

This worked for a few years until the technology caught up again. During the making of the Star Wars prequels, George Lucas specifically shot certain scenes on digital cameras to see if anyone would notice which were which. Apparently very few people did. This allowed him to take the step of shooting the final prequel completely digitally.

That was when the rush started towards digital. Some of you may know that I also spend a lot of time on film and television sets, and have done so for about six years now. Over the last two years I cannot remember a production I have been involved in that has shot anything on film. Everything is now digital. The Arri Alexa is the camera of choice and each one has a small team of operators who are responsible for taking the data on the storage media and processing it so that it is suitable for the editor to review.

In terms of personnel, the camera team isn't much bigger than it used to be. The person responsible for lugging the huge film magazines around has been replaced by someone who is responsible for the digital data cards or drives. But, whereas the film used to get sent to a processing lab, the digital storage is now given to a DIT or similar. This is a group of people who have responsibility for taking the raw camera footage and backing it up before erasing the storage media so it can be used again later in the shoot. They also take the backed-up data and synchronise the sound (recorded separately) as well as logging the contents of the footage to enable the editor to work efficiently and find what needs to be found. So, overall, the number of people needed on the crew has increased. If you are a low budget production this means that you need to either get someone else in to provide the service detailed above, or you need to be multi-skilled and have the basic knowledge and equipment to do this as part of your workload.

I shot a corporate video recently where I was both the director and the DIT specialist. I purchased a separate backup device and made sure that at the end of the day all of the footage was offloaded to this device and a separate hard drive (dual redundancy), as well as logging the shots so that editing knew what was where. It certainly made for long, busy days on the film set!

So what has this got to do with process? Well, the sharper minds amongst you will have noticed that there are two facets that should be looked at here. The first one is the fact that different cameras and different people have different post-processing workflows. In an ideal process world there would be a common workflow amongst all cameras. Additional to this we have the issue of different players needing to be involved to enable the process to work ( or at the by least having performers with multiple skillets to enable the work to be done). Neither of these is ideal from a process point of view.

But we must ask ourselves whether this is something that needs to be the case. As technology has evolved, are we in the situation where the cameras themselves can make the workload easier? In a recent blog post an owner of a DIT company has said that he expects technology to move on at such a rate that his company will not be needed in three or four years. he expects the camera to have a large amount of the functionality built in to it.

Does this mean that the current processes set up to deal with things like this are wrong? I think it means they are immature. Of course the process professionals amongst would like more standardised handling of digital data - and no doubt the film crews and production companies would also like to be able to handle things the way they did in the old paradigm of celluloid. but until the types of data, the amount of data and the storage media are standardised, there are always going to be some sort of workarounds and camera specific actions that need to be performed. Does this make the process wrong? No, But it makes it less efficient.

Things will mature and standardise. They always do.

---

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

Standards.

I’ve written on this blog before about some of the issues and problems with BPM as a concept and implementation of these concepts. Mainly the issues can be boiled down to a few key items: Lack of correct change management. Lack of Executive Sponsorship. Lack of ownership.

The key thing that these have in common is that they identify something that isn’t there - be it an owner, a manager, an objective. But today I want to talk briefly about something that is usually there - and often in too many different places to be useful: Standards.

Time for the obligatory anecdote:

Back when I worked with a pharmaceutical company we developed a set of standards that would be applied to technology across the organisation. These standards detailed the operating systems we would adhere to, the specification of PC’s we would use, the types of devices we would allow to attach to our networks etc. etc. This was referred to as “The Standards List” for obvious reasons.

However, there was one part of the company who believed that these standards didn't apply to them. They were always looking to use something different, or not use something on the standards list. They were applying for exceptions on a regular basis and getting these approved. It helped that they were a large part of the organisation with a huge budget and some political clout at the CIO level.

But the result of this is that we, effectively, ended up with two lists. There was “The Standards List” that was used by 90% of the company, and there were the exceptions that were used by the remaining 10% (usually this one functional area)

In effect we had two sets of standards. Which, in effect, meant we had no standards. Because it then became known that if you wanted to bring something into the organisation that was non-standard it could be done because there was a precedent. You only had to say ‘This area uses Mac computers on our networks so we want to use them as well - it’s on the list', and we couldn’t stop you.

Why are standards important?
While each department had a perfectly legitimate reason for wanting to bring in something that was non-standard, it did create a problem that was one the standards list was trying to avoid - maintenance and associated costs.

One reason why the company decided on Windows 2000 (at the time) as the standard for desktop operating systems was because we had agreements in place with Microsoft to supply the software and associated upgrades. These were then placed on a disk image which would be quickly and easily replicated onto new machines. Centralised software roll-outs were also provided which meant that a new piece of software could be rolled out to the 30,000 pc’s in the company virtually overnight and under controlled circumstances. All this resulted in lower maintenance costs for the organisation.

However, once we started to allow Ubuntu and MacOS into the company we had to add new steps to our maintenance processes. These steps were exceptions to the standard. They cost time and money to implement and they slowed down software roll-out and burned resources at a time when the company was resource constrained.

Of course these costs were not born by the department that requested the exceptions. These costs were born by the support organisations that had to roll out new software and manage the desktop environment. These costs came out of their budget. They cost the company money it didn’t have.

I suppose it would have been easy to take these costs and bill them back to the appropriate department and make them feel the pain (and in fact I believe that’s what they did towards the end), but this merely resulted in justification for the departments who then took the view that “If you’re billing us for maintenance of our own systems why should we adhere to your standards anyway? We might as well do our own thing”. As a result they created a parallel support organisation which sapped overall costs across the company.

You can see the problem. It all came down to standards. Standards are there for a reason. They have been defined to allow consistency across organisations and allow ease of use and maintenance. It’s the same with process diagram notation. BPMN is a standard, as are TOGAF, Enterprise Architecture and Rummler and Brache. I’m not about to give any credence to one over the other, other than to say as long as you have made your choice and know what you want it doesn’t matter which one you use. But you must ALL use the same one in an organisation.

This can become particularly onerous when you are part of a company that has recently been bought by another company. You will, no doubt, have your own set of standards for many things in the business. The purchasing company will have similar. The chances of the two being the same are very small. So at some point there has to be a rationalisation. The two standards have to become one. This can either be through wholesale replacement of one set with another, or through the merging of the two into a third, common, standard. Either way the newly defined standard has to be accepted and implemented across the organisation.

But what is more important - and often overlooked - is a process for managing the standards. The set of standards you put in place when a business is two years old working in a manual environment manufacturing goods, for example, will not be the same set of standards used by that company after it has been running for twenty years and has automated many manufacturing steps. The management of that evolution should be in place as well. This is an area that is too often left to chance. Without a standardised process to manage your standards, you will end up with a process of half-measures. But you will have a process.

But I’m not sure it’s a process you really want.

---

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

Selfishness and Process.

Back in the mists of time I used to have a valid private pilots licence (PPL). One of the things I wanted to do was get a share of an aircraft so I could increase my flying hours and learn more about this great pastime of flying. I inquired at the local airport and found a great little plane that was within my price range at the time.

But when I looked into the small print of the costs there appeared to be something which - at first - struck me as strange, but than raised a red flag.

As a bit of background: when using a plane there is always a cost involved. This cost varies depending on whether you own a piece of the plane or are borrowing it without an equity involvement. But regardless of whether you are, or are not, there is always the cost of fuel that needs to be factored in. In many cases you take the plane, use it for however long you want and then fill it up when finished, at your own cost. In some instances you can fill it up on a company account and it gets charged to your costs or - and this was the case with the plane I was looking at - you were charged a fixed amount per hour for fuel, regardless of what you used.

The problem with this was the behaviours it promoted. Imagine the situation: regardless of how fast or how far you fly, you are going to be charged a set amount of money for fuel. This was not an insignificant amount either. It equated to 55 litres of fuel per hour for a single engine Cessna. (That's pretty much the same amount of fuel as my road car uses in about 8 days - and aviation fuel is more expensive). So in that situation, would you take it easy with the plane? Would you lean the fuel mixture to be as conservative as possible? Or would you just slam those throttles open and scream across the sky as fast as you could and as inefficiently as you could? Human nature would expect us to do the latter rather than the former. After all if there are ten people renting this plane in a week and they are all paying the same amount per hour, why should you be the one who only uses 75% as much fuel as them but still gets charged for 100%?

There was a knock on effect of this, too. The amount per hour was calculated on the average fuel usage that the owners of the plane were being charged. (They paid for all the fuel themselves and offset it against the hourly fuel rate). But the rate they set was based on current behaviour rather than future expected behaviour. Which means that after a few months of running at the new fuel amount (55 litres per hour), they discovered that they were actually paying for 70 litres per hour of usage (for example). Therefore the owners were losing out on this deal. So what did they do? That's right, the increased the hourly fuel charge to 75 litres regardless of actual usage.

Can you see how this would then become a bit of a problem? The upshot was that a lot of the guys who were renting the plane found that the fuel cost became prohibitive (even though they were using that much fuel per hour), and stopped flying. The owners then started to lose out on the rental charges for the plane. When it came to doing routine maintenance such as replacing the engine or the propellor, they found they had to stump up the money from their own pockets.

As I thought about this today I realised that there is a lesson in there from a process point of view. The process that was being initiated had measures or metrics that were - effectively - Key Performance Indicators for the whole process. They determined the efficacy of the process (after all, if the plane was using more than 55 litres of fuel per hour then the ROI on the process was reduced). But what had happened to this process was that it had become driven by the KPI rather than measured by the KPI. This was an occasion when the adage "What gets measured gets rewarded" did not apply. Quite the opposite intact.

The process had been designed with a flaw in it. The measure was inappropriate for the process. A more correct measure would have been to remove the fixed cost per hour and replace it with a variable cost based on actual usage. This added a small administrative burden to the billing process, but resulted in more flexible (and better run) flights, where the fuel usage wasn't excessive.

It might be worth having a look around your current process and seeing if there is anything in there which is working in a counterintuitive way. Do you have any process steps that are time dependent and allow a larger amount of time than is needed? Could you cut down that time to enforce the right behaviours of efficiency and speed? Could you organise your workflow in such a way that you are not encouraging unwanted behaviours from the participants.

You might be surprised at what you can change.

---

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

Dark processes and the implication for your business

Jim Sinur recently posted a piece which discussed Dark Processes. These are the unofficial processes used to deliver results that are not visible to management. Jim mentions that there are a number of ways Dark Processes (or Shadow Processes) come into being, these being - for example - when a variation is needed in a process that has no flex, or when an IT limitation inhibits the ability of a process to work as required or - my personal favourite - because Old Habits Die Hard. I wrote something akin to this a few years ago when talking about “The Way Its Always Been Done”.

Jim finishes up his piece by saying

“Dark processes are here to stay. Let’s not fear them, but reduce the number of opportunities to create and feed them for no good reason. Intelligent business operations allows for intelligence built into processes to reduce the need for dark processes.”

I couldn’t agree more.

What does this mean?

But lets have a look, for a moment, about what these dark processes mean for your business, shall we?

• If you have a process which is inflexible enough to deal with variation, or where IT inadequacies have put some sort of constriction on the ability of people to do their job, you will get a shadow process building up. I have encountered these in many, many organisations. 
• If you have a finance department that uses Excel as a means of creating management information using data imported from your ERP and ‘manipulated’, than you have a shadow process.
• If you have employees keeping paper records of transactions with customers because the customer wants something that the system can’t appropriately handle, you have shadow processes.

The existence of shadow process do - in themselves - indicate some sort of underlying issue that needs to be dealt with. Why is an employee having to record transaction off the books to assist a customer? Why are the finance department recording different figures for MI than are shown on the system?
Sometimes the issue is simple. In the case of Finance it could be that they are taking figures from several systems and using Excel to amalgamate and ‘pretty them up’. But sometimes there is a deeper-seated underlying reason.

I worked at one organisation that took centrally affiliated reporting criteria and ‘massaged’ the figures each month in Excel prior to submitting them to corporate for review. The reason was that they were accounting for things in a none standard way and knew that taking the figures directly from the system would show them as having sold less than they actually had. Rather than change the way they accounted for things they decided to alter the figures instead. This resulted in a shadow process which allowed them to do what they needed. The issue came to a head when I implemented a new financial system that allowed all figures to be queried centrally without the affiliate themselves doing any manipulation of the data. That particular shadow process didn’t last long.

How do you remove them?

But overall a shadow process needs to be identified and the underlying cause removed. But how do you do this?

As Jim himself says:

Intelligent business operations allows for intelligence built into processes to reduce the need for dark processes

What this means, in my opinion, is that when new processes are put in, adding a sensible amount of intelligence into the processes will reduce the scope for a dark process to appear. But this doesn’t remove the existing ones that we haven’t found yet.

Identification of a dark process is - by definition - quite difficult. If you knew the dark process existed you would try and stop it (or understand why it exists).

One solution is the one listed above: replace their process with another one and see what breaks. That’s a little radical for my liking (but very effective)

Another slightly less radical way of doing this is to put someone new into the role and ask them to report back to you with their impressions of what happens. You can compare that with what should happen (You do have documented your processes, right?) and identify the discrepancies. But this isn’t always the best thing to do. Employees get distrustful when you suddenly introduce someone new to the company, and rightfully so in this case.

No, the easiest way to identify a shadow process is to go, systematically through your existing processes and document them appropriately. That way you will understand what the employees are actually doing rather than what they think they are doing.

I facetiously asked earlier in this post “You have documented your processes, right?”. In actual fact this appears to be a key factor in understanding where dark processes occur. Get your users into a room, start to ask them what they do. Work through the details until you understand the points at which the current process breaks down. Sure, it'll take a while, and probably cost you a fair amount of money. But compare that with the amount of money you're losing by having the processes there in the first pace and you'll understand the importance of doing this.

Summary

We know they're there. We know they're happening. Understand that they happenmand understand why they happen. If you can life with that, fair enough, go ahead and do what you do. But if you think the dark processes are costing you time and money (and they almost certainly are) then you need to start looking in detail at where they occur and trying to stop them.
It's the only sane thing to do.

---

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

Who's your vendor? And why?

New BPM systems

Everybody sees them. Everybody knows about them. It seems that a week doesn’t go by without some new system coming to market.

So the dilemma which exists for a prospective purchaser of these systems is “How do I differentiate between all these systems?”. In previous posts I’ve looked at some of the criteria that are used for selecting these tools, but at a more macro level I’m interested in understanding what it is about one software company that will encourage you to work with them over a software company which has a broadly similar offering?

As an example: If I worked in the sales department of a major multinational and I needed a CRM tool, there are a number of tools I could use that are on the market. Some are stronger in one area relative to another, but overall they are very similar in what they do and how they do it. Price is always a factor when it comes to software packages, but as the size of the company increases, the price factor lessens (after all you’re going to be spending millions on the project it doesn’t really matter if it costs £1000 per seat or £2500 per seat). So what is it that I would look for in a company that I am going to work with on a large project such as a BPM implementation?

Possible options

1. Is it the size of the company itself? Would you work with a smaller company if it could convince you that it was more agile and responsive to your needs?
2. Is it the track record of the company? Does it need to have had many similar implementations with companies your size before you will even look at it? If this is the case, how is the company meant to get started with doing this as it appears to be a Catch 22?
3. Is it the people you deal with? Mostly - when looking at software tools - you end up dealing with sales people or folks from the marketing or pre-sales team. They are trained to be polite and helpful, and in many cases will promise things that in reality might be difficult to provide. They are usually very pleasant people but they aren’t going to be the ones your project is dealing with after the contract is signed.
4. Is it case studies? Do you look for organisations that can provide case studies which align with the kind of things you are looking to do by implementing your software package or finishing your project?
5. Is it references? Do you try and speak to other companies that have implemented this tool? Does it matter if a company cannot produce these references?
6. Is it accolades from research organisations such as The Gartner Group or Forrester? Lots of organisations subscribe to research provided by groups such as this and they provide “Magic Quadrants” and “Wave” diagrams which identify the top vendors in particular market areas. How much influence does this have on your thinking?

Summary

I’m very interested to understand what it is that helps influence a project to decide on a particular software vendor. Any of your thoughts would be greatly appreciated.

The BPM Project - What's next?

It seems in the world of BPM that we end up with something cool and new every so often, or some major software update/release on a regular basis and yet - despite the best efforts of many people - I don't think anyone has solved the undying problem of getting BPM into the organisation at the right level

I've talked in the past about BPM by stealth, where I have implemented BPM at a low level in the organisation as a means of seeding the capability in the business. This can then lead to growth at a larger level. The downside to doing that is that we end up with BPM being implemented in several smaller “bottom-up” implementations. These are better than nothing, but can lead to silo mentality in the organisation. Ideally we would enter the business at the top level of Management and get buy-in and sign-off at the board level to implement across the organisation. Obviously this is a major nut to crack when trying to put forward the Tao of BPM, but I believe it is one thing that is absolutely vital to happen

The problem is that the benefits of BPM at this level are not always obvious. The work involved in documenting and managing a whole enterprises process is huge. It is, without doubt though, the best approach to take. This can be either with an outside-in approach or an inside-out approach (and the merits of each of these are discussed endlessly across the BPM world). But holistically the benefit to the organisation has to come from integrating and managing the whole of the business, not just small silos.

The problem is that the huge amount of work involved in doing this is something that the top level of management will often baulk at approving. Because, despite the amount of work and effort that we in the BPM community have put in to promoting the benefits of our product, there is still an approach held by many vendors that implementing the software solution is the aim of BPM. This means that the focus is on the nuts-and-bolts of BPM/BPMS systems rather than the holistic approach of ensuring the best thing is being done for the business.

And I can understand why. When the CIO looks to the project manager to see how the project is progressing he’s going to want to see metrics reflecting the successful implementation of licences or affiliates/sites to a particular software tool. After all, nobody ever got promoted from project manager because the project they had for implementing an ERP system successfully reviewed how six affiliates could improve their cash-flow. They got promoted because they actually improved the cash-flow and implemented something to make sure this happened (usually a piece of software).

The same thing happens in BPM. Projects are deemed to be successful not because somebody was able to improve a process (even though that is the end result of the work), but because a piece of software was implemented and the users are using it.

I worked for an American multi-national organisation for some years and they replaced their ERP system with a competitors tool. The competitors tool was no better than the one they had in places already (in fact in some respects it was worse). After several years of work the global organisation had created ancillary processes and work abounds to deal with the fact that the required software didn't work. Overall the project was a waste of a large amount of money and the benefits were never going to be materialised. BUT, the software had been implemented successfully across the globe and the  project was deemed a success. We can argue for days about the relative merits of different pieces of software and whether the project should have been approved at all, but this doesn't change the fact that the negative aspects of the implementation (frustration, need for work around, user dissatisfaction etc) we're outweighed at the senior management level by the fact that software had been successfully implemented. This was despite the fact that the company was (allegedly) spending over $100,000 per week on external consultants to do this.

I was in meetings recently with a software vendor and we were discussing the barriers that they were hitting when trying to get their software into various businesses. It fell very neatly into the points that I have raised here in this post, namely: We want to get in at the top but were being forced in at the bottom level

So how do we get the business to understand that BPM as a capability is an enterprise-wide requirement rather than a project specific need? How do we get the CIO to sign-off on implementing BPM across the organisation rather than approving just a project to implement software?

It's the million dollar question (quite literally).

Here's my solution: We don't.

This is like the old eastern saying “How do you eat an elephant? One piece at a time”. We can't go around trying to push the CIO’s into doing what we want, anymore than they can push their boards into doing what they want. There is always a cost/benefit that needs to come with projects like these. This is the reason the software implementations are always looked at from a deliverables point of view. Tangibles are the thing that the CIO will be looking at. A process is not a tangible thing that an be seen and held for inspection (although some would say that a process diagram is a tangible, and I accept that).

The simple fact of the matter is that I don't think the software vendors are doing a good enough job of selling BPM as a concept to C-level management. They seem to think that showing an expense claim process with the appropriate approvals and routing will convince a CxO to spend a fortune on putting such a thing into their organisation. It won't. What the vendors and the consultants - and I include myself in that group - need to do is to position the capability of BPM as a prerequisite to implementing a tool or solution. They need to be able to enumerate the tangible benefits to having a good BPM capability in an organisation, and they need to be able to show good case studies about where this has happened and what the benefits were. A good case study is not a vendor-provided example of where their software has caused a company to become mildly excited about the potential. A good case study is independent, non-vendor specific, and covers more than just the software solution.

Only then will we be able to go to the CIO (Or any other member of the board) and show them why they need to be looking seriously at BPM.

Or am I completely off-base? 

---

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