Factoring in Barriers to Entry
As part of understanding what business projects need to do to leverage BPM technology, I’ve been trying to eat my own dog food, so to speak. I’ve been looking at some of the EA processes and trying to model them using BPMN. These processes aren’t terribly complex, but at the same time, there is potential for technology to assist in their execution. They involve email distribution, task assignment, timer-based checks, notifications, etc., all of the same things that a process for a non-IT department may want to leverage too. The problem is that I look at these simple lightweight processes and think about the learning curve required to leverage the typical enterprise BPM suite, and that big barrier to entry is a large inhibitor. Even with using BPMN versus the built-in flowchart template, I can generate the process model in Visio very quickly.
A challenge that the BPM space faces right now is its barrier to entry. There are tools, most prominently SharePoint, that excel at having a low barrier to entry. When a team can quickly create a process model that can orchestrate and manage their work requests via an intranet site, that’s a big win. At the same time, does that low barrier to entry eventually become a boat anchor, either through infrastructure that poorly scales or a lack of more advanced features such as process analytics? On the flip side, does the business need another technology that requires significant development expertise and months-long (or more) projects to utilize? What’s the right path to take?
My opinion is that adoption is more important than sophistication, especially with the rate of technology change today, and the influence of consumer technologies on the enterprise. There is so much an individual user can do today, and human nature is to take the path of least resistance. This doesn’t necessarily mean that we should all pick the tool with the lowest barrier to entry, but it does mean that whatever tool you choose, you must get that barrier to entry to an appropriate point, especially if there are competing technologies that can be used. If your BPM technology requires that every process initiative have the equivalent of a senior developer involved, that could be a big problem if it’s something that the end users could do using Visio, Excel, or anything else. Find a way to lower the barrier.
3 Responses to “Factoring in Barriers to Entry”
Leave a Reply
Todd,
I was reading and jumping at the chance to comment, until you made that last point tacked onto the end of the last paragraph (which by the way, is very important, but nearly invisible!).
You, and the vendors who deliver products, make it sound like you can choose one of the following:
1. An easy to use product, with no scalability or sophistication, or
2. A product that requires a PhD to use, but scales well and is advanced enough to do complex things well.
This is not an either-or choice. Vendors need to start focusing on making products more easily consumable, without dumbing them down.
Coincidentally, yesterday I wrote a post that touched on this tangentially. At the very end of my post, I wrote:
“Personally, I think the answer is simpler, purpose-specific products that work more easily (install and integrate) and intuitively (user experience) and customers who shop for what they need.”
(full post at http://bit.ly/EJiru)
I think the challenge is that rewarding vendors for ease-of use in the current way that software is purchased is going to be difficult. Ease of use is hard to quantify, and most people/teams evaluating software don’t (can’t?) put themselves into the shoes of regular users.
I feel quite passionate about this topic, as you can probably see, and fully agree.
We (vendors) must lower the barrier to entry for using complex, enterprise-scale, products.
David Bressler
(@djbressler)
I think your discussion supports something I’ve been saying, which is that we shouldn’t think of adoption as a simple binary event (from “unadopted” to “adopted”) but as a curve (from shallow occasional use to sophisticated and seamless integration into working practice).
If a vendor boasts thousands of users, and then I discover this merely means installing the trial version of the software and playing with it once, then I’m not very impressed. If a vendor has a dozen customers at the top of the curve, that’s much more impressive than a thousand at the bottom of the curve.
From this point of view, lowering the barriers to entry is only half the story. What I’m interested in is the shape of the whole adoption curve, which enables people to find an appropriate level of adoption and not get stuck on the nursery slopes.
Does this basically get back to enterprise architecture and the maturity of our IT organization and the industry space?
An organization, as a living organism, grows either in its complacency or in its leanness. And it isolates between the direction depending on a number of factors.
I totally agree with David statement of “simpler, purpose-specific products.” But the things come to mind that need to happen.
One: a good, semantically accurate, rich taxonomy of functionality at the platform layer
Two: A way to prove/test the honesty of vendor’s claim against that taxonomy.
Three: a way to make it all interoperate.
Then we can have a true “best of breed” scenario.