Look mom, we do Six Sigma too! - Part 1

I see the relationship between lean thinking, agile development methodologies and technology for an actual implementation of business improvement being closer than ever, and one that is barely touched by more than marketing by traditional business process management (BPM) vendors.

A short post on CIO.com by Leonardo Mattiazzi prompted me to think a little more about the relationships between lean, agile and the tools you use to actually run a better business. The post doesn't contain any amazing revelations, although it is a good summary of the benefits of avoiding traditional software projects when trying to improve the way your business runs.

In the past I've talked on this blog a few times about the importance and success of using an agile methodology in business process improvement projects, and a little about the style of business process management (BPM) tools that can support this. But this morning (and all may change by Monday!) I feel the relationship is more important than ever.

There has been a large amount of marketing targeted at the rise of Six Sigma, and the traditional BPM vendors have gone at it in the only way they know how:

Let's draw a pretty picture of your as-is process, then have everyone collaborate around that to remove the waste. Look mom, we do Six Sigma too!

For huge business process re-engineering projects I won't deny the importance of strong analysis and process modelling tools to ensure the process is well understood. For a rigorous process that can allow no errors, and a low degree of flexibility, this is a decent approach. IDS Scheer built a good business around this type of thing for good reason.

My view is that there are a limited number of business processes, even in regulated industries, that require this level of definition in such an abstract form. I say 'abstract' because these models are exactly that - they take little into account of the target software solution they will be implemented on, so in fact the most successful products will be those that are vanilla, generic, tick-the-boxes process engines (perfect for IBM + dozens of Global Services consultants).

Fundamentally, you can run a project to make some business processes more lean on paper, with Visio or with software design tools built for the job. Reality is, if you take this on-paper design too far, you will achieve such an abstract design that only generic software makes sense. You can take advantage of none of the cool or compelling features in the software package you just persuaded your CIO was the best choice. You wasted your money on stuff you'll never use.

So here, I want to talk about taking lean, agile methodologies for process improvement back to the real world of work. I want to talk about designs and implementations that happen hand in hand, leveraging the capabilities of a product, to get you better business processes faster, cheaper and easier.

Follow this link for Part 2 of 'Look mom, we do Six Sigma too!'

A post from the Improving It blog

To implement workflow and process automation in your business today, visit www.consected.com

Download the podcast of this blog post

SMBs and the BPM vendors' dirty little secret

What's the hidden trend in the business process market? Targeting the benefits of business process management at small and medium sized businesses (SMBs). I strongly believe that the SMB market is underserved by the traditional BPM suite vendors, because their business models don't allow, and because they have industry analyst rankings to chase. This is a shame, as in my opinion there SMB market for real process improvement ranges up to a level of $250 million companies. Not so small really.

One of the big issues with traditional BPM software is just too expensive, or the cheaper stuff requires just too much custom software development to be appealing to mid-sized businesses. BPM tries to be 'everything to everybody', rather than 'enough for you'. It is impossible to build a generic suite that doesn't need a huge investment in custom software development to glue it together in any way you want.

Want to know the dirty little secret that really proves this point? If it was truly easy to deploy BPM, why is it so rare for BPM vendors to install their own software in-house. Is it too big and complex for what they really need, and they can't free up the resources to do the work? Or maybe it doesn't offer them the value to justify the effort?

Brian Reale has an article on ebizQ today that talks about business process improvement, or workflow, from an SMB perspective, and his thoughts mirror mine:

Every business manager instinctively knows which processes are inefficient, and probably has a vision of how they ought to work in an ideal world. But there's also a sense that a lot of effort would be required to make this happen. Three-letter acronyms such as 'BPM' recall other three-letter acronyms, such as ‘ERP’, conjuring up unappealing thoughts of expensive, months-long implementation projects.

Brian goes on to list six items that are important points to pay attention to when selecting a product for your new workflow implementations. I do feel that these are very much centered on what his open source product offers, though we all skew our writing to our products, so he is forgiven for a couple of the points. The two that I can really buy into though are these:

1) Flexibility. Choose a tool that lets you create the documents and processes that you need, rather than one that requires you to change your ways to fit with what it provides. For example, does it let you create, edit and format your own forms, or does it just provide standard forms templates?
4) Ease of Use. A workflow automation tool should not require specialist technical skills to operate. Look for one that’s easy and intuitive to use and that can get you up and running quickly without extensive user training. If it’s a web-based tool, make sure it’s properly architected for a web environment, and not just an old client/server package with a web front end. Check that help and support are easily obtainable.

If these truly are features of his product he has picked well, as I believe they are essential for SMBs, so companies don't have to spend more on implementation than the product itself. Also, Brian's points do help to guide buyers away from Big Blue's, 'this is not really an IBM product, so don't run away' web-based offerings; and the other enterprise software vendors out there doing the same thing with infrastructure products with a little lipstick.

I have been working on some similar concepts for a product that is inherently easy to get up and running. Consected is an online (SaaS) system that helps businesses of any size to run and automate workflows and business processes that help their employees to improve the way they deliver, organize, find and escalate work without requiring a complex software to be developed or installed.

Consected, and Brian's company, Colosa, have similar aims for their customers. Ease of use, flexibility and a cost that can be stomached by SMBs. Beyond that, I'm sure we are very different, but that's a good thing. There is room for everyone in the vast SMB market that the traditional vendors choose to ignore.

A post from the Improving It blog

Coming soon... Download the podcast of this blog post

Bank branches are only good for one thing. Closing your account.

The Bankwatch blog had an interesting post this week: Survey shows shift in consumer preference away from visiting bank branches. I'm sure that there are many ways you can slice and dice the data, though I have some feeling that although this is not just about bank behavior, much of it is their own making.

The reducing number of people using branches is probably a reflection of the rate of transactions in all retail outlets. If there are less people pounding the pavement to go shopping, its likely that they'll also not be walking in to a bank.

There is also a bank MO that comes into play: trying to lock me in to their services. For example, when a bank insists I perform certain transactions in person (Citizens, when I want to withdraw a CD for example) that could be done by phone or Internet (ok, phone if their online banking system sucks), I tend to close ALL my accounts. If I'm going to make the effort of going to the branch, I'm going to make sure that I close everything, all in one go. Restrictive practices do not lock me in, they make me feel trapped and resentful.

I wonder how many people feel the same way, and whether that number is growing as the generation of kids who only know a 24/7 online world start earning cash that is deposited directly to their bank account. Why on earth would they want to deal with a 1970's style institution that insists they stand in line in a branch, waiting for someone to assist them. Unlikely, when even calling a call center in Mumbai, being in line is no worse than having to listen to crappy muzak and catching up on some Facebook or Twitter time.

Some banks seem to have it right: Bank of America, despite have an expansive branch network has started to say that certain transactions can only be done online. Which is good, as their online service is well thought out, and works well. (Its a shame you have to be a US citizen to open an account with them, even when you already hold an account, but that's not effecting much of their customer base I'm sure.)

Citizens Bank, maybe they're suffering from old school Scottish banking thinking. Plus they need systems and workflows to manage transactions that are not completed there and then by a teller in a branch. Nothing fancy, but enough to get the job done (contact me - online - I can help you!). Citizens, and likely many other banks, need to think about transitioning to an online only world, or just shutting their old-fashioned doors for good.

A post from the Improving It blog

Coming soon... Download the podcast of this blog post

When Business Process Management (BPM) is a waste of time

The great selling point of business process management (BPM) technology is that it will boost the efficiency of your operations, reduce waste and provide visibility. Or some other combination of appealing words. This can be true, to varying degrees, largely dependent on the actual business problems that need to be solved and how much of a mess the business is in already. After many years around process and workflow software, I'm coming to the conclusion that there are two styles of business improvement / workflow / process project requirements:

1. BPM automation
2. Everything else

If you have a business improvement project, you probably only should use BPM tools if you are absolutely focused on automation and systems integration, rather than enabling the interactions of people. Otherwise it seems like a misplaced investment. Let me dive into this a little more, so you can see what I mean.

1. BPM automation
When it becomes more important that the process runs without fault or error every time, and can be represented as rules and logic, then putting a person in the middle of it is naturally going to fail. We've all had rough Monday mornings, or Friday afternoons where we just want to leave for the weekend. People have not evolved over the millennia to make perfect decisions in an office environment. But they are great for decisions that require judgement, intuition, intelligence, or where the work being done is not valuable enough to require the investment to achieve complete automation.

If you're going to make the huge investment to try and codify your current human-run business processes with BPM tools, you often should consider cutting out the middle-man (literally). See what can be done to move the manual intervention out to the edges of the process. Let people handle the 5% of really complex stuff, the errors, the escalations, reading and data entry of scrawled correspondence, and the touchy-feely customer services - the things that machines can't do. Let the BPM tools process the work 'staight-through' wherever it is possible, making perfect decisions in split-seconds, finishing the process with an automatic update of another system, or throwing a really complex case to an intelligent worker.

2. Everything else
In my opinion, most human-to-human BPM solutions (i.e. those that move work from one human worker to another) end up becoming glorified collaboration tools with a few rules scattered around. Most of the time and effort involved in implementation of new BPM solutions becomes a matter of working out how to make the workflow flexible enough to meet the many interactions that real people in real offices must perform to get work done.

Go ahead, remove the waste from that process you want to improve (I agree that is important), but don't get too tied up in trying to map it out and enforce the new process at every little interaction, because frankly, if you feel you need to do that you probably need to reconsider your use of humans in the process.

Projects that fit the 'Everything else' bucket can be nicely categorized. Typically they

1. do not warrant the huge investment and effort required for full automation, but do still need improving
2. can not be automated, because people absolutely have to be in the middle of the work
   

If you have a project that fits either or both of these categories, consider using a tool that is better suited to the type of work that is being done. BPM is probably not it. Find a tool that does not require 3 months of wasted time analyzing how to improve human interactions, before actually delivering anything. In short, consider tools that are designed for humans: out of the box solutions that do what you need already; work management tools designed for human workflows; collaborative and case management tools that provide structure around an otherwise unstructured set of operations.

If you want to improve your business but don't want to completely automate it, select a tool that assists people in doing their jobs, not one that is actually designed to prevent workers from doing the many things that need to be done.

A post from the Improving It blog

Download the podcast of this blog post

Case management - a concept described by a product

What is case management? Well I've written a little in the past about about case management as a concept, a component and a product (I won't bore you with a full list, just search the blog) . And Bruce Silver has just put together a nice paper on the subject, using the Case360 product (which I used to product manage during my time at my previous company) as the core for describing the many facets that make up the case management concept.

By using a product to describe the concept of case management, the definition that Bruce creates is both clearer (with real world examples) as well as being skewed by the product. But don't get me wrong - Case360 is a product that I am still very proud of having been involved in, and I know for sure that it lives up to many of the claims. It is also a highly flexible and therefore often overly technical product, and for that it can sometime make the goal of case management harder.

What do I mean? For me, the fundamental attribute of case management is the flexibility it affords knowledge workers to do their job, using their knowledge of what needs to be done. A case management tool should provide a template for guiding work, while allowing 80% of this being unstructured work to comfortably sit inside (or on top of) the 20% of structured processing that exists. For me, the formality of BPM, modeling, simulation, optimization and all the rest, delays the delivery of a solution that should be largely flexible, collaborative and semi-structured. The structured stuff often gets in the way, or forcibly tries to take over the case working that needs to be done. This ends up with the (anti)pattern I strongly believe in: if it's not structured chaos, it doesn't need BPM. When processes get complex, its because they are not being flexible.

At the end of everything, the right tool is the one that workers adopt when they can use it to improve the way they work. I believe that the examples given by Bruce are hard to dispute. I also think that for similar requirements, there is another way. Am I being vague? Yes - and its intentional! Stay tuned...

A post from the Improving It blog

Coming soon... Download the podcast of this blog post

Pave the cowpath - good and bad

'Pave the cowpath' is a term commonly used in workflows and BPM to indicate a rapid implementation that takes the current flow of work, automating it as-is. The cowpath (or goat-track) exists because its a commonly trodden path followed by workers to get the job done, some based on rules (there's a fence in the way and a gate to go through) and some based on convention (a well trodden track is easier to follow than blazing a new course through the long grass).

Yesterday, @dhinchcliffe 'tweeted' about a bulletin for the American Society for Information Science and Technology, which mentions the 'cowpath' in the context of social websites:

The Information Architecture of Social Experience Design: Five Principles, Five Anti-Patterns and 96 Patterns (in Three Buckets) by Christian Crumlish (curator of the Yahoo! Design Pattern Library).

This article presents paving the cowpath as the first of five patterns for the design of social websites and applications that are trying to put social elements on top of them. Crumlish's insights apply to workflow and BPM as well in my opinion:

[...]study some of your potential customers. How do they do what they do today? Yes, of course, the thing you want them to do will be better, but is it really entirely different? Can you offer people a way to continue doing most of the things they’re comfortable doing today as you introduce new possibilities into their lives, or are you really going to insist on them changing everything at once?

I know that this goes against the philosophy of process reengineering and methodologies such as six-sigma, since in paving the cowpath you are doing little to remove the wasteful activities in the process. Slapping a tool on to help move work around does not necessarily enhance the underlying process, but it does make it quicker and reduce wasted time while people wait for work to get to them (which is not necessarily a bad thing). In not removing waste or adding more rules, according to Crumlish:

Often the impulse is to stamp out these rogue behaviors and enforce draconian rules requiring only the behaviors you had planned for. This course of action really only makes sense if the behaviors you are trying to stamp out are truly destructive or evil. There are many anecdotes about thriving social sites that killed themselves off by legislating against fun and forcing their users into exile to find the activities they had been improvising “incorrectly” in the site they had to leave.

I also have many anecdotes about business workflows that were overly restrictive and prevented knowledge workers using their brains (1, 2, oh and the one I never wrote about 'cos its not a flattering story) that led to a similar effect: the application failed and was not adopted.

The great thing about paving the cowpath is that you can implement quickly, assuming you don't try and automate some of the completely ridiculous manual things that are done today, and just let people realize they are ridiculous and stop doing them in their own time. With the right tool, you can also play into the second half of Crumlish's cowpath definition:

A better plan is to support the behaviors your users are engaged in. Let your users tell you what the best and highest use of your interface may turn out to be. Don’t be so arrogant as to assume you know everything about how the social dynamics you’ve unleashed need to evolve.

In a business context this means that you, the business analyst or process analyst does not have to sit for 8 hours a day doing the work of the potential workflow users. Analysis can be done quickly and a flexible system implemented equally quickly. And do not assume you know best when it comes to the way workers must interact or handle exceptions to the rules.

Given some time and professional assistance from a process analyst and workflow tool, users can improve their own processes. The process analyst will need to be strong, since 'Management' will always have the desire to put in more rules, not take them out. Go ahead, pave the cowpath, and give the workers a chance to see how a new system might improve their operations. With a new tool in place (e.g. a lawnmower), users could be presented the freedom to forge a completely new cowpath that works better for them. It would be a shame to prevent user innovation through initially overdesigning a new workflow.

A post from the Improving It blog

Download the podcast of this blog post

A larger online community is not always better

I always love going back to London, as it gives me the chance to catch up with friends. One such friend is a serial entrepreneur, learning and improving his art with every new venture. His ideas are a source of constant lively discussion and debate, especially when enjoying a local brew. Currently, he's directing the technical side of a social networking site for avid readers, called BookRabbit. Since I knew nothing about the site, we started chatting about its target audience, who was using it currently.

The BookRabbit site is a platform for the broad target audience of 'avid readers' to get together and discuss the books they are currently reading and their favourites of all time. It uses the cool concept of taking a photo of the reader's bookshelf and tagging it with the actual identification of the books on it. This provides the starting point for seeing who else has your taste in books, then providing the tools to build a reading relationship with them. Its a nice idea that has drawn a population of thousands of active users.

So our discussion of the target audience started... The site is targeted at the UK, through design. I initially guessed this design was a technical limitation around the book catalogue the site could use for all book references, and it seemed odd to me that you would limit your potential user base through something as 'silly' as a technical limitation! After all, would it not be better to open your audience to the US, with the potential of adding maybe five times the population? The answer as it was explained to me was 'no', and I have learned something important from this.

The BookRabbit site is targeted at 'avid readers in the UK', since there is just a far better chance that these readers are reading the same books and have similar interests to share. This is what makes the community work. By attempting to bring in the US book catalogue, and a US user base, the community would be diluted, or at least split into distinct groups that would be based on geographical, rather than interest-based boundaries. That makes for a bit of a disfunctional (or rather unscalable) approach to building a community, since the geographical users do not gain much benefit from the presence of the other country and the technology does not automatically enable their presence.

OK, lesson learned. Don't assume that more users makes a stronger community. BookRabbit is smart for sticking to its guns. And I have learned a little more about the marketing and mechanics of social networking sites that are based on specific interests.

So if you are an avid reader in the UK (or at least with a strong interest in British books), and you want to share your reading experience with like minded individuals, take a look at BookRabbit and upload your bookshelf.

A post from the Improving It blog

Coming soon... Download the podcast of this blog post

End of vacation blues

To any regular reader who wondered why I dropped off the face of the planet (again...), I apologize. My project in Mexico finished in a blaze of activity (to time and to budget), and was followed by some crazy 'life admin' stuff back in London, then a much needed vacation with the missus.

Get ready for the next round of blogging, now I have my feet back on Boston soil...

A post from the Improving It blog

If its not Structured Chaos, it doesn't need BPM!?

I received an interesting thought from someone who questioned my post on my preferred patterns for implementing business processes. In my post I discussed why I felt that a business process automation or management solution that arrived at effectively a Straight Line of activities was great result, and why I felt that highly complex models were Structured Chaos. The question implied that in wishing to arrive at a nice straight line (or effectively a manual straight through process), potentially I was trying to oversimplify the process. This is certainly a valid consideration.

To me, this type of virtual straight line is a thing of beauty. It represents refinement of the process and removal of waste (a la Six-Sigma). It more importantly represents the real world of business processes that involve people.

To me, the complex business process that attempts to model every possible variable and combination of interaction between people and systems working together is incorrectly trying to force fit a process on top of a system that requires collaboration. If you must use BPM for some of the advantages it offers, model the collaboration through a Single Step or Star.

I'm sure that over time, some of my beautiful straight line processes will become complex, through the addition of plug in requirements, new rules and careful extension. In reality, I also acknowledge this as the success of the original process. It was flexible enough to enable this, to be extensible, without being initially restrictive or brittle and dangerous to touch from the outset.

So I thank the person who chose to give me this thought the opportunity to talk a little more about my design philosophy for processes. I hope to continue with my 'simplistic' approach to business processes, which can be put into production (without any infrastructure at the start of the project) in under 12 weeks, with minimized risk of failure.

In my dim, distant past I was part of the Structure Chaos implementation team, and 9 months in, as now, I never want to go there again. Give me the go-ahead to use an agile, iterative, release early and often approach to BPM, with a nice flexible straight line process, and I'll give you a solution that works on time and to budget, and you can build on in the future.

A post from the Improving It blog

Processes patterns as predictable as Mexico City rain

Mexico City, another wet afternoon

Three months, two business processes, one client with a new system in production. And I'm not talking about some irrelevant back-office processes. The Technolab team have implemented, for the Mexico division of a major international life and medical insurance company, a BPM system for processing new policies, policy renewals and maintenance, from client request through to payment.

In three months, we've taken the blueprints for current state processes from the business analysts and designed, built and deployed a system that should see huge benefits for the company and its employees. And at the end of it, the one prediction I made to myself came true. Business processes fit one of three patterns, and I only like two of them:

1. Straight Line
2. Single Step / Star
   
3. Structured Chaos

When I lead process projects, as I did this one, I tend to guide the client to one of the first two patterns, since they tend to reflect the reality of the way people work and lead to a successful, usable and subsequently easily adopted (by the users) system.

Let me quickly talk through the three process patterns.

1. Straight Line

I love it when a process turns out to fit this pattern. Its exactly what you are trying to achieve when you improve a business process; a process that starts cleanly with a specific outcome in mind, and with minimal deviations that always try to return to the main path as quickly as possible. Why is this good? Because its easy for users to understand, and its clear what the fastest, most efficient set of operations is. A company can build key performance indicators around this, since its easy to measure progress of work through the process.

2. Single Step / Star

How can I call this 'single step' and 'star' in the same breath? This process pattern really revolves around a key single step where the vast majority of processing is done. The steps outside of this often represent exceptions or sub-processes, so much like the Straight Line, they are deviations. And although I say this is single step, the reality is that the work may well cycle around this 'step' many, many times, being delivered to different people and roles on each revolution. But since there is little way to enforce the order of this work (at least with the time or money available to re-engineer the process), while still allowing users to get the job done, the process pretty much becomes an orderly way to track work as it passes between users, with delivery under their control.

3. Structured Chaos

Its when project teams try to force fit a process on top of current operations without effective analysis or change management that I think you see the third pattern. Note I say effective analysis, since there may still be a large amount of time spent on it to produce this result. And there is a chance that is may just work in practice. This is what BPM tools strive to be able to represent, and the temptation is therefore to go with the flexibility they offer. But to me, this process pattern shows a poorly thought out scope for the process. In other words nobody has defined what the process is actually trying to achieve and what type of work it is trying to handle. The more steps and decisions you have to add to manage the necessary requirements of the process, the more likely it is that you have missed one. Often, if a prototype process starts to indicate Structured Chaos, it may be time to rethink, and split the process into several Straight Lines, or possibly one Single Step / Star.

So at the end of three months, what have we arrived at? Well, I'm sure I would not be telling the story in the same way if it was structured chaos. We have deployed a nice clean Straight Line for one process and a nice Single Step / Star for the other. The end result is deceptively simple, and perhaps as much time was spent getting us to this result as actually physically implementing software. Which is great, as the processes will work fast, there is a lot less to go wrong and a lot more flexibility to handle the 20% of cases that don't quite fit strict rules.

Maybe BPM vendors would relabel Structured Chaos as a beneficial Complex Process. It all comes down to how you market your capabilities and limitations. Still, after 12 years of doing this stuff, I haven't seen a customer happy when you finally deliver them Structured Chaos. I'll stick with my two successful patterns, and leave the 'anti-pattern' to the BPM marketing departments and services teams.

A post from the Improving It blog