Six Sigma and EA viewpoints

As it’s an interest area of mine (honest!), I had a 30 minute chat with a Six Sigma black-belt colleague of mine yesterday about how EA and process improvement methods like Six Sigma fit together. His viewpoint was interesting:

• EA/BPM people tend to see things as a technology problem/a problem to be solved using technology first – and maybe jump to creating a “change programme” very early, i.e. tend to solutionize too quickly. Often when working with clients I see projects that have already been dreamt up in the business/change community, and so the “master plan” behind them all is never clear – and some projects are almost contradictory in their objectives/vision.
• On the other hand, six sigma people see things as a process problem to be measured first (set up the right metrics etc), understand where that process can be improved, and then instigate change initiatives. So once the metrics are in place, it may take 6 months before you are confident with your data that you know what to do. His example was to take the business goal “increase sales conversions from x% to y%” and then set up/capture the right metrics to understand why people don’t buy, and then (and only then) drive changes to improve it. I thought this gave the magic linkage/traceability between business vision->objectives->goal->change programmes that I rarely see in the EA world (although it is often talked about).
• His view was that the bulk of business processes in an organisation are performed by people with limited technology support. What I mean by this is that a person might deal with some post (ok – scanned and held in a CMS), decide what to do, make a phone call, check a report, escalate to their manager if necessary etc, then key the result into a system – most of the real action happens outside an IT solution. Therefore the bulk of process change and improvement options lie in the marshalling of human resources first. The “IT is just an enabler” theme was really true to him, and it occurred to me that although we say this a lot in the EA world, we don’t really mean it in the same way and with the same conviction that he does.

Even in the organisations which are reasonably mature in EA terms, it is interesting that I’ve not seen a ‘Change Process Improvement’ team having much contact with the EA team. It’s really confirmed to me that there are two camps who both believe that they should have CEO mindshare – but where neither necessarily has the full picture or skills though.

 

Process Modelling and Process Oriented Organisations

I have recently been on a course about Business Process Modelling, which gave me some other perspectives of BPM and how it can be promoted and used by companies.

Prior to the course, I have used a few BPM tools to graphically represent business processes (including IBM Business Process Modeller, Oracle SOA Suite and AquaLogic BPM tools). When using those, I have felt that their use is more related to the automated execution of business processes, through BPEL and service integration capabilities. This seems to be just a technical approach, which isn’t really the solution – although that does depend on how you classify the problem to be solved.

In working with clients, and team members, I have had numerous discussions and explanations on modelling of business processes where there is no technical view involved. It is from this approach that modelling the process can help in understanding, defining and subsequently refining or improving the operations of an enterprise. In process modelling terms, this would consist of creating the Process Architecture for an organisation. From an Enterprise Architecture, this could correspond to the Business Architecture view, where the business is represented as a series of processes operating across defined value chains.

The interesting part of the BPM course I attended was not so much around the approach and methodology described for modelling, but more about the real-world experiences, cases and examples put forward by the course trainer (who does this as a real job, not just as a trainer). Many industry speakers and research analysts are promoting the benefits of process modelling and in structuring companies around process delivery and value chains, rather than in the more common functional silos and hierarchies. The examples discussed on the course seemed to put forward a strong case for this approach (as you would expect), but perhaps with more explanation. My task could now be to summarise and promote those concepts within my own company, as well as that of clients that we work with.

A parallel was frequently drawn with the way in which manufacturing has long been structured and organised around processes, with the production line of Henry Ford being one example. Also, the quality and time controls from Deming et al being another way in which that industry has rationalised and improved over time.

In contrast, the service industry is still mostly structured in functional areas, with a process crossing over many areas and responsibilities from start to finish. That is clearly inefficient. The hand-offs between teams mean that no one person or function is responsible for the process as a whole; each functional area is mostly tasked with ‘doing their job’ and not focused on the end result of the process within which they are working. This is further highlighted by the way in which company budgets are defined. These are nearly always on an area-by-area basis, not on a process-by-process. That can result in functional areas not having any strong interest in delivering value through a complete process, merely in getting their piece of work done in the quickest, easiest or cheapest way. Generally, not the behaviour that an organisation would truly wish for.

A point I would like to repeat from the course is that processes should have objectives or targets and associated measures that cover not only efficiency, but also effectiveness and adaptability. Many measures look just at basic efficiency, which is a waste if the overall process being followed is not actually effective (why optimise a part of a process to the nth degree if that part isn’t even needed in the first place). Analysing and designing processes against such measures can give an objective outcome for any recommendations, and a way to show the gains as a result. Consider also that efficiency gains through optimising process steps may gain percentage improvements, but making larger-scale changes to the overall process may result in many-fold improvements. Figures such as reducing a process from weeks to hours, those are the major gains available to companies if they do things right.

I would think that the one take-away from my views and comments above should be that organisations can definitely be improved through process re-engineering, and that business process modelling is a great approach to achieve this in a visible way. In fact, if you spend time looking at things from a BPM perspective, you would wonder how companies can look for large benefits without such modelling and associated organisation structures.

 

Enterprise Architecture and Six Sigma

Prompted by one of my EA colleagues, I’ve been reading up a bit on Six Sigma recently, and I’m surprised that I cannot find very much info on the web about the relationship between EA and Six Sigma. The best article I could find was this from Andy Blumenthal, but not much else. No real mention of any relationship to it in TOGAF 9 that I could find either.

Whilst Six Sigma has a heavy quantitative and process improvement focus to it, it is very aligned to the loftier business architecture aspects of EA and so they have very similar ambitions. I’m sure this question must have come up at various EA/Six Sigma conferences – or does this just demonstrate the IT rather than business roots of EA? All views welcome…