In-Depth

Ask the Right Questions: How to Identify the Weak Links in the Supply Chain

• 06/01/1999

When it comes to the Year 2000, co-dependence can be frightening. Each of us may feel some control over the destiny of our own organization, but it is much more difficult to detect the weak links in the supply chain.

To gauge how quickly a supply chain can break down, and the effect it can have on your business, consider what happened to General Motors last year when two plants went on strike. A labor issue, not the millennium bug, caused the shutdown, but the domino effect that resulted illustrates the dependencies inherent in business-to-business relationships. The shutdown began with 3,400 workers at two metal-stamping plants going on strike. Within a week, more than 50 percent of GM’s 223,000 laborers were sent home because of parts shortages at other plants. Roughly 90 percent of GM’s manufacturing capacity was idled. By the time the strike was settled, GM losses exceeded $2.6 billion, hundreds of GM suppliers suffered losses and the launch dates of three new car models were delayed. Remember, this whole chain of events started because two metal stamping plants stopped producing and shipping parts.

Do the same type of dependencies exist within your own organization? Will the impact be the same if some of the suppliers you depend on are idled by the Year 2000? Absolutely! But ask your suppliers for credible evidence of Y2K compliance and you’re unlikely to get it. At the same time that your legal counsel is telling you to require your suppliers to provide written Y2K status reports, your suppliers’ legal counsel is advising them not to put anything in writing, because it could be used as evidence if their project fails.

Given the impact non-compliant suppliers can have on your business, simply hoping you can rely on your suppliers to be Year 2000-compliant is not good enough. You need reassurances. Yet, when you don’t have access to all of the details, there is something unsettling, not reassuring, about suppliers saying they are Year 2000-compliant or that their Y2K project is "on track."

A supplier’s notion of being "on track" or of being compliant may not be the same as yours. Has the supplier tested all of its systems? Have all systems been remediated, or only mission-critical systems? And if only mission-critical systems have been remediated, how is the organization defining "mission-critical?"

So what can be done to ensure that the supply-chain domino effect doesn’t topple your business? The following process is recommended:

Dependency Modeling. No matter how closely you look, your company’s external dependencies won’t be identified in the millions of lines of code your company has inventoried, fixed and tested. You will need to establish a dependency model that identifies and prioritizes any external party on which your company depends, including suppliers, customers, distributors, government agencies and others.

If even a single dependent party has a Year 2000 crisis, your company may, too. Will a key supplier of a key supplier fail, creating a domino effect? Will the manufacturer of a single screw that holds your product together be sent back to 1900? Will the embedded chips in your point-of-sale terminals fail to work, closing down your retail business? Will your HVAC system break down? Will your overnight lock-box system fail? Will your EDI network crash? You’ll need to understand your dependencies well just to survive.

Supplier Audit. Ask a simple question, such as, "Are you Y2K-compliant?" or "What is the status of your Y2K project?" and you’ll get a vague, meaningless answer. For a project as complex and multifaceted as Y2K, it is naive to assume that a single question will trigger a response that is sufficient to gauge the status of an organization’s Y2K project. Instead, a detailed series of questions should be asked.

Analysis. Once all of the information is gathered, it must be analyzed carefully to determine the impact it will have on your organization. Hopefully, your contingency planning process has identified alternative suppliers, process changes and other steps that can be taken to wean your dependence from non-compliant third parties.

How the Supply Chain Management Process Works

What needs to be done to ensure the continued operation of your company after January 1, 2000?

Step 1: Dependency Modeling. Dependency modeling should answer that question, taking the Year 2000 beyond the IT shop and framing it in a business context.

Managers from IT, purchasing, finance, sales and marketing and other departments need to work together to identify and understand the dependencies that link their organization with other organizations, and what the risks of those co-dependencies entail.

A dependency model can be built simultaneously from the top-down and from the bottom-up. Anyone who has participated in business process reengineering (BPR) understands the top-down approach that is used to identify key products, customers, suppliers, processes and other components that are critical to the business. The company’s Year 2000 inventory should have yielded the detailed bottom-up information about hardware, operating systems, applications, compilers, utilities and whatever else is needed to keep the business operating. Facilities dependencies, such as PBXs, elevators, security systems and other features should, of course, also be included.

Collecting this information is the easy part. The challenge comes when the top-down business information and bottom-up technical information are combined. Again, BPR experience can help to map key business processes onto specific applications to complete the chain of dependency that runs through the enterprise.

The information that is gathered should be loaded into a dependency modeling tool that will allow the organization to test various "what-if" scenarios, and to determine the likely result of individual dependency failures and combinations of failures. If properly developed, the dependency model can be a valuable aid not only for helping to understand the organization’s complex business environment, but for mitigating any problems that are encountered. Trade-off analyses can be performed and the impact of various strategies can be determined. The model should be based on an extensible database so you can capture attributes such as how important the supplier is, whether you have audited the supplier and what percentage of your business the supplier affects.

The dependency model can also help the organization adjust for unforeseen events. If, for example, an application vendor’s Y2K project falls behind, assuming that your dependency model is date driven, you can plug in the vendor’s expected completion date to determine what problems it will create. Based on the results, you can make an educated decision about whether to seek out another supplier.

A dependency model can also help to identify where to install early-warning devices, such as data filters, which can alert your company when non-Y2K-compliant data is coming into your information system from an external source.

Step 2: The Supplier Audit. Many suppliers are unwilling to provide written documents verifying their organization’s Year 2000 compliance, or the compliance of their products. Even if written statements are provided, it is important to verify their accuracy. For key suppliers, it is worthwhile for members of the Year 2000 project team to visit sites and inspect suppliers’ test plans and results. An on-site visit also presents an opportunity to make note of the resources allocated to the Year 2000 problem and to determine whether they are adequate.

When written documentation of Y2K compliance is unavailable, the organization should seek answers to the following questions. A composite of answers, assuming the answers are complete, can identify the status of your suppliers’ Y2K project with some degree of precision.

1. How does your organization define Y2K compliance? Every organization should have an official written statement that defines Y2K compliance. If there is no definition, how does the organization know whether it is Y2K-compliant? If there is a definition, is it accepted throughout the organization? Will the definition hold up to legal scrutiny? Has the company completed a certification process? If the company defines compliance as including only mission-critical systems, how does it define "mission-critical?" If a mission-critical system is dependent on another system, is that system also, by definition, mission critical? Are embedded chips mission critical?

Various measures of compliance exist. GartnerGroup, for example, has developed the COMPARE (COMpliance Progress And REadiness) scale that defines five levels of compliance – sort of like the five stages of mourning (See COMPARE sidebar).

While COMPARE gives some measure of compliance, there is a huge gap between levels 3 and 4, and again between levels 4 and 5. GartnerGroup addresses this issue using sublevels. For example, 3.5 indicates that 50 percent of systems are compliant. Every enterprise should be close to completing level 3 at this point. Consider dropping any suppliers that are not close to level 4 yet. (For more on GartnerGroup’s Year 2000 analysis, see Year 2000 World Status Update by GartnerGroup analyst Lou Marcoccio.)

2. Have you completed an inventory of all date-dependent assets? Any reliable Y2K project should have begun with an inventory of all of the organization’s date-dependent assets, including software, hardware and embedded chips. Some organizations have spent little time on the inventory process, or skipped it completely. They are at risk. How can an organization claim Y2K compliance if it has never identified precisely which assets needed to be remediated?

Contracts, agreements, warranties and business relationships are also date dependent and should have been inventoried. Questions that should have been asked during the inventory process include: Who owns the assets? Where do the assets reside? Who is responsible for maintaining them? For software assets, the organization should have determined whether any source code was missing, since remediation takes place at the source level. It is not enough to determine whether source code exists for a particular application – the organization must also be certain it is the right version of source code.

For hardware assets and embedded chips, the manufacturer should have been identified, and the organization should have determined whether the manufacturer is still in business. The supplier should have worked with the manufacturer to ensure compliance. If the manufacturer is no longer in business, the supplier should have identified whether the assets are mission-critical. If so, they should have been replaced.

3. What is your process for remediating date-dependent assets? Be certain suppliers have a reliable process for fixing, replacing or eliminating all Y2K date-dependent assets. Did experts review the process and have they confirmed that it is reliable? Were adequate resources – including time, money and people – assigned to implement the process? Have milestones been met? What has the organization done about missed deadlines?

4. What is your process for testing remediated assets? As with the inventory process, many organizations are taking shortcuts with their testing and hoping for the best. To determine whether your suppliers are testing adequately, ask them whether they have developed reliable tests to certify that their date-dependent assets will perform properly, based on the organization’s definition of Y2K compliance. Ask whether they have, or plan to, retain an outside party for testing, and whether test results are available for inspection by an outside expert. Keep in mind that many Y2K-related problems are unlikely to appear for some time after January 1, 2000. Ask suppliers whether they are archiving test results for future reference.

5. What process was used to ensure that newly purchased assets are Y2K-ready? Many IT organizations have assumed that they could avoid the remediation process by replacing old systems with new ones. It is best never to assume that a new system is Y2K-compliant. For example, Microsoft recently discovered that Word 98 had minor Y2K glitches (even the product name contains a two-digit date field!). Every organization should have a process in place to ensure that all newly acquired assets conform to the organization’s Y2K readiness definition. The organization should also specify who is responsible for carrying out the process. If your organization acquires other businesses, the due diligence extends to inspecting those assets also.

6. What impact will the Year 2000 have on your business partners? Y2K may have an impact throughout the supply chain. It’s not enough to know that your suppliers are Y2K-compliant. They must know that their suppliers are Y2K-compliant, too. And those suppliers should be checking on their suppliers. Let your suppliers know that you are ready to make changes if they are not Y2K-compliant – and ask if they plan to do likewise. Other business relationships should also be taken into consideration. Non-compliant customers, for example, may develop accounts receivable problems and be unable to pay their bills.

7. Have you performed an analysis of the risks associated with possible Y2K failures? Year 2000 risks are like a hydra; chop off one head and two sprout in its place. In addition to risks created by suppliers and other business partners, organizations should consider financial, legal, environmental, health, safety, regulatory, human resources, competitive and investor risks. Another question to ask is whether the organization is insured for Y2K risks, or whether Y2K exclusions have been written into the organization’s insurance coverage.

8. Do you have a contingency plan? No one knows what will happen when the clock rolls over on January 1, 2000. Our best efforts can only minimize the degree of uncertainty. Bad things can still happen – and every organization should have a plan in place in case they do. If there is a contingency plan, how does it address possible interruptions in business processes? Have employees received the proper training to carry out the plan? Has the plan been tested? Is it being updated regularly as project milestones are reached and conditions change?

9. What is the organization’s communications strategy? How is the organization informing stakeholders of its current Y2K status? Who is responsible for coordinating Y2K communications? Is a crisis communications plan in place in case a Y2K-related crisis erupts?

10. How committed is senior management to the company’s Y2K project? Y2K extends well beyond the scope of any IT organization. An IT organization that tries to tackle Y2K without a serious commitment from senior management is bound to fail.

Step 3. Information Analysis. Based on the results of the organization’s dependency model and on an analysis of the information gathered in Step 2, the organization should be ready to make the decisions that need to be made about each link in its supply chain. As with the company’s internal Y2K project, a triage approach can be taken. Hopelessly non-compliant suppliers who are not essential to the business can be dropped immediately. Key suppliers who have reached level 4 compliance or higher can be congratulated.

Concentrate on key suppliers who are in danger of missing the Year 2000 deadline and decide what to do about each of them. While a consistent set of rules should be applied, some decisions will have to be made on an individual basis. For example, it may be difficult to replace some key non-compliant suppliers. It may even be worthwhile for your company to help such suppliers achieve compliance.

Even if all of the above steps are followed diligently, a key supplier or other dependent party could fail. You could find your company without a key part, without telephones, even without power on January 1, 2000.

What makes supply chain management even more frightening than any internal Y2K project is that it is beyond the organization’s control. Following the process recommended here will at least minimize the probability of a mishap – and help to ensure that your organization is better prepared to recover from any Year 2000 setback than your competitors may be.

It is also important to apply the same standards to your own organization that you apply to your suppliers. The answers to the questions outlined in Step 2 will identify the Y2K status of suppliers, but every organization should be asking many of the same questions internally. Anyone involved with the Year 2000 should look not just outward, but inward.

Economist John Maynard Keynes once said, "I’d rather be vaguely right than precisely wrong." Unfortunately, with competitive markets overcrowded, regulators anxious to reprimand and Wall Street willing to take apart companies that miss earnings projections, being "vaguely right" on Y2K could be a company’s death sentence. We all must strive to be precisely right – and to ensure that our suppliers are as well. To achieve that goal, we must ask the right questions, and do whatever we can to ensure that we get the right answers.

About the Author:

COMPARE Where You Are

by Leland Freeman

Based on the COMPARE scale, companies can rate their suppliers and decide whether it is necessary to replace a supplier or follow some other contingency:

• Level One: Preliminary Activity.
At this stage, the organization has recognized the problem and has begun to address it. The organization remains at this level until it has completed its inventory and defined the scope of its problem.
• Level Two: Problem Determination.
Enterprises reach level two by completing an inventory of their IT and non-IT assets and making a preliminary estimate of the effort needed to resolve the problem. The organization should be able to identify the level of risk posed by Y2K.
• Level Three: Plan Complete and Resources Committed.
A plan has been completed that identifies mission-critical technology and separates it from non-mission-critical technology. The plan should identify timeframes for completion of various functions, specific cost estimates and resources needed, and it should be fully accepted throughout the organization.
• Level Four: Operational Sustainability.
All mission-critical IT and non-IT assets must be compliant, and compliance of all key business partners must be certified. At this level, Y2K should no longer be a threat to the survival of the business.
• Level Five: Full Compliance.
At level five, all technology that supports the enterprise’s business processes is Year 2000-compliant.

• --L.F.

by Doug Deffenbaugh

Payless Cashways, Inc. is a full-line building materials and finishing products specialty retailer. The Company is the fifth largest retailer in the industry as measured by sales and it operates 159 building materials stores in 19 states. The success of Payless Cashways depends on our ability to leverage the many opportunities in the IT environment including Year 2000 compliance, merchandise-decision support, technology-based productivity enhancements and systems that help build better customer/supplier relationships.

The IT organization at Payless Cashways uses third-party software, which is customized according to specific business requirements. Such modifications to the vendor’s source code often make it difficult to upgrade to new vendor releases. We had extensively customized our Human Resource Management System (HRMS), from Integral Systems, and needed to apply those changes to each maintenance release that the vendor delivered. This was necessary, as each release added functionality and responded to end user enhancement requests.

Our customizations were not well documented and it was difficult to differentiate the custom code from the packaged code. When Integral delivered a minor maintenance release of HRMS, we manually integrated our in-house changes, but this process was fraught with errors. For the major releases, it was clear that we needed an automated tool to re-implement our modifications into the new vendor release. Otherwise, the upgrades could cause months of delay and squander valuable programmer time.

Based on Integral’s recommendation, we purchased Princeton Softech’s Version Merger to reconcile our in-house changes with each release. When Integral delivered the Year 2000 compliant version of HRMS, it was a massive release. Because of the custom code scattered throughout the entire application, Version Merger proved to be a powerful tool for merging our customizations with the Year 2000 compliant release of HRMS.

Well before the Year 2000, we found that testing was often a slow and painstaking process. Many of our testing tasks were performed manually and the tests had to be repeated for different conditions and special cases. Two tasks in particular were problematic: extracting test data and comparing the results. Extracting test data required that we coordinate our requests with the DBA. To compare the results, we had to review our output listings in detail.

Princeton Softech’s Relational Tools for DB2 (relational test data creation and verification tools for MVS) was our choice. Comprised of Move for DB2, Access for DB2 and Compare for DB2, the Relational Tools create, age, edit and compare relationally intact DB2 test data.

In several instances we used Move to extract a subset of data using relationships that were not defined to the DB2 Catalog. For example, there is application-driven RI between the EDB (Employee Data Base) and the HDB (History Data Base) within HRMS. However, in some instances, we need to extract all the EDB and HDB information for every employee working at a specific location. By using Move to build a relationship between the Employee ID on the EDB and the Employee ID on the HDB, we can extract every employee for a particular department and the extract will include the history data as well.

We have built a separate LPAR region to change the actual system date and time. Originally, we had employed Compuware’s Xchange software to do so, but now we can accomplish this with a separate machine dedicated to testing. Of course, comprehensive testing requires more than just changing the system clock -- we needed to age our test data.

Move’s Legacy Date Interpretation feature correctly recognizes legacy dates that were not converted into DB2 "date" data types, but were instead defined to DB2 as general alphanumeric fields. Thus, we can age every date, producing accurate, useful data while ensuring that legacy dates are not erroneously excluded from the aging process. The Semantic SafeGuard feature eradicates date warping errors caused by legacy applications that make use of special values in date fields to quot;flag" certain conditions.

Move’s support for built-in semantic date aging, using Payless Cashways’ business rules, eliminates the need for us to code exits or create holiday tables by hand. The ability to apply business rules is particularly important for our payroll and distribution systems. It allows us to age dates accurately so that we can reflect events such as a specific day of the week.

Move supports Object-Level Semantic Aging, which ages dates in interrelated tables via a single pass of the source database, while maintaining the referential integrity of the data. For our sequential data sets, we use Compuware’s File-AID/Data Ager. This product increments, decrements, or replaces dates in files, enabling our programmers to simulate the century date change. This product allows us to repetitively age or advance dates in our sequential files, eliminating a time-consuming and error prone task. Users can create test data by automating the process of incrementing, decrementing or specifying default values for day, month, year and century fields.

Access for DB2 enables us to simultaneously browse and edit related data from multiple DB2 tables. Access also allows us to define supplemental relationships that have not been defined to the DB2 catalog, which enables us to edit the primary key columns without violating an RI rule.

The time-shifted nature of the Year 2000 upgrade raised concerns about regression testing. We needed to ensure that the changes we made to comply with Year 2000 requirements did not cause existing functionality to break. Compare for DB2 contrasts "before" and "after" versions of HRMS data in their referential context, to be sure that the application is performing correctly. We used Move to extract a subset of data from both the production and test versions of HRMS. We know which fields should remain unchanged and which should not. Using Compare, we can see if the Year 2000 compliant program is executing correctly.

Before using Compare, we randomly chose a few hundred records and manually compared them. We couldn’t assume that the application was working based on such a small sample. Compare allows us to compare all 20,000 records in our database.

By improving our IT organization’s testing methodology well in advance of our Year 2000 project, we were well prepared. Our experience with automated tools enabled us to handle the Year 2000 project with our own staff, thereby avoiding the cost of expensive, outside consultants. We are confident that these tools will expedite our remaining Year 2000 application upgrades.

About the Author: Doug Deffenbaugh is Manager of Integral's Human Resource Management System at Payless Cashways, Inc.