Applications of Supply Chain Management

Published on February 2017 | Categories: Documents | Downloads: 30 | Comments: 0 | Views: 275
of 12
Download PDF   Embed   Report

Comments

Content

22
Topography of Supply Chain Applications
When designing and implementing a system, remember that system effectiveness is inversely proportional to the complexity. George Plossl, as quoted in ERP: Tools, Techniques, and Applications

George Plossl offers sound advice for those contemplating the implementation of any major software tool.1 In this chapter, we describe the major software categories that fit into the supply chain domain. We mentioned in Chapter 21 that the boundaries of these categories are fuzzy. A particular package may be classified or marketed under multiple categories. The types themselves also change over time. This can be the result of package providers joining forces, or industry providers seeking new “space” in the marketplace. The joining of two or more providers usually involves the building of software links between packages. In this fashion, they become “integrated” and offer a “single solution.” Other companies, working alone, will build new versions of their packages with additional capabilities. A “map” of the supply chain information terrain will aid our discussion. Figure 22.1 is such a map; we’ll use it as a reference to place different categories in the chain. Figure 22.1 shows three enterprises that compose a “supply chain.” The central shaded figure could be our own organization. The enterprise to the left represents our supplier base. Our customer base would be on the right. All three enterprises have separate functions, or departments, as noted by the vertical lines, or “silos,” in each enterprise in the chain. Across the top is the “enterprise level.” This consists of corporate functions or processes that cross department boundaries within the organization. Between organizations the figure shows linkages of two types — information and physical flow. The information flow is two-way, while the physical flow is one-way from raw material to delivered goods. We recognize that product also flows backward due to transactions such as returns. Also, there are financial flows in supply chains. Early systems were generally developed under functional sponsorship and had minimal integration between departments. This was the problem addressed by ERP. Once data is entered into the ERP system, it is available for all departments. Faxes, mail, EDI, the Internet, or proprietary networks pro1-57444-273-2/00/$0.00+$.50 © 2000 by CRC Press LLC

167

168

Handbook of Supply Chain Management

FIGURE 22.1 Map of supply chain information terrain.

vide pipelines for the information links. As indicated above, the Internet is becoming standard. An understanding of what different categories of systems will and will not do is important to effective management of the supply chain. We hope these descriptions will be helpful in sorting what one might need. As we proceed, we’ll return to Figure 22.1.

22.1

MRP and ERP

By far most of the money, time, and effort expended recently on supply chain systems have gone to this category. “MRP” stands for materials requirements planning. “ERP” stands for enterprise resource planning. We consider MRP and ERP together, since the newer incarnation, ERP, has its roots in MRP. Carol Ptak and Eli Schragenheim have traced the evolution of MRP to ERP.1 Figure 22.2 shows their MRP to ERP evolution. They liken each phase to “ERP growth rings.” Each generation, like the rings on a tree, has added to the capability of this category of application. According to Ptak and Schragenheim, at least three drivers are behind this growth. The first is the expanding capability of technology. The declining cost and increasing capability of computers brings with it hardware for handling more transactions faster. The second driver is increasing expectations in the supply chain for fast response. The result has been greater reliance on “just in time,” or JIT, practices. Under JIT, long lead times are out; speed is in. In the JIT environment, materials must be managed with much more rigor. The third driver is the shift from labor-intensive to material-intensive business models. This has come from improvements in worker productivity and

Topography of Supply Chain Applications

169

ERP MRPII Closed Loop MRP MRP Bill of Material Processor

FIGURE 22.2 ERP growth rings. (Reprinted with permission of CRC Press, LLC.)

a growing propensity to buy, rather than make, components. So ever-improving methods of managing material are welcome and downright necessary to stay competitive. Successful companies work on lean inventories and strive to have the right material available at the right time. The bill of material processors, shown as the first growth ring, documented what material went into what product. This was a major step in matching the material purchased with the products being sold. It became feasible with the coming of age of computers in the early 1960s. MRP added visibility and took advantage of increasing calculating power. In MRP, the forecast need — represented by the master production schedule — could be compared with onhand and on-order amounts. Orders could then be placed to fill the gap. MRP schedules have two logical flaws that, according to critics, limit their effectiveness. The first is that MRP requirements are based on forecasts. With cloudy crystal balls, MRP causes overstocking of items that don’t sell and understocking of those that do. The second flaw is the assumption of infinite capacity. Associated with this is the use of fixed lead times. As a result, forecasts may make impossible demands on the production process. Actual lead times vary with the workload. When backlogs go up, lead times are likely to go up as well. (Refer to the “3C” alternative to MRP in Chapter 29 for an approach that addresses these two shortcomings.) Relieving the capacity planning problem led to “closed-loop MRP.” In closed-loop MRP, the computer calculates the effect of the production plan on work centers. One now knows which centers have the most demand and can take action. Examples of this action can include rescheduling, adding capacity, or contracting out production. Closed-loop MRP requires the organization to fully document manufacturing processes, particularly the bottlenecks.

170

Handbook of Supply Chain Management

In manufacturing processes, this usually includes capacity expressed by the time required to produce a part, the set-up required, and lead times. Producing this documentation adds considerable cost and time to implementing MRP or ERP. This cost is commonly expressed as a multiple of the software cost. Multiples of five or six times or more are not uncommon. The documentation and training also strain the project management capabilities of many companies and their system integrators, which are usually consulting firms hired to get the systems installed and running. It is likely that the failures cited in Chapter 21 are not the result of deficient software logic. They are probably due to shortcomings in the integration of packaging, training, or managing needed organization changes. When MRP evolved to MRPII, available computing power made it possible to track financial as well as material requirements in the same application package. According to Ptak and Schragenheim, MRPII produced an integrated business system that • provided visibility of the requirements of material and capacity driven from a desired operations plan • allowed input of detailed activities • translated all this activity to a financial statement • suggested actions to address those items that were not in balance with the desired plan1 This means that MRP, established to manage material for production, had leapt departmental boundaries, spreading from the manufacturing floor to financial and planning processes, and in the process improving communications among multiple functions. ERP extends MRPII even further. As defined by the ERP/Supply Chain Research Center, this includes “modeling and automating many of the basic processes with the goal of integrating information across the company.” The huge advantage is getting every department on the same page when it comes to data. No longer is it necessary to reenter employee data or orders or sales forecasts into multiple department-level systems. The scope of ERP can now include product development, capacity planning, and marketing. ERP has found eager customers in many industries beyond manufacturing. Table 22.1 is a list of common modules in a typical ERP system for manufacturers and distributors. A claim by many ERP providers is that their system incorporates what they refer to as “best practices.” One package claims to have over 800 predefined business processes that can be tailored to suit an individual user ’s case. This is valuable if the company is willing to change. It can cramp the style of some implementers, however. An electronics distributor insisted on making each report in the new ERP system match the equivalent report in its legacy systems. The purpose was avoidance of any change that would require adjustments by employees. The result was a very rough implementation that, due to the customizing necessary, ran far over budget.

Topography of Supply Chain Applications
TABLE 22.1 Functionality of ERP Applications
• • • • • Capacity Requirements Engineering/Product Definition Human Resource Management Material Bills and Routings Real Time Planning and Scheduling (often with bolt-on software) • • • • • Cost Management Financials and Accounting Manufacturing Processes Order Management Purchasing and Inventory

171

Another note of caution is in order. First, ERP systems are sometimes “rejected” because the inherent best practice method isn’t accepted by the organization. If the organization tries to modify the software to fit its processes, it will likely end up with a “one of” system — and a costly one at that. Every upgrade to the base software may necessitate extensive modification. Another caution lies in fitting ERP to a supply chain strategy. We have said that strategy depends on uniqueness. While adopting standard processes for nonstrategic activities is certainly acceptable, one must understand which processes have to be different for strategic reasons. In Figure 22.3, we return to our supply chain map to trace the expansion of functionality in these systems. The original MRP was principally a supply function, confined to a single department as we show in the figure. So it occupies a space on the incoming side of the enterprise where material acquisition is planned and processed. There is little effect on other functions. Closed-loop MRP has an impact beyond the supply function. Production processes have to be documented. Forecast requirements are bounced against the capacity to deliver them. So multiple departments in the enterprise are affected.

FIGURE 22.3 Progression from MRP to ERP in the supply chain.

MRPII involves financial functions and becomes the centerpiece of corporate systems in manufacturing companies. ERP extends that reach even fur-

172

Handbook of Supply Chain Management

ther. But, as Ptak and Schragenheim point out, the heartbeat of most ERP systems remains the basic MRP module.

22.2 Specialized Applications for SCM
ERP isn’t the end of the systems journey for most companies. And to some, like the manager making the statement at the beginning of Chapter 21, this is a surprise and a disappointment. They may find important shortcomings inherent in ERP’s role as a transaction system. The shortcomings lie in planning and scheduling important processes in the organization. Examples include incoming materials, production processes, and the warehouse. In the dynamic software environment, many ERP providers are scrambling to add this functionality to their own systems or are building linkages with special application packages. However, for most, these additions must come through bolt-on packages. Here we briefly describe a few of these specialized applications and what they do.

22.2.1

SCM and APS

This category is the vanguard of what is referred to as supply chain management or advanced planning and scheduling software. In our discussion of MRP and ERP we described what some believe are the weaknesses of MRP and ERP. The lack of features is particularly dangerous when supply chain partners are closely coordinating their production and the supply chain is running close to capacity. A response has been the growth of applications in the SCM and APS category. We’ll use the term “APS” here since it’s a more descriptive term of the software functionality. Applications in this category are likely to displace the scheduling and planning roles of ERP systems. Dave Turbide, editor of APS Magazine, has listed the MRP and ERP shortfalls addressed by APS systems.2 Table 22.2 compares the two categories. Turbide reports that many APS applications are moving beyond single companies to supply chain solutions. These extend the capabilities described above beyond the immediate enterprise. Suppliers of APS applications emphasize the planning capability of their products. Typical modules include both supply planning and demand planning, providing forecasts of expected production. These are shared up and down the supply chain. An important benefit in multicompany planning is having a common forecast. A frequently cited shortcoming of noncooperating supply chains is that each link must make an independent forecast. Demand fulfillment, another APS feature, helps the organization respond to demand as it actually unfolds. This includes the ability to look forward and

Topography of Supply Chain Applications
TABLE 22.2 Comparing MRP/ERP to APS
MRP/ERP MRP is a batch process. It’s not run in “real time.” Often run outside normal hours. No priorities for customers, products, and materials. All requirements treated the same. Uses the infinite capacity assumption. Lead times are fixed and known. APS

173

Uses technology that allows for fast turnaround of results. Can optimize solutions using business rules.

Calculates in a one-pass sequential process working backward from due dates. Weak decision support/simulation capability.

Recognizes capacity constraints. Lead times are a result of many dynamics in the schedule and should reflect business rules and procedures. Solves material and capacity availability simultaneously, assuring both are present for scheduled production. Fast turnaround allows for multiple “what if” scenario analysis and fast response to inquiries.

test alternatives for supply chain production. An APS may operate over a wide time frame, providing both short-range and long-range decision support. The system may also have to make delivery commitments on a minuteby-minute basis. It does this by quickly reassessing capacity and due dates based on the latest orders. This is possible because the data is in the core memory during computation, speeding the process. On the other hand, it’s also a tool for long-term capacity planning with time horizons measured in years.

22.2.2

MES

Another “bolt-on” application category is manufacturing execution systems (MES). MES also sprang from the inability of traditional MRP systems to plan in dynamic shop floor environments. This category automates much of the scheduling activity needed to run work centers on the shop floor. The time horizon is short, ranging from minutes up to days. It is described by some as a bridge between the MRP/ERP or APS plan and the machine-level controllers on the plant floor. An MES solution will likely perform some or all the following: • Resource allocation and monitoring. • Operations scheduling recognizing capacity constraints. Dispatching. Maintenance management. • Data collection on labor, quality, and work completion. • Manufacturing/process engineering tools including simulation, process planning for parts, and design for manufacture (DFM) analysis.

174

Handbook of Supply Chain Management • Quality management including inspection and testing, laboratory results, and statistical process control.

An MES package is suited to complicated production settings where fast execution of orders is important, and operations must be rescheduled frequently.

22.2.3

Warehouse Management Systems (WMS)

What APS and MES do for the factory, a warehouse management system will do for the distribution center or warehouse. More sophisticated operations require specialized applications designed to their needs. WMS applications fill this gap. On the outbound side, it is particularly important in coordinating shipments with customers — a process referred to as fulfillment. WMS functionality can cover a broad range including internal operations, shipping, and transportation, and management functions such as payroll and inventory management. The systems also incorporate automation like barcode reading and the use of radio frequency hand-held terminals to communicate in the facility. These provide real-time updates of inventory status. Other functions include those listed in Table 22.3.
TABLE 22.3 Functionality of Warehouse Management Systems
• Labor control and planning • Inventory tracking including cycle counting and locations • Transportation planning and routing • Decision support for planning • Capability for random slotting to increase storage density • Directed put-away • Order entry through EDI and e-commerce methods • Planning of picking routes for improved productivity • Yard management • Shipping transaction processing • Receiving processes to improve accuracy • Batch picking

22.2.4

Customer Relationship Management (CRM)

ERP is largely known as a “back office” transaction processing application. This has left a vacuum in the “front office.” The front office covers the activities that bring the business into contact with customers. This category, while certainly important to the supply chain, is not included in lists like those produced by CLM, which focuses on distribution-related applications. Like other categories, CRM suppliers are building bolt-on links with back office ERP systems. The CRM category includes a large number of functions for both e-commerce and traditional interfaces between customers and product suppliers. Examples include those shown in Table 22.4. CRM is likely, in our opinion, to be an important enabler of supply chain strategy execution. Once a customer

Topography of Supply Chain Applications

175

demand enters the supply chain through a CRM application, it can be dispersed rapidly throughout the chain. Rule-based decisions can then support both planning and execution systems in response. We describe this approach in Chapter 28.
TABLE 22.4 Functionality of CRM Applications
• Contact management • Account/territory management • Customer service systems • Data “mining” to understand customer trends • • • • Customer history tracking Field sales Order entry Decision support for sales campaigns, market segmentation, and so forth

22.2.5

Product Data Management (PDM)

While many have focused on ERP implementation, some companies — particularly those with technical products — appreciate the need for PDM applications to improve their supply chains. As time to market requirements for new products increases in importance, so will this category. PDM has long been the domain of individual company engineering departments. One of the hallmarks of SCM is the increased role of partners, and sharing product information becomes more necessary. A particularly important example is electronics. Increasingly, producers in this fast-moving industry rely on contract manufacturers to produce their designs. PDM fills the need for standardized ways of exchanging product information. Many companies maintain product-related information in separate applications. Examples include the CAD (computer-aided design) system for engineering drawings and a word processing file for product descriptions or technical manuals. This makes mixing and matching files a difficult job. In this environment, steps in the process are likely to be done in sequential fashion. Conceptual design, detailed design, drafting, testing, and so forth proceed at a slow pace in series. If a downstream change occurs, the design process may have to be repeated. PDM is seen as an enabler of “concurrent engineering,” which has the potential to shortcut the design process. With concurrent engineering, design activities proceed in parallel. Effective use of PDM will likely be a “make or break” factor in competing in many markets. This includes both new-product introduction and management of product design change orders. Roy Schulte of the Gartner Group, which monitors information technology trends, describes the need for “zero latency.” This term implies “instantaneous” left-hand/right-hand communication. As soon as a new design is ready or a change in design occurs, it is published up and down the chain. Slow communication of product design information increases cost and wastes time.

176

Handbook of Supply Chain Management

Another practice that is supported by PDM is referred to as “design for supply chain.” In this case, a supply chain partner, perhaps a large distributor, reviews a bill of material as the design is near completion. The review may surface opportunities for substitution of a functionally identical part. The alternate part carries a lower cost due to the distributor ’s contracts with suppliers. Within the PDM category, we would also include recording the “rationale” for important design decisions. This is the “why” of the design. It will provide those with whom one must collaborate now and in the future the rationale for a design decision. Separate tools are available for this purpose. A collaborative PDM system requires the capability not only for defining product components but also for sharing those designs along the supply chain. It must also be dynamic in terms of tracking product configurations, referred to as “configuration management.” Separate applications are available for this purpose. Cutting-edge applications in this category allow buyers to order customized products from suppliers. Accessing the supplier ’ s design library with Internet-compatible links does this. Such links support purchasing, manufacturing, and life-cycle maintenance requirements. Typical components of PDM include those shown in Table 22.5.
TABLE 22.5 Functionality of PDM Applications
• A product database • Configuration control • Messaging system • Non-proprietary interfaces for access to the database • Rationale for design decisions • Integration of PDM tools

22.3 Meeting Improvement Objectives for Systems
There is much written on why systems efforts fail. We described some problem cases earlier. Systems have a lot to offer, but the systems solutions are seldom easy or cheap. In understanding why systems fail, one must understand why the efforts were undertaken in the first place. Much recent activity has centered on the kingpin of systems project — the new ERP system. Deloitte Consulting and Benchmarking Partners reported the results of a survey of companies undertaking ERP implementations plus their own experience with technology implementations.3 There were a number of technological reasons that necessitated the projects. Factors, listed in order of importance, were 1. Systems not Y2K compliant 2. Disparate systems

Topography of Supply Chain Applications 3. Poor quality/visibility of information 4. Business processes or systems not integrated 5. Difficult to integrate acquisitions 6. Obsolete systems 7. Unable to support growth

177

Since the survey was conducted before 2000, many companies were facing the Y2K deadline. So that need has receded. In the future, motivators will likely include one or more of the remaining factors. The survey also measured ERP expected against actual benefits. Table 22.6 lists the areas identified as benefits and indicates whether the benefits exceeded or disappointed expectations.
TABLE 22.6 Fulfillment of Expectations for System Implementation
Benefits Exceeded Expectations Productivity improvements Procurement Order management/cycle time Financial close cycle Transportation/logistics On-time delivery Benefit Level Disappointing Inventory Personnel reductions IT cost reduction Cash management Revenue/profit Maintenance Supplier management

There are many commonly mentioned root causes for project failings. Here is our summary.

22.3.1

Strategic Plan

Too little thought goes into matching systems design with strategic needs. To date, most systems efforts fulfill “back office” requirements. This is generally the day-to-day transactions needed to run the business. Most companies that have been in business for any amount of time have built systems around departmental needs. Often these are added to gradually without benefit of an overall plan. There is never a concerted effort to look at the whole, including enterprise and supply chain processes. This includes ways in which the organization will interact with its supply chain partners. With Y2K pressure behind us, we expect better linking of systems efforts with other strategic implementation initiatives.

22.3.2

Documentation Shortcomings

Systems depend on accurate data to produce high-quality outputs. For example, the schedule for a poorly documented manufacturing process will have

178

Handbook of Supply Chain Management

minimal value. Implementers of systems often overlook the need for creating and maintaining this documentation. The result is a “brittle” system where underlying data inaccuracy makes the system all but useless.

22.3.3

Modularizing the Job

We would agree with others that a systems effort should be subdivided into distinct projects. This will be even more important as users look for more value-adding solutions beyond back office operations. The systems effort must be part of an overall initiative that includes supply chain design and experimentation with alternative ways to create information links.

22.3.4

The “Simpler Way”

In any supply chain effort, the “best” systems solution may not require a computer at all. Going into an effort with a preconceived idea that the solution requires a computer application is a mistake. This is particularly true in the case of many SCM applications. There are alternatives to consider either as a final or interim solution on the way to new systems. One such method, called the 3C alternative to MRP, is described in Chapter 29.

References
1. Ptak, Carol A., and Schragenheim, Eli, ERP: Tools, Techniques, and Applications for Integrating the Supply Chain, Boca Raton, FL, St. Lucie Press, 2000. 2. Turbide, Dave, What is APS? Midrange ERP, January/February 1998. (Available at www.apsmagazine.com/apswhat.htm.) 3. Jennings, Dana and Kling, Greg, Integration of Disparate Enterprise IT Systems, presented to Supply-Chain World Conference sponsored by the Supply-Chain Council, April 1999.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close