The process of selecting and implementing software and subsequent evaluation of the systems can be thought of in terms of programs, processes and practices. Understanding each, their relationships and how they change through time gives us insight into the health of our systems.
Programs refer to the software with its functions and inherent limitations. The programs can also be called the system or the solution. The programs may be customer designed and coded or can be acquired by a software vendor. If from a software vendor, the programs include and customer designed modifications or extensions. The business Processes include procedures for using the programs plus the various manual procedures that are required to meet the total needs of the business. Practices refer to the actual way things are done in the business.
If programs or software are to be purchased, the requirements of the business must be determined and various options compared to the functions provided from vendors. If custom solutions are to be built, a comprehensive design is required. A common problem in designing custom solutions or evaluating packaged software is communications. The business people are not skilled in specifying their needs and the software designers or vendors can only respond to what the business people tell them is required. Frequently, this results in gaps between what the business needs and what the programs provide. Many companies use outside consultants who are skilled in both business processes and software to bridge this gap. The role of these consultants is to guide the process, identify key needs of the business and, more importantly, translate between the business and the designers or vendors and vice versa.
The identification and evaluation of key needs is often a source of problems. No company has ever fully evaluated the entire product that they are buying, time does not permit such a complete evaluation. Reality says that people spend more time looking at functions they feel comfortable with, not the ones that are difficult.
Of the thousands of details that could be evaluated in depth, relatively few are critical to the overall success of the system. These few are "fatal flaws" which can stop the business from succeeding, if 98% of the system is adequate but the 2% that constitute the fatal flaws fail, the entire system fails. These fatal flaws must be identified and thoroughly examined before selecting a package or finalizing a design. One of the great values brought to the process by a consultant should be identification of these fatal flaws. The consultant should also be able to ensure that these functions are fully evaluated.
The business processes include how to use the programs plus the various functions that are required to meet the total needs of the business. For example, after an order that has been received by mail or fax is entered into the system, how should it be filed? When a pick list specifies that an item should be pulled from a specific warehouse location, what is the procedure if it is picked from an alternative location for some reason?
Once the best fit is found, it is common to realize that the selected software cannot meet all the requirements of the business. This calls for a decision to either change the requirement so the package can accommodate the business, modify the software (see Should You Modify an Application Product) to match the business need or to design the business processes to work-around or account for the difference. If significant functional gaps exist between the system and the needs of the business, has the right product been selected? Does the right product exist? If these gaps fall within the list of fatal flaws, the system will never be successful.
Practice reflects how the programs and processes are actually being used. If differences exist between process and practice, problems exist which leads to the company not obtaining the value that is available. Why would a gap between process and practice exist?
What clues exist to tell us that gaps exist between process and practice? Any errors that exist, for example inventory variances or location inventory balances not reflecting the reality at the location, point to a possible gap. If the users begin to keep additional files (paper or on a PC), gaps may exist. If transactions are missing, never entered into the system, gaps may exist. If information does not flow in a timely fashion, the practice may be to work-around the system and then "catch up" later pointing to a possible gap.
If the gaps exist at the point of implementation, something was wrong with the implementation. If the processes do not reflect the needs of the business, people will work outside the process to get the job done -- creating a gap. If the people have not been properly trained, they will not execute the processes as designed -- creating a gap. A gap can also be caused by a lack of motivation and/or management. If people are not motivated to use the new system as designed, they will not -- creating a gap. If people are not managed, gaps will not be recognized and corrected.
If gaps between process and practice show up after initial implementation, what could be the cause? The major cause of these gaps is change. The needs of the business changes, the processes and/or programs are not changed accordingly, so the practice changes to meet the new need. For example, a new type of order is now received. The new order type cannot be serviced by the existing processes or programs so people figure out how to get the job done another way. They did what was called for by the business, the gap was actually created by the processes and programs not changing with the needs of the business.
A lack of motivation or management can also create gaps later in the life of a system. People will always find ways to cut corners, to make their job easier this is human nature. Motivation can slow the creation of these gaps and management can identify them and correct the situation.
What are the impacts of gaps between programs and processor process and practice (see Application Erosion: More Causes and Cures
). These gaps attack efficiency; it typically takes longer to work around the system than using the system (if the faxed order is not filed correctly, it takes time to find it). These gaps attack data accuracy (if an item is pulled from a different inventory location and not reported as such, two inventory errors exist, one at each of the two locations). Any initial gaps point to a problem with implementation. Any subsequent gaps point to a problem in recognizing and reacting to change or to management issues. In both cases, these gaps cause the company not to realize the value that is available to them.
About the Author
Olin Thompson is a principal of Process ERP Partners. He has over 25 years experience as an executive in the software industry with the last 17 in process industry related ERP, SCP, and e-business related segments. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry.
He can be reached at Olin@ProcessERP.com.