Last-Minute Advice for Solving Y2K Problems

According to the Gartner Consulting Group, up to 90% of all applications software are affected by the Year 2000 problem. Approximately 30% of all companies, which may include yours or your key suppliers, still have not started compliance efforts. And while most test equipment does no date-related processing, most companies apply date associations to their test data for quality and costing purposes.

So what can you do to make sure your company is not crippled by Y2K issues? Follow these guidelines to determine what you need to do now to get your manufacturing test operations Y2K-ready before Jan. 1, 2000.

Assess the Situation

Perform high-level risk assessment. Pull together representatives of all major functional areas and brainstorm about what processes are critical to your ability to serve your customers. Inventory computer-related data and systems that are essential to the performance of these processes and services. The list should include systems related to:

• Health and Safety Risks-chemical processing, elevators, and waste treatment.

• Customer Support/Order-Taking-call centers, service support centers, and business-administration order-processing centers.

• Customer Shipments-testing, QA, shipping, logistics, and customs.

• Business Metrics-materials planning, tracking, expense management, profit-and-loss management accounting systems, and process-control tracking.

Develop a Preparedness Strategy and Implement Changes

Working with upper-management guidance and oversight, the Y2K team must determine what priority level, metrics, milestones and resources will be devoted to Y2K compliance. The team needs to recognize that fixing the problem in the time remaining will require parallel efforts (top down and bottom up).

Finally, the team must realize that not all problems will be found and fixed in the remaining time. To minimize costs and potential disruptions to customers, business-continuity planning and disaster-recovery processes must be defined and documented as soon as possible. The business-continuity plans also need to include communications with customers, suppliers, and employees.

Most importantly, you must decide where Y2K glitches are most likely to cause serious problems if they do develop. To determine the second part of this problem, you first must inventory your business dependencies.

Business dependency is the information that one process relies on from the others to get its job done. For example, manufacturing needs information from sales to build products to order. Compare actual test times to desired test times to determine cost variances and whether the test process is within acceptable control limits.

Next, the Y2K team must determine in what systems problems are likely to develop. The answer is simple: Any process or piece of equipment that has a computer chip in it or relies on inputs from a computer is potentially susceptible to Y2K.

In reality, the vast majority of computer chips and programs, especially embedded chips, actually do no date-related processing. The problem is finding the small percentage of chips and programs that performs date-related processing and determining if they cause any problems for your business. Keep in mind, we have been writing computer code to assist us in running our businesses for about 40 years. Couple this with our habit of using two digits to represent the year, and you’ll soon find that this can be a big challenge.

Y2K problems are likely to be most prevalent in the COBOL code of the programs you use to manage your business. However, Y2K issues also are present in your manufacturing test processes:

• Performance Monitoring Systems-control for processes such as waste treatment, fabrication, and machining.

• Maintenance and Service-time- and date-related programs for calibration and periodic maintenance.

• Engineering Design-time and date stamps on files used for your product specifications and performance simulations.

Other Mandatory Actions

The Y2K team also needs to closely investigate a variety of hardware and software issues.

• Test Equipment

Examine all test equipment to see if any of it involves date-related processing. Provide each equipment manufacturer with model and serial numbers to determine if Y2K updates are needed. If so, schedule them as part of normal calibration.

Test the equipment before putting it back into regular service. After all of a system’s components have been updated, test the system itself.

• Test Data

Investigate how test data is stored. Are dates associated with the data or any data files? If so, are the computers that are storing the files and the software that is using the files Y2K compliant?

• Computers Controlling Test Equipment

Inspect the computers, the operating systems, and the application software for Y2K compliance. For example, most UNIX systems prior to and including 11.x require Y2K patches for compliance. Patches may not even be available for many versions of UNIX, such as systems dated prior to 10.x.

Obtain compliance information from the supplier of your UNIX operating system. HP provides free Y2K patches for many versions of its UNIX operating systems at www.software.hp.com/products/Y2K/index.html. Examine all applications software. For example, are all the versions of C, FORTRAN, and BASIC that you are using Y2K compliant? If not, update as the code manufacturer recommends.

• Test Code

Does your test code use two digits to represent the year? Update all date-related program calls. For example, newer versions of HP Rocky Mountain BASIC are compliant, but a test engineer still can write code in compliant BASIC which only uses two digits to represent the year.

The code can be revised to four digits to represent the date, or the logic of the program can be modified to use windowing, such as 50:50 to keep two digits for a date. The 50:50 windowing logic will assume that dates equal to or less than 50 fall between 2000 and 2050, and those greater than 50 fall between 1951 and 1999.

• Calibration Tracking and Calibration Programs

Is the program that tracks equipment calibration Y2K compliant? Are the calibration programs used on your equipment Y2K compliant? Contact suppliers for compliance information, and update as needed.

• Business Applications for Process Control or Expense Tracking

Review all business applications that use date-coded data for process-control, expense-tracking, or billing purposes. Make sure each program is tested for Y2K compliance.

• HVAC Control Systems

If your processes are environmentally sensitive (temperature, humidity), make sure that the HVAC controller and software are Y2K compliant. Ask your facilities department to test the system for compliance by forcing dates forward.

• Networks

If you depend on a network for managing your test and manufacturing processes, verify the compliance of servers, operating systems, and service providers.

• Design Files

If you use CAE tools to develop your products, are the tools and the data files Y2K compliant? For example, do you have older PCB designs that were developed on a system that is not Y2K compliant?

Is there any risk that the files will be erased or become inaccessible due to Y2K problems in the software that reads and stores the files? If so, work with the manufacturer to determine what must be done to protect the design files from being accidentally destroyed or corrupted by Y2K problems. Make sure all critical files are backed up on a system that will work after Y2K.

Unit and System Testing

Follow these steps to successfully test units and systems:

• Develop a backup plan in case the tests fail before doing any testing.

• Set up a time-machine environment to test single systems isolated from any networks. For example, HP set up time-machine environments for each of its major computer systems (HP 3000 and HP UNIX). Then, we tested all changed programs by moving the computer clock to the test dates and reviewing the functionality of the changed programs.

• Test the revised system using the other systems that interface with it, if possible in the time-machine environment (off your current network). Find, fix, and retest until you are satisfied that the system is Y2K compliant.

Redeploy Systems and Applications

After you have completed testing at the unit and systems level, it’s time to put the Y2K-compliant applications and systems into production. The key part of this last phase includes business-continuity and disaster-recovery planning as part of your implementation process. Y2K problems are too complicated to assume you will have found and fixed all the bugs.

The key to minimizing business impact is not only to be diligent in finding, fixing, and testing as much as possible, but also to put problem monitoring and escalation processes in place to find and fix bugs quickly. Otherwise, problems could domino into expensive business disruptions.

Develop Risk-Mitigation and Business-Continuity Plans

Finally, develop risk-mitigation plans. Determine which processes are most at risk and develop the business-continuity procedures and critical staffing that you will need to use if a system fails. Include monitoring processes for key variables that indicate if a critical process is in or out of control, including trigger points that activate the business-continuity plan. Then test the plans to make sure that everyone on your recovery team knows what he or she should do.

Communicate now with key employees who will be contacted during critical rollover periods. Have honest discussions with top management about priorities for recovery if key systems or multiple systems fail (what will be fixed first). Include key suppliers and customers in developing and testing your business-continuity plan.

Rather than vacillate as time slips by, act now to update your technology management and business-recovery plans and to build better relationships with your business partners. Follow these guidelines, and Monday, Jan. 3, 2000, will be free from any panic caused by Y2K.

Where Do We Go From Here?

After completing the steps outlined, the Y2K team must get top-management sponsorship and cross-functional participation and keep priorities clear such as Y2K vs new-product introductions and organizational changes. Remember the end date will not change. We can only change the amount of resources we throw at the problem or the scope of what we choose to evaluate and fix. In other words, how much business risk we are willing to take by not evaluating everything and fixing things if they fail later?

Communication is the key to minimizing Y2K misinformation and correctly prioritizing and fixing problems that do occur. Include your employees, customers, suppliers, and community in your Y2K preparedness communications. By investing resources now, you can minimize the risks and costs related to Y2K and hopefully use this as an opportunity to build better relationships with your customers and suppliers.

Figure 1. Critical Y2K Dates

About the Author

Scott Conrad is a Y2K program manager at Hewlett-Packard’s Sonoma County, CA, site which includes five Test and Measurement Divisions. Mr. Conrad has been with HP 16 years, with past experience as a sales development manager, a manufacturing engineering manager, and a manufacturing engineer. He has a master’s in business administration from the University of Minnesota and a B.S. in industrial engineering from the University of Wisconsin. Hewlett-Packard, 1400 Fountain Grove Parkway, Santa Rosa, CA 95403, (707) 577-1400.

Return to EE Home Page

Published by EE-Evaluation Engineering
All contents © 1999 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.

October 1999