Improving It

Case management - follow the bouncing ball

phil_ayres@hotmail.com (Phil Ayres) — Thu, 05 Nov 2009 10:50:57 PST

I just had the unfortunate pleasure of tuning in to a sponsored webinar called "Smart Case Management: Why it's so smart" on ebizQ - unfortunate because I tuned out before the end and missed what was so smart about it. Unless I really missed the punchline though, I am starting to believe that nobody in the traditional business process management (BPM) software industry really understands case management. This is probably because it doesn't fit their view of the world, so they'll just force fit everything into fixed workflows (sorry, 'executable business processes' is the marketing term) and add a rules engine, or a pretty collaborative-esque UI, or whatever other thing they own that helps them try a new marketing tactic.

If you know that you have a major business process with a need for real case management, not 'smart, slideware case management', how do you convince your boss that traditional BPM might not be the real answer? See if these five attributes fit your business process:

A large chunk of the process is centered around knowledge workers, experts, brokers, underwriters, assessors, analysts, specialists, or whatever else you might call the people using brainpower to get the work done
Your process has many starting points, and channels through which a 'case' may begin, or be identified as being part of a pre-existing case (phone, email, customer call, broker, management edict)
There are many possible successful (and possibly unsuccessful) outcomes that represent the end of this process, but not necessarily signify the end of the whole case (the client lives on)
The users of the system need to be guided when to deal with work in workflows centered on this case, but also need to be able to interact with it at any other time (such as when a client calls unexpectedly or the auditor stops by)
The general flow of work may follow a fairly basic structure, but a case must always have the opportunity to deviate from that previously defined path, to cater to: the unusual situations; the escalations; the high-risk / high-value opportunities; the client threatening litigation; the partner offering a huge deal.

To visualize what case management is, try this. Think of the bouncing-ball that used to guide you in singing the lyrics on TV and early karaoke. (Image courtesy of ASIFA)

The ball is the 'case' (an account, partner, client, policy, etc or combination thereof). As the ball bounces along its path, the singer is guided and assisted in singing the song to the predefined flow. Real life says that the singer, being the expert in vocalization of words and tunes (the animator of the ball maybe can't sing), may actually deviate from the written words, as he or she ad-libs a little. The TV doesn't prevent them from doing so, but certainly makes it easier for them in an unfamiliar tune if they can follow the flow.

As the ball is bouncing along, you look closer at it and realize that it has a bunch of other items revolving around it (visualize electrons around the neutron if the ball was an atom). These other items are the processes and communications that go on as needed around the core case (such as the auditor digging in to the detail). Typically they interact with the ball and the words, but unless something goes wrong, they don't throw it off its bouncing path.

Occasionally a separate harmony kicks in, and the ball (here the visual messes up a bit) floats between multiple lines of lyrics being sung by different people. No one person is the owner of the tune, and they all interact a lot, or slightly as they harmonize. The case follows the tracks of the different processes, for as long as required, though not necessarily according to a predefined path.

Finally the song ends and there is a successful outcome. The singer, and the ball, don't disappear though, they just go off to do different things for now.

So, if you were able to visualize that, you have a good sense of the complexity of case management, and why it is so valuable for some business processes. It is the facilitator to the case (the ball), following its general path, while allowing everything else to get on with what needs to be done around it, and enabling the 'ad-libs' to result in a better outcome than a strictly mechanical approach. In reality, case management reflects the real life of business, clients, opportunities and day to day work, and the value that smart people can bring to what they do when the systems the use allow them to do so.

A post from the Improving It blog

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

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

Running a project should not be mismanagement by email

phil_ayres@hotmail.com (Phil Ayres) — Wed, 04 Nov 2009 09:43:42 PST

If you have ever run a project, or even been on the blunt end of the tasks coming out of a project manager, you'll understand how difficult effective tracking of communication can be. The tracking of individual tasks on the GANTT prove hard enough, with many projects resorting to a printed copy that gets a thorough paint-job with a green highlighter at regular intervals. Now try and track the implicit communications and requests that make up the tasks on the plan (or often outside of it), and you'll prove to yourself that there really has never been a good way to track your project related conversations and responses, many of them getting lost in email. So, for my newest consulting project, I decided to 'drink my own champagne / eat my own dog-food' and use Consected to manage the structure of my project, track the communications with the joint teams, track the project plan and record the masses of notes that I normally expect to generate or receive.

What did I want to achieve? First for the good of the project I wanted to make sure that all of my project information was carefully organized so that I could find it at any time, and so I could track follow ups with the client and vendor (I'm sitting in the middle, trying to clean up a messy project) without driving myself make sure that all of my project information was carefully organized so that I could find it at any time, or the post-it notes into crisis. Second, I wanted to get a better handle on the strengths and shortcomings of using the Consected solution for a project that doesn't have a lengthy business process or workflow.

What is the outcome? The project appears to be picking itself up well, due to (or despite) my last minute introduction to it (the aim being to pick it up by the scruff of the neck and beat it into shape). And Consected has proven what a great fit it is for this type of unstructured or semi-structured project management or case management work. Even better, it now has a nice, simple, but powerful ready-to-run solution for managing consulting projects, or likely many ad-hoc projects you see in typical organizations.

Does this sound like something you could use to track your projects and communication better? Great, because this is a preview that Consected will offer this Consulting Project service, and some accompanying solutions for immediate sign up and use in the coming weeks. If anyone is interested in signing up for the free, public beta of this ready-to-run solution, drop me an email at phil_ayres @ consected.com or go to the contact page of www.consected.com, so I can add your name to the list of people to notify on release day.

A post from the Improving It blog

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

Listen to your gut when process intelligence fails you

phil_ayres@hotmail.com (Phil Ayres) — Mon, 02 Nov 2009 07:31:06 PST

Business leaders seem to pick for themselves one of two styles of decision making: decisions based on data or decisions based on gut-feel. Both have their place, but only the former can seem to be enhanced through the use of technology. When measuring work inside business processes, gaps in data are assumed to be a failure of the analysis, rather than an underlying indicator of something worse.

If you take a read of ZDNet's Is BI ready to meet the real world? article today, it should reinforce the fact that leaders pick their own style, though the article pushes the belief that logic trumps intuition, even if the data it is based on is only 70% complete. The article suggests that intuition and the gut can be all too easily influenced by such 'evils' as marketing and branding, things that are designed to generate a reaction at a subconscious level. The problem is that a leader making a decision based on data is also being manipulated - by the often blinkered assumption that the data shows all the facts, or is even relevant to the decision he or she is trying to make. Numbers, charts, and 'lies, damned lies and statistics' present a view that one can not argue with.

My experience working with business process management (BPM) tools and the statistics they show are that rarely, if ever, is the performance information they present at all truly valuable to a business leader attempting to make high level decisions. The data is valuable only to a micro-manager concerned with the task-level supervisory role. The so called 'process intelligence' (that I admitted to be a novice of, back in 2006 when I first wrote about it) that is provided by BPM is limited to the slice and dice of individual workers' times to complete work, or such similar metrics; experience has shown me that there is little relationship to the actual value of the work to the business. To give you two examples of where process intelligence and BPM really fails:

1) The process intelligence does nothing to help make an assessment of where in the organization your highest value sales-leads are, what the conversion factor is, and whether increasing or decreasing the opportunity count in any part of the sales process generates higher or lower total revenue.

2) BPM does a fine job of allocating work, but a terrible job of understanding the complexity of the work that it is delivering. When the BPM analytics look at the work that was pushed around, it sees it only by the simple classifications that the data contain (this was a 'work order', that was an 'employee onboarding' case). There is nothing about the complexity of the work, since BPM can't handle the ad-hoc nature of the requirements and these continue in email as before.

"OK, so BPM and process intelligence don't give me that information. I'll just use the information I do get from it.". The problem here is that the data will lull you into a false sense of security - you will believe that you have everything you need, and will force fit decisions into what the data shows you. It is hard to get the gut and logic to work fairly, side-by-side, when both know that they are right.

So instead, it becomes important that you gain a better view of what is really going on inside your business processes, while actually running them better. If BPM can't provide the data for what your people are doing, its probably because the tool or implementation can't actually influence or assist them in what they are doing. That is what the data is really telling you: there is a gap in your data because there is a gap in your processes.

If you want your business to run better, don't try and fill the data with gut-instinct. Instead follow what your gut is really trying to tell you: the BPM implementation you currently have is not delivering all it should. Work to improve it, or replace it with something more appropriate.

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

Your desktop will get a facelift. Who is holding the scalpel?

phil_ayres@hotmail.com (Phil Ayres) — Fri, 30 Oct 2009 06:28:53 PDT

There are discussions everywhere you look on whether desktop applications, such as the Microsoft Office productivity suite, have any value in a future of cheaper PCs and netbooks, software as a service (SaaS), and a need to cut energy consumption (aka less powerful desktop computers). One example of this discussion is a recent ebizQ forum, talking about exactly this. Windows 7 has also refocused people on the fact that the desktop is important. But the operating system wars are unlikely to be where the next big facelift for the desktop comes from.

In this discussion, much attention has been placed on the new platforms that provide a rich internet application experience (like Adobe Air and Microsoft Silverlight), software that is installed on your computer that supports the building of pretty application UIs that work well with centralized Internet based services. An evolution of the pretty Flash advertising that is everywhere, into something that might offer the end user some actual value.

What does this mean? It means that software developers have identified the traditional desktop operating systems of Windows, OSX and Linux (Gnome, et al.) to be insufficient for building visually attractive applications quickly and reliably that rely heavily on central web servers for information. Users have noticed that old traditional applications don't work in an Web environment either (have you ever tried to use Outlook on VPN for any period of time). And web browsers are tied to their standards for displaying traditional document type pages that they are too limited for stunning user experiences to be built.

The new platforms provide a polished look and feel, some decent software development tools (essential for adoption by the guys that make the software to choose one platform over another) and a way to almost make the OS that the application is running on irrelevant. For Adobe, for example, by getting a huge adoption of their Air/Flex platform across all different OS types, more and more applications get built on their platform. Much like Acrobat for reading PDF documents, once you have a majority level of adoption, you can assume that computer users can use your applications. Suddenly Adobe takes control of the desktop and its experience, not in a malicious spyware attack way, but in a subtle, corporate, 'we are more important than the OS vendors' kinda way.

Control of the platform gives Adobe three advantages: the ability to drive the direction of future applications through the platform functionality they provide; a justifiable way of charging a bunch of money for better developer tools; earlier access to the platform than anyone else so that their applications look better and work better than anyone else. The latter two are the items that will make Adobe the money.

I've spoken about Adobe as if they are already the winner in this. Its not true of course. There are too many vested interests for it to be that easy. But unlike the early days of the PC, where users were tied to the OS, cos that's what came in the box, today tech-savvy consumers demand openness and choice. This is why Microsoft may struggle with Silverlight - the platform ain't half bad, but it carries a stigma and assumption that it will only work well on a Windows OS (despite offering Max OSX and Linux versions). Linux and/or Java based offerings may end up being technically superior, but will be late to the game, and almost certainly lack the visual shine that comes from teams of paid designers working alongside the tech guys. I've talked about Adobe already. But I missed one -- Google.

A quick inroads with the Chrome browser and Google Desktop has brought many people a Google mindset to the desktop. Chrome is a way of perpetuating the current web application approach with some speed and simplicity, while Google gets their heads around whether Google desktop and it's gadget/plugin approach can grow into something bigger.

This is not a new fight, and is likely to continue for ages yet. Your PC, Mac or Linux desktop is going to get a facelift, we just don't know who is holding the scalpel.

A post from the Improving It blog

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

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

What are the required attributes or skills of an excellent professional?

phil_ayres@hotmail.com (Phil Ayres) — Wed, 28 Oct 2009 07:12:40 PDT

"What are the required attributes or skills of an excellent professional?". That was the question I was asked for a recent research study. "Give me some guidance or categories to guide my thinking", was my response. The five aspects are below; what would your responses be?

the technical background
the educational qualification or the Breadth of knowledge
the essential character of the leader
the management ability
the interpersonal relationship

If you don't have the time for a long winded response, feel free to add a single click to the short poll.

Here is what I responded, quickly and without much deep thought (which may mean they represent more or less truth than 'marketing'):

1st, the technical background

Technical background appears to be most important early in the career of a professional and can get a person a foot in the door of a company of interest. It is after getting in that the other attributes really take over (though #5 is essential to getting in as well).

2nd, the educational qualification or the Breadth of knowledge

I hold more importance around the relevant experience and adaptability of the person than their educational qualifications. In the US at least, there is a trend to making the minimum requirement for any senior position an MBA. I believe that this represents HR laziness, or the lack of an organization's ability to spot real talent, since 'MBA required' is an easy filter to a minimal level of capability. A breadth of knowledge is essential, since a person will not be focused on a single task or category of work, especially as they progress beyond their starting point in a company. It is also more appealing to customers to work with a well rounded individual

3rd, the essential character of the leader

There are only a handful of great leaders in my opinion. Most CEOs seem to lack the interpersonal skills or even traditional leadership skills people around them have come to expect. In the US, if the compensation (salary + potential big bonus) is right, people put up with CEOs that typically say one thing and do another. I'm not a fan of many of the CEOs I have had to work with, and the others were not successful in that particular company (though may have been successful in others).

4th, the management ability

Below CEO level, management ability for me suggests that the person is focused, and communicates clearly and honestly about the company's goals and their own goals. For me, great managers have often been great mentors -- people who have really shaped my progress in a company, and helped me through gentle guidance to be better and do better. True, personal, honest mentoring, rather than the formulaic approach that some companies try and approach (you must check in with your mentor once per month for coffee) is invaluable.

5th, the interpersonal relationship

This of course is what makes or breaks a professional. Close bonds with your peers (both in your department and beyond) is essential in any profession that requires management through influence rather than 'chain of command'. For example, a product manager role requires personal relationships to be formed with every department in a business - sales, marketing, customer services, manufacturing or R&D, etc, etc, since the product manager has no resources, but must persuade people to do specific work based on their own needs, rather than as a manager telling them to do it. Without interpersonal skills, a product manager will fail, since nobody will help and nothing will get done outside of the employees defined tasks to move the products forward. For most people, it is the people they work with that make the job exciting and interesting. Without interpersonal relationships, that is impossible.

A post from the Improving It blog

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

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

EMC 'consumes' Sharepoint, saving IT from becoming backoffice cleaners

phil_ayres@hotmail.com (Phil Ayres) — Tue, 27 Oct 2009 06:42:30 PDT

The SearchStorage channel on TechTarget (Australia) reports EMC's drop in sales in its Content Management and Archiving (CMA) division, due to what some may call uncharacteristic tardiness on the part of EMC when it comes to technology acquisitions. If you didn't know about EMC's CMA division, you have probably heard the names Documentum or DiskXtender, so just think of it as the banner for that stuff and anything else that consumes documents and emails at a software level. In general I try to avoid talking about the dynamics of corporate M&A on this blog, since it is the technology strategy (and therefore customer solutions) that companies eventually develop from it that really interests me. So I'll stick to the strategy and what it means for companies that may never even speak to EMC.

There is nothing really exciting about the SearchStorage story, apart from the stuff going on between the lines: 'corporations are back on the defensive, worrying about compliance, governance and litigation'. EMC and OpenText have been hit by Microsoft's Sharepoint, since the latter has given organizations a rapid and more cost effective way of deploying content management systems that were previously extremely costly (I'm ignoring the many hidden licensing costs of Sharepoint for now). In doing so, as Microsoft succeeded in selling Sharepoint in all directions, little silos of high value documents, data, wikis and blogs have popped up across the enterprise in standalone Sharepoint servers, barely recognized by IT, but causing insomnia for Legal.

Imagine this scenario... a particularly aggressive competitor, or aggrieved customer or partner of Company X wishes to inflict financial and operational pain on that company. They design a well placed lawsuit to support subpoena of documents across the enterprise (especially many of those Sharepoint servers). This turns Company X's IT team into little more than backoffice cleaning staff for weeks on end as they search under desks and in rarely vacuumed back offices, dusting off Sharepoint servers and other file storage assets.

This is what EMC is playing catch up on. The eDiscovery game got bigger when Sharepoint made the ability to find all the information related to a customer, partner, contract, product or whatever, so much more difficult by enabling employees to unthinkingly spread it around the organization on servers often unmanaged by IT. A bit of a boon to the employee, since finally they got a server with their department's name on it to put stuff in, but a nightmare for anyone trying to find information. EMC has worked out, a little later than its competitors, that understanding and consuming data from Sharepoint is a good thing, if you can make it easier to find stuff. Enterprise search, the ability to Google content across all sources inside the firewall, is a good start, though nothing new (Autonomy has been doing it for years, and Microsoft bought the technology to do it). As we all know, 'Search' is not 'Find'. eDiscovery demands Find, because the lawyers will ensure you do.

EMC are visibly playing catch-up to get the fundamentals in place for managing documents they don't control. As they know, the key to solving eDiscovery is ensuring that all documents and data are classified when they are created so that there is a perfect understanding of what the documents contain. An alternative is ensuring that an unclassified the document ceases to exist (the Mission: Impossible self-destructing message). Putting controls around ad-hoc documents becomes essential. Preventing documents (e.g. contracts) from leaving the organization that have not been classified and stored securely becomes important (one draconian and highly effective approach is to block all attachments from outbound emails). Automatically working out how to classify all data that exist already and isn't in the ERP is equally important.

Whatever EMC is doing behind the scenes (and I hope they are doing something big, or they are losing their touch) just reflects one thing: whether you are a huge multi-national or a more unique mid-sized business, having the information around your customers, partners, contracts, projects and employees, available for access, without having to hunt every corner of the organization, can save you big if lawyers come knocking.

Rather than waiting for the giant software vendors to work out some magic for automating the handling of random, ad-hoc documents, there is another approach. Give employees a system to communicate with organizations outside their own four walls in a controlled and tracked manner. Removing the need for email, Word and Excel can boost efficiency and accuracy, and even better can be done today with targeted business solutions, simple business processes and automated workflows.

A post from the Improving It blog

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

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

'The Cloud' is big, therefore BPM is irrelevant

phil_ayres@hotmail.com (Phil Ayres) — Mon, 26 Oct 2009 06:44:22 PDT

A new study, commissioned by Avanade and reported by Joe McKendrick on ZDNet, talks about some solid evidence for the drivers of companies to 'cloud computing'. This made me consider how the cloud became such big news, when other technology spaces, such as business process management (BPM) touted by vendors and analysts never quite make it to the top of the list.

For me, much of the 'cloud' buzz and adoption comes from the fact that everybody is talking about it, and the traditional guys with big marketing budgets have latched onto the concept. The 'cloud' could have remained a niche market, profitable to a small group of unusual players when it came to enterprise software (Amazon, Google). Much like service oriented architecture (SOA) in fact, which in my opinion would have remained niche if it was not for the mega-vendors attention. For me, business process management (BPM) sits in that category, since IBM, Oracle and SAP had too much invested in SOA at the same time for them to be distracted, so BPM had to wait on the sidelines for its time. Now that the cloud has them focused on what could be a whole new business model, its down to the independent BPM vendors to make BPM relevant again.

How will they do that? Well, I'm not going to give them the benefit of my opinion on that one for free (since they'll just profit from it), though it seems obvious based on the Avanade sponsored research that a service-based (SaaS) delivery model is essential:

More than half of respondents report that they are currently using Software as a Service applications. In the United States, that number increases to more than two-thirds (68 percent).

The problem of course is that current pure-play BPM is a terrible fit for delivery as a service, since it has relied so heavily on a delivery model revolving around skilled, expensive consultants with a mix of business and technology acumen.

It is time for a new model for business process improvement based software, and it works a little something like this... Oh, almost let the secret out there. That though is why I am working on business process improvement as a service.

A post from the Improving It blog

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

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

The 'process maven' and reaching employee buy-in

phil_ayres@hotmail.com (Phil Ayres) — Thu, 22 Oct 2009 06:37:24 PDT

Its hard to get employees to buy-in to any form of change, and process improvement is a really tough one. This strikes at the core of people's working existences and identities, making them resist the change more than can sometimes be considered rational. But its OK, you have an undiscovered ally. There is a largely untapped resource that companies need to identify, who can really make employee buy-in achievable, if not easy.

A forum question on ebizQ asks what it takes to achieve buy from end-users in the use of business process management (BPM) software. My response is out there, but it seemed like a question worthy of a more detailed post too.

BPM software vendors obviously know the value of BPM - their marketing departments ensure that the benefits are well understood. My opinion, and this is a hard one to test objectively, is that most companies outside of the software community just don't get the value of process improvement through BPM:

Without a burning need, BPM is unlikely to spring to mind at all. Sure, you can try and persuade prospective clients and users that they need BPM and it will save them time and money, but without them really feeling pained by a current process they are unlikely to actively respond.

It takes real process chaos to get companies to react and change what they are doing. Otherwise they will typically just throw more resources (often the same employees, working longer hours) at the problem. Its not rejection of BPM as a waste of time, its the lack of realization that something can and should be done.

So, let's assume that a company discovers that process improvement is required, and that some form of workflow or BPM tool could be valuable in that change. That realization typically starts with one, strong minding, and fairly senior manager in an organization - often at the department level. That person puts a lot on the line to start selling the idea to the senior executives, but that's easy -- the ROI has to be right in most cases.

For the real workers, getting the buy-in for any change to current working practices can be harder, as we all know. The efforts of the manager in persuading his or her bosses of the ROI of process improvement can be misconstrued (or possibly interpreted correctly, depending on your level of cynicism).

At an individual user level there is likely to be buy-in once they have truly acknowledged there is a need to change, and its not just the current management team's desire to leave their mark with an expensive software solution.

One problem is that the right employees are rarely engaged early enough in the process. This shouldn't be about including a couple of worker representatives in a vendor selection process, purely because it seems like the right thing to do. Companies embarking on process improvement projects should be looking at really involving some of the powerful resources they have, in a way that is quite unusual.

... the high profile employees, the most vocal, the potential advocates among their peers have to be able to see, feel and experience a working solution as soon as possible, possibly even pre-sale.

If this sounds difficult, it probably is. Traditional BPM vendors are good at showing demos, although they may run to a proof of concept project for the company's developers and analysts. As for real end-users, they are harder to support without building out a solution.

It is worth the effort to get specific end-users involved early. Why? Well there is one department (you never thought you would learn something useful from) that has been refining the use of expert advocates, sometimes called mavens, for many years:

This is where we can learn something from marketing - spending your (both the vendor and the customer) effort on gaining the buy-in of the users who are the most vocal, highly respected among their peers. These end users 'BPM mavens' will go out of their way to get buy-in from the majority of other users. But don't oversell the maven, because they can as easily destroy your product after it fails to please.

I believe this is the key to getting buy-in for your process improvement project. Now all you need is to make sure you have a solution that can facilitate the conversion of the mavens, up-front, honestly and early in the process. The solution must be one that can address their needs and that they can actually use in hours, not months. Don't give them promises and Powerpoints, which they are sure will disappoint.

To achieve buy-in of end users, first convert your mavens by giving them what they really desire: a solution that they can see, touch, and experience immediately.

A post from the Improving It blog

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

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

Comic-book software projects

phil_ayres@hotmail.com (Phil Ayres) — Wed, 21 Oct 2009 09:21:36 PDT

If software projects were comic-book characters they would NOT be Dilbert, nor would they be ugly beasts with two heads and dripping slime. Instead they would be insidious, vicious, but mostly normally proportioned human beings, with a exterior veneer of smooth style and a hidden core of vile aggression.

Put another way, software projects can be compared to one of two sports (sorry if you only follow US sports): rugby, a thug's game played by gentlemen; or football (soccer), a gentlemen's game, played by thugs. Which you get depends on the vendor you pick, but that's another story.

Does this mean I don't like software project? No.

It does mean that I treat software projects (either the implementation of products or the deployment of customer systems) with the utmost respect. I know they can bite. I've been bitten in previous lives, and I would never trust a software professional who won't admit to having been involved in (but of course was never leading) a software project that hadn't failed fairly spectacularly. You learn from these failures, not so much from the successes.

Software projects make for an interesting challenge. For the uninitiated, trust me when I tell you that this is not like dealing with some other services vendor your company may employ to get stuff done. Software is unpredictable at the best of times. So if you don't really know the rules of that particular game, expect that the other team - the inanimate software, not the software vendor itself - will get the better of you.

The moral of this comic-book tale? If you don't know the software industry well, find an expert who can help you run that project your are planning, or at least set best-practices upfront and track the milestones for it throughout. We cost more after a project is already on the way down the tubes.

Alternatively, don't run a software project at all. Use prepackaged, ready to run solutions based on software that is already running, hosted and maintained by a single vendor (the software as a server, or SaaS model). When the solution you need is already running and just needs you to set up account, there is a lot less to go wrong.

A post from the Improving It blog

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

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

Survey! What is the biggest business process headache for small businesses

phil_ayres@hotmail.com (Phil Ayres) — Mon, 19 Oct 2009 11:42:40 PDT

You'll see a few changes around here as this blog starts to evolve. First, apart from the new template and URL, to reflect the blog's link to Consected (though the old URL and feeds continue to work), I'm going to try out some online surveys. Here is the first.

There has been a lot of discussion recently about how mid-sized businesses could (and should) improve their business processes, to reduce costs, improve customer satisfaction, achieve more repeat business, etc. From what I have seen, there is very little tangible evidence of exactly which processes they should go about enhancing. I would love to know what your thoughts are.

If you have an opinion, please respond to the one-click survey (no registration required) at: http://www.consected.com/surveys

If you'd like to add some additional thoughts, add a comment below!

A post from the Improving It blog

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

Balancing free, subscription and paid software licenses

phil_ayres@hotmail.com (Phil Ayres) — Mon, 19 Oct 2009 09:05:07 PDT

Laurie McCabe writes an interesting blog about computing for small businesses, though I think that many of his thoughts make a lot of sense to anyone interested in cloud computing, SaaS and online collaboration tools. A little while back, Laurie posted about the pricing model for subscription based SaaS services and whether it is time for SaaS vendors to get creative in their pricing models, to get their subscription levels to a more 'meaningful' level and prevent the fatigue that comes from vendors constantly asking for a little more for extra services. He posted an interesting survey (Poll: Do SaaS Vendors need new pricing models to attract more small businesses?), which show pretty decisively that a new model is something that customers would like to see.

This is obviously important for all SaaS vendors, since creating a model that helps them grow their subscription base without giving away their services for free, is going to become more important as the number of credible online service offerings grows.

In my opinion, as the traditional enterprise software companies enter this market as well, pricing models are likely to stagnate. Publicly traded companies are generally not in a position to get highly creative on their pricing, due to the accounting rules surrounding VSOE. This really only applies once they have started to sell and recognize revenue, and although I can't claim to understand the technical accounting rules for revenue recognition around starting new subscription services, I think that their stockholders may envision a watering-down of profits. For this, the smallers independent SaaS vendors should be able to stay ahead, as long as they can work out a model that benefits their customers and themselves.

If you have any experience, good or bad, with SaaS subscriptions, please leave a comment.

A post from the Improving It blog

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

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

Wasting money measuring Turn-around Time

phil_ayres@hotmail.com (Phil Ayres) — Thu, 15 Oct 2009 08:36:25 PDT

Many years ago, I remember my father talking about being involved in a time and motion study. In his office, managing the movement of railway equipment and trains to ensure the optimal performance of the London commuter rail network (given the suboptimal resources they had), working efficiently and effectively was key to many millions of journeys being completed on-time. It was a fascinating idea for me.

I haven't heard the term 'time and motion' in a long time, and to me it sounds dated. Taking the 'time' piece of it is still very relevant for business process improvement, and frankly studying the time in a process that needs some improvement is something that seems unfortunately overly hard to achieve.

I have worked on business process management (BPM) software projects that try and achieve the study of time alone, rather than any real process improvement goal. The projects had the single goal of putting a basic work delivery solution in place so that the business analysts could start to measure (and management could work with users to improve) the turn-around time (sometimes called TaT) for individual tasks within a process.

The time analysis solutions provided a very simple mechanism for packaging up work items or cases, then delivering them under the control of individual users, as a single step process without any real rules in place. These processes allowed the measurement of the time taken to complete tasks (the turn-around time), and the amount of time work was sat waiting to be acted on (wait-time). The solutions were a minimal use of expensive and complex BPM technology in my opinion. The processes gained from automating the manual delivery of documents and information, but little additional control was provided to further improve them.

It seems to me that the analysis of time used in processes that have yet to be remodelled and improved with BPM would be better handled use lighter weight, easier to deploy and cheaper to buy tools designed with this type workflow delivery in mind. It seems even more important, when you think that many of those processes that were initially analyzed for TaT and other simple measurements, using expensive BPM licenses and consultants, where never actually enhanced afterwards to benefit from all the features of the product they were using.

Understanding the processes you run in your business today is desirable. Improving them quickly is essential. Doing that in a way that doesn't waste money goes without saying.

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

The (hush, hush) next big thing for your business processes

phil_ayres@hotmail.com (Phil Ayres) — Wed, 14 Oct 2009 13:12:51 PDT

If you ever wondered how to improve your business processes today, to run your business better at a lower cost, you'll probably not be excited to hear that all the business process management (BPM) software industry can do is debate what the next big thing in BPM will be tomorrow (a related ebizQ forum is here). BPM is tied to big businesses who want to spend money, and as we all unfortunately know, there aren't too many of them around. So the software vendors need to guess where their next big buck is coming from.

Business processes are the workflows that are followed by your people, clients, partners and suppliers, and are internally how your employees respond to the requests to get the results that are needed, fast, accurately, and at minimum cost to everybody. Getting this right makes a huge difference to your business. So what are BPM vendors focusing on? Pretty diagrams of business processes that involve no more than five people and suddenly appear to have 53 steps; dashboards optimizing the sub-second response of stuff that is out of your control; and complex technology filled with buzzwords to keep their software developers in kicks.

Mid-sized businesses and departments of big businesses are in fact incredible similar. They need results and improvements in how they operate, today, not tomorrow. They need to use technology that is not for the laggards (to use a common, slightly derogatory marketing expression), but is still quite innovative, without managers and users struggling with its complexity to understand, configure or use.

Making business processes run better, by helping people track the work they do, across the many people they work with and systems they are forced to use, is what BPM vendors should be focusing on today. Taking that one step further and making that simplicity available as a service which you can sign up for, online, with no software to install is where email has already gone, CRM has gone and BPM is going.

A post from the Improving It blog

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

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

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

phil_ayres@hotmail.com (Phil Ayres) — Thu, 15 Oct 2009 07:02:17 PDT

In Part 1 of Look Mom, we do Six Sigma too!, I reiterated some of my views on the use and misuse of lean thinking and agile development in business process management projects. I suggested that a standard approach to improving business processes often follows this rather lame approach:

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!

Practitioners of Six Sigma have pointed out to me the benefits of the 'collaborate' part. I agree that there is a huge benefit in taking workers out of their usual environments for a while, to disconnect from email and daily tasks, and actually think about what it is that they do. Only when a worker is not embedded in the daily grind can he or she start to separate the wheat from the chaff - the valuable activities from the tasks we do 'because we always do it that way'. Despit this, my feeling is that the longer workers are kept in the abstract mode (aka the conference room), the more likely it is that they will also forget the reality of work. The temptation to oversimplify kicks in - 80:20 rules are great, until you get to the point where improving the 80% of common use cases actually prevents you from doing the 20% that are more complex, but often more profitable.

My view is that a short period of time away from real work is a benefit. Workers realize that a change to their working practices is necessary and inevitable; they start to look at what they do differently and can see some of the wasteful practices in a new way; and they get a feeling of ownership for the subsequent, painful changes that will happen to their work tasks.

This is where I would like to propose a different model for improving business processes. Rather than continuing to try and redesign the business processes in a conference room away from where the real work is done, send the workers back to their working lives. In a conference room, when thinking about the pain-points of their work, employees tend to fixate on the most recent and most painful issue they had, or are having, not necessarily the issues that are the most common. What you need is some way of seeing and measuring where the real problems are and a way of seeing what can be done to improve them, within the real context of the work being done. But how can you do this?

Here is how you could go about it:

Put in place a workflow or process automation system that manages the main work process, as it is today.
Ensure the system is flexible enough to handle the many use cases you have not thought about or never knew existed, so that users don't have to revert to email.
Use the system to track the activities that workers perform and who they interact with to get their jobs done. This is not Big Brother spying on users; we are trying to get an accurate and non-judgemental view of the flow of work in reality.
Now use the same system to enhance one part of the process that appears painful. Use the employees involved to understand what is going on, and why they do certain activities. Now agree on a change and implement it immediately.
Go back every so often to see how the change has improved the process, making enhancements and responding to the way workers have adapted to (and possibly found new flaws) in the new way of working.

Doing this, you take the best bits of 'lean' and 'agile' methodologies (reduced waste and 'release early and often') and keep the processes you design real by adapting them within the context of the business. For this to work, you need two things: a software solution that can automate a workflow and make it ready for use within hours; the flexibility to support work that the modelled workflow can not handle directly.

I don't believe that I'm proposing anything particularly radical here. My aim is to reduce the amount of time and effort businesses have to spend on analyzing and improving their business processes, and to provide them results that fit their unique working environment better. As I talked about in Part 1, this approach probably does not fit business processes that can never fail. But if you have processes that need some help urgently because they are less than perfect, taking a new approach to making them better can only help your business, especially if that approach requires the investment of hours, not weeks.

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

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

phil_ayres@hotmail.com (Phil Ayres) — Thu, 15 Oct 2009 07:01:29 PDT

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

phil_ayres@hotmail.com (Phil Ayres) — Wed, 30 Sep 2009 07:14:52 PDT

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.

phil_ayres@hotmail.com (Phil Ayres) — Fri, 25 Sep 2009 07:20:36 PDT

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

phil_ayres@hotmail.com (Phil Ayres) — Tue, 15 Sep 2009 08:50:33 PDT

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:

BPM automation
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

do not warrant the huge investment and effort required for full automation, but do still need improving
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

phil_ayres@hotmail.com (Phil Ayres) — Wed, 26 Aug 2009 12:43:31 PDT

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

phil_ayres@hotmail.com (Phil Ayres) — Fri, 21 Aug 2009 04:58:34 PDT

'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

phil_ayres@hotmail.com (Phil Ayres) — Tue, 18 Aug 2009 09:44:09 PDT

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

phil_ayres@hotmail.com (Phil Ayres) — Mon, 17 Aug 2009 13:23:44 PDT

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!?

phil_ayres@hotmail.com (Phil Ayres) — Tue, 21 Jul 2009 20:27:13 PDT

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

phil_ayres@hotmail.com (Phil Ayres) — Sun, 19 Jul 2009 20:00:32 PDT

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:

Straight Line
Single Step / Star
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

The joy and pain of rolling out a new business system

phil_ayres@hotmail.com (Phil Ayres) — Sun, 19 Jul 2009 19:53:32 PDT

As three months in Mexico City draw to a close, the business process management (BPM) based system we've been building is heading for production. Not wanting to risk jinxing it (so there is a lot of wood touching happening here), I am trying to avoid saying that it may possibly, if the stars align, be on time and to budget. Technolab and the large multinational insurance company that we have been working for should be proud, as even if we do see a last minute hiccup, the teamwork and desire to get the job done has been incredible. So, that's the joy over with. What about the pain?

The pain (at least for me) comes from the uncertainty; the last minute unexpected mishaps; the possibility that the production servers just won't run right; the fear that integration with the system of record is just not the same for production as in dev and test; the fact that I'll have to perfect meditation to try and sleep without my brain going over every last detail (again). Dreaming software is not fun or relaxing. Especially not dreaming it in a foreign language!

But its just an application, right? And its been tested?... Of course.

Its the fact that the system touches the working lives of practically every skilled worker from sales, through underwriting, to policy issuance and accounts receivables. If the system screws up (like throws every item of work into an error state) for some unforeseen and therefore untested reason, there's going to be a lot of people sat on their backsides drinking coffee and waiting. That would not be the ROI that we all hope for. But its not just this project. For me, every system I've deployed (more successes than mishaps, it has to be said) leads to this mix of adrenalin and some other unknown compound (probably caffeine).

So for now, all I can do is keep on using the revolving brain, mentally touching and prodding every last piece of the processes and applications, to satisfy myself that everything is good. Reality is, its been good for a while. We have settled, just in time, into the essential phase of stabilization and risk reduction. So I'm ready for some joy on Friday. Just a little. Seeing the first users successfully login and start working full time, full on, with their new system. If so, you could see a deliriously happy post from me at the end of the week. Please keep your fingers crossed! Mine are, and its making it difficult to type.

A post from the Improving It blog

Download the podcast of this blog post