News & Events
This Week in IDEA | March 07, 2007
Our eNewsletter, This Week in IDEA, keeps you informed with the latest news and education about IDEA, our solutions and services, and our customers and partners. IDEA’s knowledgeable staff and other contributing writers share insights, resources and special offers to help you Unleash the power of e. Subscribe now to receive This Week in IDEA in your email inbox every other Thursday and add our RSS feed to your reader.
- Request Form: Distributor Request for Net Pricing Information in the IDW2
- New IRD/CERICOMX® Customers
- Change in March IDW2 Training Schedule
- Getting Better Software into Manufactured Products
- FullTilt and Accenture Webinar Reminder
Request Form: Distributor Request for Net Pricing Information in the IDW2
We can all agree that providing clean, complete data, that includes Net Price into Stock, shows a manufacturer’s commitment to the health of the electrical distribution channel.
The NAED Board of Directors approved a resolution tasking IDEA to implement the capability to house and deliver enriched data, product images and Net Price into Stock Data via the Industry Data Warehouse. IDEA has met this resolution and now it is a matter of the manufacturing community providing the information to the IDW2 to meet the needs of their distributor Trading Partners.
Please sign the Request Form with your name and company. If you would like this to be sent to each supplier on your linecard, please leave the manufacturer field empty.
Please email or fax signed copies to Rita Hagopian at (703) 562-4629.
New IRD/CERICOMX® Customers
IDEA, a 1SYNC Data Pool On-Board Solution (OBS) partner, implements suppliers that subscribe to the 1SYNC data pool using IDEA's IRD CERICOMX application. IDEA was recently assigned the following suppliers:
These companies will be trained to use IRD CERICOMX®, an IDEA branded product for supporting and uploading supplier product information into the GS1 Registry® and GDSN via the 1SYNC Data Pool.
If you would like to learn more about the CERICOMX® product, please contact John Etrie, IDEA IRD Product Manager, here or at (703) 562-4624; or Tony Gaffney, IDEA CERICOMX® Implementation Manager, here or at (508) 386-0261.
Change in March IDW2 Training Schedule
Please note that the manufacturer training session scheduled for Thursday, March 15 from 1:30-3:30pm has been changed to Monday, March 12, from 2:30-4:30pm. To sign up for a training session, please contact Robert Hollands, IDW2 Training and Technical Representative, at 703-562-4616.
Getting Better Software into Manufactured Products
The problems of embedded software are rooted in the legacies of hardware development.
Software development increasingly dominates the engineering process in consumer and industrial products as small as cell phones, as commonplace as washing machines and automobiles, and as large as farm equipment, mining tools, and airplanes. At companies that once focused largely on the mechanics of hardware, the primary challenge today is developing high-quality, reliable software to embed in these products. Siemens, for example, now employs more software engineers in its high-tech businesses than do large software companies such as Microsoft, Oracle, or SAP. The focus and value in engineered products is shifting from chips to code.
As the focus shifts, companies accustomed to managing the development of their hardware need to learn new processes and metrics for managing the development of software so that they can make the process more productive and the software more reliable. Hardware typically involves much less uncertainty about how the elements of a system work together: something connects or it doesn't. Software development involves shades of gray. Because there are more levels of connectivity and greater integration with other systems, it's often hard to uncover all of the side effects during the testing stage.
Automobiles make a good case study for demonstrating the challenges of this mounting complexity and for devising a road map to improve the quality and reliability of embedded software, which now drives most of the industry's innovations and accounts for a substantial and rising part of each new car's value. Unfortunately, embedded software has, at best, a varied record of quality: newspapers regularly report failures and recalls.
To improve the reliability of embedded software—and to protect the reputations of automotive brands—carmakers and their suppliers must find ways to improve its quality. This won't be easy to do, but other industries have succeeded by adopting more mature architectures and improved procedures for design, development, and testing. The aerospace industry, for example, is adopting central computing architectures that promote reuse and help companies manage complexity and meet strict reliability and quality standards. For some commodity handsets, several players in the mobile-phone industry have developed the Symbian standard interface between the software protocol stack and applications. This approach helps manufacturers collaborate with suppliers and thus speeds up time to market.
Reduce the complexity of features
Anyone who has flipped through the 500-page instruction manual accompanying a new car knows that automakers add more features every year. The industry should look hard at the value each of them adds to a car, since their complexity has major implications for quality ratings and warranty costs. Research suggests that productivity in small-scale projects (up to 300 feature points, according to the metric used to express complexity) is three times higher than it is in large projects involving more than 3,000 features.
Automakers should analyze the way consumers and ratings organizations evaluate features and then design cars to meet these standards without additional complexity. An airbag supplier, for example, recognized that airbags are judged by the number of stars they receive in the New Car Assessment Program (a global standard of safety and quality), so the company focused on software features that would be visible in the test. This move limited the scope of development and allowed the company to beat competitors to market with new designs and avoid needless complexity.
Adopt a more mature software architecture
Good software architectures—the patterns or frameworks that underlie software design—are modular, with a well-organized system of layers, as well as libraries of code that allow developers to reuse components. But in practice, many embedded-software developers rely on architectures that have grown up incrementally and often haphazardly, resulting in what is sometimes called "spaghetti" code. In fact, our research finds that the architecture of embedded software is one of the weakest spots of its development, lagging half a grade behind the development of comparable traditional software.
This shortcoming must be corrected, since the maturity of software architectures has a big effect on productivity: more mature ones are more modular and standardized, reuse components, and have fewer point-to-point interfaces. Research has found that moving from one maturity grade to the next can make development efforts 2.5 times more productive. In most cases, the improvement comes from abandoning an existing platform and then adopting a more developed architecture as a corporate standard. With further improvements—leveraging standard operating systems, hardware, and integration platforms—developers of embedded software could aspire to the level of productivity that traditional PC software developers now achieve. A telecom-equipment company that switched from its proprietary system to an embedded Linux architecture found that it could develop new features six times faster. A supplier of engine controls invested in a flexible, layered architecture and cut time to market from four months to three weeks.
Understand the economics
Cost pressures can tempt suppliers and automakers to try to save money by selecting less expensive inputs, but this approach often raises warranty costs down the road. In hardware, cheaper components may break or wear down faster. In embedded systems, faults usually emanate from poor design or insufficient testing. When suppliers and OEMs undertake design-to-cost planning, they must learn to consider a broader set of criteria, including the lifetime costs of complex software and less expensive hardware.
One automaker looking to reduce the cost of its components had to analyze whether it would make sense to use less expensive hardware, since this option would require additional software development and could lead to more defects. After factoring in the higher warranty costs likely to result from this added complexity, the company calculated that it would break even only if it produced more than 260,000 units. By using more expensive hardware, it lowered its breakeven point to 120,000 units.
Improve development processes
Many companies that use embedded software—whether in the automotive, telecommunications-equipment, or consumer electronics industries—have a strong engineering tradition. As a result, they often take a hardware-driven approach focused on physical components and tend to have a mechanical view of how pieces should fit together. Such companies need to improve their skills in developing and integrating software systems.
Over the past 20 years, the software industry has professionalized its approach to development by adopting global quality measures such as the Capability Maturity Model or those based on function points. But software development in embedded systems has lagged behind the industry. Fewer software-development tools are available for embedded systems, and those that exist tend to focus on parts of the design cycle rather than the whole. Because embedded development requires expertise in software and in hardware engineering and physics, best practice includes the use of cross-functional teams of experts (feature-based development), development methodologies that apply common models and simulation tools, and "time boxing" (giving developers specific deadlines for deliverables). By instituting cross-functional teams and time-boxed development, one navigation systems company boosted its productivity to more than twice the industry average.
As in other industries where products increasingly rely on software, the automotive supply business needs to shift from a hardware-development mentality to one more attuned to the iterative nature of software development. As compared with many other software developers, those who create the automotive industry's embedded software are less likely to follow norms that have boosted productivity elsewhere—for example, measuring both the productivity of the development process (say, by feature points per person, per month) and the quality of the software (defects per feature point). These developers still labor under the hardware-development legacy, so hardware-oriented productivity measures still dominate their thinking. Until companies learn to deploy software-oriented metrics to measure the productivity of the development process, they will struggle to improve their performance and to make the right trade-offs, such as increasing their up-front investment in architecture to raise the quality of the software.
Managers will also have a tough job changing established mind-sets. Within the company, they will have to persuade engineers to adopt metrics that closely monitor productivity—something that few employees rush to embrace. They will also have to make compelling fiscal arguments for trading out established architecture and development processes for more productive internal standards. Examples from other industries can help managers make the case for change, and the job will inevitably become easier as more auto suppliers get up to speed. In the larger web of the automotive supply network, individual players will have to become more familiar with how their systems interoperate with those of their suppliers. Proprietary advantage is important, but they can no longer afford to work within a black box, hoping that automakers will make all the necessary connections. In the absence of strong industry standards, systems integrators will have many new opportunities.
Auto manufacturing is just one industry—albeit a high-profile case—where the potential of embedded software is being squandered and the weakness of current models for developing it has been exposed. If auto and other manufacturers are to protect their reputation for quality, they and their suppliers will have to raise the quality of embedded software and make its development more productive while reducing time to market.
Article published by The McKinsey Quarterly
FullTilt and Accenture Webinar Reminder
You are invited to attend a free Webinar: The ROI of Product Data Quality
- Is inaccurate product data hurting your business?
- Are you supporting supply chain data synchronization requirements?
- Learn the business benefits of product data quality
What: The ROI of Product Data Quality
When: Tuesday, March 13th at 1:00pm EST
Speakers: Marco Ziegler and Benny Hagood, Accenture; Andy Fedun, FullTilt
Many companies are challenged with inconsistent product information. Does your organization spend more time reconciling product data than it does analyzing it? Join us for this free webinar and learn how to define the business case.
Product information challenges include:
• Multiple systems for managing product information for internal and external use
• Supporting supply chain data synchronization initiatives
• Driving accurate product data for eCommerce initiatives
• New product introduction delays
What You Will Learn:
• How to identify the business value of integrating Data Synchronization and Data Quality initiatives
• How well your company is ready to support supply chain data sync initiatives with quality data
• What current technology and best practices can help you achieve a competitive advantage
• What is PIM and how it supports data quality through internal and external synchronization
Tags for this post: events