According to the previously cited guide from ERP Focus, choosing an implementation consultant is the second step of ERP implementation, right after selecting a vendor. In the consulting business, being a certification as an implementer from a leading ERP vendor is known as a license to print money. Even vendors of ERP products acknowledge that their customers spend more to implement the software than to buy it, and that much of this cost goes into consulting fees. The following are a few thoughts about the process of ERP implementation and the roles played by consultants, contractors, and the in-house IT team.
Although I have not seen it described elsewhere in these exact terms, the implementation of an enterprise software system comprises all the activities needed to go from the decision to buy the system to its use in daily operations by all intended users, whose numbers may reach into the thousands. It is a daunting process. In a large company with multiple sites and thousands of product configurations, it may take years and cost billions of dollars. On a single site with 1,500 employees, it can occupy 40 full time for two years, and tie up managers and engineers for 30 hours of training each.
And implementation mistakes can hurt the business, particularly during system startup. It’s not uncommon for customer service to invoke the use of a new system as an excuse for delayed or wrong deliveries. The same company mentioned in the previous post about ERP, that postponed ERP implementation, had a customer consuming a family of products at a fixed rate, set for 18 months, and should therefore have been able to produce and deliver at a matching, fixed rate. The customer’s new ERP system, however, issued orders for varying quantities at seemingly random times, introducing artificial variability in the supplier’s planning and production process. Asked about the reason for this erratic ordering pattern, the customer’s buyers said “We don’t know. It’s just the way it comes out of the system.”
ERP implementation entails the following:
Installing the software on your equipment for an on-premise system, or provisioning a server in some fashion if it is on the cloud.
Configuring the system. This includes:
Creating user accounts with appropriate privileges.
Setting switches on modules to activate and operational parameters.
Entering or transferring the metadata from legacy systems — that is, in a manufacturing context, the product definitions, bills of materials, routings, resource definitions, supplier and customer definitions, etc.
Transferring operational and historical data from legacy systems.
Developing custom interfaces to legacy systems you intend to retain, and add-on modules, all of which must be tested and plugged into the new system.
Testing the new system, usually, the new system is tested by running it in parallel with the legacy systems to correct any functional errors and validate its performance when subjected to the expected volume of transactions in actual use.
Deploying and networking all the peripheral hardware, including user work stations, screens, barcode, QR-code and RFID tag readers, etc.,
Training the users on the new system.
Cutting over to the new system.
Retiring and disposing of the legacy systems.
While these tasks have precedence constraints, they cannot be carried out in just one sequence through multiple facilities. You obviously have to install a system before you can configure it, and you must train users before cutting over, but not long before, lest they forget everything they learned… As much as possible, you try to do these tasks in parallel, fully implementing some functions at some location and collecting feedback prior to expanding. It requires skills in project planning and management as well as technical skills.
The Role Of Implementation Consultants
The key statement in the ERP Focus guide is “if you are looking for consultants as teachers, you may choose a different vendor than if you are looking for consultants as technicians.” In fact, there are two types of professionals who call themselves “consultants,” those who provide advice, guidance, coaching, and training for you to do the work, versus those who do the work for you.
The former charge higher fees but for fewer days, and transfer know-how to your in-house team; the latter become a temporary extension of your work force, reside on site full-time as a team possibly for months, and get a job done, but their expertise walks out the door with them. Strictly speaking, those who become a temporary extension of the client’s technical staff are more accurately described as contractors rather than consultant.
If you are a manufacturer of diapers, frozen lasagna, or jet engines, how much IT expertise should you have in house? “IT” covers a continuum from generic computer, network and peripherals hardware to the company-specific information model. It also covers a stack of applications with the lowest layer being machine controllers and the highest ERP.
The more generic the subject, the more attractive outside help is. If the company’s business is not IT, there is a strong case for not bearing the full-time cost of resources that are not, or should not be needed full time. In addition, it is a challenge to recruit and retain top talent in non-core specialties. If you are a systems engineer with up-to-date skills in networking hardware and software, you have better career prospects in a networking company than in a manufacturing company. Of course, the option to outsource work on your IT infrastructure is only available if there is a local base of contractors to tap into. Such a base is available in any manufacturing center in the US, Western Europe, or Japan, but, if your run a mine in the Peruvian Andes or in the desert of Burkina Faso, you are on your own.
On the other hand, the more company-specific the topic is, the more it makes sense to do the work in house. Setting up and maintaining the business logic of working with customers and suppliers, or the technical data about products and processes requires knowledge that outsiders don’t have, and often shouldn’t have. It is therefore an area where contractors shouldn’t be doing the work, but where consultants can guide and coach in-house employees on the way to do it.
In the continuum of implementation activities, there are extremes where the choice is clear, and gray areas in-between. There is no universal rule on where to draw the lines between what contractors do, what consultants help with, and what employees do. It depends both on the skills available within the workforce and on the facility’s environment. A key question what the consequences would be if information were to leak to competitors. If wouldn’t help them much to know which brand of WIFI routers you use. ERP suppliers are usually allowed to publicize their customer lists, which means that the brand of ERP software a company uses is not a secret either. On the other hand, a copy of the cutting program used for a particular product in a machining center would go a long way towards helping a competitor replicate the process, and should therefore be guarded like the crown jewels. In particular, it should be developed by employees, not contractors, and CNC or PLC programming is a skill your engineers should have.
Issues With Customization
Using contractors or employees to customize generic systems to the company’s specific needs is done not just for ERP software but other classes of assets, including production machinery. Devices developed internally by ingenious operators, technicians and engineers work enhance the capabilities of purchased machines, increase their capacity, or perform unique processes. A forging plant in Japan used its own automation retrofits to second-hand presses to perform a sequence of operations simultaneously and make multiple different items from the same billet. A frozen-food plant in Italy used its own machine to pack blanched spinach leave into a carton and tamp them without breaking them. An avionics plant in the US used its own heat-staking machines to make low-volume parts one by one when the smallest commercial machines processed 50 at a time…
These clever devices are often a competitive advantage and, at first sight, customizing ERP seems to offer the same opportunities. There are, however, differences that make it less attractive. Machine-tool suppliers don’t replace installed machines with a new version every year, but software suppliers do. In fact “software maintenance” refers to the process of releasing and implementing new versions, and has neither technically nor conceptually has anything to do with what manufacturers know as equipment or facilities maintenance.
Not software maintenance
Software maintenance is not about replacing oil filters, but it nonetheless generates a continuing flow of work for in-house IT resources and contractors. Sometimes the custom add-ons work with the new version of a purchased system; sometimes they don’t and must be fixed. And sometimes, the new version provides, as part of the standard package, the function the add-on was developed for and makes it redundant.
Custom add-ons are proprietary software, used only in one company, which, as a consequence, bears all its maintenance costs. If it is developed by contractors, only these contractors are usually able to maintain it, and it is only maintainable as long as they are around. Historically, manufacturers have engaged into software customization without realizing what they were getting into. 10 years into a local scheduling project, users still only had the “Version 0” functions available, while the massive Version 1 specs were in dusty binders on shelves. 25 years into another project, for configuration management, the company used software written in a once fashionable but now dead programming language, by a contractor who had since retired and moved away. The users did not understand how it worked, but had to live with its output.
That there are horror stories does not mean that custom development of software for the needs of a manufacturing plant is always wrong, only that managers should not underestimate the commitment it requires, and should do what it takes to avoid entering into relationships with individual contractors that last longer than most marriages. I visited a printed-circuit fabrication plant in Silicon Valley two weeks ago, and was surprised that they proudly used an ERP system that they had developed themselves. I don’t know why they had made that choice, but it did not look antiquated, and they seemed happy with it.
Developing In-House Talent
IT groups have existed in large companies since they started acquiring mainframe computers 60 years ago, as depicted in Desk Set. Specialists were hired to set up, operate and maintain these machines. Their descendants today are often overworked and demoralized, and are not perceived as effective by the rest of the company. I don’t believe it has to be that way, or that relying entirely on contractors and consultants to implement new systems is the solution.
Issues with IT Teams and ERP
IT and manufacturing teams rarely understand much about each other’s fields. The ERP applications I have seen are generally able to perform non-manufacturing tasks like taking orders or issuing shipping notices, but not to issue actionable instructions to a production shop floor. Production requirements communicated by the ERP system to the shop usually cannot be executed in the prescribed sequence, if at all, and must be locally edited and rearranged.
Sometimes it is just because the materials needed are not available, when the system thought they were. At other times, however, it is because the ERP model of manufacturing is simply too crude. For example, the ERP system may allow you to specify that an operation has a setup time and a runtime per piece or load, but not that the setup time depends on the product you are changing from as well as the one you are changing to. In reality, changeovers within a product family may be an order of magnitude shorter than between families, and raising the temperature of a furnace does not take the same amount of time as bringing it down. By not representing such structures in their data models, ERP system suppliers in effect dismiss them as irrelevant details, and cause their implementers to treat them that way. To the manufacturing team, however, the ERP implementers are living in a fantasy world, according to rules that are not those of the shop floor.
IT Staff Versus Users
ERP Command Line Interface, 1990s
Plant and corporate IT staffs, having invested time and effort in mastering the current systems, are usually less than enthusiastic about new technology that makes their hard-earned skills obsolete, which puts them at odds with the more dynamic members of the operations group, who like to tinker with software as much as the manufacturing engineers with production equipment. It took decades for Graphics User Interfaces (GUI) to replace command lines in ERP systems, when they were already commonplace in home and office machines. The picture on the left was taken in 1993, 25 years after the GUI was invented at Stanford, 20 years after the release of the Xerox Alto, and 9 years after the launch of the Apple Macintosh.
For years, corporate IT staffs dismissed GUIs as “toys,” and insisted that “real work” could only be done through 4-character commands in green, uppercase character on an 80-column black screen. The old tools were more difficult to learn and use, but this is exactly why those who had taken the trouble to learn them were reluctant to let go. Today, the debate is between cloud-based versus on-premise systems, and the defense of the older approach is based on the dubious assumption that on-premise systems are more secure and reliable.
Alan Turing
In a 1947 speech, before the first commercial computer was built, Alan Turing predicted this behavior from the people who would be in charge of IT. “They may be unwilling to let their jobs be stolen from them in this way,” he said. “In that case, they would surround the whole of their work with mystery and make excuses, couched in well-chosen gibberish, whenever any dangerous suggestions were made.”
The software tinkerers, on the other hand, are often enamored of the intricate spreadsheet models they develop, but the ease with which they get initial results blinds them to the distance between a quick-and-dirty solution and a tool that can be made part of the organization’s information systems. Making software work at all for themselves is at most 10% of the work professional software developers put in to make it maintainable by others, reliable, easy to learn and use, and mistake-proof. The tinkerers usually process extracts from the ERP and other systems, and, when several meet to discuss their results, they often find differences due to their unknowingly using different extracts. This is in addition to the differences introduced by changes made by individuals in multiple copies of the same spreadsheets.
Strategies To Bridge The Gap
In most companies, management has given less thought to the long-term role of the IT group than Alan Turing had. Here are a few recommendations on making them more effective:
Clarify the mission of the IT group. Its purpose is to make sure that all employees and teams that need IT have tools that actually work for them meaning that the tools help them run routine operations, solve problems, and make decisions, without creating more record keeping work. It is not there to meet only the needs of top management or to impose a standard set of tools on everybody. Integration between the systems used in different groups is a plus, but only if it is not achieved at the expense of function. Systems for production planning and scheduling, warehouse management, quality assurance, equipment maintenance, etc., that work are effective; systems that play well together are efficient. And efficiency should never be pursued at the expense of effectiveness.
Outsource infrastructure tasks. As discussed above, to the extent possible, all IT related activities that do not require specific knowledge of the company’s business, management, or technology, are best outsourced to contractors.
Provide resources for IT to stay current and experiment with new technology. Just as it is necessary for manufacturing engineers with machines, the IT staff needs time set aside for technology watch and a “sandbox” to experiment with the latest. Current topics of interest might be, for example, the Internet of Things (IoT) and mobile apps. They need to learn what is available and experiment on ways to make it useful.
Rotate individuals into and out of the IT group as part of a management career. You cannot bridge the cultural gap between IT and operations unless at least some of the members on both sides have been in each other’s shoes. The IT team should not be comprised exclusively of computer scientists who have never worked in operations, and vice versa.
Feb 14 2016
Is Choosing a Consultant Truly The Second Step in ERP Implementation?
Contents
The Implementation Process
Although I have not seen it described elsewhere in these exact terms, the implementation of an enterprise software system comprises all the activities needed to go from the decision to buy the system to its use in daily operations by all intended users, whose numbers may reach into the thousands. It is a daunting process. In a large company with multiple sites and thousands of product configurations, it may take years and cost billions of dollars. On a single site with 1,500 employees, it can occupy 40 full time for two years, and tie up managers and engineers for 30 hours of training each.
And implementation mistakes can hurt the business, particularly during system startup. It’s not uncommon for customer service to invoke the use of a new system as an excuse for delayed or wrong deliveries. The same company mentioned in the previous post about ERP, that postponed ERP implementation, had a customer consuming a family of products at a fixed rate, set for 18 months, and should therefore have been able to produce and deliver at a matching, fixed rate. The customer’s new ERP system, however, issued orders for varying quantities at seemingly random times, introducing artificial variability in the supplier’s planning and production process. Asked about the reason for this erratic ordering pattern, the customer’s buyers said “We don’t know. It’s just the way it comes out of the system.”
ERP implementation entails the following:
While these tasks have precedence constraints, they cannot be carried out in just one sequence through multiple facilities. You obviously have to install a system before you can configure it, and you must train users before cutting over, but not long before, lest they forget everything they learned… As much as possible, you try to do these tasks in parallel, fully implementing some functions at some location and collecting feedback prior to expanding. It requires skills in project planning and management as well as technical skills.
The Role Of Implementation Consultants
The key statement in the ERP Focus guide is “if you are looking for consultants as teachers, you may choose a different vendor than if you are looking for consultants as technicians.” In fact, there are two types of professionals who call themselves “consultants,” those who provide advice, guidance, coaching, and training for you to do the work, versus those who do the work for you.
The former charge higher fees but for fewer days, and transfer know-how to your in-house team; the latter become a temporary extension of your work force, reside on site full-time as a team possibly for months, and get a job done, but their expertise walks out the door with them. Strictly speaking, those who become a temporary extension of the client’s technical staff are more accurately described as contractors rather than consultant.
If you are a manufacturer of diapers, frozen lasagna, or jet engines, how much IT expertise should you have in house? “IT” covers a continuum from generic computer, network and peripherals hardware to the company-specific information model. It also covers a stack of applications with the lowest layer being machine controllers and the highest ERP.
The more generic the subject, the more attractive outside help is. If the company’s business is not IT, there is a strong case for not bearing the full-time cost of resources that are not, or should not be needed full time. In addition, it is a challenge to recruit and retain top talent in non-core specialties. If you are a systems engineer with up-to-date skills in networking hardware and software, you have better career prospects in a networking company than in a manufacturing company. Of course, the option to outsource work on your IT infrastructure is only available if there is a local base of contractors to tap into. Such a base is available in any manufacturing center in the US, Western Europe, or Japan, but, if your run a mine in the Peruvian Andes or in the desert of Burkina Faso, you are on your own.
On the other hand, the more company-specific the topic is, the more it makes sense to do the work in house. Setting up and maintaining the business logic of working with customers and suppliers, or the technical data about products and processes requires knowledge that outsiders don’t have, and often shouldn’t have. It is therefore an area where contractors shouldn’t be doing the work, but where consultants can guide and coach in-house employees on the way to do it.
In the continuum of implementation activities, there are extremes where the choice is clear, and gray areas in-between. There is no universal rule on where to draw the lines between what contractors do, what consultants help with, and what employees do. It depends both on the skills available within the workforce and on the facility’s environment. A key question what the consequences would be if information were to leak to competitors. If wouldn’t help them much to know which brand of WIFI routers you use. ERP suppliers are usually allowed to publicize their customer lists, which means that the brand of ERP software a company uses is not a secret either. On the other hand, a copy of the cutting program used for a particular product in a machining center would go a long way towards helping a competitor replicate the process, and should therefore be guarded like the crown jewels. In particular, it should be developed by employees, not contractors, and CNC or PLC programming is a skill your engineers should have.
Issues With Customization
Using contractors or employees to customize generic systems to the company’s specific needs is done not just for ERP software but other classes of assets, including production machinery. Devices developed internally by ingenious operators, technicians and engineers work enhance the capabilities of purchased machines, increase their capacity, or perform unique processes. A forging plant in Japan used its own automation retrofits to second-hand presses to perform a sequence of operations simultaneously and make multiple different items from the same billet. A frozen-food plant in Italy used its own machine to pack blanched spinach leave into a carton and tamp them without breaking them. An avionics plant in the US used its own heat-staking machines to make low-volume parts one by one when the smallest commercial machines processed 50 at a time…
These clever devices are often a competitive advantage and, at first sight, customizing ERP seems to offer the same opportunities. There are, however, differences that make it less attractive. Machine-tool suppliers don’t replace installed machines with a new version every year, but software suppliers do. In fact “software maintenance” refers to the process of releasing and implementing new versions, and has neither technically nor conceptually has anything to do with what manufacturers know as equipment or facilities maintenance.
Software maintenance is not about replacing oil filters, but it nonetheless generates a continuing flow of work for in-house IT resources and contractors. Sometimes the custom add-ons work with the new version of a purchased system; sometimes they don’t and must be fixed. And sometimes, the new version provides, as part of the standard package, the function the add-on was developed for and makes it redundant.
Custom add-ons are proprietary software, used only in one company, which, as a consequence, bears all its maintenance costs. If it is developed by contractors, only these contractors are usually able to maintain it, and it is only maintainable as long as they are around. Historically, manufacturers have engaged into software customization without realizing what they were getting into. 10 years into a local scheduling project, users still only had the “Version 0” functions available, while the massive Version 1 specs were in dusty binders on shelves. 25 years into another project, for configuration management, the company used software written in a once fashionable but now dead programming language, by a contractor who had since retired and moved away. The users did not understand how it worked, but had to live with its output.
That there are horror stories does not mean that custom development of software for the needs of a manufacturing plant is always wrong, only that managers should not underestimate the commitment it requires, and should do what it takes to avoid entering into relationships with individual contractors that last longer than most marriages. I visited a printed-circuit fabrication plant in Silicon Valley two weeks ago, and was surprised that they proudly used an ERP system that they had developed themselves. I don’t know why they had made that choice, but it did not look antiquated, and they seemed happy with it.
Developing In-House Talent
IT groups have existed in large companies since they started acquiring mainframe computers 60 years ago, as depicted in Desk Set. Specialists were hired to set up, operate and maintain these machines. Their descendants today are often overworked and demoralized, and are not perceived as effective by the rest of the company. I don’t believe it has to be that way, or that relying entirely on contractors and consultants to implement new systems is the solution.
Issues with IT Teams and ERP
IT and manufacturing teams rarely understand much about each other’s fields. The ERP applications I have seen are generally able to perform non-manufacturing tasks like taking orders or issuing shipping notices, but not to issue actionable instructions to a production shop floor. Production requirements communicated by the ERP system to the shop usually cannot be executed in the prescribed sequence, if at all, and must be locally edited and rearranged.
Sometimes it is just because the materials needed are not available, when the system thought they were. At other times, however, it is because the ERP model of manufacturing is simply too crude. For example, the ERP system may allow you to specify that an operation has a setup time and a runtime per piece or load, but not that the setup time depends on the product you are changing from as well as the one you are changing to. In reality, changeovers within a product family may be an order of magnitude shorter than between families, and raising the temperature of a furnace does not take the same amount of time as bringing it down. By not representing such structures in their data models, ERP system suppliers in effect dismiss them as irrelevant details, and cause their implementers to treat them that way. To the manufacturing team, however, the ERP implementers are living in a fantasy world, according to rules that are not those of the shop floor.
IT Staff Versus Users
Plant and corporate IT staffs, having invested time and effort in mastering the current systems, are usually less than enthusiastic about new technology that makes their hard-earned skills obsolete, which puts them at odds with the more dynamic members of the operations group, who like to tinker with software as much as the manufacturing engineers with production equipment. It took decades for Graphics User Interfaces (GUI) to replace command lines in ERP systems, when they were already commonplace in home and office machines. The picture on the left was taken in 1993, 25 years after the GUI was invented at Stanford, 20 years after the release of the Xerox Alto, and 9 years after the launch of the Apple Macintosh.
For years, corporate IT staffs dismissed GUIs as “toys,” and insisted that “real work” could only be done through 4-character commands in green, uppercase character on an 80-column black screen. The old tools were more difficult to learn and use, but this is exactly why those who had taken the trouble to learn them were reluctant to let go. Today, the debate is between cloud-based versus on-premise systems, and the defense of the older approach is based on the dubious assumption that on-premise systems are more secure and reliable.
In a 1947 speech, before the first commercial computer was built, Alan Turing predicted this behavior from the people who would be in charge of IT. “They may be unwilling to let their jobs be stolen from them in this way,” he said. “In that case, they would surround the whole of their work with mystery and make excuses, couched in well-chosen gibberish, whenever any dangerous suggestions were made.”
The software tinkerers, on the other hand, are often enamored of the intricate spreadsheet models they develop, but the ease with which they get initial results blinds them to the distance between a quick-and-dirty solution and a tool that can be made part of the organization’s information systems. Making software work at all for themselves is at most 10% of the work professional software developers put in to make it maintainable by others, reliable, easy to learn and use, and mistake-proof. The tinkerers usually process extracts from the ERP and other systems, and, when several meet to discuss their results, they often find differences due to their unknowingly using different extracts. This is in addition to the differences introduced by changes made by individuals in multiple copies of the same spreadsheets.
Strategies To Bridge The Gap
In most companies, management has given less thought to the long-term role of the IT group than Alan Turing had. Here are a few recommendations on making them more effective:
Share this:
Like this:
Related
By Michel Baudin • Management • 0 • Tags: ERP, Information technology, IT, Manufacturing