website hit counter

Tuesday, June 1, 2010

AS/400 Users’ “Phantom Limb” Pains

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.

0 comments:

Post a Comment