I suppose that some point that I had better comment about the Gartner magic quadrant report for BPM that was released last week. Actually, there is an excellent article about this very topic on the EbizQ web site which can be found here.
Basically, and I align myself very closely with the sentiments in that article. It says that the magic quadrant - or similar analyst rankings - are actually a little bit meaningless.
This is for a number of reasons: primary of which is the fact that the basis on which the reports are created is not always comparable. For example is the Gartner magic quadrant for BPM defined in the same way as the Forrester wave report? Even more pertinent to this point, is the Gartner magic quadrant for 2009 created on the same basis as the Gartner magic quadrant for 2008 (even though there wasn't actually a Gartner magic quadrant the PM for 2008).
Gartner, of course, use two axes in their magic quadrant, the first one being "ability to execute" and the second being "completeness of vision". "Ability to execute" doesn't actually mean the ability to actually execute a given piece of functionality within their software. What it means is the ability to to influence and corner market share with the product that they have. Naturally some of the larger companies that have large marketing budgets are able to corner more of the market than smaller companies which exist out there. Furthermore it appears the Gartner have a set of criteria which they impose on companies wishing to be considered eligible for the Gartner magic quadrant. What we don't understand is have the criteria changed since the last time the BPM magic quadrant was published two years ago?
One thing which occurred to me on reading Gartner magic quadrant for BPM is that there appear to be a large number of companies competing in the space. I don't have the previous couple of documents to compare it too, but is the just my imagination that this now appears to be a very crowded market sector? In fact, it appears that every single day I'm receiving some sort of news article which indicates that the new vendor is starting to dabble their toes into this particular part of the market.
I did find it interesting, however, that Gartner did not deem the Microsoft's suite to actually be a fully fledged BPM Suite of tools. I'm not sure what this indicates and I would like to understand Gartner's rationale for excluding them, but I can't say I'm entirely unhappy.
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.
Computerworld magazine UK has an article direct from the Gartner BPM conference in London which talks about Gartner's analysis and survey of business leaders. According to Gartner the number one priority for IT business leaders is Business Process management. As the article states:
"We're in year one of the recovery. Recovery will take a few years. Thus you must do BPM — apply BPM practices — more than just gain the necessary competencies. It is 'all hands on deck' now. Do make changes. Later, you'll have to invest time and energy into increasing your competencies. But 2009 must be a year of action,"
What's surprising about this - and has led some to question the findings - is that in the current economic climate BPm has become something which rates higher than cost cutting as a priority.
Personally I think it is spot on.
I've mentioned before on these pages that I align to the Jim Sinur view that good process management is actually a profit centre in an organisation rather than a cost centre. This means that any company focusing on, and prioritising, BPM will in effect also be cutting costs and increasing the bottom line. As Jim says in his article "Historically, well scoped BPM projects approach a 15% internal rate of return." That's pretty compelling stuff!
For example a lot of companies will look at 'trimming the fat', or 'reducing costs' by doing things such as cancelling a travel budget or slimming staff figures down. This has the effect of reducing headcount without reducing work and results in fewer people doing the same (or more) work than before. As a short term measure (and a way of makig sure that your employee's aren't coasting) this works. But this is untenable in the long run.
The only logical way to deal with reducing head count is to then ensure that the work those remaining people need to do is also reduced. This is through either automation or process redesign. Both of which are elements of BPm.
So for anyone involved in the world of BPm let's hope that Gartner's comments which heads this article holds true.
(Note that throughout this article I use a lower case 'm' when referring to BPm. This is to avoid the trap of people looking at this through a technology view but still trying to focus peope on the overall capability of managing business processes).
Here are a few items that are coming soon on the Process Cafe
Interview with the Director of Strategic Initiatives at IDS-Scheer This Thursday (26 Feb) I have a briefing session with Allen Johnson who is the Director of Strategic Initiatives for the Americas at IDS-Scheer. This company is the vendor who supply the industry leading Aris software. I will be talking to him about the impact current federal change initiatives are going to have and how BPM will play into that. I will also take the opportunity to ask him a few choice questions about the Aris software and it's future direction as well as covering the whole BPM space in general. If you have any specific question you would like me to ask him please leave your question in a comment below. I can't guarantee I'll ask all of them, but whatever I do ask will be published as a post (or a series of posts) over the next couple of weeks.
Review of the Lombardi Blueprint software Shortly after that has occured I am going to be working with the Lombardi company to do an impartial assesment of their Blueprint software. This is touted as "the simplest way to document your processes" and "next evolution of process documentation and workflow diagramming tools". I'll be getting a copy of the software and running it through a typical 'real-life' scenario to let you know how it works.
Review of the ProcessMaster Software Just for balance and in comparison I will also be looking at the Process Master software. This is a fairly new piece of software which competes in the same (or similar) space to the Lombardi product mentioned above. Speaking with the team at Process Master it appears that they have gone head to head with Lombardi on several occasions and have come out victorious on more than one. I will attempt to put the Process Master software through the same test as the Lombardi one to try and get an equal comparison
These things will be occuring over the coming month or so, so stay tuned for updates.
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.
Just a quick link to an excellent post from the BPM Fundamentals Blog which lists a whole page of BPM related sites.
There are links to just about everything you could imagine on this page from BPM Vendors to Industry, Enterprise Architecture & Related Frameworks, Performance & Decision Management, right through to a super long blogroll(on which The Process Cafe appears)
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.
I am a big fan of Yahoo! mail. I like the interface, I like the functionality, and like the overall package. I've used it for many years now. Recently, however, I started to look at another mail system. This, of course, is the G-Mail system provided by Google. Up until now I have been hesitating to use the system because of one huge reason: I don't actually like the interface.
It, of course, has some great functionality. It's quick, easy-to-use, and slick. Millions of people use it every day. Every forum and web site that I visit usually has some very positive comment about the Google mail system. So what don't I like? Good question. I think the reason I dislike it is because it fails in comparison with Yahoo! on the aesthetic level.
It just doesn't look as good.
However, recently I came across a Firefox extension that completely removed every obstacle I had to using Google mail. It's called GMail redesigned. What it does is completely change the look and feel of the Google mail interface. And it does it in a way which is much, much, better than the existing set of Google themes. This very subtle, simple, change has completely transformed the way I view Google mail. It is now my primary mail client.
I find this very interesting for a couple of reasons. The primary reason is that my view of the software has been completely changed: not by the functionality, but by the appearance. This started me thinking about how many other people are influenced by the way a thing looks rather than the way it performs. Imagine if all your users had the same initial reaction to Google as I did. How much more difficult would that make your job?
I know it's not logical. I know that I should be influenced by the functionality rather than by the appearance. But, it is a plain fact of life that sometimes appearance accounts for more than functionality (Just ask the lonely but intelligent nerd sitting at the side of the dancefloor while the cute cheerleaders all end up dancing with the hot jocks.)
Now imagine you are a project manager who is trying to implement a new, large, complicated, software system in an organisation. How much more difficult will your job be if the users are focusing on how the new software looks rather than how it works? I would suggest that this is not a situation you want to find yourself in. I, personally have been in this situation (or one very similar). Many years ago I implemented a financial package in Germany. The existing package, whilst old and limited in it's functionality, was much loved by the users. They didn't want to change. But even if they had to change, they wanted to implement a German package, SAP. I was coming in with a little-known American package which they had never heard of. At the very beginning of the project we gathered everybody together in one room. The financial director - who was the sponsor of the project - said, in German, "I would like to thank the project team for the work they are about to do. We know that we don't want this system, and that we would prefer SAP, but at least we will help them as much as we can." What a way to start a project! This was a situation where the users had convinced themselves that the functionality was not important but the software they had chosen was more important than the software the project wanted to implement. It all came down to appearances. The SAP. software was written in German, it adhered to German standards, and the support was all local. Thus, the appearance of the software meant more to the users than the functionality of the software.
Of course, it's not always like this. Usually problem is the other way round. The users don't particularly care what the software looks like, but they have to have functionality that they can use. The usual complaint is "It looks good, but it doesn't do what we want". I suppose it just goes to show the can't always get what you want.
So, how do we deal with a situation where the uses don't want the software that you are offering? Good question. My advice in this situation is to understand where the actual resistance is coming from. Are the users resisting the software totally, or are they resisting a specific aspect of the software? Remember, in every project involves change (which is usually any project that you're implementing) you are always going to get users who will be resistant to change. It is the nature of the individual. The trick with all change project is to identify key change agents who can help you achieve your ultimate objective and win over those individuals who are resistant to change.
On the subject of applications that people don't like I read an interesting post from Wide Awake Developers today entitled "Why do Enterprise Applications Suck?" Quite true, quite amusing and worth five minutes of your time.
I still wish GMail Redesigned had appeared several months ago though. Or are least I wish I had discovered it a lot earlier. It would have made my life far, far, easier.
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.
You know you've done it. The boss has said "Let's get our business processes sorted out" So you've drafted in some Visio guy who's put together your business process documentation. Now it has been printed off, bound up, reviewed and signed by the department head. Everyone is happy, right?
Wrong!
It's a waste of time and money doing this because it's just paying lip service to the whole concept of business process management, and will result (usually) in a set of documentation languishing in a drawer for years.
If you think doing this is going to help you become a sleeker, more efficient, business entity then you are sorely mistaken. This will actually have the opposite effect as your users. They will resent the time they've spent helping put the documentation together. There is no guarantee that it's the right process and therefore there's no guarantee it will actually be followed.
Actually you're not alone in doing this. Many companies have fallen into the same trap of thinking that a documented process is a defined and managed process. But it doesn't have to be like that. Let's look at ways out:
How to solve this issue
1) Don't go there in the first place. If at all possible try to make sure that you don't confuse documenting processes with defining and managing them. If you want to get some documentation of what your processes are, bring in someone who knows about facilitating processes and get them to do the work for you. But understand yourself WHY you are doing this. If it's just to say "I've documented the processes" then you're probably doing this for the wrong reasons. If it is part of a bigger review then this is slightly better. If it is a small step in a larger Business Process Management initiative this is the best reason of all
2) Don't take the documents as gospel. Given that you've spent the time documenting your processes, make sure this is the start of the process rather than the end. Look at how you can take the documented processes and use them as a basis for improvements. Don't look at this as the end state i.e the gospel according to St Swim-lane (the patron saint of process), but look at this as the first step in a journey to process salvation. Use the existing documentation as a springboard to build a full process documentation set - along with a process management capability.
3) Ignore and start again I know it's painful to throw away things that you've worked hard on but the fact is that unless the process documents were put together under the authority of someone who knows how to document and manage processes, the chances are they will not be right. The might not fully reflect the process as it exists. They might not be a complete record of all the items needed for process documentation. They might not even be documented according to set documentation standards. All these factors mean that it is probably just as useful to throw them away and start again using someone who knows what they are doing. As in the previous suggestion, use this as a basis to build an internal process management capability
Build the capability Managing processes is much more than just documenting the work in Visio. Building a process management capability involves identifying and training individuals who can expertly analyse and document current state processes, who can design future state processes and who can appropriately work a tool to store all this information in. They can identify owners at a process level, implement a governance process and put in place appropriate metrics to measure the processes.
The next time someone asks you to 'just document our processes' you should be wary of this and understand the pitfalls and problems associated with it.
With an appropriate strategy - and a couple of rules about 'what' and 'why' - you should be able to appropriately manage this request and end up with a useful end product.
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.
You all know I'm a big fan of sorting out the fundamentals of processes.
Well it appears that the movie making arm of Sony is also a similar fan
Garrett Hunter, Director of IT at Sony Pictures Entertainment, has posted a slideshow illustrating a case study of a software implementation project he ran for the studio
It makes very interesting reading.
It appears that Garrett and his team spent time putting together requirements with their users but when it came time to sign them off the users baulked at this.
They stated that 'IT does not understand our business'.
This sent Garrett and his team back to the drawing board.
When they reviewed the situation it appeared that the methodology they had initially used had missed a great deal of the complexity and detail that the users needed for their new system. The team had used unstructured narrative based requirements and very high level process models to define the majority of the system, with the developers being left to define the class diagrams and data models. Consequently they had missed a large amount of detail contained in items such as complex business rules.
So they started a different approach using process mapping at a greater level of detail and standardising on BPMN as their notation.
Garrett indicates a number of 'ah ha!' findings that he shares in is presentation. They include
'Get all the right people in the room or on the call'
'Focus on the person doing the work not the supervisor'
'Focus on modelling the end to end business process' and:
'Develop business modelling as a discipline not a byproduct'
These are interesting for two reasons:
1) Looking back on the project with hindsight I would say that these findings are extremely obvious to all concerned. Which illustrates how important it is to define a lot of these things in the first place. 2) A lot of the findings Garrett talks about are identified and highlighted in my book "The Perfect Process Project"
As with many things in life the issues highlighted are usually caused by a case of 'lack of common sense'. I don't mean that in a derogatory way to Garrett or any of his co-workers but it's just that a lot of ingrained dogma about how projects are run causes simple things to be missed. Garrett states, for example, that current projects used numerous tools and modelling techniques which were prone to the whims of different analysts. As a result they standardised on BPMN and (apparently) the Metastorm/Provision toolset. This reduced the complexity and - along with a defined style guide - created a single standard that both users and developers could align with and understand.
This meant that ultimately the process models they created became the agreements with the end customer about requirements.
Are there any lessons that your business can learn from this?
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.
In the sidebar of this blog (in red) you will see some links to publications that you can subscribe to.
Go ahead, take a look, you might find something you like.
All these publications are free to subscribe to - naturally you will need to fill in a form with your email details etc. - and in the spirit of community I would like to expose you to some more offers.
My February special offer is for those of you currently running Oracle products. Did you know that Oracle produce a magazine called "Profit Magazine: The Executive's Guide to Oracle Applications"? Published quarterly, Profit Magazine is distributed to more than 110,000 C-level executives and provides business leaders with a road map on turning their technology investments into top and bottom line advantages.
So go ahead, take a look, you might find something you like. Don't forget they're all free.
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.
BALTIMORE, MD – February 10, 2009 – Metastorm, a leading provider of Business Process Management (BPM), Business Process Analysis (BPA), and Enterprise Architecture (EA) software for aligning strategy with execution, today announced financial results for its fiscal year ending December 31, 2008. The privately-held company posted record revenues and a record number of new customers for the year. Metastorm experienced 29% growth in total revenues year-over-year and added 181 new customers. The company’s strong performance was the result of increased adoption of the full Metastorm Enterprise software portfolio – including Metastorm BPM®, Metastorm ProVision® and Metastorm Integration Manager.
Not a bad little increase for this company. The press release goes on to say that they have also added 181 new customers over the last twelve months, 51 of which they added as the year drew to a close. As this is currently a privatly traded company it is not easy to gather their true earnings in terms of physical dollars, but a 29% growth year-on-year is not bad at all. Of course the other factor to play into this is the increase in customers. I don't know exactly what Metastorm's existing customer base is and whether 181 additions is meaningful or not, so that is something that will need to be taken under advisement.
One thing is for sure it does highlight the growing trend in using technology to support BPM initiatives. We mentioned before in these pages about the fact that BPM can be a profit centre for your organisation and this is a natural fall-out from that statement. The current economic climate can only highlight that fact even more.
EDIT: Title changed from 'Metastorm Announces Record profits' to 'Metastorm Announces Record Revenues' Looking for Metastorm resource?
Do you want to benefit from the efficiency increases that BPA and BPM can bring? Do you use Metastorm tools? Are you looking for additional resource to come in and assist you with your process mapping? GCP Consulting can offer expert Metastorm Provision resourcing for you.
With several years of experience on the tool and expertise in both the Enterprise Architecture and Business Process Analysis functions (along with simulation), a quick discussion to understand your needs is probably the first step.
Call on (44) 845 833 1179 and talk to us about your Metastorm needs.
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.
Dr Geary Rummler (who died on October 2008) did an interview with The Gartner Group prior to his death. In it he discusses a wide a varied range of topics, all related to process and his role in it. Check out the interview here:
I was particularly taken by one of the first things he said in connection to a question about the impact of process management, process improvement, and process re-engineering:
Well, I'm "underwhelmed" by the impact that the field has had. The field – I think – is broader than process improvement. I believe "process" can have both strategic and tactical impact. Most of the work to date – going on for 15 to 20 years – has been about process improvement, which I think of as tactical.
He also has some interesting things to say about BPM:
When you go to various BPM conferences BPM appears to mean the latest software thing. And if you walk down the vendor aisle at these conferences, by the time you reached the end you'd be convinced that BPM is all about technology.
This was in response to a question clarifying the meaning of 'BPM'. Dr Rummler describes BPM as :
"So, we're in agreement that what's necessary is a sound underlying methodology for looking at, understanding, and managing processes. And that there is a process improvement and management methodology that is distinct and separate from technology. And that the methodology might cause you to apply technology as part of what you're doing, but it's not all about technology"
He also talks in some depth about the different levels of process definition which is something I have been struggling with. Basically according to his thoughts (See this diagram) there are several levels at which we can define processes but the key is to use the value chain hierarchy (levels 2 and 3) to map the process change back to something that is meaningful to the business and the customer. If you can't do that you are not adding the right level of value to your organisation. He then goes on to say:
"Consistently working on a Level 5 subprocess, buried in a function, disconnected from the business goals at Level 2 might be interesting and get you a high score in your process-maturity rating, but it sure looks to me like a waste of time and money. And it is the kind of waste of resources that causes senior management to wonder if this process stuff is getting them the payoff they were led to expect."
In closing he made the following remark, which I think is critical in the current environment
It is very difficult (and dangerous) to sell BPM on features alone. And I'm betting that the majority of those CIOs who say BPM is their No. 1 initiative are going about the task without understanding and communicating the benefits of BPM to their clients. More BPM disappointments in the making
Take heed from the man who invented the discipline. He's not happy with what's happening and he's here to tell you why!
I have comments enabled on almost all the posts on all my blogs
However, these are ALL moderated without exception.
The reason for this is twofold:
1) It allows me to track comments which merit a response as all comments come to my inbox for review 2) It let's me reject inappropriate comments
On that last topic let's talk about inappropriate comments.
Generally if you write something which disagrees with something I say but does it in a respectful and considered way, I'm going to allow it. I have no problems with contrary opinions. But if you start to degenerate into slander, verbal assault and derision then, I'm sorry, but your comment is going to be deleted faster than you can say 'troll'. Back at the beginning of the year I wrote a post over on the Musings Cafe about my new Macbook. In that post I was concerned about the fact that I couldn't really do anything because I didn't have an internet connection for it. But I did like the machine itself. I received several, very uncomplimentary, comments from Mac fanboys who were unable to see the post for what it was and merely dismissed me as a loser because of my 'network' comment (In fact I wrote a post about this called 'The Zealots').These comments were never published.
The other kind of post I won't allow is something which is blatantly self promoting. The last half dozen or so posts I've written on the Musings Cafe have all been commented on by one individual (who's name I shall not mention) who works for a large mobile phone manufacturer. EVERY post he has commented on he has managed to turn the comment into a blatant self promotion. As an example, on the 'Things I didn't know' post about working with the Japanese film crew he commented as follows:
"Great Post! I wonder how the film crew manage to communicate between themselves. If it was me I would use the NokiSonMotoEric BFG2000 mobile phone. I really like this phone. You should check it out too."
"Great post. I wonder if you can us Twitter on a mobile phone? If it was me I would use the NokiSonMotoEric BFG2000 mobile phone. I really like this phone. You should check it out too"
To be honest I actually like the style of the guy. He obviously thinks a little bit about how he can spin the post around to focus on mobile phones rather than writing a stock answer to every post.
However, it's blatant self promotion and will not be allowed.
Now if I'm talking about a topic that you happen to know and understand, and you have a relevant website that can throw some added detail into the conversation, then - providing you write a comment that's reasonable and detailed - I'm not going to delete you. Try writing "I blogged about that here: http://www.mysite.com.org.ua" and you're gone.
It's a simple policy, but it works......
(Image courtesy of Guspim released under a Creative Commons Attribution Share-alike license)
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.
Forbes.com has an article that is garnering some attention around the web. it's called "Stalking and Capturing a Business process" and it is concerned with how we design a business process. As the article says:
Why are business processes seen as being handed down from on high? This week, the JargonSpy argues that business processes are like wild animals. They should be stalked, crept up on and then captured.
It goes on to mention several methods of doing this. These include Wiki-Based process discovery, Task-based process discovery and Mash-up-based process discovery.
The problem I have with all these approaches is that they are fundamentally flawed in their underlying principal. The article is predicated around the fact that new business processes come down 'from on high' with minimal, if any interference from the users. This is flawed for two reasons
1) Processes do not come down 'from on-high'. Good process design is a combination of interview, facilitation and process discovery
2) Asking the users to design the process using wikis, mash-up's and task-based discovery is tantamount to asking the fox to design the chicken-coop. Users do not know the best process to do their work. They know the current process, they may even know some flaws in the current process, but they don't have an overall view of the end-to-end process and they certainly don't know how to design the process to work correctly with, for example, a new system that may impose restrictions on how their workflow operates. Many users, in fact, do not even understand the difference between a business process and a procedure (but then again not many process analysts and industry experts do either). Getting them to define and document their own processes is not a viable proposition.
The key issues is that users are users and process analysts are process analysts. It is the role of the process analyst to determine what happens at the moment (using facilitated sessions, questionnaires and observation) and it is the role of the user to validate and confirm that. Of course the analysts should work in tandem with the user and of course the process must be defined whilst understanding the users needs and requirements, but the skill of the process analyst (The good one anyway) is in putting together a process which meets those requirements as well as giving them something they don't already have: simplicity and easy of use.
Stalking and capturing your process will result in a caged wild animal. You don't want one of those running your business, do you?
I do agree with the following point made in the article:
Fred Brooks, author of The Mythical Man Month, teaches us to plan to learn from the process of building the first version of asystem, and then throw it away and build a second one that has a better chance of working. Advocates of agile and extreme programming tell us to build the smallest possible system and put it in the hands of users to get evidence of what really is needed. Then keep this loop going and improve the system rapidly. Google has led the way in launching large-scale products advertised as beta versions, a moniker that sets the expectation that continual evolution will take place. This is the triumph of incrementalism.
I am also aware enough to understand that in big business process improvement projects working in this iterative or waterfall method might not be allowed.
I came across this great little article recently which is a case study of a company investing in Web 2.0 to help define and manage their business processes.
The summary of the article (which is well worth reading) is that a dairy in Oregon used web-based tools to define and manage it's old business processes and improve the efficiency of the business.
Here's what's interesting about this:
1) The situation they found themselves it is something I think many companies could identify with.
It used more than 30 different legacysystems with customised interfaces.
It relied on "paper based business intelligence, plus spreadsheets or Word documents" but also "napkins, or any method of getting information back and forth between the business units"
The business had built up a lot of "tribal knowledge", with silos of information about the way business procedures were operated.
"Smoke clouds were going backwards and forwards between business units, and we did not really understand what the processes were, as they had been handed down over the generations."
Do any of these ring any bells with your company?
2) It chose a unique method of solving the problem.
It investigated Web 2.0 technology, to see how it could be used to identify, capture and optimise the firm's "tribal knowledge", and drive down inaccurate information.
The company examined several applications, including diagramming tool Microsoft Visio but eventually chose Lombardi Blueprint, a browser-based, collaborative, process-planning tool, designed for non-technical as well as technical users. The application itself is Java-based, built using the Google web toolkit. It was hosted and managed by Lombardi through Mosso, a cloud computing service provider owned by hosting giant Rackspace.
3) It found that the end result was:
The BPM exercise has meant that it has been able to revisit all of its processes, measure their effectiveness, and perform root cause analysis on problem activities.
It has also meant the firm could drastically reduce process duplication, inaccurate data, and its usage of older IT platforms.
But more profoundly it has allowed the business to consciously move away from the traditional hierarchical view of management, with the corporate team and chief executive officer at the top, to a structure which is much more horizontal.
Now none of this is actually surprising to me. What is surprising is that this is something we just don't see as much of as you would imagine. According to the article the IT director had been in place since 2001 and it was only when a new CEO came in that he was asked to investigate the possibility of BPM as a means of improving efficiency. We have discussed on these pages before about the fact that BPM is a profit centre not a cost centre and this has been proven with this exercise.
I commend the Tillamook County Creamery Association on having the chutzpah and the courage to attempt this and for being so successful.
(I was also quite amused to find that they rated Microsoft Visio as "too complicated for its needs". But you all know my views on Visio)
For an interview with the head of Tillamooks Business Process Management office done by Barton George from Lombardi, click here
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.
The Enterprise Architecture Practitioners Conference will feature the formal launch of TOGAF version 9, the popular enterprise architecture framework, on Monday, February 2nd. TOGAF 9 introduces significant enhancements to the previous version of the standard, which will be showcased in detail by some of the top TOGAF experts and trainers in the world. Chris Forde, chair of The Open Group Architecture Forum and VP technology integrator at American Express, will kick off the day by delivering a plenary presentation about the v alue of TOGAF. The conference’s second day will further explore TOGAF, using real-world case studies to showcase some of the successful outcomes of using the standard. Parallel tracks at the conference will feature sessions devoted to further examination of enterprise architecture, including sessions about ArchiMate®, The Open Group’s open and independent modeling language for enterprise architecture.
“In difficult economic times, the adoption of open standards related to enterprise architecture by customers of IT products and services is even more important, since it results in greater freedom of choice. The scale of adoption of TOGAF 8, the growth of our membership and the strength of participation at our Enterprise Architecture Practitioner Conferences are all evidence that this is an area regarded as critical by many types of organizations,” said Allen Brown, president and CEO, The Open Group.
As an ex-Enterprise Architect I read this with interest. TOGAF is becoming a de-facto standard when it comes to enterprise Architecture and I think the extreme effort put in by the Open Group has a lot to do with that. Consider the Zachmann Framework, which is by far the best known example of an architecture framework. It has been around for many years but still hasn't evolved beyond the basic level of a grid with relevant items at the intersection. As I have mentioned before on this site John Zachmann himself is hard pushed to give concrete examples of the artifacts which are produced from some of his intersections. But as I look at Enterprise Architecture roles which are being listed in the classified sections I note that a large number of them are wanting TOGAF trained or TOGAF experienced people to apply. Surely this cannot be a co-incidence?
eBIZ has a great little article by Beth Gold-Bernstein about TOGAF v9 and it's components. If you are at all interested in this I would suggest a quick read would be appropriate. The article can be found here.
His theory is that the film paradigm of having thousands of different people in a movie all working under a single man (the director) to produce a successful product should work for everything.
Listen to the presentation if you want (one comment was 'That was wildly obvious and verbose', so judge for yourself), but I'll summarise it for you here:
People who design things for a living fail because they have a lot of very talented people who produce something that is less than the sum of it's parts. But having a single person in charge with 'Final Cut' is the best way to ensure a quality well designed product.This is the reason a director such as Spielberg or Cameron was able to make his own decisions and say 'This is how it should be' and produce classic films.
Would this work with processes? Traditionally it is the job of the process analyst to design the process (working, obviously with the users etc.) but who has the job of approving that? Gruber's theory is that the quality of output of any creative endeavor tends to approach the level of taste of the person with final cut. In the case where intelligent, informed people are deferring to someone with little or no 'taste' the final product will be of low quality. But the reverse can also happen. So in the case of process design, the sign-off is generally deferred to someone such as a process owner or a project manager. But in today's environment there are a lot of project managers who are 'professional' project managers i.e. they don't actually do anything other than manage projects. They don't have anything invested in the final outome other than making sure it comes in on time and under budget. Are they the right people to make this choice?
This leaves process owners. In "The Perfect Process Project" I make the point that there should be an end-to-end process owner responsible at a senior level for owning and managing the evolution of the process as a whole. This is the individual who should have Final Cut' on the processes. If this person does not understand the intricacies of the process then they will make a 'final cut' which will reduce the quality of the process. On the other hand if they are someone who is intelligent enough to understand that the process should be simple and well designed the resultant process should have sufficient quality to make it robust and workable.
So, two questions for you:
1) Do you have a process owner for your processes? 2) Does that process owner have Final Cut?
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.
