How To Prepare For A Systems Application Installation or Upgrade

By Paul Beretz

(This article was reprinted by permission of Business Credit, a publication of NACM, and appears in the January 2000 issue of Business Credit magazine).

The author, Paul Beretz, is Managing Director of Pacific Business Solutions, a company based in Alamo, CA, which identifies and implements strategic planning opportunities and cash flow improvement solutions. He shares his business experience in working through the business processes involved in ERP installations and upgrades with Fortune 100 companies. This article is taken from Paul's presentation during the November 1999 FCIB Global conference in New York.

Have you found yourself in the position of being advised that your company is either installing or upgrading an ERP (Enterprise Resource Planning) application from a company such as SAP, Oracle, PeopleSoft, Baan, or JD Edwards? All of a sudden, you meet IT people from your company that you never saw before; consultants contact you and want to set up appointments; steering committee and action-group meetings are created to add to your already impossible meeting schedule: all the while, you are supposed to be managing your business and keeping staffing levels under control!

What are the various ways to manage the impact of the install or upgrade project in your department? How do you get your staff to maximize the features of the tool that is supposed to solve all your business process problems? How can you anticipate customizing issues that you may have to face? How do you keep your sanity? Most importantly, what are the post-install and upgrade solutions to issues that will maximize your opportunity for success?

Whether an Install or Upgrade, It Will Be a Long Trip

It would be a perfect world if you had the people with the combined qualities of both understanding your business processes and experience in all facets of an ERP cycle. What's clearly evident in any installation or upgrade is that there is never the proper level of resource allocation or a clear identification of business requirements or comprehensive training programs that exist. Just as important, the best people in the department will be called upon to lead and be involved in the project.

Time management of the regular workload becomes critical - not just to achieve the business performance expectations, but to acknowledge the stress and morale problems that the ERP event creates. Experience shows that ERP, whether a first time installation or an upgrade to an existing system, is a time commitment of one year or more.

Additionally, without the confirmed buy-in and support from senior management, the project has little chance of being entirely successful. Throughout the entire project, remember that ERP is not just "new software", it will change the way business is executed!

Who actually owns the ERP project? It should not be the IT (or IS) department. While they are critical to the success, it is the business unit who needs owners or "champions". The magnitude and weight of the daily work activity that must continue while the ERP is underway usually suggests the need for a clear definition by phases of the project. Rather than trying a "Big Bang" approach (where the entire ERP and its applicable modules are scheduled for the same time delivery schedule), the total strategy should be scoped, with time lines, milestones, team structure and identified final deliverables. The Wall Street Journal carried a number of front-page stories during the past year related to the problems associated with trying to implement and execute completion of the entire order through delivery, finance and manufacturing cycle on the same date.

Establish an employee reward system that will be presented on completion of the project. It should be consistent with all departments - cash, stock and similar recognition. The awards should be given selectively to those who have gone "above and beyond" during the project phases.

What about your time commitment? Even if you are the director or manager of the department, plan to allocate 20 to 33 percent of your total time to the project. Do not make the mistake of delegating the leadership, for example, to a manager in finance who agrees to lead the A/R, A/R GL process - you will need to be pro-active as the manager of your specific discipline. Without an early, hands-on approach, you will not be equipped to recognize and understand the areas that break down or that require direction. At the onset of an initial ERP installation, I had worked long and hard with my staff to define what we needed for the proper accounts receivable aging report. However, I later learned that I did not get specific enough with the consultants and IT group. The result for the first six months following the installation was an aging that did not properly reflect cash or credits and brought unwanted attention to our group. In the early stages of the project, the manager needs to understand and document the business needs of the organization, emphasizing its strengths and weaknesses, both functional and informational. By working with the IT organization, project plans with specific design and implementation schedules should be agreed upon.

Building The Team And Planning Effective Communications

How do you select the right people? I have always sought out the busiest. These are the same people who will say "but I already have too many priorities!" You should be able to determine who they are in your own organization. What about those who will be assigned from IT or the major players in the other organizations that will interact with your function? Too often, the VP, director or manager initially gets involved but delegates to those who are not decision makers or to those who don't have the level of dedication to liaise with your own group. The ERP process will transform your business and people's careers. This is inclusive of how orders are taken, how invoices are generated, how collections are accomplished and what people want to do in the company after the project is completed.

Effective organization of the project means the team has to be identified by major stakeholders (e.g., business and IT project leaders, and one leader in each discipline finance, manufacturing, sales) with functional leads within each specific discipline. At this stage, specific resources - people who are technical experts - need to be identified and assigned roles in the project. The IT organization may have the right people in place, but it is more likely that outside contractor consultants will be hired to work with IT and the functional groups. I made it a requirement that my organization had input in the selection criteria of the consultants. I personally participated in interviewing prospective consultants to gauge their fit with my organization. As the team is developed, so are the communication vehicles, frequency of meetings, published minutes and most importantly, conveyed project status to management. As with the rest of our daily business activities, senior management wants no surprises whether they be in cost overruns or unanticipated resource needs. They will want specific dates for project phases, milestones and a clear understanding of the steps that lead to final implementation of the ERP.

Be sure to maintain an attitude of "over-communicating" to senior management so you can eliminate the uncomfortable need to explain unexpected events that will require their approval of more people and additional training dollars. By effectively communicating with your own group, IT and those organizations that impact your process will you have a chance to succeed. A well-planned initial "kick-off" meeting sets the proper tone. Responsibilities and roles are defined, cross functional issues are addressed, the lobbying for availability of a "war room" or separate testing facility begins and various reporting templates and forms for tracking issues are developed.

In addition, director-level team meetings, super-user meetings, and functional and track lead meetings are defined. Questions need answers. When will the cutover occur from the legacy system to the "new" system? What about date for completion on the business impact of the time of month or quarter? Consider rescheduling vacations and advising the staff of required weekend commitments, particularly in the testing phase. Always remember the regular production of current business information will be impacted. What about the effect on your overseas offices? Even if the project is in North America, don't ignore the off-shore locations and bring them in at the end, especially if a world-wide ERP approach is in the cards at some future date.

Customizing Reports

You probably have customized reports in your system, whether you are already on ERP and upgrading or moving into the world of SAP, ORACLE, or PeopleSoft for the first time. How do you convert the reports that you "need" to run the business? Do you replicate everything or trash what you have because you believe that ERP will solve your problems? Most experienced implementers of systems recommend that you establish a list of all your customized reports and categorize them as "critical, need to have and don't know." Evaluate and question your staff on the content. Test the reports you currently utilize and don't assume that customization will be available in the upgrade or install, or that it is cheap. This is a great opportunity to develop reporting improvements by combining and eliminating reports. This also means employing the management concept that avoids accepting responses such as "we've always had this report". This is one of those times you're paid to be a manager - don't leave it to an individual or departmental vote to determine which reports stay or go. Use your judgment based on asking questions about the output and actual need for the report. Democratic principles do not always work in the world of effective management!

Testing, Testing and More Testing

Experts say that testing is probably the key to the outcome of a successful project. At the beginning, it may be difficult to get your IT group and your department together on defining the needs. Often, the tendency is for the business unit to abrogate responsibility and, by default, IT provides facets of the testing criteria. Do you want IT to determine that because a screen looks the same as before that it hasn't changed?

Management support, at all levels is critical for the commitment to testing. The manager also has to be aware of the daily work requirements that will prevent a user from moving to the training room for the scheduled testing. An "Issues Tracking Logo" becomes a critical tool to determine how successful the testing process works. This report, which usually is developed with guidance of the IT group, indicates the status of each issue identified in the testing process, and can be traced by date, action and when it is closed.

Cathy Cakebread, a consultant who founded Agate Systems in San Mateo, CA, has an excellent approach to testing. She was a key developer in the original A/R module with Oracle more than a decade ago. She stresses two levels of testing in any ERP system: "Break It" and "Simulated Close". "Break It" has two aspects, to confirm that the product works as expected and to try out the new features and ways of doing things in an uncontrolled environment. This means running every report, scenario and process until they work. This is where all interfaces should be tried.

All multi-step processes can be tested along with defining what a successful test is. The "Simulated Close" tests everything in a controlled setting replicating period end and validating reports and system interfaces while looking for glitches. The simulated close usually starts after you have identified and resolved all the bugs in the "Break It" test. It's also an opportunity to determine the major basic reports you need to run your business. It is usually recommended to keep three to five in number. These reports will contain balance and transaction data so that the accuracy of the detail can be measured. Copy all the details and run the reports against the upgraded data. Compare results - they should be identical!

Report the Bugs

"Bugs" are those programming glitches that create user problems within the application. Often the manufacturer will catch the bug and issue a patch until a "new, improved" version is worked on. However, the user will recognize the bug and note the transactions and interfaces causing problems. Usually an astute IT organization will have a form available to log the problem. I've always been an advocate of assigning specific "exterminators" who are responsible to both log and track bugs in each business group. Once trained, the "exterminator" can log what, where and the situation or event that occurred when the bug was discovered. This process includes use of screen shots and examples of the problem. The IT organization should get a list of patches available from the ERP provider and check the known bugs and related patches, using the patches in a test environment only. As the business user, don't ignore the bugs. They can create major production problems unless detected and reported early in the testing process.

Training

Start training early in the ERP process and understand that training needs to continue beyond the life of the ERP project. An effective ERP training program means dollar commitments as well as time and facility availability. All users, regardless of job level, need to schedule training time. Ideally, a "war room" has been previously designated with posted schedules. The time slots include access to specialists and consultants who know the program. Training in the branch offices can take on interesting dimensions.

Once, during an ERP installation in a company's Asia Pacific office, it was discovered early in the process that despite the availability of personal computers on each desk, 50 percent of the staff did not have a basic understanding of the system - including how to turn the unit on. Needless to say, this put a severe crimp in the training plan! Consider creating your own training manual. This should encompass a write-up of the "big picture" so current and new users understand the scope of the project in addition to specifics about what screens are used in the department. Description of the modules that are to be implemented, with a list of in-house personnel support and consultants, should be shown.

An effective training program is future-oriented as well. It anticipates additional upgrades and enhancements that will undoubtedly take place. This means that the manager has to commit resources to ensure his or her staff makes adequate time for training throughout the year, even after an installation or upgrade is completed.

Are You Ready to Sign-off on The Project?

If you've ever wanted to feel like an NFL quarterback at a pressure-point in a football game, your opportunity will arrive along with the sign-off date. You are requested to acknowledge that everything works to your satisfaction in the ERP process.

Who do you trust? Have you completed enough testing and was it thorough? Has everyone been trained to your satisfaction? Have the other groups who impact your operation done their job so that the information and transaction flow will give you the data expected to run a better business? A final functional review of the components in your area is always appropriate prior to signing off. Make sure people are scheduled to begin the install or upgrade. Do not change variables. Use the same parameters that were used in the testing process. Compare results and don't forget to run back-up reports.

Most importantly, celebrate! Plan an all-hands dinner, distribute t-shirts and meet with the other directors to determine how much, in the way of financial rewards, should be distributed. Publicize on the company Intranet. Get senior management involved and let them cook at a barbecue for the employees.

Life After the Installation or Upgrade of an ERP System

An enterprise re-source plan is just that, a plan. It is not so much a project, because it is never really finished. It's a true journey, with constant change inclusive of upgrades, testing and people.

People will often want new assignments - returning to the "old" world of entering orders or calling customers for money may not be enough. Headhunters thrive in the post-world of ERP. Managers must prepare for the fact that they will likely lose people unless they keep them challenged. Many companies establish permanent ERP teams who assist in the process when acquisitions or overseas locations are at the stage of an install or upgrade. A national consulting firm recently said that companies should be ready for a drop in performance after an ERP project goes live. Their survey indicated one in four companies, 25 percent, could document a decline in individual and company performance. Why? Because everything is different now. What can be done to deal with the change in performance and to ensure that the company remains up to date in maximizing attributes of the system? Most of the ERP user companies belong to "User Groups". Unfortunately, they tend to be driven by and directed toward technical folks. While the meetings deal with specific topics such as accounts receivable, the actual users who face the screen everyday, are poised to enter orders, collect money, schedule manufacturing and shipping. They have little or no exposure to these organizations.

In Northern California, I've had success in spearheading the formation of a Special Interest Group (SIG), specific to Oracle_the Bay Area Oracle Receivable User Group. By coordinating administration with the local Credit Managers Association, quarterly meetings are held, with the agenda determined by a volunteer steering committee composed of other local Oracle users. A key to success of the group is to locate a consultant willing to participate and who is knowledgeable of the modules.

Additionally, the vendor in this case also happens to be located in Northern California, which has resulted in participation by the ERP supplier. We have invited their developers and experts in the order through collect modules to participate in the meetings. There's nothing like networking and sharing ideas with a group of companies who work with the same ERP tool. We've held six meetings since 1998, with as many as 98 people from 40 companies in attendance. Participants include credit and receivable managers, order administrators, general ledger and IT experts. When someone says "I can't write notes on my screen for collection follow-up" and a user from a different company explains in 30 seconds how that activity works, the value of the organization is more than validated.

Topics have included how to use the various screens, reporting, forecasting, bolt-on reporting tools, e-commerce, cash application, credit tools, invoicing and billing. In general, the goal is to share "best practices" of the members to others who have the same ERP.

In summary, be committed to the ERP project or you may feel at some point as if you will need to "be committed". Apply all those manager attributes to the project. Plan, lead, organize and control. Train, test and do more training and testing. Consider getting involved in a special interest user group. You are not alone!