AS/400 Users’ “Phantom Limb” Pains
Published On: October 2009
As you may know, TEC performs all types of system selection projects with clients in which analysts are usually involved to a lesser or greater degree. In collaboration with a client, analysts usually prepare the “to be”—the future system business and technical requirements document, or request for information (RFI)—and make corrections or additions to the template based on the client’s current needs. Often analysts are astonished about the kind of future requirements that users demand—especially the users of early Application System 400 (AS/400). I clearly understand that with that statement, I am at risk of inciting anger in AS/400 system proponents; nevertheless, I cannot keep silent and as such need to share what I have discovered during these projects.
It is quite a difficult task to understand the nature of a user’s future system requirements. Their requirements often look unusual—until you know what type of system they’re currently using.
Here are some examples of user worries.
• Concern about the availability of multiple internal interfaces . In my understanding, the interfaces for GL and accounts receivable (A/R), GL and fixed assets, and GL and invoicing (for example) are the core of any enterprise resource planning (ERP) system and must be there by default. Moreover, submodules of the same functional module cannot be interfaced to each other, simply because they are inherent parts of a whole. There are no such problems in any modern ERP software packages.
• Odd report formatting concerns bring you to the era of early mainframe environments—in which black spreadsheets are needed to set up the initial spreadsheet layout (field length, number of fields, etc.). How can this be compared with such highly powerful and flexible analytical tools as business intelligence (BI) applications? Is there a need to specifically require cell font formatting or rows sorting capabilities? I don’t think so. It is there by default.
• Having a user’s query as the only way to obtain current information instead of seeing it on the screen, is a big weakness of AS400 software. Still many of the AS/400 programs show users very little except menu screens, lists of running jobs, and a few information fields. Thus users are still concerning about running queries instead of using visual and user-friendly reporting and data mining tools.
• Green and black screens are the most visible attributes of AS/400. It is quite obvious that there is nothing to discuss here; however, it is fair to say that too many different bright colors, too much animation, and a wide variety of fonts and styles available in some modern software applications quickly become a substantive irritating factor.
• There are multiple user concerns about programming and coding, as AS/400 systems require the user to remember and type program codes and be a “light” programmer. I don’t think it is abnormal when an accountant wants to have, say, pseudo-coding capabilities in a new financial system.
• Another worry seems to be obsolete; running multiple “engines” is no longer required. Lots of errors and other problems were related to the simple fact that one or another software engine is not running for some reason.
• The ability to see a document or the results of a report on the screen before printing is still considered a problem in the AS/400 world. This type of functionality is now available to every PC user, and raising this question in terms of new enterprise software requirements is quite strange.
So, you can imagine how saturated with manifold IT-related issues the typical day of an AS/400 system user can be and what level of software problems that user is fated to resolve or avoid on a daily basis.
No doubt, AS/400 systems provided outstanding input into the world of ERP during their time—and nobody is arguing against that.. Hopefully the most recent releases and versions of the system are much more user-friendly and do not need accountants, buyers, and other regular users to possess the level of technical and programming skills needed to simply navigate and perform basic work functions.
The reason many companies are still using AS/400-based ERP systems is rather simple. At the time they entered the market in the 1970s and ’80s, the first generations of material requirements planning (MRP) and ERP systems were very expensive, and required an extensive infrastructure; thus, they were affordable mainly for large manufacturing, retail enterprises, and banks.
Nowadays, those AS/400 customers have become very complicated businesses with dozens or even hundreds of remotely located subdivisions, plants, or branches. Let’s say an average manufacturing company has 60 plants and distribution centers worldwide, and is going to launch an ERP implementation project in order to replace its existing application. Because of its complexity and size, this level of business requires only tier-one ERP software, for which implementation time in the best-case scenario (using standard implementation methods and standard techniques) cannot be performed in less than six months per plant. Assuming that the company is able to replace the system at six remote sites a year simultaneously, it would take a total of 10 years. New software can become obsolete within that time, and the cost of this implementation would be significant—even for a company of such size.
As a conclusion, I should note that there are absolutely no reasons to be so detailed about remembering all the problems of obsolete applications and in transforming them into new system requirements. Similarly to the medical term “phantom pain” referring to when a patient experiences pain in amputated limb, users of old AS/400 systems still struggle with issues that have been solved years ago. The IT world is very different now. Existing AS/400 users will be surprised at how significantly ERP systems have changed and how far they have progressed since the days of green-black screens.