Maintain existing applications / The ERP Implementation Story

A company starts on a small scale, has no need for computers. Grows. Starts experiencing the limitations of manual processes, but still isn’t big enough to invest heavily in IT. Buys some PCs. Employs one person. He is the IT Manager, Developer, Operator, Network Engineer – in short, a one-person IT department.

The company continues to grow. Employs one more person in IT. Each PC becomes an Information Island. Data gets transferred from PC to PC using diskettes, CDs, Pen Drives, or Drive Sharing through the network, depending upon when the company started. The information on PCs isn’t in sync. The Production Manager’s Delivery figures don’t match with the Marketing Manager’s Receipts from factory. The Marketing Manager’s Sales figures don’t match with the Finance Manager’s Revenue figures. Everyone spends lot of time finding out why the figures don’t match. And everyone finds reasons – plenty of them. Everyone agrees that something needs to be done to improve the situation.

ERP vendors’ Marketing folks are looking for companies in the situation described above. One of them is a friend of someone on the Board. The Board gets a presentation of the ERP. Everyone is impressed. It is decided to let the market know that the company is interested in implementing an ERP. Presentations for various ERPs take place. Two or three vendors are short-listed. Negotiations take place. The company management tells the ERP vendor, “We are special. Though most of your ERP’s features suit us, we find that some are missing. Can you customize?” Marketing folks from the ERP vendor say, “Yes, of course – at extra cost. We can’t tell you up front how much it will be, because we can’t do that unless we know the exact requirements. You list the requirements, and we’ll discuss them later. In the meantime, let’s go ahead and sign a contract for the Vanilla implementation.”

Contract for the Vanilla implementation is signed; training & implementation plans are drawn up. Someone from the top management is put in charge of the implementation, usually the CIO or the CFO. They have the responsibility but do not have the authority over the folks that need to be trained. Daily operational tasks get priority over the ERP implementation related tasks, because the Business Managers tell the top management that the company must first earn its bread & butter today if it has to survive & thrive. Delays start occurring. The list of customizations starts getting longer. Cost and time overruns start occurring. Middle Management is already stressed a lot by this time. Managers in that level start looking out for jobs elsewhere. And they go, taking away precious ERP knowledge that the company had acquired so far. The ERP implementation now seems like a tunnel with no end in sight. Lots of time and money spent, but nothing close to the results originally expected!!!

The company somehow manages to implement something. No one within the company is really happy with it. The issues pile up. The customizations are not in place, because the company has already spent so much that it cannot now afford the ERP vendor’s charges. The company starts looking for someone who could help, without costing too much. If you are at this stage, I may be able to help you.

Provide technical support for preparation of Knowledge Transfer phase

Taking over support of existing applications developed by someone else is quite different from developing new applications. Many factors that are not applicable for new development come into play. If proper planning is not done at this stage, the result can be a nightmare for all parties involved. The value of having a person with rich technical & project management experience cannot be over-emphasized.

Typically, the first step in taking over support is a Knowledge Transfer. In this phase, the new support team learns about the application from the current support team. Planning for Knowledge Transfer phase is crucial. Questions, such as the following, need to be asked before planning the Knowledge Transfer phase:

What if a user wants a screen to be modified but the source code for the screen is not available? What if multiple executables of the same program compiled from multiple sources are present on the machine, and there is no record of which executable belongs to which source? How critical is the application from a business point of view?

What is the typical problem resolution time expected by end users? Are there any service level agreements? What if a problem is not resolved within stipulated time? Are there any penalty clauses?

Is the existing system documented? Is it well documented? Is the documentation up-to-date? Has the application been well designed? Is the structure modular? Have any standards been followed for screen, program, and report design? Is historic data regarding the issues and solutions available? Can it be queried quickly?

Have any commitments been made to the end users by the existing support team and are expected to be delivered by the new offshore support team? Was the application developed in-house or bought off-the-shelf? If it was bought from the market, was it customized? What’s the extent of customization?

Can the knowledge transfer be smooth or will it be in a hostile environment? What’s the language used by the end users? French, English, Chinese, Japanese, German? Do our technical resources understand it?

How is source code managed? Is any commercially available configuration management tool in use? Do we have knowledge of that tool? If not, how do we get that knowledge? Has time been planned for this knowledge transfer as well?

Are the applications being taken over for support having interfaces with other applications that are not within the scope of our support? What data our applications receive from other applications? What data our applications send to other applications? Are any changes likely in their format in the near future?

Are the applications being taken over SOX compliant? Do they require to be SOX compliant?

How is the testing done? Is a separate test environment always available for developers / support staff? Is it a replica of the production environment? Is it possible to get the test data refreshed using backups of live data? Will the offshore team be allowed to refresh the data? Or will it be necessary to go through the operations department? Is the operations department working 24 hours? When is the machine not available because of the backups?

Represent my client during Knowledge Transfer phase

Typically, after the Knowledge Transfer (KT) phase has been planned, a small team of experienced members with good communication skills goes on-site for study. The team should be able to build confidence in the end users that my client can support them as well as the existing team does now. The  team that goes onsite for KT is always being observed by the customer, right from the time the plane lands at the airport until it takes off for the return journey. The way the team members dress, communicate with each other and with the customer’s staff, spend their evenings and week ends, take  lunch / tea-coffee breaks – all gets noticed. The rapport established during this period helps a lot when the maintenance is fully handed over to the new team. My experiences in Hong Kong, Belgium, Netherlands, France, Singapore, the UK, and the US will help my being on board with my client’s team.

Conduct AS/400 technical interviews

Companies need to build a strong team to support/maintain applications. There has to be a good mix of experienced AS/400 professionals and freshers. I have conducted telephonic as well as personal AS/400 technical interviews for local and global IT companies.

Build AS/400 Application Maintenance Team

Even after a good team has been formed with the right mix of experienced and fresh resources, it is necessary to impart to this team as much application knowledge as possible, as quickly as possible. It is necessary because only a handful of team members can be accommodated in the on-site knowledge transfer phase. Experience of documenting acquired knowledge and later using that documentation to train new team members helps. I have got that experience.

Train freshers for AS/400 development jobs

In my experience, it is possible to make bright, hard-working, eager-to-learn youngsters ready for AS/400 development jobs within three months. People I trained are now working / have worked for IBM, HSBC, KPIT Cummins, Wipro, Hexaware, Capgemini, FiServ, PCS, and Cognizant. I do not claim that anyone can be trained for AS/400. It requires a certain aptitude. I have developed my own aptitude test that has helped a lot in identifying candidates with good potential. (However, maintenance is an altogether different ball game. Twenty one-year olds cannot replace one twenty-year old when it comes to delivery!)

Since year 2001, I have been training freshers with no AS/400 background. Based on my experience, I have designed a syllabus for such novices. My objective of training the freshers is to make them productive at the earliest, for technical development work on the AS/400. In my experience, trying to teach anything more does not yield good returns. In fact, it reduces the returns. This happens because the participants get overwhelmed.

In my experience, it requires 220 hours to cover the topics in my syllabus. These 220 hours do not include any time for practicals. I have not included the time for practicals because the requirements & expectations of clients vary greatly in this regard. Some expect that the participants should code everything from scratch during the practicals. (I do not recommend this because it means higher training cost for the client. The client will be paying me for the time when I’ll not be full time busy with the participants because they will be typing, thinking etc.) Some are happy to completely skip the practical during the training. They want the participants to focus on understanding rather than doing during the training. They know that even after the training, the candidates need some practice in order to get up to speed, and they plan and schedule for the same. They do not expect that the participants will become fully productive on day-1 after the training.

Re-use is the key to increased productivity. It reduces IT cost. It reduces the delivery time. It improves the readability of the code. It improves the reliability of the software. It reduces the maintenance time. It reduces the impact of attrition. An established IT shop will have templates and standards, not only for coding but even for documents like “Response to RFP”, “Functional Specifications”, “Technical Specifications”, “Program Specifications”, “Test Cases” etc. I think that’s what SEI CMM & ISO are all about. I very strongly believe that freshers should never code a program from scratch. Their seniors must have coded, after considerable thought, thoroughly tested, and then implemented programs in Live environment. The seniors must insist that the freshers use these time-tested, well-proven programs as the starting point instead of reinventing the wheel. They should explain why the code has been written the way it has been written – the philosophy behind the programs’ structure, naming conventions etc. They should review the freshers’ code to ensure that the code is as per standards, and that the freshers have not introduced bugs in the original bug-free code.

I do not allow freshers in my team to write code from scratch. My programs have a “Based on program” comment line. When I review the code and find “None” written in this line, I ask the trainee programmer to fill that in. I never assign any program to freshers unless I already have a similar program working in Live environment. After all, what do we do in any Business Application? Capture data, store it, sort it, summarize it, and present it.

Though I insist that the programmers should not code a program from scratch, I am totally against blind copying. I tell programmers that they are responsible for every single character in their source code. They should be smart copy-cats, not dumb dummies. They should copy not because they don’t know how to code from scratch, but to avoid silly mistakes that even the smartest of the programmers will make, if he starts coding from scratch.

The syllabus and the training material that I have prepared are based on my beliefs stated above. After explaining the AS/400 basic concepts, I start with a very simple example – “Hello World” – that most freshers are familiar with. And then, using examples that become more and more sophisticated, I demonstrate how to develop an application on the AS/400. An example towards the end of the training is very close to a real-life business application. Then I give the participants a mini-project for practicing the skills they acquire during the training. My idea is that the participants should, using the examples they have learned during the training, develop an application that resembles real-life applications.

Train AS/400 developers for System/36 maintenance jobs

Some code written for System/36 is still in use. It needs to be maintained and supported, until it is phased out eventually. Typically, the System/36 code may form a small percentage of the total application code that needs to be maintained and supported. There aren’t very many developers in the market who have actually worked on a real System/36 and have also got first-hand experience of migrating & supporting original System/36 application to S/36 environment on the AS/400. A four-day training for your AS/400 developers is a wise investment if they have to support / maintain System/36 code on the AS/400. I conducted such a training in Bangalore for Wipro.

Train non-IT staff  in IT Basics and COBOL

I designed these two training courses at the request of a customer. This customer has got an offshore development centre in India and serves the Japanese market. This customer employs translators. The documents that need translation are mostly technical documents related to IT. My customer thought that it was a good idea to introduce the translating staff first to basic IT concepts and then to COBOL, because most of the documents needing translation were related to COBOL. The feedback of the participants was so good that the customer asked me to conduct AS/400 Concepts & Tools training for them.

Conduct Control Language Training

Introduction to Basic CL programming: Control Language-Features, Command Syntax, Program Structure, Declare CL Variable, Conditional Execution, Branching Within and Outside, Changing value of a variable, Concatenation, %SUBSTRING, Local Data Area

Advanced facilities of CL programs: Control Language-Features, Using Display File, Interprogram Communication, Job Switches, Retrieving External Attributes, Convert Date, Data Area Objects & Programming, Prompting for Command

Message Programming and User Written Tools: Predefined Messages and Immediate Messages, Message Types, Managing Exceptions, Reply Messages, System Reply List, User Written Utility, Using Database File, Commands without an OUTFILE parameter

User Defined Commands: Creation of User Defined Command, Command Definition Statements, PARM Statement, QUAL Statement, Dependent Relationship, Conditional Prompting, Examples, Command Execution

Advise on AS/400 technical matters, especially maintenance of existing applications

Pointing the bright, hard-working, eager-to-learn youngsters in the right direction is all that is sometimes necessary. My experience of working on a variety of hardware like IBM 1401, Data General MV-4000, IBM 43xx Mainframes, IBM S/34, IBM S/36, and AS/400, and ERPs RentalMan, Movex, Mapics, JBA, Prism, Macpac, and J D Edwards would certainly help my client’s maintenance team. For many reasons, the coding style of legacy RPG applications is quite different from the coding style of COBOL programmers.

Enable Unicode

I don’t claim to be an expert in this area, but I have worked on a real Unicode enablement project for 12 months. Here are the details:

Project: Create Unicode-enabled version of a leading software product
My Role: Tech Lead Client: A US company
Hardware/OS: AS/400, OS/400 (V5R4) Languages: RPGLE, CLLE

Project Summary

The client was a leading provider of software products and services in the US market. It decided to Unicode-enable one of its products as a strategic initiative for Globalization. The project involved two phases: software modifications, and testing.

The modifications to the software made it possible to acquire, store, and retrieve data seamlessly in both, Chinese and English languages. This feature was relevant for alphanumeric data. Every Unicode-enabled field takes twice the original storage. Therefore, only some of the fields were Unicode-enabled, for example, the fields that would store information like the names of people, the descriptions of items, addresses, search words, etc.

Changes to Physical Files are required for storing the Chinese language data. The data type of the field changes from CHARACTER to GRAPHICAL (CCSID 1200). Unicode-enablement is relatively new and, in my opinion, IBM is not yet fully geared up to seamlessly support Unicode in applications developed using RPGLE & CLLE. Hence, Logical Files, Display Files, and Printer Files, and RPGLE & CLLE programs also need modifications. A tool developed by a third-party vendor was used for the Unicode conversion process. It automated some of the modifications, but the more complex changes had to be handled manually. The client decided not to Unit Test the modifications, for several reasons.

IBM does not provide Unicode support for legacy Printer Files that use O-specs. We had to convert programs to use external printer files instead of O-specs. I developed a utility to generate the DDS for the external printer files from the corresponding RPGLE prgrams having the O-specs.

The testing phase started after the modifications were completed. Issues were found during the testing. The cause of most issues was human / tool error, but we encountered an issue with OPNQRYF, which IBM resolved by providing a PTF.

The project was medium-sized, involving about 800 Physical Files (PF), 900 Logical Files (LF), 800 Display Files (DSPF), 700 Printer Files (PRTF), and more than 2000 programs.

My Responsibilities

Develop tools
Define and refine processes
Manage the team
- Assign work
- Monitor progress
- Resolve technical issues escalated by the Developers
- Report progress to the Project Manager
- Train the team (for project specific skills and general technical skills as well)
Set up test environment
Resolve Unicode related issues found by the Testers
Escalate Unicode related technical issues to IBM