Making Enterprise Software Sexier: Repeatable Process Without Endless Boredom

I couldn’t quite get past thinking about the issue of “sexy Enterprise Software” that Scoble started us talking about a few days ago.  The topic was such a Rorschach Test for what people think of when they think Enterprise Software.  That in and of itself was quite interesting.  Seeing lots of new perspectives on a thing I thought was familiar is always food for thought.  After a few days of almost unconscious cogititation, an interesting new perspective or two often starts to take root.  My initial response to it all was to suggest that what was interesting about the software was perhaps not so much the immediate UI as the potential for business transformation that Enterprise Software offers, but there were wildly differing perspectives.  Michael Krigsman and Nick Carr got into a real snit over the whole thing.  Nick Carr, who often writes that IT is becoming irrelevant, was strangely passionate about the idea that there is nothing precluding business software from being engaging, while Krigsman was determined that it’s a complete non sequitor to even ponder the sexiness of Enterprise Software because it’s all about repeating a crucial business process:

I demand the system work every time without fail.

While I disagree with much of what Krigsman had to say (including his parting shot at Carr which asks where’s the revenue: compare Google and Oracle and you’ll see the revenue is very much there), the idea that it was all about perfecting process got me thinking. 

Stowe Boyd tickled my thinking further, when he says that Enterprise Software is about Groups not Individuals:

Enterprise software starts with the premise that the user is an employee, or member of the marketing department, or a minion in the IT department. The users rights and capabilities are tied to membership, not to individual identity.

Stowe gets a lot closer to the way I am thinking about making Enterprise software sexier, but not all the way.

My new thinking is focused around the idea that a lot of Enterprise Software is about implementing Repeatable Process.  Perhaps the ultimate incarnation and priesthood for Repeatable Process is Six Sigma.  Practitioners will point out that there is a lot more to it than repeatability, in the sense that one is supposed to continually improve the process.  Any defect that is identified results in a process change that eliminates the root cause of the defect so it can’t happen again.  It can be a powerful methodology: much of the success for companies like General Electric is laid at the alter of Six Sigmas. 

This is all fine and well, but I think it can be taken too far and applied in a manner such that the endlessly repeated process results in endless boredom.  That in and of itself can be a problem, because boredom leads to mistakes and lack of attention.  Boredom costs productivity, which is not what we’re about with Enterprise Software.  There is a further danger to Six Sigmas that has started to be heard more recently.  According to Wikipedia:

A Fortune article stated that “of 58 large companies that have announced Six Sigma programs, 91 percent have trailed the S&P 500 since.” The statement is attributed to “an analysis by Charles Holland of consulting firm Qualpro (which espouses a competing quality-improvement process).”^[15] The gist of the article is that Six Sigma is effective at what it is intended to do, but that it is “narrowly designed to fix an existing process” and does not help in “coming up with new products or disruptive technologies.” Many of these claims have been argued as being in error or ill-informed.^[16][17]

When Six Sigma is used as a cost cutting program, it has been shown to stifle new product innovation.^[18]

Of course this gets the High Priesthood into a fine frothy fit, but it sure seems to fit with everything I know and have read about innovation.  Even Deming advocates something shockingly similar to the choices I’m suggesting for our Enterprise Users.  According to Wikipedia, one of his principles is Semi-Automated, not Fully Automated:

Dr. Deming lamented the problem of automation gone awry (“robots painting robots”): instead, he advocated human-assisted semi-automation, which allows people to change the semi-automated or computer-assisted processes, based on new knowledge. Compare to Japanese term ‘jidoka’ (which can be loosely translated as “automation with a human touch”).

I like this concept of semi-automation, where everyone understands the ultimate goals and destination, but there is personal freedom about how best to get there.  If Deming, the Grand Pajandrum of consistent process execution can advocate choice, why doesn’t it make sense here?

What then to do about it?  In part, I think there is a problem in that we continue to carry over a lot of the old 3270 Green Screen approach to Enterprise Software.  We view that the job of the computer is to rigidly control the people using it and that this is the only way to ensure our perfectly concieved process will be accurately carried out.  Much of it has extremely rigid workflow.  Such user interfaces are extremely modal, and frankly, they feel awful.  They force their users to act in a pre-defined play like marionettes.  There are endless “screens” that have to be dealt with, and sometimes a key piece of information is on a screen that we can’t quite remember how to get to.  The track is extremely rigid, and usually make no sense at all to a newcomer.  It might also be less than ideal for achieving the best possible results.  After all, people are not marionettes.

Jason Kolb says this about Krigsman’s posts:

…his point is that enterprise software is to be stable, above all else, sacrificing the user if need be. 

Jason is not advocating this, in fact quite the opposite, but it is another way of saying what Enterprise Software is in many cases.  I take exception to the idea that we may need to sacrifice the user in favor of the process.  People are not at their best and most productive when treated this way.  There is a tremendous amount of literature about the value of offering people choices as they go about their tasks, but the rigid process brand of enterprise software doesn’t hold with that.

An awful lot of Enterprise Software is nothing more than moving database records and fields from one form to the next while some poor user is expected to do some menial task to the form that the computer can’t quite manage for itself.  Shades of Amazon’s Mechanical Turk.

What if there is a better way?  What might it be?

There are tantalizing glimpses out there.  One of the best comes from James Governor, who made a long post about some SAP demos he has seen.  It’s worth a read.  The essence of it is enabling the ad hoc to become a part of the process.  I think of it as self-modifying process.  It is modified if and when the users of the process need to change it to do better.  Such an idea places individuals back into control, at least a little bit.  After all, part of Six Sigma involves continuously improving the process to make it better.   When was the last time your Enterprise Software was malleable enough to improve on the fly?  I thought so.  Yet here is an example that shows how to give at least some of the users choices rather than locking them into an immutable process.

Perhaps it is simply a matter of providing choice that matters to the users about what to do next.  Choice that goes beyond the green screen menu.  It blinks at you and says smugly, “Figure out how to fit what you want into my world or you’ll never get there.”  No, we want software that fades into the background.  It has choices that are natural, make more sense to people than machines, and that any reasonable human being can fit together in the way that people are great at and computers are lousy at to make anything they need to have happen get done.  One of the maddening things about “workflow” and “business process” is that it’s so synchronous.  You have to follow a task to its completion or lose everything.  It’s like those annoying web storefronts where if you make one tiny little mistake on a form late in the process, it kicks you back and makes you reenter all of the information. 

Such choices might be more like Google’s system of project management.  They’re a very textual company, so they use a system based on email.  Folks receive emails asking them what they expect to accomplish next.  They respond via email.  The system then comes back at a later date and asks whether they got the tasks done.  Reporting based on these results is available to managers.  Wouldn’t such a system be tremendously more friendly than trying to fight through Microsoft Project or some other highly stylized project management system?  Given all the complaints about Sales Force Automation (salespeople often hate filling in the data), it made me wonder why you couldn’t create a CRM system around the same principles.  Maybe that would be the ultimate killer CRM that salespeople would finally accept as being worthwhile.

I wonder when the last time a workflow designer (Business Process Architect or whatever high-faluting title they use) actually thought about giving users more choices was?  Hmmm, probably depressing to consider.

Maybe users would be happier if the tasks were much more granular and the users could bounce around as they saw fit.  How do you maintain the integrity of a process in a world like that?  Well, it’s an asynchronous world, so you have to keep track of what’s left to do and let the users decide what to do next.  The email inbox. RSS feed, and Social Network newsfeed are such paradigms.  They’re worlds where users can open as many cans of worms as they like and work on them in any order.  It recognizes that people are people.  They get interrupted.  They change their minds.  They may forget or need to go back to something.  They get tired of doing one thing and need to do another for a while as a respite.  But despite all of that, they don’t want to be led around by the nose.  They want choice.

With choice comes responsibility.  Folks are accountable for their choices.  That’s okay.  Responsibility is a good thing.  People rise to the challenge more often than not and everyone is better for it.  But we need to help people make the best choices.  Give them feedback.  Give them a way to keep score on their choices.  Some form of analytics.  To choice and analytics, let’s add another valuable spice: collaboration. Consider a case that seems completely unrelated:  in Agile programming, a lot of productivity is gained by having programmers work in pairs instead of as individuals.  Collaboration is not only fostered, it is forced.  And it turns out to be a lot of fun once you get used to it.  Does anyone do something like that with Enterprise Software?  Is there no way to pair up users and benefit?  I’ll bet there must be.

Here is another crazy thought: what if we need to turn Enterprise Software inside-out to make it sexy?  Old school Enterprise has various user categories that are largely clerks locked into precise workflows based on how a particular company likes to operate.   HR and Finance are the categories where most of this stuff lives.  Enterprise Software has succeeded in making the clerks wildly more efficient, so we need fewer of them, but there are still many many clerks out there.  How can we turn Enterprise Software inside-out and eliminate the need for clerks?  Remember (or perhaps you don’t, there are fewer and fewer who do) how it used to be before the PC was common and there was such a thing as a Knowledge Worker?  Managers all had assistants who did things like taking memos and writing letters.  Go further back and we learn that CC meant “Carbon Copy”, which was literally the process used to send a memo to more than one person.  Word Processors on PC’s turned that task inside out in a relatively short period of time and there was suddenly much less need for everyone to have an assistant.  Now an assistant could take care of a relatively large department, and he could do so with day-to-day tasks that were at a much more interesting level. 

And then I had the craziest idea yet.  What if the software was designed in a way that its users actually wanted to follow the best process?  What if they actually enjoyed it, or perhaps at the least overlooked that it was repetitive and boring for some reason?  Think about it for a minute.  Isn’t most of what goes on with Social Networks repetitive and boring if you strip it down and just look at what you can do?  All that newsfeed reading and poking and messaging, it isn’t as if this is the world’s greatest game.  Yet people seem to stay engaged.  Some would say addicted even.  What’s needed here?  An incentive would be my first thought.  A reason to move forward and do the next thing well.  A reason that is more compelling, more immediate, and more under the user’s control than just the promise of their next paycheck.  Incentives are a powerful force, and often, they need not even be monetary to be effective.  I mentioned the idea of keeping score above.  I’ve used score keeping many times to get competitive people working above and beyond the call of duty.  It’s a way of life for salespeople, and they love it.  It’s tantamount to turning work into a game, albeit with more serious consequences.

Let me give one last example that ties all of this together.  There is more choice, there is scorekeeping, there is self-service, and at the end of the day everyone benefits.  A friend recently suggested a great application for businesses that have lots of part-time help.  My brother manages a retail store, and his situation is not unique.  He has available 90 part-time hours for the store, and 5 or 6 employees to spread those hours around to.  Nobody is ever happy about it.  They all fight constantly for more hours, and this places my brother as manager into the role of the “heavy” who has to say “no” more often than “yes.”  You can just imagine some heavy-handed Enterprise Software arbitrating this fight with an obscure HR-derived algorithm that is deemed fair to all but annoys everyone and is almost opaque to understanding.

Enter this other friend’s idea.  He wants to turn the whole thing into a Dutch Auction.  People would hop onto a web application and bid what hourly rate they’re willing to take for a certain number of hours.  Lower rates get more hours.  He sees this as a win-win.  Management is no longer cast in the role as heavy.  If you an employee really wants a lot of hours, they can bid to get them.  Chances are that a slightly lower hourly rate is more than offset in gross dollars by gaining more hours.  The company was going to pay for 90 hours (in my brother’s case) anyway, so it wins by getting a lower hourly rate over those hours.  Management is happy because they’re no longer in the middle of a no-win dispute.

It’s a case of self-service, offerings choices, and loosening up a process until people can participate and imporve the situation for everyone.  By completely rethinking the problem instead of paving the cowpaths (i.e. automating existing manual processes), it’s possible to provide radically better solutions.  Enterprise Software can be sexy, but only if you think of the people more than the process.