|
|||||||||
|
|||||||||
Today's industries, particularly those that relate to high-tech products, needs to undergo changes because of the variety of external fluctuations – the complexity of a global market. Changing customer requirements, fluctuating market trends and market segments, integrating several technologies, and linking with multiple industries to create a bigger consumer spectrum has made the traditional way of conceiving product features difficult.
Technology advancements in the telecommunication, wireless and electronics industries are changing the way the automotive industry satisfies its customers. Customer requirements of security, comfort, and resource optimization are forcing these industries product companies to design unique features catering to multiple user needs in more than one market. This case study focuses on a process to identify innovative features using the Theory of Inventive Problem Solving (TRIZ) techniques – navigating through design for a telematics and fleet management product.
The specific TRIZ techniques used include:
Product development is becoming more important, even for service organizations, across the globe. Companies, especially in India and China, are playing an important role in bringing products to the marketplace faster. Technology companies, including start-ups, outsource portions of design and development to service companies. The expectation from these organizations is to provide the services for identifying the suitable market segment and creating new features in every phase of a product's conceptualization.
Some characteristics of technology service companies include:
The present approach used by service companies for product realization revolves around the technical knowledge and expertise of individuals using traditional product requirement design tools and processes. This involves discussion, research and heavy interactions with industry experts to identify product requirements and define the marketplace.
The technical background and scope of this project follows:
The product companies in the telematics/fleet management (and related) space offer innovative products catering to specific, set customer needs. Many of them are for location tracking, infotainment, security, theft and espionage prevention, and parking assistance. A plethora of new technologies, like satellite navigation, telecommunications (GSRM, WCDMA, WiFi, WiMax), weather forecasting systems, intelligent traffic management and remote diagnostics impact the product features customers expect. Additionally, the convergence of technology is bringing about integrated features, saving costs and increasing usability. As the customer requirements are fast changing along with technology, defining next generation features for a product in this space requires an understanding of emerging technologies and the knowledge about present market opportunities.
The second important challenge from a service organization perspective is limited time and knowledge about the domain. Understanding current and emerging technologies, existing market players, consumer and technology trends, and then realizing the new features, consumes too much time if attempted in a typical product requirement design framework.
Cost reduction is an important phase of product design. Apart from deriving new and innovative features, their implementation of them – without cost increase – is critical to a product's lifecycle. The causes of cost are many – hardware, components, tools, service and support from third party vendors. The big challenge is to reduce the cost of hardware and components that constitute the product as this is the deciding factor in producing large volumes of the product.
The other common requirement of present day product design is keeping multi-functionality. Adding more functionality often means adding hardware and software complexities. Contradictions arise when scaling up functionality while simultaneously keeping the costs low. Addressing these contradictions in traditional product development processes is challenging.
The present trend is to have various flavors of the same product so that it can be sold to satisfy slightly varying customers needs while retaining the same basic architecture. This brings the challenges of modular architecture that fit with all customer needs in the telematics/fleet management market. As cost is an important consideration, designing multiple products for a varied customer base is not possible.
TRIZ offers several techniques to aid structured creativity and innovation. The following TRIZ systematic innovation techniques are most suitable for this project and enabled a process flow to work toward overcoming the previously mentioned challenges.
Although this case study is based on the implementation for a telematics/fleet management product requirement design, this process can be generalized and applied to any product requirement design in a service organization.
The system operator helps think about time and space in a simple manner. The 9-windows technique identified several elements associated with user needs, the current market, technology, user constraints, and also identified various resources available around the system. Nine windows was applied in two phases, each time identifying an actor associated with the product and determining the need and perspective.
The following actors were identified based on the expected product usage and the market in which the customer wanted to sell their product:
In the system operator phase shown in Figure 1, each actor was considered as part of the present system, and includes analysis of the elements and functions associated with the vehicles, fleet management company and drivers.
|
This step of the system operator revealed several potential resources available at the super-system that are associated directly or indirectly with the vehicles, drivers and the fleet management company, and the evolution of needs in each user category. Eventually this brought forward features that could be derived for the product.
Before starting the second phase of the system operator, data collected from the web search about the existing market players, products available and a few of the features offered to the customer were analyzed (narrowed to a search of specific markets and associated technology). Each helped identify the technology being used therein, features that most of the products offer currently. Figure 2 shows the features of the existing solutions in the present system and started looking at the constraints from each actor's (vehicle, driver and fleet management company) viewpoint. Phase two identifies better features than the current marketplace offers.
|
From the application of the system operator in each perspective, a bigger knowledge base was created for the products, including the current constraints and unused resources available around the system in telematics and related areas. (See Figure 3.)
|
Some of the available resources were either not used, or were used ineffectively.
There are several constraints from the driver's perspective.
At the end of the system operator exercise, new features were derived by associating the constraints, the sub-system elements, super-system elements (present and future) and the unused resources. The following describes one of the derived features.
Proximity-based advertisement. A small on-board computer provides the driver information on the road – picture messages on a LCD screen share information on shops 200 meters ahead, the special discounts offered and directions. The existing mobile service provider will transmit the data. Directions/locations are determined through GPS coordinates controlled by the central server.
According to TRIZ, the ideal system is a system that does not exist yet. However, increasing the degree of ideality of a system is possible. New products, systems and methods being developed for the market clearly show the increasing ideality of functions.
The IFR was applied by looking at the existing data captured from the web about similar leading telematic based products available in the market. As in a typical S-curve, existing product features can further travel to ideality, achieving more functions without extra cost or harm. In order to get the maximum benefit from applying the IFR, the best approach is to consider each defined actor and create one ideal final feature for all. The following tables describe this approach in detail.
Table 1: Need – What Is the Final Aim? | |
Immediately helping driver/passenger in case of accident | |
Driver | Get immediate help if accident occurs |
Vehicle | Collect the data about the accident – who is responsible and damage |
Fleet management company | Know where the accident occurred, extent of damage and provide fixes |
Table 2: Need – What Is the Ideal Final Result? | |
Immediately helping driver/passenger in case of accident | |
Driver | Real-time information about the accident goes to the people who will provide help |
Vehicle | Send the collected data of the accident and damage to someone about needed repairs |
Fleet management company | Automatically inform the parties who will bring help to the passenger(s) and vehicle |
Table 3: Need – What Stops Us From Achieving the IFR? | |
Immediately helping driver/passenger in case of accident | |
Driver | Driver/passenger may be badly hurt and/or unconscious |
Vehicle | Only collects the engine health data and fuel-related data, but not when the accident happened; the collected data may not be related to the accident |
Fleet management company | Hospitals, mechanics, police, etc. in the area are unknown |
Table 4: Need – How Can We Eliminate the Above Obstacle From the System? | |
Immediately helping driver/passenger in case of accident | |
Driver | "Take out" the responsibility of informing the parties from the driver and have somebody else do that |
Vehicle | Have "somebody" inform the vehicle about the accident and then the vehicle collects data (such as engine health) itself |
Fleet management company | Maintain a detailed listing of police stations, hospitals, mechanics for all locations that the vehicle may pass through |
Table 5: Need – What Are the Available Resources? | |
Immediately helping driver/passenger in case of accident | |
Driver | The vehicle itself – the existing communication technology used in the telematics and fleet management products (such as GSM, GPRS, WiFi, CDMA), police station, medical services, ambulance, people, timer, clock |
Vehicle | The data of airbag deployment and crash sensor data through OBD |
Fleet management company | GPS data received from the vehicle – to identify the location/contact information for hospitals, police, fire station and service technicians in the area where the accident occurs |
Current products available in the market offer features associated with safety and security for trucks/trailers, rental car customers, theft, loss of valuables, etc. Creating a feature that can further mature the functionality came from looking through the IFR framework and the law of technological system evolution.
We found the following resources available to implement the safety and security features:
For the safety and security of the passenger as the requirement while the driver is on road, without third party involvement the product that goes into the vehicle can sense the deployment of airbag or activation of crash sensor, and this data – along with the location data – can be sent to a central server. The data center contains a database with GPS coordination and the nearby police stations/hospitals/fire stations. Once a crash sensor or airbag data is received by this central server, the system identifies the police station/hospital and also the nearest service center from a directory created by the fleet manager/administrator.
Along with the requirements for asset tracking for trucks and trailers, another feature involving the sensor network was derived. An external sensor network (any type of digital or analogue sensor for temperature, chemical leak detection, glass breaking sensor, proximity sensor, etc.) talks to the product installed on the truck and passes the information to the respective authority in case of a breach.
The following known laws of technological system evolution were also looked at to ensure that the ideal final features correspond to the trends:2
The contradiction visible here is – we should implement maximum features derived and the cost of the product should not increase drastically. Incorporating maximum features will increase the need of high speed processing power, battery life, communication bandwidth, data storage capacity and other costs involved in their manufacturing, software development and testing. The result of compromise impacts the market opportunity for the product. The following shows the mapped results of this contradiction:
What needs to be improved? Implement new features derived.
Parameter 1: R&D spec/capability/means
Parameter 6: Production spec/quality/means
What is getting worse? Costs will increase.
Parameter 2: R&D cost
Parameter 7: Production cost
Table 6: Suggested Principles From TRIZ Business Contradiction Matrix1 | ||
What Needs to be Improved? | What Is Getting Worse? | Suggested TRIZ Principles |
Parameter 1: R&D spec/capability/means | Parameter 2: R&D cost | Taking out, 2; asymmetry, 4; dynamization,15; enriched atmosphere, 38 |
Parameter 1: R&D spec/capability/means | Parameter 7: Production cost | Relative change, 37; parameter change, 35; prior action, 10; local quality, 3; universality, 6 |
Parameter 6: Production spec/quality/means | Parameter 2: R&D cost | Merging, 5; taking out, 2; cheap disposable, 27; segmentation, 1 |
Parameter 6: Production spec/quality/means | Parameter 7: Production cost | Dynamization, 15; self service, 25; local quality, 3; prior action, 10; merging, 5; counter balance, 8 |
From the suggested TRIZ principles, the following principles were most relevant:
The current hardware architecture for implementation was based on two processors – one that takes care of the data processing and communication to the central server, and another that interacts with the vehicle OBD interface. By applying taking out (principle 13), a reduction in cost resulted in removing the processor required for vehicle interface, instead using another system to achieve that function. This approach led to a multi-processor architecture and introduced a low-cost processor that takes care of the vehicle interface functionality. Adding this component saved the BOM fourteen dollars. Prior action (principle 10) provided insight into pre-configured modules at the central server units. The concepts of policy based alarm systems, pre-configured database of location based service center, hospitals, and police stations were derived.
During the process of new feature development, multiple customer segments were associated with a single product. Here, the challenge is not developing multiple versions of the products, but catering to different customer base.2
What needs to be improved? Adaptability, flexibility, usability and configurability.
The extent to which a system/object is able to respond to external changes. Also, relates to a system capable of being used in multiple ways or under a variety of circumstances. Flexibility of operation, use and customizability.
What is getting worse? Ease of manufacturing.
Issues related to manufacture, fabrication and assembly issues associated with an object or system.
The technical contradiction matrix suggested segmentation (principle 1), other way around (13) and porous material (31). The following principles are relevant:
The contradiction was a single product vs. multiple customers segment and different costs. The product should be sold to independent car owners, fleet management companies and rental car companies. In each segment, not all product functionality would be used by the customer. Using segmentation (principle 1), the idea to implement two PCB boards, one circuit board with the main components (processor) and the other for communications, configurable for various market needs, was suggested. This helps not only to meet the market needs, but also to maintain/configure the product with changes in communication technology. This reduces the design time as well as simplifies the upgrading of products in the field. Using the other way round (principle 13) helped configure the product for various user displays. Keeping the existing architecture, it is possible to use different kinds of display from simple LEDs, low-cost alpha-numeric displays to a high-end touch panel.
The objective of this project was to create a process that can be reused with TRIZ techniques in product development in the similar scenario. With time and knowledge as significant concerns in the service company, TRIZ techniques like 9 windows and the IFR provide structured thinking and ideation processes. Another important objective was to force the creation of not just new ideas and features, but also how to implement them without increasing the cost and effort. Table 7 lists each technique and their respective uses in this example:
Table 7: Systematic Innovation Techniques and Their Results | ||
Techniques | Usage | How it Helped |
System operator (9-windows) |
|
|
Ideal final result (IFR) |
|
|
Contradictions |
|
|
Laws of technological evolution |
|
|
This case study showcases one of the ways of using systematic innovation tools and techniques to design a technology product from a product development service company perspective. There are many case studies focused on the use of TRIZ techniques in product design, but this case study focuses on the processes (in order) to achieve the ideal outcome with globally dispersed product development strategies.
This project also revealed the need for techniques in the product development process beyond the system operator. Nine windows can help extract resources and elements associated with the system. However, effective brainstorming was required to create associations among the elements and resources.
TRIZ, even beyond innovative problem solving, offers techniques in structuring out of the box thinking. Nine windows, the ideal final result and technology evolution are all useful techniques to apply to different contexts of a service problem's domain.
Girish Deshpande and Suresh Govindaghatta were involved in this project from start to finish. Others who helped me with valuable feedback and critiques are Dr. Raghunath Govindachari, Darrell Mann, Kalyan Kumar Banerjee, Sathish V.J. and Raj Datta.
This article was previously published as a part of the Altshuller Institute's TRIZCON2007.
Prakasan Kappoth is a systematic innovation facilitator and internal innovation consultant at MindTree Consulting Ltd., Bangalore, India. He teaches TRIZ techniques to engineers and facilitates problem solving exercises. Mr. Kappoth has more than ten years of experience in the software industry. He has worked in a variety of technical domains including network management, industrial automation, image processing, consumer application, and embedded appliance and storage. Contact Prakasan Kappoth at prakasan_k (at) mindtree.com.