Business process automation

Factors Against a Custom Application

My previous post pointed out a few of the reasons why one might choose to create a custom application.  For this post I’d like to further the discussion to review some of the reasons (valid and otherwise) for NOT creating a custom application.  I would include in this category:

• FEAR - Many a story has been told about the “dream” development project that became a nightmare - obviously what there is to do here is to carefully select developer(s)
• It will be “Too Costly” - It doesn’t have to be in most cases
• “Standards” won’t allow it
• Too big of a commitment
• No “New” requirements are on the horizon
• Suitable “Off-the-shelf” software for your industry is available and within your budget range
• Your operation is running efficiently, programs being used suit your needs
• Users are getting what they need from the existing system
• Existing system is technically “up-to-date”

 Certainly if the last four points above hold true for your operation one would be hard-pressed to create a valid case for a custom program - you just don’t need it!  As for the standards issue there’s not much I can say about it.  I have seen companies that have struggled with exceptionally ineffective and inefficient software - only because a proposed app won’t “fit” the “Standard” - I have to seriously wonder about this decision.  In some instances it seems to be that the “Fear” or “Too costly” or “fear of commitment” arguments come into place.

Next Post — “Identifying Potentially Valuable Custom Applications”

Identifying Potentially Valuable Custom Applications

Without fail, in my experience as a developer any potentially valuable custom application project has been the result of identifying some area of operation which:

• Has become unwieldy, requiring too many steps or multiple data entry
• Has become more and more demanding as a result of increased volume
• Always seemed to be behind time - trying to play catchup and not succeeding
• Required information availability not currently or effectively available
• Just “seemed” to take too long to accomplish

My post Application Value is an excellent example of creating a custom application because of unwieldiness.  Another application which I designed that provided for scanning and categorizing of tax exempt certificates was an application which solved all of the issues mentioned above. 

Availability of information is a key factor in identifying value - i.e. An operation may be required to maintain original records  to produce during audits, yet, that same information may also be required at out-lying locations.  The choice can be to maintain a file at each location (trying to keep it up-to-date at all times of course), or somehow provide the means to quickly access the information via a custom application.  “Scanning and Cataloguing” such information can provide the ready access required to solve the problem - and there probably isn’t an “off-the-shelf” program to help!

Bottom line to identifying potentially valuable applications — Review operations closely to identify any of the categories listed above.  Once identified - it’s time to get creative!

Why Create a Custom Application?

First — In the interest of public discloser I must confess that perhaps I am biased on the subject of custom applications.  While writing my previous post I found myself once again becoming excited about application development, and more especially the value that such an application can bring to an operation.  I suspect that thousands, maybe hundreds of thousands of potentially high value applications remain undeveloped because those responsible for the operation do not realize that it is possible to have the kind of efficient, specific and valuable applications developed at a reasonable cost.

Development tools available today provide the means to easily produce an application in stages, creating an initial database, entry forms and limited reporting as users are loading data into master tables etc.  While my experience with development tools other than Visual Dataflex (VDF) is limited, I’m aware that there are multiple paths to produce powerful applications for a reasonable cost.  The applications can easily be multi-user at the start and grow as additional functionality is desired.  No need to use an expensive database, although the tools in most cases can “talk” with multiple databases. 

So, back to “Why a Custom Application?”  I’d list the following:

• Custom Apps can be “lean and mean” - no “extras” needed
• “New” functionality is added only as desired, not at a designers whim
• “Lean and mean” is efficient
• More “understandable” for users - thus easier to use with fewer errors
• A well developed app can provide excellent return on investment
• “Off-the-shelf” software doesn’t really “fit” your needs or requires too much in the way of training, maintenance or “tweaking” for it to be of value
• Your industry doesn’t have any “canned” vertical market software available, or it is designed for too large/small an operation, is too costly, doesn’t “fit” the way you want/need it to.

You can probably think of many others as well, but I believe those above list covers the gambit.

Next Post — “Factors Against a Custom Application?”

Accelerated ERP Implementation Risks

To this day (…and possibly forever) I remember August 1, 1999 not with fond memories, but rather with a complex set of emotions which begin a churning upset in my stomach.  The day was, without a doubt, one of the most memorable days of my life for its stress level.  It was the perfect example of an ERP implementation gone wrong!  In retrospect it is understandable that it was.

What has brought this infamous day to mind was reading a white paper entitled “ERP at the Speed of Light“, an excellent white paper which I discovered this morning as the result of an email. Looking back for me as I read the white paper’s list of “key risks” of an accelerated implementation, we experienced each of the risks outlined in the paper, as well as a few more not mentioned — not the least of which was “buggy” and incomplete software.  While we made every effort to work with the “out-of-the-box” processes offered, they just didn’t work.

The article states that “…in any scenario, there is a certain level of disruption of existing operations in the course of an ERP engagement…”, and we certainly experienced that to the utmost!  Our implementation accomplished only one primary goal in its early stages — our unmanageable different applications inherited during growth through acquisition were replaced — as a company we were now all “on the same page”, the page hating the new software.  We had in fact been united!

Business Changes, Personnel Changes and the Custom Application

There’s nothing that I can think of to “shake up” business processes and the custom applications used to support those processes more than a personnel change.  This is most clearly apparent in the small company applications used by a handful of key users in the company.  If for whatever reason one of those key users is not available for an extended period of time and others are doing what was “their” job, questions are inevitably raised about “Why is this like this?  Why are we doing this this way?  Wouldn’t it be better to…?”  In my experience while changes in business needs can elicit those same questions, by far the most dramatic and in-depth questions come from the change of personnel doing a job. 

I have been dealing with a couple of situations in the past weeks that fall into this category — and the end result of those questions is, and will be, a much “cleaner”, “user-friendly” and “efficient” program.  The change is good!  It seems that the longer an application is used the more “set in our ways” we get about the program just “being” a certain way - rather than challenging either the process or the program.  My clients are always encouraged to be on the lookout for potential changes to make their jobs easier, that’s just the kind of relationship that I’ve built with my clients, but it seems to take some dramatic change to elicit new requests.  In so many cases the changes are not necessarily extensive — often just a “tweak” here or there that over time makes a significant contribution to efficiency. 

Software Application Speed and ADD Users

ADD — aka Attention Deficit Disorder — is, some say, an altogether too common ailment in today’s society, at least in the U.S. While I certainly don’t intend to debate that issue, a recent experience got me to thinking about how children with ADD do and will grow up to be computer application users. These thoughts in turn had me thinking once again about application interface design and user needs.

Much is written about interface design. For years we’ve worked hard to provide intuitive “user-friendly” interfaces for our applications. Much has been written about visual presentation, and many options for changes to the visual presentation such as “skinning” have been introduced.

Perhaps, however, the most important of all the considerations for an application should be the application response time. I’m not aware of any user who doesn’t get impatient with poor response - defined here as a response time meeting their personal expectation! As more and more users (ADD or otherwise) become frustrated with either speed issues OR for some, the cluttered screen, it seems imperative that we as developers be constantly on the alert for signs of this frustration brewing. My experience would indicate that most computer applications used in a business environment are not being used by “computer” users, but rather by users who understand the task or job they are required to do, and (in some case, regrettably) must use the “computer” to accomplish the task.

Application design is no trivial task!

New Applications - Taking the First Step

Social networking in business has been receiving quite a bit of press lately with many differing views on just what should or should not be allowed, or how to use various social networking tools now available.  I ran into an interesting read in an article “Social networking in business: Avoid the ‘Kumbaya Zone‘.  Now, the ‘Kumbaya Zone’ is a new term for me, and the article refers to it as “…the place where social media is ultimately a time-waster and has little business value”.  

Now I don’t want to get into any do’s or don’ts about social media - nor do I think that it would be wise for me to do so — but what I do want to address is that perhaps many of us have seen applications which appear to become time-wasters with little business value, I certainly have.  They may be the “old” application never replaced, or they may be an application for which users have developed so many work-arounds to have it fit that there is much time wasted.  Either way, the application has little business value.

The referenced article ends with the statement “Get comfortable taking that first step, and see what works along the way. That is way different from the software model we’re used to.”  Now, I certainly agree with the first sentence concept of getting comfortable and  seeing what works - and while the article specifically is talking about social media, I would posit that this is an approach worth considering for any new application.  As for being a different software model than we’re used to, I must say that working with my customers we’ve been able to create an environment where we do to a large degree follow the concept - it doesn’t have to be “…way different…” than we’re used to.

What keeps an out-of-date application in place

I had the opportunity recently to make some minor changes to reports originally created in the late 80’s. The application is a character-based app running on an “old” version of SCO Unix, and hardware that has been kept alive by some clever mix and match combination of “old” components taken from servers long ago taken out of service.  To say this is out-of-date is being kind - let’s say it owes nothing.

My first thought when I posed the question “What keeps an out-of-date application in place?” was that of course — it’s money!  While that jumped into my mind immediately, I began also to consider what else would be keeping the app alive.  For one thing, there is the fact that it is basic, lean and mean (read that fast response), and works well for what it was designed to do.  The issue here is that it wasn’t designed to do much of what the modern business requires it to do in 2008.  It is also difficult to support, although it doesn’t require significant support.

So what else might be keeping it going if money isn’t the real issue?  How about fear?  With any new implementation there is always a fear factor that has to be overcome.  What if the wrong application has been chosen?  What if it doesn’t fit as expected?  What if, what if, what if???  You can probably think of dozens of scenarios which might cause an organization to avoid replacing an application, but none of them would exist on any of the “best practices” lists.

It just so happens that in the history of this company there was a failed implementation of software which at the time was thought to be a good “upgrade” for the company.  Many thousands of dollars were spent on equipment, software, support and consulting fees for the project which never got completed.  It seems that the business processes that needed to change in order to get the desired results from the software were just too much.  The company was sold during this time.  Go figure!

(…although I don’t remember the year that took place, I’m pretty sure it was over 10 years ago

Information Overload

Information overload is a topic which has seen enough blog and article time to provide a generous amount of information overload on its own!  As an example, I searched Google for the term “information overload” and it returned the first 10 of approximately 2,160,000 “hits” (…but who’s counting?   :-)   No wonder we need data warehouses!  I figure that is probably a bit more information than this modest man can (or wants) to handle - yet of course as I scanned that first page of “hits” I had to check out a couple of them.

One of the hits that I followed in particular caught my attention and prompted me to both chuckle to myself and to think about my own habits.  A blog response from Noam Chomsky  really started me thinking — in response to a question about tips for handling information overflow he replied:  “I wish I could answer sensibly. I just can’t. You should see the room in which I’m working. Piles of books, clippings, manuscripts, notes,… All sorts of lost treasures buried in them.“  Sound familiar?

His response really brought home to me that my habits of saving information, whether it be printed material, sound clips, email or internet links encourages my sometimes overwhelming “buried” feeling - information overload is alive and well in my life, as well as “…all sorts of lost treasures…”!

Now, to get to the real point of this post — as a developer I believe that it is in my clients best interest to support them in providing the information they need to forward their businesses -  whatever that is.  It is very easy for me to provide them with too much information (…some say there can never be enough) in the form of reports, graphs and miscellaneous on-line “views” of their data.  However, I believe that it is a “key” responsibility of mine to constantly be aware of the tendency toward “information overload”.

Sometimes the Obvious is Missing

We developers need input from our users!

This became very clear to me once again last week when I received an unexpected request from a user to add a simple lookup function to a field in their order entry program which has been in use (…and regularly enhanced) for over 5 years.  When I first received the request I was shocked to discover that such an obviously beneficial function would be missing.  In fact, my first thought was something like “How could [the user] miss it?  Of course there is a lookup there!”  Then, upon further investigation and review going back numerous iterations and versions I discovered much to my surprise that it NEVER was there — an obvious omission.

All of this led me to recognize once again the value of having a close relationship with my user community.  Working with the small & medium size companies that I do, it is generally commonplace.   This incident also pointed out to me that user and software developer/designer alike can easily miss obvious functionality enhancements.

P.S.  The program now has the desired lookup!