December

Preparing for a Maintenance System Upgrade

EP Editorial Staff | December 2, 2003

Roles, responsibilities, and policies have to be defined to manage the risks of software installation.

A new software installation is one of the most difficult challenges for an organization. There are many considerations in managing the selection-purchase-implementation of a modern system. Buying a new system or developing a program in-house carries several risks that must be realized. Understanding the risks up front is the first step to overcoming them. Here are several key steps to make sure your project goes well.

Custom or off the shelf?
In the past, most companies had an information services (IS) department that had a number of programmers who were able to slowly incorporate managers’ ideas into an existing system to provide better reports. The system was completely customized to meet the needs of the managers and unique to that specific organization.

There are two primary concerns with these highly customized systems. First, the hardware is becoming obsolete and there is a lack of replacement parts. The second issue is that the computer language that the software was written in is often no longer the preferred method. The old languages do not provide the flexibility and strength that newer coding allows. Even if an organization wants to stick with the old system, schools are not teaching the old languages and it is difficult to find people to keep an old system running.

This dilemma leads organizations to a fork in the road. How do they go forward? One way suggests they task the IS department to write a whole new program that does everything they want it to do while keeping the existing system up and running. Often the expense of system maintenance plus new system development is too great. The second path is to scrap the old system and buy a commercial off the shelf (COTS) solution. This path leads to many choices, new risks, and integration issues with other packages. The fact is that there is no system available that will do business exactly like an organization does it now.

Minimizing risk
Either choice is expensive and both have significant risks. Business leaders of large organizations have to decide how to face this situation and minimize the risk. Smaller organizations probably have no IS department and cannot even consider the first path, so they have the risks of only the second path.

The path to a COTS package has obstacles, too, but there are a number of ways to avoid those obstacles. Begin with a detailed needs statement. This statement will help guide other decisions.

If an organization has most of its internal processes detailed in standard operating procedures (SOPs) or detailed work instructions, the first hurdle to a COTS selection has already been eliminated. However, experience shows that only 20-25 percent of businesses have this level of detail prepared in advance.

If there are no SOPs, a plan needs to be developed to document the roles and responsibilities for each person who will be even remotely associated with the software change. Do not shortcut the list. The time going back to revise the list will be exponentially more expensive than doing it right in the first place.

Documenting roles, responsibilities, and policies
For each person’s role, be sure to include everything that may be related to the new software. See the accompanying section “Roles and Responsibilities List” for an example.

The associated policies also must be collected and sorted. Policies are the laws, regulations, and company rules. There may be guidelines or rules that have been institutionalized and have been part of the program for years but have no real value. These should be identified and considered for change in the new system. All of these policies should be listed for each major area of the business being affected. Collecting these three items will empower your organization.

Collect the information and display the information in small workgroups. Let them review the bigger picture that goes on outside their individual roles and responsibilities. Several positive things will occur.

First, coworkers will realize the connections and relationships their work has in ways they have never seen. Second, they will likely identify some paths of workflow that do not make sense. And finally, any errors in recording the roles and responsibilities will be identified and a final edit of the documents can be made.

Even if SOPs are completed, go through this procedure of reviewing the documented processes. More than 90 percent of businesses operate outside their SOPs, usually because the business rules, tools, or software does not help them get the job done efficiently.

Evaluate workflow
Take some time with these workflow discrepancies. Find out why the list is wrong or why the employees feel a workflow does not make sense.

Ask if there are any ideas on how to make a job easier. During a recent project at a public transit authority, the opportunity was taken to identify what they do, identify best practices for those processes, and implement as many of those best practices as possible with the new software installation. In this case, the COTS selection was to replace the maintenance and inventory system, which had to interface with financial and HR/payroll systems. The organization decided to research similar businesses to see how they performed maintenance and inventory management and found 15 best practices that they wanted to install as soon as possible.

The best practice research was an up-front expense to the process, but it offered some surprises. Using the best practices resulted in a multimillion dollar return on their investment. The research also identified frustrated business leaders from the research group itself who were interested in making similar improvements. The return on investment paid for more than half the cost of professional services and the entire cost of the system purchase.

Taking this process seriously can pay off. The risk is to underestimate the importance of knowing, reviewing, and improving the processes. If these steps are not completed in advance of the installation, the software vendors who typically charge for these services will have to do the research to find the same answers.

Starting ahead
One of the primary risks in implementing a COTS package is that the software may dictate certain processes. Consider the following example. The normal process for adjusting maintenance technicians’ payroll issues at one company is to wait until all employees have entered their times in the system and then make adjustments to any exceptions on the last Wednesday of each month before the monthly payroll is sent out.

The COTS system selected allows for adjustments for only three days after each person enters his data. The business processes were never reviewed in advance and, when the vendor came in and demonstrated all the new features, no one thought to ask about the time sheet exception process. Suddenly, the organization is sitting on a huge investment that either cannot be used or is so painful to use, everyone hates it. Does this sound familiar?

Every software vendor has a closet of skeletons. The closet has a list of past sales that were implemented poorly for multiple reasons. When this happens, employees have to work in frustration and likely have dual processes going on to get the job done. It is common to find organizations doing the same process twice—usually electronically and an identical paper trail—to make sure everything is complete. This is a big opportunity for organizations to streamline operations and get the job done right the first time.

Once you have made the full list of roles, responsibilities, and department policies, develop high-level workflows for major tasks. Ask potential COTS vendors for a similar list of how the business will operate with their system. A common response will be that the system’s flexibility will allow you to configure the system in so many ways that they cannot give you that list. Insist on the list even if it has to resemble their best client’s site. With the two lists, differences can be analyzed.

Software selection
When the processes have been identified and the quality assurance is completed, the next step is to select software that fits the work as closely as possible. The term “as closely as possible” is used because there is not a perfect match from an organization’s model (the roles and responsibilities lists coupled with the policies) to any software. Vendors are designing COTS to fit specific niche markets but there will always be some percent of an organization’s model left out of the proposed system.

The “Current vs Proposed Processes” diagram shows an example of current processes and a proposed process by a vendor. In this oversimplified example of how payroll works, two processes are lined up side by side to reveal similarities and discrepancies; the discrepancies are highlighted in green. These highlighted processes are examples of discrepancies that an educated buyer of a COTS system will know about in advance of the final purchase.

The two examples also demonstrate how a discrepancy may not be a bad thing. The first highlight shows how time cards used to be typed in manually and now through the automation of scanning the time cards can be scanned in automatically. This change will likely be considered a preferred cost-saving process. The second highlighted example is the exception report. This exception report within the current process is conducted monthly. Perhaps the supervisors only have time to do it once a month due to some internal business rule. The proposed process shows the report running weekly. The business leaders of the company will have to decide on how to handle the differences. The power is knowing about these differences ahead of the purchase.

The next thing is to meet with the vendor representative and discuss the undesired discrepancies. This may be an area within the software that has great flexibility and modifying the report run times could be an easy fix. On the other hand, this may not be an area of flexibility; the company will need to decide whether to change processes or look for another software that better meets its needs.

Talk to users
A smart step before installing a COTS package is to go to one of the sites where this software has been installed and talk with the people who were involved in the process from beginning to end. Asking questions will provide a good idea of the product’s capabilities. Vendors will typically recommend only the best sites where their product has been implemented so ask the tough questions.

Remember, the issues in a successful installation are only a fraction of the issues in a bad installation. See the section “Site Visit Topics” for issues that should be explored when talking with current users.

There are cases where the buyer made the installation more difficult than necessary. Software capability is not usually the cause of poor installations. Take the advice of the software vendor coupled with the advice from the on-site visit and make a plan to install the COTS system with the very best effort.

If the company is short staffed or short on employees who can think out of the box to get this done the right way, seek out contractors who have real-world experience. The most expensive thing is to shortcut the process and face a failed implementation.

Have a change management plan
Remember that adjusting processes to meet the COTS solution should be well planned. No COTS solution can do everything the way a business currently does. There will have to be changes; with these changes there will be resistance. Having a strong change management plan is crucial.

With few exceptions, the most important assets of a company are its people. These critical assets are usually the most neglected during the installation if appropriate change management steps are not in place from the beginning. Managing attitudes and frustrations will accelerate the installation and overall success.

One of the most important lessons in managing change is getting employees accustomed to the concept that new ideas will be tested and some will fail. Failed attempts will be discarded and new ones will replace those left behind. Every opportunity to make people’s jobs easier should be incorporated. Gaining this buy-in will pay off as new roles and responsibilities are assigned with the installation of the new system.

As long as critical policies and regulations are followed, roles and responsibilities can shift to meet the new technology. Change management should be simple and easy to understand. If the organizational change management plan does not include assistance to ground floor supervisors and leads, review other plans. These lower tiered leaders will face the bulk of the attitude adjustments and will need real tools they can use to make positive changes.

Many organizations are looking to improve their business with new software. Taking these steps of mapping out how business is done and how the new software will help get to the next level is critical to making sure the risk of a failed implementation is dramatically reduced. Knowing and using these steps has saved organizations millions of dollars. Skipping these steps has cost many businesses the same amount while not achieving the desired result. MT


Joe Mikes is a consultant in improving company performance. He can be reached at 8534 Tambor Way, Elk Grove, CA 95758

ROLES AND RESPONSIBILITIES LIST

Plant Maintenance Manager
Role: To assure the optimal performance of the plant equipment, including major systems; air, steam, power, water; and building structure as well as production equipment. Oversee the well-being of all maintenance employees.

Responsibilities:
Safety
Equipment availability
Strategic and tactical planning
Budget/capital expenditures
Policies and procedures
Reporting results to plant manager
Meetings
Training/mentoring/team building
Evaluate employee performance
Work reviews
Employee discipline/grievances
Hiring/interviewing
Authorize purchase orders
Work orders/backlog management
Coordinate with public utilities
Communication (staff, plant, corporate)
Customer service/interpersonal relationships
Assist in equipment emergencies
Construction/maintenance contractors

back to article

CURRENT vs PROPOSED PROCESSES

Current process

 

Proposed process

Hours are written onto time cards

 

Hours are written onto time cards

Time cards are handed in at end of each shift

 

Time cards are handed in at end of each shift

Hours are typed into HR payroll system

 

Hours are electronically read by the new system

Shift summary report is run at the end of each day for supervisors

 

Shift summary report is run at the end of each day for supervisors

Overtime is approved or disallowed each day

 

Overtime is approved or disallowed each day

Last week of each month exception report is run on Wednesday

 

Exception report is run weekly

Last Thursday of each month supervisors review any discrepancies

 

Last Thursday of each month supervisors review any discrepancies

Final time summary is sent to outside payroll company to process checks

 

Final time summary is sent to outside payroll company to process checks

back to article

SITE VISIT TOPICS

• Installation time
• Vendor’s project management
• Customer service after the sale
• Ease of configuring the software
• Vendor’s ability to stay on budget
• Buyer’s ability to stay on budget
• Questions that should have been asked before buying
• Required support from the buyer’s group to keep the system running
• Software shortcomings
• System upgrades since the purchase
• Availability of 24 hour service assistance
• Software warranty
• Capabilities to run reports
• Ongoing user-group assistance
• Special hardware requirements
• Special database requirements
• Ability to work on the system over the Internet
• Business process change surprises
• Other questions specific to a company’s circumstance

back to article


FEATURED VIDEO

Sign up for insights, trends, & developments in
  • Machinery Solutions
  • Maintenance & Reliability Solutions
  • Energy Efficiency
Return to top