What you need to know about supply chain management: while there are the occasional horror stories about botched SCM implementations, if you have a good understanding of what you want to achieve and a measured approach to implementation, you can prevent the nightmare from featuring your company.

"I wish we could ship a company a CD and that company would suddenly become an efficient supply chain leader," sighs Karin Bursa, marketing vice president for Logility, Inc. (www.logility.com; Atlanta, GA). Alas, that is not to be. Supply chain management (SCM) practitioners must invest time and effort--"sweat equity"--defining the supply chain, understanding and selecting the applicable technologies, and then managing the implementation project. Given the advances in technology, help is on the way.

START WITH A MODEL

Probably the most well-known description of supply chain business requirements and processes is the Supply Chain Operations Reference (SCOR) model from the Supply-Chain Council, Inc. (SCC; www.supply-chain.org; Pittsburgh, PA). The latest version of the SCOR model, released in June 2003, is the sixth major revision of the model introduced in 1996. The model is a broad framework to help professionals users translate business objectives to operational objectives, and those objectives then to information technologies (IT).

The bummer is that the model tends to be "trailing-edge," admits Scott Stephens, the SCC's chief technology officer. "We look at stuff pretty much after it's been released--after practitioners have had some use with it." Also, adds Andrew White, research director for SCM at the Gartner Group (www.gartner.com; Atlanta, GA), the SCOR model "doesn't give you the important stuff: What makes my business competitive?" But it's a start. Says White, "SCOR is a good leveler. It's a standard set of high-level business processes--activities within a department or domain, right down to a shopping list of metrics and key performance indicators (KPIs). It's a great way to get running very, very quickly, or maybe walking very, very quickly."

Other models exist. The lean-manufacturing folks have methodologies that help define SCM needs. So do the Six Sigma folks. RosettaNet (www.rosettanet.org), to a degree, identifies standardized processes and standardized workflows, but it doesn't identify KPIs and metrics. The Gartner Group also has a model; it's more a general business framework, versus manufacturing-specific, and it doesn't go anywhere near the detail of the SCOR model. Europeans, by the way, tend to gravitate toward the Efficiency Consumer Response Scorecard, which, points out White, suggests grocery industry supply chain requirements but it is not specific to that industry.

Applying the SCOR model to supply chain design can be automated. For example, ProVision from Proforma Corp. (www.proformacorp.com; Southfield, MI) is a software modeler for designing, defining, and analyzing business processes. The ProSCOR module of ProVision provides the high-level supply-chain definitions and best practices used by the SCC. After the SCM design phase, this same module can help tie business processes back to business objectives by providing metrics (KPIs) to measure the effectiveness of those business processes. As needed, the supply-chain model can be translated into simple English for business documentation, enterprise architecture analysis, ISO certification, and other business needs. The software can also highlight changes made between As-Is and To-Be supply-chain processes, thereby helping address process implementation issues and tasks. The module's simulator can calculate process timings, analyze activity-based costs, and identify bottlenecks, resource constraints and excessive queuing.

Of course, using the SCOR model as a standard can lead to what Stephens calls "cookie-cutter solutions." On the other hand, he notes, these solutions let supply-chain practitioners focus on customizing what they need to, to the degree they need to. "Every company will do things a little bit differently, and that's probably the way it should be because that's what provides companies competitive advantage," he says.

SAP (www.sap.com), for one, isn't knocking the cookie-cutter approach--as a first step. SAP incorporates the SCOR model's 300-plus KPIs throughout its business software, starting with the SAP Solution Manager. This software-based implementation guide lets users map almost on a one-for-one basis the SCOR model's best practices against what the users want in their SAP ERP and SCM implementations.

Once in operation, the SAP ERP and SCM systems automatically deposit the data from ERP and ongoing supply chain transactions into SAP's business intelligence applications. These, in turn, calculate the plan-source-make-deliver KPIs and deliver them to SAP's management cockpit" for role-based breakdowns of the SCOR model. So, for example, plant managers view the KPIs relevant to their jobs, sales managers view the KPIs relevant to their jobs, and so on.

BEYOND SCM DESIGN

Insofar as implementing the "M" in SCM, several technologies and IT approaches are becoming more commonplace. For instance, Logility's Lifecycle Planning Engine includes pre-trained neural networks and a number of profiles (different planning algorithms and methods) to help tune sales forecasting. Analysts would apply these profiles to specific product families or items, and then decide how granular the forecasts should get. The key here is the neural network technology. A best-practice template is just not slapped into place to manage the supply chain; instead, the neural net actually interacts with real-time supply chain information, and then decides on a course of action. The result, says Logility's Bursa, is to better "synchronize the availability of manufactured items with when you're going to need them in the marketplace." In short, to better balance supply and demand.

Further downstream, sophisticated calendaring options are now becoming a standard function within planning and execution software. According to the Gartner Group, this solves the problem of each trading partner having "different calendar requirements for period (weekly, monthly, yearly) start times, holidays, and shift start times." Not being able to synchronize calendars results in inconsistent views of time for an enterprise interacting with multiple trading partners.

Advances are occurring in "platform management." On the user side, vendors continue to develop thin-client software with an eye toward streamlined Web-based operations, data integrity and security, ease-of-use, and overall scalability. Workflows are now available that cross the back offices of multiple trading partners within a supply chain. Add to that XML and other Web services, which link the workflows to Web pages. Mind you, not all of this has to be created from scratch; predefined, but customizable, templates and decision alerts help when configuring software for specific supply chain needs.

On the server side, explains Thad Dungan, director of global solution marketing, automotive, for SAP (Detroit, MI), vendors are working on standardizing both the supply chain execution and the planning systems on one platform. This eases the maintenance, upgrade, and integration of software packages from multiple vendors, as well as eases scalability. And all of this will presumably reduce the total cost of ownership.

Software vendors are also working on flexible data aggregation and hierarchy definition. These two functions, says the Gartner Group, are key to data sharing between trading partners with dissimilar "hierarchies for viewing/processing time-phased data," as well as item and price data. Software products infused with XML and other Web services, along with the use of public and private data hubs and electronic trading places, are facilitating this data integration and consistency across an SCM implementation.

PROJECT MANAGEMENT IN SCM

While there are apocryphal stories of SCM implementations gone awry, with the software provider or consultant as culprit, Stephens thinks the blame is not always appropriately placed. "I am not comfortable that in all cases the practitioners know what they want to do other than 'to get better.' They don't know how to get better, and they're hoping the software provides the magic bullet."

Too often, what software vendors and consultants know about a business's needs is intuited from a checklist of software requirements the supply chain practitioner first puts out. Here's a better approach toward a more successful SCM implementation:

* Understand supply chain requirements from a business perspective. That is, explains Stephens, understand your business, the competitive requirements, and what the existing supply chain does or what a new non-existing supply chain is required to do to support the business. Adds White, "Go back to basics. What is core to your business? Where are you in the supply chain network? If you can't identify those, then it doesn't make any difference what you do."

* Identify the required business processes, geographic coverage, material flows, and other aspects of the desired supply chain. Also identify the measurements that determine the supply chain's "goodness." "Translate the measurements for 'goodness' back into dollars toward a business objective," emphasizes Stephens. These measurements will eventually be one of the key metrics for ROI analysis, especially in the purchase of new IT. White adds, "Focus 80% of your management and investment time on the core stuff, and recognize the rest of it is still important, but don't put all your resources and bucks there."

* Translate the supply-chain requirements into supply-chain transactions, and then into software (and hardware). Get help by collaborating with the enterprise's own IT group and similar groups among your trading partners up and down the supply chain, or by partnering with consultants or a business enterprise software vendor. Better, collaborate with all of the above.

* Implement the enabling technology.

* Keep the translation of supply-chain requirements to technology an iterative process. People tend not to continually revisit their initial business requirements both during the definition phase of the implementation project and during its progress, warns Stephens. "These requirements are what keep you from experiencing scope creep."

All in all, Stephens does not doubt that over the last five to ten years, SCM has become easier to implement. "There are more tools for implementation. The packages are better defined as to what they can and cannot do. And the software systems tend to be more capable, more robust, and more scalable."

By Lawrence S. Gould, Contributing Editor