Putting The Business First

Columnists often focus on the relative merits of X technology and how it compares with technology Y. Or, they compare standard A with standard B. In future columns I will no doubt do this myself. I suggest, however, that columns on business process ought to take a broader view. A recent report from Gartner Group suggested that only about 20% of the processes in any organization can be automated. Yet 90% of the words we read about business process are focused on the technology used to implement process automation. What of the other 80% - all those processes performed by people?

At least some of the tool vendors are getting smarter and recognizing that if they are to grow to their full potential then they need to focus on how they can help people deal with the other 80%. This is great, but still, a tool is only as good as the person using it.

Where can we find the information we need to deal with the nontechnology aspects of process change? What techniques are needed? And why are they important?

Historically, it would seem that technology vendors assume that either this is not their problem, or that their users will have managed to ferret out the needed information from the vast array of available business and management books. The consulting firms will do non-automation projects for you, but most management consultancies would rather give you advice about people problems and then leave you to handle them.

It is fair to say that in any project, IT or not, it is the people issues that make the difference between success and failure. The ability of your company to successfully adopt new practices in business process will owe more to your ability to effect the cultural change required in your organization than it will to the IT tools you use.

Of course, this problem is highly visible when you look at the speaker line-ups and topics covered at "industry" conferences. They seem to either focus on the IT aspects for IT people, or the business issues for business people. Traditionally conferences have not taken a holistic view – especially when it comes to business process. In Europe, at least, it appears this is about to change.

I was recently invited to join a pre-conference speaker lunch, hosted by the Business Process Management Group (BPMG) to discuss their upcoming conference, the Global Business Process Forum 2003. Listening to the topics of conversation, I was amazed. Here was a group of people not discussing versions of software or comparing BPM solutions, but discussing how they could help the attendees deal with the people, cultural and organizational issues required to produce a successful business process project.

Round the table we had people like business process guru, Roger Burlton, respected IT industry analyst and known skeptic, and Katy Ring. Both were readily agreeing that whilst technology was important, all too little time was spent helping people deal with and manage the non-IT issues.

In fact, as they introduced me to the program, it seemed that 2 of the 3 tracks were dedicated to people and culture issues, whilst the third dealt with technology. And, best of all, the keynote sessions were focused on issues of interest to the whole audience and were designed to present both sides of the story. (You can find details of the GBPF 2003 conference in the Calendar section of the BPTrends portal or at www.gbpf.com)

After attending the planning session, I decided to do a little further research, trying to find out whether this really was so unusual. The results I found were quite interesting.

I could find no other conferences that tried to bridge the gap. There were, of course, many technology-focused conferences that included presentations from users on their experiences, but largely these stories were about how someone managed to make technology work for them. Conversely, there were a number of seminars aimed at CEO's discussing the importance of change, how to drive up profits, reduce costs, etc..

From personal experience, I understand how difficult it is to cross the divide. I have spoken at a number of conferences in Europe, where I think I am presented as the "novelty" speaker – the one who dares try and talk about business issues to IT people, or the one who dares suggest to business people that they might like to consider how IT can help. Having said this, I have noticed several signs suggesting this might change. At a recent Software Architecture conference in the UK, more end users were asking about how to deal with business managers than I have heard before, and many reported that they were now working on mixed IT/business project teams.

The other interesting thing that I found was that, increasingly, vendors and consulting firms alike are starting to "tread on each other's toes." Apparently they have decided that end users are more and more likely to turn to a provider that can help them implement the people and cultural issues, as well as the technology issues. This raises some interesting issues How many technology vendors or consulting firms are prepared to provide a consultant to help you utilize or understand techniques like Neuro Linguistic Programming (NLP), or any other technique designed to help understand people and their motivations? Conversely, how many management consultancies would suggest using modeling tools to document and analyze a process implemented entirely by employees?

As I said in the beginning, if only 20% of our business processes can be automated, then we need to be doing a lot more to measure, manage and improve the 80% that can't.

Note: This article first appeared in April 2003 on Mark McGregor's "Postcard from Europe" Series of articles on BPTrends

Breaking Down The Language Barrier

There is a well-known saying, "Two nations separated by a common language." Where the saying comes from, nobody really knows, though most would attribute it to George Bernard Shaw, who in a 1951 book of quotations, and without attributing it to a source, was credited with saying, "England and America are two countries separated by the same language." Then, there is Dylan Thomas, who said in a radio talk in the early 50's, "European writers and scholars in America are up against the barrier of a common language."

Now, the relevance of these sentiments may not at first seem obvious, however, unfortunately, the sentiments are all too relevant to the everyday issues facing people in the Business Process and Architecture worlds. Management gurus such as Michael Porter, Geary Rummler, and Tom Peters, have attached meaning to words like "Value Chains" and "Business Processes" and "Activity" - meanings familiar to senior business executives and managers.

As with most words in every day use, different groups ascribe different meanings to the same words or phrases. In the case of the business manager and the IT manager, the tragedy is that these differences inevitably fuel a misunderstanding of needs and wants between them. In fact, most observers would agree that the issue of a common vocabulary is one of the biggest obstacles to fully integrating business and IT.

So, it was with great interest that I noted that many of the presenters at a recent Gartner Symposium were scheduled to talk about business processes and value chains, and the management of business processes. At last, respected IT analysts were going to use their influential position within the IT community to clear up some of the confusion. How wrong I was!

I heard speaker after speaker continue to talk about the importance of business processes, when in fact they were only talking about what I will refer to as ABPs (automated business processes). I listened to them talk about value chains as simply linking Supply Chain Management systems with Customer Relationship Management systems. They talked about business process management, referring only to the libraries of ABPs a company has.

As I left the conference I could not work out whether I was more disappointed by the fact that they were misusing the terms, or the fact that, inevitably, thousands of senior IT professionals were leaving the conference believing they had a better understanding of how to communicate with their business colleagues.

On a positive note, there were four notable exceptions to this trend, one of whom was Dr. Tony Murphy. The presentation from Tony was like a breath of fresh air, and certainly inspired me to buy and read his book, Achieving Business Value from Technology. (I highly recommend it.) Tony spent his time explaining how we no longer have IT projects. We have business projects supported by IT. He also suggested that the old ways of measuring ROI were out of date and suggested new ways of measuring success. Now, I don't want to go into great detail here, but I do want to point out that 90% of Tony's referenced definitions were from a business perspective and not from an IT perspective. Indeed, Tony actually used the word "Enterprise" to describe the entire business of an organization, where every other presentation I heard used the term to refer to a company's "IT Architecture." – or, to mean "big" or "scalable." Afterwards, when I asked him why he and his colleagues were talking about completely different things when using the word "Enterprise," he seemed bemused.

If we are to truly integrate business and IT functions in order to create the flexible and responsive enterprise of the future, we really must find ways of getting both parties to use a common vocabulary. (BPTrends has included a very comprehensive "Vocabulary" section within the "Resources" section of the portal, in the hope of promoting such a common understanding.) Beyond that, though, we need the help and support of the IT Research community, as they, more than anyone, are in the best position to influence the entire IT community.

So, as we start the spring conference season, I urge the analysts at Gartner Group and other IT research firms to ensure that they use everyday business terminology in the way that business people do, and to refrain from taking commonly understood business terms and redefining them to describe IT specific meanings or functions. For if this doesn't happen, the problem will persist and they will have missed the opportunity to become a part of the solution by helping to bridge the business/IT language gap.

For IT managers wishing to improve their own understanding of the issues, I would recommend reading some of the books your business colleagues are likely to be reading - books like Competitive Advantage and Competitive Strategy, by Michael E. Porter, or Improving Performance, by Geary Rummler and Alan Braches, and of course, look for the new book, Business Process Change: A Manager's Guide to Improving, Redesigning and Automating Processes, by our very own Paul Harmon.

Note: This article first appeared in March 2003 on Mark McGregor's "Postcard from Europe" Series of articles on BPTrends

Six Sigma And The Implications For Business Process Improvement

For this month's postcard, I thought it might be interesting to share some thoughts and provide a heads up on the subject of Six Sigma. Originating at companies like General Electric and Motorola, Six Sigma can best be summed up as an approach that helps you try and achieve perfection. Traditionally, Six Sigma has been viewed as a statistical approach to quality suitable only for manufacturing, but things are changing.

In Europe at least, the biggest interest in Six Sigma comes from companies in the financial sector. Most major European banks are now looking at ways of applying the techniques to their everyday work. One can only assume that this is driven by a combination of the fact that these institutions badly need to make changes to keep pace with an ever changing world and the fact that, given the numbers they are dealing with, even a small change well thought out can save them millions of dollars.

There can be no getting away from the fact that Six Sigma is fundamentally a statistically based approach for improving processes. A simple explanation would be that point X is perfection and Six Sigma is all about measuring the number of standard deviations from the point, standard deviation being represented in mathematics by the Greek letter "sigma". The less the deviation the higher the Sigma score and the higher the resulting level of quality of a given process, Six Sigma representing close to perfection with only 34 defects per million operations.

Maths does form a major part of the work, but there is much more to it than just the maths. In order to perform any statistical analysis one first has to create measures. In many traditional process-based approaches, much of the information used by managers is subjective. Well in Six Sigma life is different! It's common to hear Six Sigma practitioners say that "If you can't measure it, you can't manage it, and if you can't manage it, you should not be doing it." This is the first good thing about Six Sigma, it suggests ways to help you create measures for activities that might have seemed un-measurable in the past.

Secondly, Six Sigma promotes a structured approach to optimizing processes. They use what they call the DMAIC approach – Define, Measure, Analyze, Improve, Control. Each of the phases is well defined and there is a lot of emphasis placed on the "Control" phase. The control phase is all about monitoring the changes made to ensure that you hold onto the gains made.

Thirdly, Six Sigma is all about getting everyone involved. A Six Sigma team is not some kind of elitist team rearranging the world for everyone else to live in. In a pure Six Sigma company you have the "Process Improvement Experts" who work on many projects and have lots of experience; these are known as Master Black Belts and are full time people dedicated to Six Sigma in the company. They also act as the mentors and coaches for the Black Belts. Black Belts are also experienced people who have proven experience in delivering bottom line improvements within their company, however most Black Belts do not work full time on Six Sigma projects. The Black Belts work with the leaders of teams working on many different projects. Most of the team leaders are Green Belts and most have had some training and work occasionally on process improvement projects. So you can see that there are many people involved, but in fact there are many others because the project teams are drawn from the people working on the specific process being improved. The team members participate to ensure that any changes will work and that the changes will be acceptable to the other users.

Any company undertaking a full scale Six Sigma is embarking on a massive program of cultural change. Most will have developed a performance and bonus system for managers that could mean up to 40% of their salary is linked to meeting their Six Sigma targets (This is probably the major reason for the success in companies like GE and Motorola). Then, an extensive training program the company is necessary to assure that the company has the hundreds of "Green Belts," possibly a hundred or more "Black Belts," and probably 2 or 3 "Master Black Belts" it will need to manage the effort. All of these people must be trained in process analysis, process improvement, and general process "thinking."

So where does Six Sigma fit in with Business Process Improvement? Well if we assume that the purpose of and BPA exercise is to ultimately reduce cost, and then improving quality can certainly help. My personal view is that pure Six Sigma companies do not actually operate that efficiently. Certainly they have large numbers of highly optimized processes all contributing some business benefit, but they often fail to understand the big picture. Many Six Sigma consultants preach that you only need to focus on the lower level process that you are looking to improve; there does not seem to be a reliable Six Sigma mechanism to help companies figure out how all the processes fit together to make the company efficient. I believe companies achieve more with a blend of techniques.

By utilizing normal BP techniques you can identify the value chains within your organization and the relevant support processes. Then by drilling down you can look at the overall business processes that are important (and that might be failing). Then as you continue to drill down you might identify processes that are redundant or others that need optimizing. It is when you find those processes that would benefit from optimizing that you can start to apply Six Sigma techniques to optimize them. There is no point in working hard to optimize processes that are redundant when viewed from a slightly higher level.

You can also apply Six Sigma techniques to accrue the measure for even your high level processes and this may be especially important if you are planning to move toward Business Activity Monitoring and want to monitor, in real time, how the processes within your organization are functioning.

Of course the best thing about Six Sigma in my opinion is that it means that we are now "breeding" literally thousands of process modelers, which can only be good news for both the industry and for user companies and the BPM market overall.

Note: This article first appeared in January 2003 on Mark McGregor's "Postcard from Europe" Series of articles on BPTrends