esjewett.com

I've been playing around with a business process platform called thingamy lately. It's an impressive piece of work. As with all software, it has a long way to go, but the path is fairly clear. I'm looking forward to the day when it is interoperable enough that I can use it as an everyday tool.

For me, the really interesting thing about thingamy is not so much the tool or the technology (Java, semantic, etc.) as the thought behind it and the difference of approach to a well-known problem, which has gotten me thinking (yet again) about process design and some of the problems in that area. Thingamy is built around the concept of a barely repeatable process (BRP), a concept that almost immediately causes one to recognize that the cost of instituting processes is too high and current process platforms are not sufficiently robust.

What's a process?

A process is a set of tasks and decisions that is part of the daily work of getting the job done. If you work in the average office, you deal with processes on a daily basis - checking out a conference room, asking a question of a colleague, getting a new keyboard to replace your broken one. If you don't work in an average office you deal with process too, but it might not be as recognizable as such. Some of these processes are more human than others, some are more repeatable than others, some more useful than others, but they all share the trait of being steps that result in getting something done.

In many organizations there is a belief that processes like those described above should not range free through the organizational structure as in the days of yore. Rather, they should be corralled into technology systems where they can be properly monitored and maintained. The efficacy of this approach to process is debatable, but it is not much debated. It is these organizations and these types of processes that I'm talking about below.

The cost of process

One of the largest hurdles to turning an organic process in a business into a technology-supported process is the time and money involved in doing so. In most medium and large companies with current ERP systems a person who sees an opportunity for improvement in a process or for the creation of a new process is faced with the daunting task of justifying an expense that totals in the $20,000 - $500,000 range.

That's a big number. Let's back that up:

This is an example of a workflow/process build estimation tool tailored to SAP's workflow technology. For the simplest possible workflow (5 steps), it provides an estimate of 32.5 person-days for the technical build. This does not include a myriad of things that require significant effort, like business process design and testing, or ongoing maintenance. I use this example not to pick on SAP (estimates on a similar order of magnitude hold for most process development environments) but to show the magnitude of the problem. (Hat tip to Jim Spath for making this available and Susan Keohan for blogging about it on SDN.)

Those who read the BRP link above will now say, "that makes it nearly impossible to justify the creation of processes that will only be used by one person or by a small department." Those people are right, but it's worse than that: this cost also stunts the ability of an organization to conceptualize, test, and grow processes. A lot of process growth that occurs naturally is organic, starting with one or a few people as a trial and then spreading out to the rest of an organization once benefit is realized. The high initial cost of process mostly precludes this sort of organic, exploratory process-building.

Thingamy certainly takes aim at the difficulty and cost of creating a new process and maintaining existing processes. Process creation is surprisingly easy and robust (we'll get to this later). Check out the video on creating an expert consultation process in under 20 minutes. The flow isn't complete, but it would be conceivable to iterate development on this flow 3-4 times in a single day; more if the person building the flow is also the person who will be using the flow.

Robustness of the process tool

Thingamy is also a robust process building tool, once you figure out what the heck all the pieces are doing. This is important because a lot of no-code business process modeling tools trip up on branching, looping, or interfacing problems and end up requiring code. Additionally, they have often so over-loaded their visual representations of processes that it is next to impossible to model anything but the most simple process.

For a basic example of this complexity, take a look at these "Email voting process" outlined here. The email voting process itself is made up of a several other processes such as the "Collect Votes" process, each of which are of similar complexity and is completely invisible from the overall process view. Thingamy's textual representation, focus on robustness of process description, and process re-usability is an example of another, apparently better, approach.

Onward and upward

Those are some gripes about the current state of business process systems where I see some light at the end of the tunnel. There are also areas like personalized processes and exploratory process-building where I think the hurdles above exist but the tools haven't even begun to attempt to address the problem.

What areas do others see where improvements could be made? What interesting tools haven't I seen?

Michael Krigsman blogs at his IT Project Failures in response to a Robert Scoble post asking why enterprise software isn't sexy. Vinnie Mirchandani also responds on his Deal Architect blog. Scoble is asking why enterprise software doesn't get more press, and Krigsman and Mirchandani hold that it doesn't get press because it's doing important things. More likely it doesn't get press because your everyday blog reader doesn't really want to know about the software that processes invoices and manages supply chains, nor should they.

But I think this misses the point. It's not just your person on the street that doesn't care. The people that use this software every day don't care about it. A lot of people use software from SAP, Oracle, and Microsoft but very few of these people view the software as anything other than a necessary evil. I don't think it's unreasonable to attribute this lack of interest on the part of actual users to a lack of sexiness, usability, humanization, etc. on the part of the software.

So back to Scoble's question: Why the lack of sexiness?

I believe it comes down to a tendency to discount aspects of software that encourage use because in the case of enterprise software we can require use. This, of course, despite the fact that you can both require and encourage use.

Because of this mentality, and the resulting software (or vice versa), people don't care about the software they use every day. Not caring results in resignation and a cycle develops under which individual employees don't have and don't expect to have control over their software, their business processes (enshrined in the software), or their workflow (also increasingly in the software). This begins to shape up into a recruiting and retention issue because people who care won't want to work with software that they can't control. But it's also a issue because we leave a huge amount of business and user interaction expertise on the table when designing enterprise software for resigned users.

Now, that's money on the table, but I think the amount of money on the table here is dwarfed by the loss of whole areas of enterprise software. Companies are just starting to try to figure out social software and the jury is still out on this area, though there are some positive signs. How about user-controlled business process modeling, even just for analysis processes? Most people are still using Excel for this.

One area of enterprise software that has been an unmitigated failure is the knowledge management arena. A big part of problem is the fact that people have to be able to integrate the KM software into every aspect of their workflow in order to achieve the necessary level of information transfer into a knowledge management environment. Enterprise software traditionally doesn't enable this type of user control, so failure ensues. Sure, documents show up in KM repositories, but a working knowledge management system isn't really about the documents, it's about ideas and knowledge diffusion.

This is all especially concerning when we have Gartner analyst/VP Jeff Mann holding that "social interaction is the way most value is delivered in the modern work environment" and that "by 2012, the primary role of business networks will be to support social interactions, not routine business transactions." (Yes, I really love this quote.) I assume that Mann includes social knowledge creation in his calculus.

I think we can agree that un-sexy software probably doesn't do a very good job of enabling social interaction. And that's a big problem.