Phase III - Performance Enhancements - Business Process Evaluation
Dateline: Roseville - May 29, 2008
Today's news post discusses Phase III of our Performance Enhancement effort: Business Process Evaluation. There are two things going on here:
- Making sure users are using the system as intended - matching up their workflows with Escape Online 5..
- Creating new functionality based on our architecture and users workflows.
Matching up user workflows with the system.
I was on site many months ago when a payroll user stopped me to complain about the speed of something she was doing. She fired up Escape Classic and showed me that doing it in Classic only took about 2 seconds per form, whereas in Online 5 it took 8 seconds. My response was that we didn't build that process to support the workflow she was doing, which was verifying what she had previously entered. I knew that there was a report we had designed specifically for this purpose. So I called one of our support reps and found out that it is the Pay13 report. I had the user print this and she was very delighted. "Wow, this is going to go so much faster!" she exclaimed.
Very proud both of my success, and our foresight in having spec'd, developed, tested and deployed exactly the report she needed, at the office the next day I explained my "big score" on-site. "Well," says one of my co-workers, "I told her about that report last month too."
My bubble suitably burst, I sat down to ponder this situation. The reality is that people like to keep doing things the same way. This user was very successful with her process for many years. She really didn't want to change it, even though the new process was quite a bit better (more information on hand than on the previous screen), easier physically.
Online 5 is a Windows program. There are some aspects of the program that are never going to be as fast as a character based system like Escape Classic or all the HP-3000 based systems out there. But - we can also create amazing functionality that those systems could never dream of. In overall terms, the Online 5 systems processes will save user large amounts of time compared to Classic, but only if they use it as intended. This will be an ongoing process as we have the chance to interface with users, or they ask us for a better way to do something.
Having said that....
Creating New Functionality Based on Our Architecture and User's Workflows
Our system is built on a series of "frameworks." It's a Windows application. It's written in Microsoft .Net C#. We have created our own "look and feel" - it's the Escape Online 5 User Interface toolkit. The Search/List/Form metaphor.
For the foreseeable future, this is very nice "house" that our application lives in. So if a given "thing" a user does takes 5 seconds, unless there is something really wrong with it, it is unlikely we can tweak it to only take 1 second. In the context of the purpose of this activity, 5 seconds would be acceptable. But what we can do is invent new functionality - when we find a given user workflow that does not have a Escape Online activity which supports it well.
Example: Approvals. In Classic, approvals of documents like requisitions was done on a one by one basis. Approving any requisition was a minimum of 15 keystrokes, could be more. So if you have 20 reqs to approve, you are looking at 400 keystrokes. But because the system processed those keystrokes quickly, no one ever compained. Since this is an activity used frequently, by lots of users, when we designed this functionality in Online, we took a fresh approach. What if users don't have to open the form? What if we show them all of the important information, for all the reqs, all on one screen? We used the advantages of the Escape Online 5 system, and created functionality that replaces those 400 keystrokes with about 5 mouse clicks.
This screen displays all the requisitions requiring your approval. In order to see the detail, you press the preview button, which shows all of the important information for each requisition in a single scrollable screen. Two clicks then brings up this posting confirmation, one more click and you are done. In Classic, the user would need about 20 keystrokes for each individual requisition to accomplish the same process.
We have repeated this kind of advancement in many areas of the system.
And we will continue to do so. Where it is determined that a given process is not as efficient as users would like, in most cases we should be able to devise another way of processing that data, perhaps even with a new activity, within the framework we have.
Gaining end user performance through this phase is a bit more difficult than other phases. Most people do not have the imagination to say "if this process was changed like this, we could get our work done more quickly." Secondly, doing new development is costly from a time perspective. Whereas a change we might make for a monthly release could affect many activities, improving performance of each of them, these types of enhancements are targeted at specific sets of users.
As we come up with new twists on ways to handle user workflows, and can fit them in with all our other development efforts, we will do so.
We also encourage our users to describe their workflows to us, the ones where they feel our system isn't handling as well as it could. Then we will apply the principles of this phase. Give them an alternative solution that exists, or devise a new one.
Comments? Send us an email and let us know what you think.
| 