To make our core decision, we needed to be clear about our base product definition. Thus, the business process kaizen team (BPK) that had been using business process reengineering to improve all our business processes since January of 1994, identified the technology and business preferences criteria to define the type of ERP product that was best suited for Lantech. The technology criteria were absolute:

The business preferences criteria were somewhat less stringent:

Looking back, we realize we didn’t fully understand some of the deeper technology decisions that we made and our choices may appear simplistic or obvious to some readers today. Regardless, before the new ERP team began its detailed process of selecting a system, it had established clear standards that enabled them to narrow their scope and eliminate months of research and discussion on every possible system.

Early in the process, the ERP search team, visiting prospective companies Jeanne had selected, realized that time spent talking with sales people was usually time wasted. Almost invariably, the team asked the sales people technical and business process questions that they couldn’t answer satisfactorily. We soon learned that the logical solution to this problem was to speak to the technician(s) behind the product. Once we had the right people to talk to, team members would visit them in their offices and invite them (along with the sales people) to Lantech.

Team members spent hours (sometimes days) crosschecking and testing product functionality and the underlying technology, and this was a source of great interest for some of the sales people and technicians who visited Lantech. Their interest sometimes took an amusing turn. The ERP search team used a large workroom for the project, and the walls of the room were lined with notes about the strengths and weakness of all the ERPs we had reviewed. Curious as to how they might measure up, or what we were up to, the visitors covertly scanned the walls, anxious to get a closer look but generally too polite to ask for permission to do so. Their longing gazes eventually caused occasional gaps in conversation, and we responded to this by giving them an opportunity to browse, ask questions, and learn what they could. This was not simply a matter of courtesy; during the process, the techies and salespeople came to understand our needs as well as our philosophy of openness in communication and information sharing, which was essential for our ERP program.

The Role of End User Participation

One waste that many companies may not even be aware of is number eight in the Table 1-1: underused employee abilities or creativity. By empowering our employees (those who actually do the work) to participate in the selection process we unleashed their ideas, skills, and creativity. From the beginning of the selection process, the ERP search team focused on having the actual system users define and ultimately find the right tool.

Three of the core team members had operations backgrounds. None of us had any significant project management experience for selecting and measuring the various ERP systems, so we invented our own. Our first priority was to create a checklist of the primary business transactions our company needed to perform as well as a list of things the ERP system had to do. The list came to about three pages and became the basis of our search criteria. Figure 4-1 shows some of the essential points. There are now numerous toolsets and consultants available on the Internet that provide a more exhaustive checklist than our three-pager. The fact that our three-page document did not miss any core functions is evidence that most companies have employees that know their business well enough to draft their own checklist.

The team also established a few basic questions about each ERP system’s underlying technology and its compatibility with other common toolsets that were important to Lantech. As vendors demonstrated the specialty of their respective tools, we used simple metrics to evaluate them:

•  How does this tool perform our business processes?

•  Can we see the tool work?

•  Does this meet the needs of what the end user needs to do?

After the team reviewed, researched and visited the home offices of about ten product vendors, we pared our list of candidates to a final three. Still focusing on user involvement, we invited each of the three finalists to Lantech to spend two days giving six two-hour reviews to the people who would be using the tool every day. We provided each vendor with a fixed script of points to cover and allowed time for general questions and answers. Between fifteen and twenty people attended each session. With six sessions, that meant around 100 people; thus, almost half of the company had a chance to evaluate each product. We collected feedback from the users via a questionnaire that included a general comment section. There were five important reasons for having the users deeply involved from beginning to end. The users:

1.  validated the impressions of the search team regarding the strengths and weaknesses of each product;

2.  highlighted issues that we would need to address with each product;

3.  had some idea about the alternatives whenever they had frustrations with the final choice;

4.  developed a consensus of the best tool;

5.  knew they were a part of the selection process and had a vested interest in making the final choice work.

The team’s attention to user involvement was one of the prime factors that helped us to identify and successfully implement an ERP. However, it is equally important to mention some of the things we did not focus on:

•  Executive reporting. We did not look for a tool that was user friendly to managers, because they would not be using it. Instead, we looked for a tool that would perform our business process. If the tool could not run the business, then the reports would not matter. Although we did not entirely ignore executive reports, we knew that the ERP would be capturing management data and we could pull it out as needed.

•  Background technology. We had a professional IT consultant, Roger Koebel of Kaizen Technologies, who traveled with us on occasion to advise us along the way. Roger was an excellent teacher and an invaluable resource, but in the few months he worked with us, he was not able to convince us that an industry standard database and programming language were critical to our selection.

When you begin implementing your ERP, you have a choice: Are you going to manage your ERP, or is your ERP going to manage you? That probably isn’t a fair or polite way to ask the question, but it is a question that you must consider when you weigh your implementation options. Specifically, you will have to decide whether to install the vanilla version of the tool and fit your business processes to the tool or customize the ERP to make the tool fit your business process. The answer depends on how much you want to customize. You can go from 0 percent to 110 percent and anywhere in between. The good news is that there is no wrong answer as long as you understand what your choice means and are dedicated to supporting that choice.

If you are an IT manager, you might decide to go with the vanilla approach of 0 percent customization. Your system upgrades will be much easier, the vendor documentation will remain accurate, and you can give it directly to the user community. Implementation itself will be quick and easy. Moreover, the IT staff or management won’t have to field questions such as, “Can we change this?” or “Why can’t we do that?” Everyone will understand that what the tool offers is what is available. This approach can work because core business dynamics and transactions are more similar than not, even across different industries. Obviously, some ERP tools will be better suited than others for your business, but ERP developers design their tool to accommodate a broad range of customers. So going the vanilla route is a viable approach.

At Lantech, we chose to manage our ERP wherever we found significant value, which means we decided to customize even prior to our final selection. When you consider customizing your ERP, you have to deal with the same issues that make the vanilla approach cost effective. One thing that you must take into consideration is that customizing will affect the time and effort it takes to implement your ERP and, as a rule, will delay the “go live” date. That means you need to factor in additional resources and time when preparing for the implementation and lost efficiency the ERP would have given you during the delayed time frame. In addition, the customizing has to be done by someone and that someone has to be paid.

The Lantech team prioritized the changes we felt were needed to WinMan and then found a way to control the customization costs. We also scheduled an aggressive but realistic go live date. Any customizations that weren’t completed by the go live date was done later or not done at all. This underscores a point already made above: Most ERPs will support most of your business processes; you just have to decide how important each change is and how much time and money you are willing to pay for the changes you want. You may find that some changes (i.e., some customization) are not worth the bother.

One important cost consideration is how effectively the vendor will support your customizations and future upgrades. The answer to this question could change your ERP selection and will certainly influence how you think about customizing. When Duane provided some ERP consulting for a Lantech partner that was implementing a different ERP system, the ERP vendor was willing to support some customizations in upgrades, but some would have to be re-created after each upgrade. That meant the company would have to limit its customizations, never upgrade, or accept significant pain and disruption as a part of each upgrade. None of these options is very attractive.

Lantech had a bit of luck with this issue of customization. During implementation, which is actually too late in the process, we asked TTW how it would support our changes. The company said it could and would work with us—and delivered! As we got more involved in TTW support and began to understand its customization structure, we found it quite flexible and workable. There have been glitches, which always take time to fix, but overall, the partnership between Lantech and TTW has worked very well.

In a perfect world, you would expect to install your perfect system and your employees would go about performing their processes happily ever after. But we all know that this level of perfection is elusive and not easily achieved. Your customers, employees, business needs, and business processes change. When this happens, your ERP system might also have to change, and you will need to review your attitude about customizing. All the cost issues and constraints that were a part of both the vanilla and customized implementation still apply, but there is a new factor to consider. You have to decide how much you want to change or whether you want to change at all. This is a valid option. It would mean less training, fixed documentation, and no development costs, and if you made a reasonable choice to begin with, your ERP will support your business without changes or improvements. On the other hand, you can never forget that continuous improvement requires constant adaptation to changing circumstances and you will need to work hand-in-hand with the lean environment to remove wastes from your processes and systems. Running an information system that is not sufficiently adaptable will prevent you from removing waste and, over time, will create additional waste.

Lantech is committed to making its ERP tools support the changes we know will occur in our business. Even after implementation, we continue to customize our ERP and we customize it a lot. For most of the past eleven years, we have kept one or two programmers on staff to review and make changes to our ERP, and we are content that our model adds value and decreases cost. In connection with this, we apply the same basic continuous improvement approach to IS that we apply to manufacturing. For example, in our most advanced lean production lines, we look to remove seconds from the manufacturing process. In our most lean IT processes, we look for keystrokes to eliminate. In our still developing production lines, we look for minutes or hours to remove from the process. In some areas, we apply IS applications with the goal of eliminating or automating entire sequences of a process.

It is important to remember that lean is not just about eliminating wastes; it is sometimes about adding useful things. For instance, we sometimes add steps to the manufacturing process to assure quality in downstream processes and to satisfy the end customer. Likewise, we occasionally add steps to the IS processes, collecting additional data in order to assure quality and service. Additional up-front data collection ensures that all information you add to the information system is correct the first time, which significantly reduces customer disappointment, rework, and cross-checking within the business process later down-stream.

Common wisdom may suggest that you are limited as to the number of improvements you can make in any given area, but when continuous improvement is a constant across the organization, you continually find ways to improve last month’s improvements. For example, a change in sales can spark an idea in purchasing that will suggest an improvement in engineering. The change in engineering will domino to an improvement in how to create equipment manuals, and the improved manuals will drive a change in the sales process, where the improvement cycle originated.

At Lantech, we change and improve our ERP every day. In the process, we gain new toolsets (or learn new tricks), especially relating to integration of WinMan to other applications like Word, Excel, and AutoCAD. Furthermore, because we add IT resources and willingly make changes, our user community now knows that no request is too outlandish to suggest. Some ideas are obviously too outlandish to consider seriously, but to generate good ideas among your employees you have to encourage all ideas. Brainstorming in kaizen events is in excellent way to do this. So is having a “nothing is off limits” policy. Both result in a plentiful flow of good ideas and lay the groundwork for following IS guiding principle #4, Nothing lasts forever. As mentioned above, your business or customer will always change. It follows that your software or hardware will also change. In lieu of a perfect IT world, adaptability is your best competitive advantage.

A company could choose to route all its requests for customization and improvements to its ERP provider rather than incur the expense of maintaining a permanent programming staff. However, it may be shortsighted to consider only the cost of “resource overhead.” For example, for most major ERP applications, the provider requires that you submit your changes and suggestions through its bureaucratic evaluation process. These suggestions can fall between the cracks, or worse, the provider will tell you up front that the cost of customization is more than you can afford. This is why a company needs to consider the total array of costs for system development, customization, and maintenance when selecting its ERP system. Alongside the normal questions about version upgrade frequency should be questions about who, when, and how much the provider will support the customizations. TTW and WinMan may be an exception to the rule in that they have always been very responsive to our requests for improving and implementing our ideas into the standard programs. Even though their costs are reasonable, the turnaround time for minor changes can take a day or two. By having its own programmers on staff, Lantech can move quickly to incorporate and easily test any kind of change, making the cost of maintaining a permanent IS staff much less of an overhead cost issue.

If you do choose to use programmers to maintain, upgrade, and customize your ERP, then you need to consider carefully whom you hire and train. We hired three different programmers over a two-year period, and though they were competent enough as programmers, they required lengthy and detailed instructions before mastering what to program and understanding how it was important to the business. The time and cost of training these programmers in Lantech business processes and database management was considerable. We tried a different approach—train our own business people. It soon became apparent that teaching business people to program rather than teaching technical people about the lean business was easier, faster, and wiser—a key breakthrough. As of this writing, about a third of the people we have on IS support do not have systems background per se, but they do have an interest in information systems, want to program, and know our business. Our suggestion is to develop your resources internally, training current employees with four to five years’ experience. Training your workforce is both a common sense investment and a learning organizational approach. You are mentoring your employees to share, grow, and adapt. In turn, they are continually learning new skills. New knowledge and capabilities, as well as standardizing the work processes, assures quality work and continuous improvement.

Lantech’s programmer-mentoring journey began with Duane Jones, whose background was in manufacturing with experience in purchasing, engineering, and sales. The ERP we chose had a different database and programming language from that used in the old network, but Duane was determined to learn it and use it. He was the first nontechnical person to learn to program from our first programmer, Steve Akers, with help from TTW associates Nick Jacobs, Scott Wilkinson, and Joe Wilkinson. Duane soon found that he loved the program and the programming, and interaction with the vendor grew from there. Duane understood Lantech’s business requirements and was able to take verbal requests and turn them into system improvements without extensive interviewing, documenting, and flowcharting. Later, Duane trained three other associates in programming and database management, and within two months, each was able to maintain and manage small to medium complex system changes. Within six to nine months, they could develop and maintain complex applications.

The authors suspect that professionally trained IT professionals would disagree, but from our experience, it is easier for a person with a business background to learn programming than it is for a programmer to learn business. For a lean business, the IT professional has an added hurdle: not understanding lean. Once we established clear technological and business preferences criteria to define the type of ERP product for our company, our lean philosophy directed us to invite our end or system users review to select it. From there it was a matter of working with our provider to help support our lean environment through customization, training, and continuous improvement. It can be that simple.

The next chapter discusses how Lantech uses the kanban process to manage inventory and how it aligned and integrated ERP to support the lean shop. To continue with the preparation for and implementation of ERP, the reader can jump to Chapter 7, Mission to Go Live—Building Teams and Overcoming Barriers, where we pick up with the formation of the BPK team and its transformation into the ERP search team, and finally, the implementation/Wizard team.