Adoption Series – Getting Over the Hump

I guess today (Wednesday) is “Hump Day” – It’s not a term I’ve ever incorporated into my everyday conversations. To be honest, I actually try to avoid using it because (1) with 24/7 connectivity and employer demands, work weeks all start to blend together – when you’re always on “the clock,” there is no true middle or hump to get over and (2) the clowns who think the double entendre of the term is still funny after saying it every Wednesday for 24 weeks straight….

That said, getting over the hump is and can be a real accomplishment. Our continuing supply management technology adoption series looks at two aspects of adoption – (1) the larger marketplace adoption of solutions by enterprises and (2) the end-user adoption of those solutions once deployed within the enterprise. We’ve focused more on end-user adoption and today is no different. We will get to the issue the marketplace adoption of technology in future articles.

When it comes to change, people tend to associate a “learning curve” to things that are “new,” be it process, policy, or technology. A learning curve generally implies that for some period of time, it may actually take the end-user more time to do it the “new” way rather than the old way – even if the “new” way is much more efficient. This can be the case for simple and complex activities alike.

I would argue that until the efficiency “hump” (or inflection point) is crossed, specific end-user interest can begin to wane which can, in turn, cause end-user adoption to struggle and fade. Let’s look at two technology examples in supply management focused strictly on the end-user:

1. “Flat” learning curve example: Requisition/PO approval is a relatively simple activity. In the offline legacy process, someone (i.e. an admin) hands the requisition to the approver who looks at it, signs it, and hands it back. The approver (end-user) can spend literally just a few seconds approving a requisition for three new servers and this is immediately off his/her plate. Utilizing an eProcurement system, the approver receives an email that has a hyperlink to a system that may require the approver to login to a system [Sidebar: the system may actually not require a login, but I’m trying to make a point]. This requires the approver to find and/or remember the password (“where did that UN/PW email go?”) and navigate a new system (“I wish I had gone to the training”) and possibly make a few bad clicks (“What do you mean I can’t hit the back button on my browser?”). Depending on the approver (orientation, aptitude, etc.) and the system (there are differences in UIs and ease of use in the supply management applications market), it will take somewhere between a few and many system-generated approval requests before the approver actually spends less time on each automated approval than an offline approval.
2. Steeper learning curve: A Request for Information (“RFI”). In the offline process, the sourcing or category lead would pull together a series of questions in excel or word doc format and email them to a number of suppliers. Cut & paste the document, make a few phone calls to get email addresses, wait for responses, review and make some decisions. I won’t go step-by-step through the online process but the new process requires some level of system competency, the registration of suppliers and the inputting of questions into an e-RFI. Depending on the user (orientation, aptitude, etc.) and the system (there are differences in UIs and ease of use in the supply management applications market), it will take one or two or four etc. events before the end-user spends less time on an eRFx.

Now, an end-user’s time spent on an activity, in and of itself, may not be the best measure of the overall efficiency or value of a new, automated process – it can miss the bigger picture. But, I believe that most end-users will focus on their time savings or lack thereof, to measure process efficiency. “If it takes me more time to set up an eRFx, I am less efficient. Therefore, if I use the new automated system, I must either work more hours or I will accomplish less.” It’s not always such a stark contrast, but this is an issue that must be addressed – something we’ll look to do in our next installment in the series.

RELATED TOPICS