A few months ago I wrote an article laying out four ways to fail at automating business processes. I wouldn’t want anyone to think that it was a comprehensive list (wouldn’t it be nice if there were a limited number of ways to fail?), so here is one more. (Actually, I have five more, but the other four will wait for other days.)
Have the Process Experts Design the New System
Your business office experts are responsible for getting the transactions into your business system. They know every field and valid value, every policy, law, exception, and pitfall. So they’re the ones to design the new, automated version of the process, right? Wrong.
Although the business process experts are the experts, there are several reasons why they are often not the right people to design a system. Although the experts in the core business offices may be the most knowledgeable process participants, they often make up a tiny fraction of the user community for the automated system. Most of the users will be those starting and approving transactions out in the departments. Excluding the bulk of the participants from the design process is a great way to fail!
Here are some reasons:
What the end users know and don’t know. Going from a paper process to an online one should be a big boon to users out in the organization. Surprisingly, though, automation initiatives often receive pushback from distributed users. It often sounds something like this: “It is HR’s job to get the data into the system. You’re making us do HR’s work.” In our experience, this usually means, “You’re giving us a system that requires us to learn more HR rules and language.”
To an expert, asking the end user to identify what action they are taking seems straightforward, but when a departmental administrative assistant who only does a few HR transactions a month has to look at a list of thirty-seven possible actions and distinguish between “Career-Track Promotion” and “Internal Promotion + Reclass”, it is understandable for him to feel he is doing someone else’s job.
End users prefer a different user experience. Core office users who are in the system all day, every day, are more likely to want condensed pages with keystroke navigation for high-speed, heads-down work. End users prefer simpler pages and a guided process that requires less expertise and practice to use successfully.
Core office users can have agendas. The core office users want the end user page to display twelve read-only fields that will populate when the user enters a position number. Why? “The department users don’t know enough about their own positions.” This may be true, but is it a priority for the project sponsor to educate the end users at the expense of transaction speed and ease of use? Maybe, maybe not.
End users have shadow processes that core users don’t know about. While estimating an automation project, we asked a client’s core office users about their workflow complexity. They said, “It’s easy, we always have two and only two approvers sign each transaction before it goes to HR.” In Discovery, they reiterated this; always two signatures on their paper forms. Okay, we asked, what two people sign it?
Silence. Eventually, they admitted that they didn’t know; they always just checked that the two empty spaces on the paper form both had a signature in them.
We then asked end user representatives from several departments how the approval process worked. Most had a complex shadow process to squeeze in additional approvals. (“The red ladybug stamp means Jill in Academic Advising has reviewed it, and the green butterfly stamp means George in Compensation approved it.”) Others didn’t have any approvals; the person filling out the form just also signed both blanks so HR would take it.
The end user shadow processes can be great targets for automation, streamlining, and standardization.
The Interdisciplinary Project Team
So who should design the system? An interdisciplinary project team that, in addition to the core office superusers, includes a sponsor representative, end-user advocates (preferably experienced end users and approvers from pilot departments), a UX (User eXperience) advisor, and don’t underestimate the value of (shameless plug here) outside experts with a focus on process automation in your business space.
So when it comes time to design your automated process, don’t just leave it to the experts; none of us is as smart as all of us!
