Business process automation

Are Users Really “Trainable”? Should they Need Training?

I have developed a reputation around the way I work with users that I am “training” and who display various levels of skill (or non-skill) with their computer system.  From executive levels to the warehouse user my reputation for telling a new user something like “…see - I told you you were ”trainable” has become noted.  Naturally this statement gets many different reactions, but it is always meant as a compliment to the trainees natural ability to use their computer as a tool for accomplishing their job which they “know” how to do. 

That said, in my opinion their “natural ability” to use the tool depends solely upon the application interface.  Should users need to be trained or should they just be able to use an application if they know how to do their job?  It is a lofty goal for sure to think that new users (who know the job they need to do) can instinctively sit down and be able to do their computer tasks without training — but one I believe in.

Now, let the record be set straight — while I may always strive for that in my program / interface design, I seldom achieve it.  But like users, I’m trainable — and that is where listening to and observing users comes in.  My users have very definitely trained me through the years to be more aware and observant of their needs. 

Probably the best example I could give regarding user interface would be the custom order entry system that I was building a number of years back.  I kept getting feedback from the primary users - the ones using it day after day - that it “just didn’t seem right to them”.  I heard their “complaints” initially as that it just wasn’t the way they used to do it.  However, after this went on for a few weeks I volunteered to fill-in for one of the users and do the job for a few hours myself, using my program.  WOW - did I learn a lot!

I learned that my idea of efficient and what they really needed were two different things - and the program was updated within the next few days, and that truly is the way I think it should be.  Yes, users ARE trainable — but I really don’t think any application user interface  should be so complicated that it requires the significant training often associated with implementing something like an ERP system.  Train for the job, the tool use should be instinctive.

The Buy, Build or Ignore Decision

A recent visit to a doctor’s office this week channeled my thinking once again toward the simple applications that can save time in any environment.  As I was checking in at the registration desk, it was noted that they did not have the latest copy of my insurance card.  I gave the receptionist my card, and card in hand she walked to the back of the office to the copier, where she leisurely made a paper copy of first one side and then the other.  She then walked back to the front of the office and passed my card back to me, adding the two 8-1/2X11 mostly blank sheets of paper to my file.

This was one of those times when I wished I had a stopwatch in my pocket.  Yes, it has become just a part of her daily routine.  It seems like nothing, but this is a very busy office, and the receptionist figures she makes that trip at least 20 times per day.  I know that this journey of hers took approximately 1 minute, and used two sheets of paper.  Anyone care to estimate the cost of doing this on a yearly basis?  Monthly? Daily?  It certainly adds up!

Now, what might it take to create a simple application to scan and electronically store this information?  Recently the most requested functionality I’ve been adding to my custom programs have involved scanning application integration.  One can get as complicated or as simple as desired — and a high level of integration can be costly.  However, a simple database coupled with a scanner can be a powerful addition - even if only a temporary one.  It wouldn’t take much time before the cost of such a simple solution paid for itself.

Anyone else see inefficiencies easily and cost effectively addressed (even if incompletely)?  I see them all around me — but maybe I’m the only one :-)  I suspect not however.  I commonly hear from clients that they’ve tried the idea of scanning “…but it was too complicated…”.  It needn’t be, but scanning applications like so many others have fallen prey to the “bloat” we have unfortunately become accustomed to.

Application Requirements, Desires, Business Value and Costs

The title of this post indicates one of the most critical areas, I believe, that needs to be addressed when considering custom applications software.  Most non-IT persons seem to have difficulty separating what is truly an application requirement and what is a desire for an application.  Naturally, a real requirement versus a desire has significant impact on the business value of an application, and of course its costs.

Of course, there are the users who are doing their job day-to-day and don’t really see anything as a requirement for an application.  They get their job done!  What is the advantage to them of doing it in a different manner?  Some potential users of a new application quickly see an advantage to having a new system, or changes made to an existing system. These users seem to instinctively understand the value of what is proposed, or the value of changing the system.

Change is difficult for most application users.  When faced with a new application it always seems to be the worst thing that could have happened to them.  They like the “old” way that has worked — tried and true.  (..yes, the same one they’ve complained about for years!).  But generally speaking, give them a period of time, maybe as little as a week, perhaps two to three weeks, and suddenly the new system is the best thing that ever happened to them.  Many have excellent ideas whcih they are glad to give.

Within a small business, at least businesses of the size I often deal with, what really exists is a collection of users each with their own unique idea of what a system should do — which is based upon their specific responsibilities.  In most instances my experience would say that they have no idea what it takes to computerize what they’re looking for.  That’s truly where the talent and experience of the analyst comes in.  The analyst must ask many questions, and they must be carefully phrased in order to have a meaningful answer returned.

It’s up to the analyst to sort out the true application requirements and what is a desire  — it’s the responsibility of the analyst to talk with the business owners or other knowledgeable management to establish what the business value of the requirements and desires is.  Then, of course, it is also up to the analyst to establish the cost.  This work is not trivial!

Of spreadsheets and databases

I had a rare opportunity last evening to have a conversation with my brother-in-law and our conversation got me to thinking once again about the use of spreadsheets as databases.  It seems that my brother-in-law is quite the guru at using the Excel spreadsheet.  As our conversation progressed, I talked about a simple but powerful application that I had created for one of my customers.  He questioned why I wouldn’t just go ahead and create the application using Excel.  He said that he could do everything that my application did in an Excel spreadsheet, and I had to agree with him — to a point.

My first thought was that the application I was describing was designed from the very start to be a multiuser system.  The application user community I created the system for would not be tolerant of opening up the spreadsheet only to find they couldn’t change it because it was locked by another user.  I also made the point that users doing the data entry had a hard time handling columns and rows and where to put information into something such as a spreadsheet.  Of course, he said that forms to allow easy data entry into a spreadsheet can be created, if one is knowledgeable enough about how to do it.

Bottom line, our conversation once again pointed to the value and requirement of truly establishing the functionality desired from an application, and with those requirements in mind establish what tool to use to create the application.  There are so many variables to consider, not the least of which will include the prospective user group.  He did agree with me that there had to be some knowledgeable person able to create a spreadsheet that would duplicate my application.  My experience with the small companies I’ve worked with, is that there is no truly knowledgeable and experienced person on their staff to create the kinds of programs that a developer can create.

“Getting Real” is Un”Real”!

After my last post where I strongly conveyed my misgivings regarding on-line web apps I found myself looking at a few web apps to see if I were going to have to eat crow after my post.  While crow is not on my immediate menu, I have found that by looking into some of the referenced services included in the article “Work Smarter” that I referenced in my previous post I have found a VERY interesting book — available in on-line pdf or paperback, or just for on-line viewing — “Getting Real“. 

My title for this post indicates the general reception that I immediately gave this reading.  It is at the same time an excellent writing and expression of what I believe software “should” be, and also a controversial, helpful, destructive, right-on — OR totally Un”Real” approach to software development!  You decide!

Is this where application development is heading?  Is 37signals.com ahead of their time?  Do you agree with the concepts of this book? …partially agree?  Or perhaps vehemently DIS-agree?  Is “Getting Real” - “Real” — or Un”Real”?  As for me, I haven’t decided as yet, but I did sign up for one of their services to “try” the idea.  Time will tell I guess! 

…and I must admit that I was impressed with the user interfaces that I saw

Web Applications, Small Business and Trust

“Work Smarter” is the name of the article I read in the April 2008 Entrepreneur Magazine which has prompted another blog post about web applications and their role with small business.  The whole idea of having my key business information and functionality in the hands of another company over which I have absolutely no control is frightful to me.  Continued »

Virtualization Revisited

With much anticipation I find myself preparing my laptop once again to be used as a tool to demonstrate capabilities of software which I developed.  This is no ordinary preparation.  I will soon start an extended road trip during which I will be doing both development and demonstrations.  Last October I wrote in this blog about how valuable virtualization has become in my environment.  Since then, it has become an even more powerful tool which I use daily.  My use of virtualization technology has become a staple component of my development environment. Continued »

Measuring Application Value - Step 2

In my previous post on measuring application value, I stated that the first place to look in establishing application value, is to complete application requirements definition.  Once you have clearly defined what the application is to consist of, and what value you expect the application to provide — you understand the business process that the application addresses and understand the value of having that business process improved.

With the requirements clearly defined, the next step is to establish, as a minimum, some key milestones that need to be met in order to accomplish the task at hand.  A project management tool can help in this endeavor.  One can get as detailed or general as required by the specific project, but with these milestones in place it provides a basis for creating a timeframe within which each task can be accomplished.

Once the timeframe has been created, it is a relatively easy task to then assign a dollar value for the time given an estimate of the individuals to be working on the project.  This approach can work as well for a large project as for a small.

Your work is not done however, because a thorough examination of your milestones will be required in order to determine the proper approach to completing the project.  That proper approach may take into account the particular development tools to be utilized, the pool of talent available for the development, or perhaps also require you to re-evaluate the steps to be taken as the project progresses.  Establishing a clear approach to the problem will go a long way toward establishing and measuring the application’s value.

Careful Application Implementation Adds Application Value

Some time back I wrote in this blog about how I just hadn’t made the time to implement the voice-recognition software which I purchased a number of months ago. (Dragon Naturally Speaking). With the meltdown of my primary workstation a couple of weeks ago, it was necessary for me to replace my main workstation. This has been a huge project, resulting also in a domino effect with my internal development network. Thankfully now my changes have all been implemented.

However, now that most of the issues involved with replacing my main work station have been resolved, I decided to spend some time this evening to install, train, and actually use my new software. I must say that this has been a great experience. (P. S. I’m not getting paid by Dragon). I now have it working on my main workstation where I intend to use it daily. Who knows, it may even provide me with a tool to be able to blog more frequently!

So what does any of this have to do with software development? One might also ask, what does that have to do with what has been my recent topic — that of application value? What I’m seeing at this point, is that in a very short time this application has proven value to me. I expect that the more I work with this software, the more valuable it will become to my day-to-day operations.

Training, taking the time for training, experimenting, hands-on experience — there is absolutely no substitute for taking the time for successful implementation. The quality of training during the software implementation phase can have a significant impact on the long-range value of the software application.

Quick Thoughts on Application Value

Experience a major meltdown of your workstation and I suspect the value of various applications will come to mind VERY quickly! There is nothing like going without your favorite applications, or your workhorse applications for a few days to develop a significant appreciation for application value. My last 2 weeks have been filled with recovering from such a meltdown.

If you’re like me as you have used your workstation (…perhaps for years) it has accumulated a number of handy utilities that are not “big” names, yet you use them each and every day. Perhaps they were something you found on the internet years ago and fell in love with and it has become part and parcel of your day-to-day work. What happens IF (or more likely when?) suddenly your workstation has a meltdown? It’s really not pretty!

Replacing a defunct workstation with a brand new one is only the start of the battle - the easy part. Gathering all the software you had, reloading it, re-registering it, restoring all the “little” applications (…finding where you got them from can even be a challenge I found!) all present challenges. Doing all this while at the same time tending (…or trying to tend to) the business needs becomes a stress-producing and frustrating experience.

When it comes to establishing application value I really wonder how one would determine in advance the effect of having an application suddenly NOT available once all the investment in application creation and implementation was made. I believe that if in the early stages of application definition one would be able to look ahead 5 years to look at what the potential dependency might be on the application it could be another way to think of application value.