Like me I am sure that you have been inundated with ads, articles, white papers and proposals for something called BPM or BPO, Business Process Management, Business Process Outsourcing and Business Process Optimisation.

Do you really understand what it all means?

BPM and BPO certainly aren’t new, there have been many companies offering innovative and often cutting-edge technology solutions for many years. The pioneering days were probably the early 1980’s. One early innovator I can recall (and admired) was Tower Technology because their office was just across from our old offices in Lane Cove.

In the early days BPM was all about imaging and workflow and forms. Vendors like Tower Technology used early version of workflow products like Staffware and a whole assortment of different imaging and forms products to solve customer processing problems. It involved a lot of inventing and a lot of creative genius to make all those disparate products work and actually do what the sales person promised. More often than not the final solution didn’t quite work as promised and it always seemed to cost a lot more than quoted.

Like all new technologies everyone had to go through a learning process and like most new technologies, for many years the promises were far ahead of what was actually delivered.

So, is it any different today? Is BPM a proven, reliable and feature-rich and mature technology?

The answer dear friends is yes and no; just as it was twenty-five or more years ago.

There is a wonderful Latin phrase ‘Caveat Emptor’ which means “Let the buyer beware”. Caveat Emptor applies just as much today as it did in the early days because despite the enormous technological progress we have all witnessed and experienced we are still pushing the envelope. We are still being asked to do things the current software and hardware can’t quite yet handle. The behind the scenes technicians are still trying to make the product do what the sales person promised in good faith (we hope) because he didn’t really understand his product set.

Caveat Emptor means it is up to the buyer to evaluate the offering and decide if it can do the job. Of course, if the vendor lies or makes blatant false claims then Caveat Emptor no longer applies and you can hit them with a lawsuit.  However, in reality it is rarely as black and white as that. The technology is complex and the proposals and explanations are full of proprietary terminology, ambiguities, acronyms and weaselly words.

Like most agreements in life you shouldn’t enter into a BPM contract unless you know exactly what you are getting into. This is especially true with BPM or BPO because you are talking about handing over part of your core business processes to someone else to ‘improve’. If you don’t understand what is being proposed then please hire someone who does; I guarantee it will be worth the investment. This is especially true if you are outsourcing customer or supplier facing processes like accounts payable and accounts receivable. Better to spend a little more up front than suffer cost overruns, failed processes and an inbox full of complaints.

My advice is to always begin with some form of a consultancy to ‘examine’ your processes and produce a report containing conclusions and recommendations. The vendor may (should) offer this as part of its sales process and it may be free or it may be chargeable.  Personally, I believe in the old adage that you get what you pay for so I would prefer to pay to have a qualified and experienced professional consultant do the study. The advantage of paying for the study is that you then ‘own’ the report and can then legally provide it to other vendors to obtain competitive quotes.

You should also have a pretty good idea of what the current processing is costing you in both direct and indirect costs (e.g., lost sales, dissatisfied customers, unhappy staff, etc.) before beginning the evaluation exercise. Otherwise, how are you going to be able to judge the added value of the vendor’s proposal?

In my experience the most common set of processes to be ‘outsourced’ are those to do with accounts payable processing. This is the automation of all processes beginning with your purchase order (and its line items), the delivery docket (proof of receipt), invoices (and line items) and statements. The automation should reconcile invoices to delivery dockets and purchase orders and should throw up any discrepancies such as items invoiced but not delivered, variations in price, etc. Vendors will usually propose what is commonly called an automatic matching engine; the software that reads all the documents and does its best to make sure you only pay for delivered goods that are exactly as ordered.

If the vendor’s proposal is to be attractive it must replace your manual processing with an automated model that is faster and more accurate. Ideally, it would also be more cost-effective but even if it is more costly than your manual direct cost estimate it should still solve most of your indirect cost problems like unhappy suppliers and late payment fees.

In essence, there is nothing magical about BPM and BPO; it is all about replacing inefficient manual processes with much more efficient automated ones using clever computer software. The magic, if that is the word to use, is about getting it right. You need to know what the current manual processing is costing you. You need to be absolutely sure that you fully understand the vendor’s proposal and you need to build in metrics so you can accurately evaluate the finished product and clearly determine if it is meeting its stated objectives.

Please don’t enter into negotiations thinking that if it doesn’t work you can just blame the vendor. That would be akin to cutting off your nose to spite your face. Remember Caveat Emptor; success or failure really depends upon how well you do your job as the customer.

Most of us have probably become more than a little numbed to the onslaught of Cloud advertising and the promotion of the ‘Cloud’ as the salvation for everyone and the panacea for everything. The Cloud is promoted by its aggrandizers as being both omnipotent and omniscient; both qualities I only previously associated with God.

This is not to say that moving business processing to the Cloud is not a good thing; it certainly is. I just wish that the promoters would tone down the ‘sell’ and clearly explain the benefits and advantages without the super-hype.

Those of us with long memories clearly recall the early hype about what was then called ASP or Application Service Processing or even Application Service Provider. This was the early progenitor of the Cloud and despite massive hype it did not fly. The reasons were simple, neither the technology nor the software (application and system) were up to the job. Great idea, pity it was about five years before its time.

Unfortunately, super-hype in our industry is usually associated with immature and unproven technology. Wiser, older people nod sagely and then wait a few years for the technology to catch up with the promises.

As an older (definitely) and wiser (hopefully) person I am now ready to accept that all the technology required for successful and secure Cloud processing is now available and proven; albeit being ‘improved’ all the time so still take care not to rush in with experimental technology.

As with many new technologies the secret is KISS; Keep It Simple Stupid. If it seems too complex then it is too complex. If the sales person can’t answer all of your questions clearly and unambiguously then walk away.

Most importantly, make sure you know all about all of the parties involved in the transaction. For example:

1.    What is the name of the data centre?

2.    Where is it located?

3.    Who ‘owns’ the rack and equipment and software at the data centre?

4.    What are the redundant features?

5.    What are the backup and recovery options?

6.    Is your vendor the owner of the co-hosted facility or do they subcontract to someone else? If they sub-contract is the company they subcontract to the owner or are they too just part of a chain of ‘hidden’ middle-men? It is critical for you to understand this chain of responsibility because if something goes wrong you need to know who to chase.

There are a lot more questions you need to ask but this Blog isn’t the place to list them all. I am sure your IT team and application owners will come up with plenty more. If they don’t, wake them up and demand questions.

Most small to medium organizations today simply do not have the time or expertise to run a computer room and manage and maintain a rack of servers. There is also a dearth of ‘real’ expertise and a plethora of phonies out there so hiring someone who is actually smart enough to manage your critical infrastructure is a very difficult exercise made more so by most business owners and managers simply not understanding the requirements or technology. It often becomes a case of the blind hiring the almost blind.

Most small to medium enterprises also cannot afford the redundancy required to ensure a stable and reliable infrastructure. A fifteen minute UPS is no substitute for a redundant bank of diesel generators and a guaranteed clean power supply.

Why should small to medium enterprises have to buy servers and networks and IT support? It isn’t part of their core business and this stuff should not be weighing down the balance sheet. Why should they be devoting scarce and expensive management time to activities that are not part of their core business?

In-house computer rooms will soon be become as rare as dinosaurs and this is how it should be, they are an anachronism in this time and age; out of time and out of place.

All smart and business savvy small to medium organizations should be planning to progressively move all their processing to the Cloud so as to lower costs, improve service levels and reduce management stress. I say progressively because it is still wise to get wet slowly and to take little steps. Just like with your first two-wheel bicycle, it pays to practice with the training wheels on first. That way, you usually avoid those painful falls.

I like to think I am a little wiser because I still have scars from gravel rash when I was a kid. I am moving my RecFind 6 customers to the Cloud and I am moving my in-house processing to the Cloud but just like you, I am doing it slowly and carefully and triple-checking every aspect. I don’t take risks with my customers or my business and neither should you.

One last thing, I have the advantage of being very IT literate and of having a top IT team working for me so we have the in-house expertise required to correctly evaluate and select the most appropriate technology and options. If you do not have this level of in-house IT expertise then please take extra care and try to find someone to assist who does have the level of IT knowledge required. Once you sign up, it is too late. Buyer’s remorse is not a solution to any problem.

In a previous career with mainframes I spent eight years as a large scale project manager and then a further two years as the international operations manager managing a number of project managers at troubled projects around the world. Those ten years taught me a great deal about what it takes to be a successful project manager and conversely, why some project managers fail.

Notice that I said why some project managers fail, not why some projects fail. It is cause and effect; projects only fail when the project manager fails to do the job required. This particular concept separates good project managers from bad project managers. Good project managers take full responsibility for the success or failure of their projects, bad project managers don’t.

Good project managers are ‘glass-half-full’ people, bad project managers are ‘glass-half-empty’ people. Good project managers are leaders, bad project managers are victims.

So the first piece of advice is to choose your project manager carefully. You want a strong willed, bright and energetic doer, not a facilitator or politician. You want a strong leader, not a careful and political follower; you want Jesus, not the disciples.

The next piece of advice is that you should set quantitative criteria for project success. No ambiguity or motherhood or weaselly words, as the Dragnet cop used to say, “Just the facts Mam.” In my day it was easy, we had to install the new hardware and software, convert from the old system, design and program the new applications and then take the whole system through a 30 day acceptance test with 99% uptime. There was always a contract and the conditions of acceptance were always clearly laid out and assiduously referred to by the customer. We knew what we had to achieve and there was no ambiguity.

Unfortunately, one of the problems with a lot of projects is that the conditions for acceptance and success are not clearly articulated or documented. But, a good project manager will always make sure that the scope and objectives and expected outcomes are clearly defined regardless before accepting the challenge. The bad project manager on the other hand is always happy that there isn’t a clear definition of success because the bad project manager wants to make judging his or her performance as difficult as possible.

I once fired a project manager who told me in three meetings in a row that he had not completed the requested project plan because the project was too complex. Obviously the more complex the project the more its needs a comprehensive project plan otherwise it will be impossible to manage. My failed project manager didn’t want to document the project plan because he didn’t want deadlines and he didn’t want to be judged on how well he was meeting deadlines.

It sounds like an over-simplification but if you want a successful project then choose a successful project manager, one who accepts full responsibility for all outcomes and one who is committed to success.

As part of the interview process, ask them what their philosophy of responsibility is. As an example, here is one I always used.

“Everything that happens is due to me because everything that happens is either due to something I did or something I didn’t do.”

I have never found a good project manager who had a problem with this credo. Bad project managers on the other hand, see it as anathema to their survival strategies. Good project managers accept full responsibility for success or failure, bad project managers do not.

Good project managers also don’t spend all day in an office playing with Excel and Microsoft Project. Nor do they spend all day in meetings or on conference calls. Good project managers integrate themselves into the very bowels of the project and ‘walk-and-talk’ on a daily basis.

Walk and talk refers to the practice of meeting with real workers at all levels of the project, especially end users. Good project managers make the time to talk to end users every day and because of this they know more about what is happening than any senior manager. They are ‘in-touch’ with the project and are constantly aware of changes, problems and successes. Good project managers who practice the walk and talk technique are never surprised in project or management meetings because they always know more than anyone else at the meeting and they always have the very latest information. This is probably why they are such good project managers. If you aren’t prepared to invest at least one hour of your time every day walking and talking to real users then you shouldn’t be a project manager.

Good project managers also always know how to select and manage their team. Because they are natural leaders, management is a natural and comfortable process for them. There is never any doubt in a good project manager’s team about who the leader is and who will make the final decisions and then take responsibility for them. There is no disseminated responsibility. The opposite is always true in a bad project manager’s team with disseminated responsibility and no clear record of who made what decision.

The calibre of the bad project manager’s team is always significantly lower than that of the good project manager’s team. This is because mediocre people always hire mediocre people and a bad project manager is afraid of strong capable staff because he or she finds them threatening. A good project manager on the other hands loves working with strong capable people and revels in the ongoing challenge of managing them. A good project manager is never threatened by strong capable staff, au contraire; he seeks them out because they make it easier for him (or her) to be successful.

There is no magical formula that will ensure a successful project, completed on time and on budget and with all contracted deliverables accepted and signed off. It also doesn’t matter what project management tool you use as long as you do use a project management tool. I don’t particularly like the latest version of Microsoft Project (and that is an understatement) but if required I could use it to manage any project no matter how big and how complex. It isn’t the tool; it is the person that counts.

This is simple advice like my favourite about how to do well on the stock market, “buy low and sell high.” If you want a successful project, always start with a successful project manager. He or she will take care of everything else.

Workflow has been defined as “the glue that binds business processes together.” Depending upon your background and experience that particular definition may or may not be as clear as mud. Despite having been a key factor in business application processing for a very long time workflow is still very poorly understood by many in business and is more often than not too narrowly defined.

For example, you do not need to pay big bucks for a heavy-duty workflow package and all the services associated with it to implement workflow in your organization. Workflow is really about automating some business process using whatever tool is appropriate. You can automate a business process with Word or Excel or Outlook for that matter and the most common starting point is to first capture a paper document as a digital document using simple tools like a document scanner. You don’t even need a computer (apart from the human brain, the world’s best computer) to implement workflow.

Designing and implementing workflow is more about the thought processes, about evaluating what you are doing and why you are doing it and then trying to figure out a better and more efficient way to do it. It is about documenting and analysing a current business process and then redesigning it to make it more appropriate and more efficient. It is by making it more efficient that you make productivity gains; ideally, you end up doing more with less and adding more value.

You shouldn’t undertake any investigation of new workflows without first having defined objectives and metrics. You should also always begin with some basic questions of your staff or end-users:

1. What are you doing now that you think could be done better?
2. What aren’t you doing now that you think you should be doing?
3. What are you doing now that you don’t think is necessary?

I call these the three golden questions and they have served me well throughout my consulting career. They are simple enough and specific enough that most end-users can relate to them and produce answers. These three simple questions provide the foundation for any business process re-engineering to come. They are also the catalyst to kick off the required thought processes in your end-users. Out of these three simple questions should come many more questions and answers and the information you need to solve the problem.

In every case in the past I have been able to add value well before using tools and creating workflows just by suggesting changes to current manual business processes. As I said earlier, workflow is really about thought processes, “How can I do this in a better and more efficient way?”

Adding value always begins by saving time and money and usually also entails providing better access to information. Real value in my experience is about ensuring that workers have access to the precise information they need (not more and not less) at the precise time they need it (not earlier and not later).  It sound simple but it is the root of all successful business processes, that is, “please just give me what I need when I need it and then I can get the job done.” Modern ‘just-in-time’ automated production lines only work if this practice is in place; it is fundamental to the low cost, efficient and high quality production of any product or service.

When something ‘just works’ very few of us notice it but when something doesn’t work well it frustrates us and we all notice it. Frustrated workers are not happy or productive workers. If we do our job well we take away the sources of frustration by improving work processes to the point where they ‘just work’ and are entirely appropriate and efficient and allow us to work smoothly and uninterrupted without frustration and delays. This should be our objective when designing new workflows.

Metrics are important and should always be part of the project. You begin by taking measurements at the beginning and then after careful analysis, predict what the measurements will be after the project. You must have a way of measuring, using criteria agreed beforehand with your end-users, whether or not you have been successful and to what degree. It is a very bad trades person who leaves without testing his work. We have all had experiences with bad trades people who want to be paid and away before you test the repaired appliance, roof or door. Please do not be a bad trades person.

Metrics are the way we test our theory. For example, “If we re-engineer this series of processes the way I have recommended you will save two hours of time per staff member per day and will be able to complete the contract review and sign off within two days instead of seven days.” The idea is to have something finite to measure against. We are talking quantitative as opposed to qualitative measurement. An example of a qualitative measurement would be, “If we re-engineer this series of processes the way I have recommended everyone will be happier.” Metrics are a quantitative way to measure results.

In summary, implementing workflow should always be about improving a business process; about making it better, more appropriate and more efficient. Any workflow project should begin with the three golden questions and must include defined objectives and quantitative metrics. The most important tool is the human brain and the thought processes that you will use to analyse current processes and design improved processes. Every new workflow should add value; if it doesn’t you should not be doing it.

Critically, workflow must be about improving the lot of your staff or end users. It is about making a process easier, more natural, less frustrating and even, more enjoyable. The staff or end users are the only real judges because no matter how clever you think your solution is if they don’t like it, it will never work.