Unraveling the Complexity of Today’s Products

By BARB SCHMITZ | Published: NOV 16, 2011

Nearly every product today, from cars and phones to washing machines, contains some sort of embedded computing technology. Customers are increasingly yearning for technology-enabled products. Smart phones, computing tablets, electronic navigation systems, Wi-Fi-enabled TVs, and a slew of other tech-enabled products offer consumers convenience, portability, and personalization at very reasonable prices, thanks to increased competition among manufacturers.

Consider these daunting statistics. Over the past five years, the average number of tech-enabled engine control units in new vehicles has grown from 20 to 80. In the mobile phone industry, the number of IT-based updates per year is approximately 40, double the number from 2000.

As the complexity of products increase, so does the task of developing them. The mounting pressure to cut time to market while also keeping prices low adds to the challenges faced by manufacturers worldwide today.   The growing demand for these tech-heavy products creates a struggle for manufacturers who are trying to keep costs low amid fast-evolving technologies and the continual pressure for product upgrades.

Traditional product development was driven largely by hardware considerations. Today’s complex products are dependent upon the effective integration of multiple hardware and software components. Software design involves strings of code that are pieced together in interconnected layers. The IT architecture underlying new product designs today, therefore, is much more complex. In products that are controlled by on-board microprocessors, sensors and processors guide their function, not mechanical components.

Manufacturers accustomed to managing the development of their hardware need to learn new processes and metrics for managing the development of software. Hardware typically involves much less uncertainty about how the components of a system work together: something connects or it doesn’t. Software development involves shades of gray. Because embedded development requires expertise in software and in hardware engineering and physics, best practice includes the use of cross-functional teams of experts and development methodologies that apply common models and simulation tools.

Successfully developing these tech-enabled, complex products requires an integrated approach that addresses a number of important characteristics. The architecture should be modular in nature, allowing sections to be stored and applied in different or future products. It should be built on standards, providing for easier integration, and be configurable so one system can meet many different customer requirements. Finally, it should be updatable, allowing new features and functions to added without having to discard large parts of previous releases.

Product development teams creating complex products should continually look for ways to simplify designs. Ask if a certain desired feature is something that customers would use regularly. If not, consider leaving it out. If the design seems overly complex, teams should not be afraid to start over and determine if the design can be streamlined to reduce its complexity. This not only decreases developments costs and design cycle time, but can also reduce the complexity of using the product. If a product is too complex and the learning curve is to high, adoption will be low.

Efficient and effective collaboration among those tasked with developing these complex products—engineering, marketing, concept design, and others—is critically important. This interaction helps IT-and engineering development teams balance what the market demands in a feature set against what the business side requires in costs and cycle times—and keeping it all within the realm of what’s technically possible.

Close collaboration also helps to anticipate where design changes might occur since changes made to one portion of complex multi-dimensional designs have ripple effects that can affect adjacent portions. Carefully and collaboratively organizing the architecture of these designs is vital to isolating the effects of design changes. By involving all those who are likely to initiate changes in the design—sales, marketing, purchasing, Quality, manufacturing, and engineering—you can help predict where those design changes will occur and design the underlying product architecture accordingly.

Because of the great complexity involved in the design of these tech-enabled products, the implementation of a product lifecycle management (PLM) system is vital. PLM systems help organizations by managing the interdependencies of these various subsystems (software and hardware) on each other, facilitating the collaboration between the multiple disciplines involved in the design, and tracking the change process.

Image  by Tom Held

MCADCafe: Hyundai Motor Company and Kia Motors Corporation Completes First Phase of PTC PLM System Deployment

By ADMIN | Published: JAN 12, 2012

“PTC’s Windchill is being deployed within HMC/KMC’s core research and development groups to establish a system of record for the complete vehicle, which will include design data from a range of different systems including CATIA and Pro/ENGINEER^® (now Creo^®). In addition, Windchill will also help handle the complexity caused by the increasing number of vehicle change management requests and, further, will provide a comprehensive Digital Mock-Up (DMU) environment.

“Our company believes that new thinking leads to new possibilities,” said ChangKy Kang, executive vice president and head of vehicle development center 4. “This philosophy is what led us to select PTC as our strategic PLM partner. We are pleased by the collaboration between PTC and our project teams in achieving this aggressive implementation milestone on schedule.”

Read the full article here.

How In-Service Support is Impacting Your Bottom Line

By AILBHE COUGHLAN | Published: OCTOBER 12, 2011

A main battle tank costs in the region of $1.5 million to procure, taking six to seven years to design, manufacture and supply. If you then consider the lifetime of the vehicle, which is, say, 25 years, the support cost is at least $15 million, ten times the original price of the vehicle.

In today’s lean times it’s no surprise that companies like BAE Systems, Thales Group, Rolls Royce, and General Dynamics are increasingly focused on providing cost-effective and efficient in-service support for their products.

In broad terms, in-service support is customer support throughout the lifetime of a system, it is delivering the right product information at the right time, and it is getting damaged systems back into operation quickly. Logistic support ensures that up-to-date content is available on time on demand anywhere to anyone in the organization from one single source throughout the lifecycle of the product.

Let’s take the first part of that definition. As a manufacturer, how can you ensure delivery of the right product information at the right time and get damaged systems back up and running quickly?

Here’s an example: Ask a mechanical design engineer to house a power supply in a heat-resistant, water proof box and he will create a box to that exact specification. The result however will be a metal box with multiple seals and many nuts and bolts, probably of varying sizes.

The box contains a power supply inside which will inevitably get hot, reducing its mean time between failures (MTBF) over time and making breakdowns more frequent. Now we are at the repair stage. Due to the unnecessary number of fittings, and many different size tools, the mean time to repair (MTTR) will be far longer than necessary. The design engineer has delivered on his specification without consideration as to what happens once the box is in-service.

What happens if we modify the design specification as follows: Ask the mechanical engineer to design a heat-resistant and water proof box with an MTBF of 10,000 hours and an MTTR of 10 minutes, using standard tools.

Now when the power supply fails you know the exact repair conditions. You have to invest 10 minutes to repair, use standard tools to open the box, and the number of times that the power will fail is one time per 10,000 hours.

With this kind of data, companies are able to calculate how often the box is likely to breakdown and how long it takes to be repaired, thus reducing the cost and time involved in the repair.

Today, most governments insist on contracting for equipment availability (Reliability over Time) and manufacturers get penalized if products are not reliable and don´t meet availability requirements. Waiting on spare parts for a downed chopper or tank in the middle of a war zone is nobody’s idea of fun. Products must be as reliable as possible and easy to repair. If not manufacturers may looses out on future contracts.

Take a company like General Dynamics, which designs and builds specifically for defense. In-service support is a critical part of its business.

“In-service support is becoming increasingly important,” says Chris Hunt, in-service manager at General Dynamics UK. “The customer base is asking about it in a more considered and educated way. Every offer and opportunity that we pursue includes consideration of in-service support, so the emphasis is increasing within our business.”

Has your company invested in in-service support? Do you think in-service support matters outside of aerospace and defense contracting?

Delivering on the Promise of PLM

By MARILYN COHODAS | Published: AUGUST 10, 2011

I’m fairly new to the concept of Product Lifecycle Management(PLM) in manufacturing but back in the day I followed supply chain issues for a purchasing magazine.

After a down year in 2009, the global market for PLM technology came on strong in 2010 and is expected to grow through 2015, according to a recent report from CIMdata, the Ann Arbor MI-based research and consulting firm.

Recently, for instance, there’s been a heavy investment by aerospace, automotive, high-tech and mechanical machinery companies driving strong growth in China for global and domestic PLM solution providers, CIMdata reports.

But what exactly is PLM? And why ten years after its introduction to the manufacturing industry, is it making a comeback in today’s lackluster world economy?

Manufacturing today is becoming ever more complex, one has to be able to deal with complicated global supply and distribution chains as well as make product changes quickly. Getting products to market on time and on budget is a tricky proposition, especially in highly competitive industries like automotive. PLM at it’s best attempts to address these challenges.

Though universally accepted standards are still evolving, one generally accepted definition of PLM technology is that its software that enhances the many processes related to a product’s Bill of Materials (BoM)—the manufacturing Bible that tells companies how to design, build and support their products. PLM solutions optimize the management and evolution of a BoM throughout a product’s lifecycle from conception, design and manufacture to service and disposal. Any activity that changes or influences a BoM are factors that drive operational effectiveness and, as such, are subsumed within the PLM umbrella.

But PLM seems to me to be much larger than the sum of its individual parts. It is a strategic approach to product development and manufacturing that applies a consistent set of business applications to the collaborative creation, management, dissemination and use of product-definition information across an extended enterprise. Simply put, a PLM working environment integrates multiple business processes and systems across disciplines, touching many users, both internal and external.  

How then does a manufacturer align its own people, processes, and information systems with out-of-the-box PLM and still support unique business requirements and existing corporate culture? That is no small feat and, quite frequently, the underlying reason behind project delays and problems, more so than financial or supplier issues, according to a July CIMdata anecdotal opinion poll on what PLM projects struggle with the most.

In the poll, when asked to identify the primary cause of their challenges, respondents pointed to technical, business, organizational, solution, and financial issues, in that order.

Asked what percentage of PLM initiatives encounter substantial surprises, detours, and interruptions , an overwhelming 75% of respondents reported the majority of their PLM projects encounter unexpected obstacles and roughly 30% said “nearly all” PLM projects experience those challenges.

 “If these sample poll results are accurate for industry in general, it means that the PLM community (i.e., the PLM softwarevendor, systems integrators, consultants, and others) hasn’t provided the guidance, skills, training, software, etc., or some combination of said elements needed for success,” according to the CIMdata research notes.

The good news, CIMData researchers note, is that very few projects go off the rails due to the wrong solution selected or from an unresponsive supplier. The bad news is that too many PLM projects encounter technical obstacles which could have been predicted and mitigated with more realistic planning and assimilation of best practices.

Analysts believe that PLM has come of age and is maturing into a game-changing discipline with the potential for becoming the most fundamental business application in manufacturing. But will PLM deliver on this decade-old promise of a technology solution that helps manufacturers create better products faster, more efficiently and at lower costs? That’s still an open question. Share your thoughts.

Marilyn Cohodas is a veteran IT journalist who, before joining PTC as marketing program manager, was editorial director for six B2B Web sites serving corporate IT managers and administrators of Microsoft enterprise Windows technology.

Safeguarding Design Concepts and IP

By barb schmitz | Published: August 25, 2011

 

Intellectual property is the most important asset of a manufacturer and, if leaked to a competitor, can lead to lost market exclusivity and competitive advantage. Today, IP contained in product concept designs is increasingly at risk, along with the revenue and corporate know-how it represents. The threat to product IP has increased as a result of globally distributed design teams that design products collaboratively, and ironically, by the approaches required to enable truly distributed design and manufacturing networks.

 

A lack of processes and procedures in place to protect IP and safeguard design concepts during development, can lead to lost IP, which in turn results in lost sales, product commoditization, and lower profit margins. Manufacturers must implement organizational structures, business processes, and technologies that support “IP friendly” collaboration, document IP and enable legal protection, and safeguard product data, including enhancing IT security and digital rights management.

Protecting Product Concepts

Concept designs are captured and managed differently at organizations. In a recent study entitled, Trends in Concept Design, conducted by PTC, only 37% of the participants responded that their company utilized some type of centralized management system to capture and manage design concepts. Another 34% indicated that their companies “strictly manage all concept designs, including revisions, in a centralized process.” Another 22% of respondents said that each person on the development team stores concept designs on his or her own computers, indicating that no centralized management system was in place.

Engineering notebooks are commonly used to capture proposed designs during the concept phase of development. In the PTC survey, the largest percentage of respondents (66%) said that some team members use engineering notebooks during the concept stage. Who owns the information contained in those notebooks? Over 59% of respondents believed the company owned the notebooks and the information contained within, however, another 41% of respondents either didn’t know who owned the notebooks (22%) or believed that the individual owned the data captured in the notebook (19%).

Despite advancements in and increased deployment of Product Lifecycle Management (PLM) systems and knowledge management systems, many manufacturers still use informal tools and processes, such as engineering notebooks, to communicate and manage key product data, which can inhibit collaboration and elevate IP risk.

Without established procedures in place to safeguard the information contained in these notebooks, when employees leave a company, valuable and proprietary data leaves right along with them. Though 67% of respondents indicated that they didn’t think the notebook would be taken upon an employee’s departure, another 33% either “didn’t know” or thought it would be taken.

So how is this information safeguarded? At many companies, there are no established procedures to protect this valuable corporate product data. In the survey, only 16% of respondents indicated that the data captured in these engineering notebooks is captured electronically in the company’s systems. Nearly 70% of respondents said that there was no such procedure in place to capture this data electronically in corporate systems.

A strong strategic approach to IP and concept design management must span from product conception to market release. Companies must implement a systematic approach to safeguarding emerging design concepts and the potential IP they hold in order to reduce the risk of IP theft or loss. Integrating IP management into R&D through product development seamlessly provides opportunities to improve IP protection that can reduce a manufacturer’s risk and lower costs.

Design Software for Tomorrow’s Engineers

By Geoff Hedges | Published: August 24, 2011

 

If you keep up with the business press, you know that many are predicting a broad disruption to manufacturing soon. Not a political disruption as world leaders seek to lure factories with incentives. But rather, a technological disruption, as ideas like affordable 3D printing and community manufacturing centers take hold.

Everyone brings a different view to the discussion of how the changes might unfold, but there’s one prediction with which everyone agrees: We’re going to need more designers and engineers. Lots of them.
That brings me to John Stuart, SVP of PTC’s Educational Program. His team offers curriculum development, deployment, and support  to institutions and students worldwide as we try to inspire and prepare the next generation of engineers. He tells us how it works:

GH: What is PTC’s strategy with respect to education?

Stuart: We look for shared value, where everyone involved in our initiative benefits by participating–employers, schools, and students.

GH: For example?

Stuart: We partner with an educational establishment that delivers engineering graduates to our customers. We work with our customers in supporting the university, college, or school. And we make sure students gain experience in the tools and processes their biggest local employers use.

GH: What are the key tactics behind this strategy?

Stuart: There are really four key tactics. First, we get involved in the top engineering initiatives between education and industry. Second, we develop a strong presence in universities, colleges, and training centers. Third, we involve ourselves heavily in schools and with STEM programs. Fourth, we simply provide students access to our software products.

GH: You’re involved in some well-known student engineering competitions ….

Stuart: We work with existing educational-industry initiatives like STARBASE, Real World Design Challenge, FormulaSAE, and FIRST. These engineering initiatives attract the best  students, challenge them with real engineering projects, and provide industry mentoring  from some of our largest customers.
Our goal is to ensure that if a students take part in these challenges, they have access to the best software tools and training available. Each year, we try to add more student teams and more customer participation too.

GH: You’re also in universities, colleges, and training centers?

Stuart: Of course. There’s a lot of activity at that level. In countries like the US, Germany, India, and China, demand for engineers outstrips supply by at least 2 to 1. In some countries, it’s 5 to 1. Governments everywhere are investing in programs to encourage more young people into engineering by adding technical colleges and advanced training centers. So, we work with both existing universities and these new colleges and training centers to make sure PTC products play a key part in the curriculum.

GH: What about high schools?

Stuart: With 9- to 13-year olds we have our best opportunity to inspire young people  to become engineers and scientists. Our key initiative here, again, is to involve PTC in the design competitions–FIRST, Real World Design Challenge, STARBASE, and so on.

GH: What about individual Students?

Stuart: Students can access free versions of our software, for example, Creo Parametric, Creo Direct, and Mathcad. We also provide access to libraries of free tutorials to help students become familiar with the products.

GH: What’s unique about PTC’s educational program?

Stuart: The program provides the broadest range of software technology and support tools out there, including 2D and 3D design software, engineering calculations, product lifecycle management. It’s what I call a 360-degree approach to education. Take Creo. We offer a  stair-step curriculum. New students work with 3D using a direct modeling approach. For students with more experience, we provide training on projects developed with Creo’s powerful parametric modeling tool, Creo Parametric. We also include a rich set of curriculum materials, professional learning managements tools, and PLM as a service on the cloud.

GH: How would you summarize your success?

Stuart: Literally tens of thousands of students graduate each year having taken part in the PTC educational program. And with Creo, and the new 360 approach, we offer one of the most comprehensive programs on the market. [Ed. In future articles, we’ll look more closely at Stuart's educational initiatives and activities going on across the world.]

Mechatronics Management (Part 2): Electrical Aspects

April 27, 2011 | Categories: Lifecycle Insights Projects, Software Applications and Systems

 

 

This series of four posts looks at the management of items, data and bills of material for mechatronic products. It is split into mechanical aspects, electrical aspects, software aspects and integrated aspects.

In the minds of many, managing electrical aspects of products has, well, already be done. Meaning there have been approaches and technologies that have been around for some time to manage the artifacts representing electrical components. But actually there have been some relatively recent advancements in the technology that, by and large, isn’t commonly managed centrally today. Let’s take a look.

Managing Electrical Aspects of the Product

When you start talking about the electrical side of the house, things tend to be a bit more complicated compared to the mechanical side of things. What is considered a part can be dramatically different depending on the type of electric item you’re discussing. Here it makes sense to split up the discussion based on the type of electronics being developed.

Managing PCB Schematics, Diagrams, Layouts and Libraries

Printed circuit boards (PCB) are used pretty frequently in today’s products. The design of a PCB often starts with a 2D logic diagram that represents the functions of the PCB. Next the design moves on to a 2D schematic, where the connections between the different board components are symbolically shown. And finally, the layout shows a detailed view of the placement of components and the path and layer for each trace in the board. From a manufacturing or sourcing perspective, the lowest level items on a PCB are the components (resistors, etc.) and the board. However, there is information embedded in these design artifacts that describe a deeper level of granularity in the board itself: the traces that connect the components on the board. To further complicate things, the components and connections between them are represented in both the schematic and layout. That means if that connection changes in one, it should change in the other.

Today’s PLM or PDM systems often recognize that the diagram, schematic and layout all essentially represents the same electronics assembly. And as such, they create links between them. And while integrated tools recognize that a change to a connection in the schematic should propagate to the layout, most PLM or PDM systems do not. Furthermore, the information about the connections themselves that is embedded within these design artifacts are often not extracted into the PLM or PDM system. From a Bill of Material (BOM) perspective, most PLM or PDM systems will extract the counts of the different electronic components, creating a flat list with quantities. The diagram, schematic and layout are often attached to the top level board assembly.

What shouldn’t be lost in all of this details is the fact that most PCBs are assembled almost completely out of off-the-shelf items. As such, a centralized library composed of approved parts lists generated by the procurement organization is used to identify which components are OK to use for designers and engineers.

Traditionally, PLM and PDM systems have managed this library as a single item that can be downloaded to a desktop. From there, the ECAD or EDA application accesses the library directly.It can certainly work. However a fair amount of functionality exists in PLM and PDM systems to manage libraries of parts, to manage change across those libraries and to promote reuse so that higher volume discounts can be achieved. By managing the electronics component library as a single item, none of those things can be proactively managed. Ultimately, electronics components would be managed as individual items, just like mechanical parts, in PLM and PDM systems.

Managing FPGA Programming

In many circumstances, manufacturers want to optimize processors to do a specific job. One option is to custom build application specific integrated circuits (ASICs), but they are extremely expensive because they require custom dies and manufacturing runs. The number of ASIC manufacturers in the world can probably be counted on a couple hands. So, instead, manufacturers often use field programmable gate arrays (FPGAs). This type of chip is a off the shelf component that can be programmed with custom logic to perform specific jobs more quickly and efficiently than generic chips. However, since they are off the shelf components, they aren’t nearly as expensive as ASICs.

So how are FPGAs programmed? Traditionally, manufacturers would hire programmers to code the logic of these chips. And managing that environment looks very much like a Software Configuration Management (SCM) problem. But times are changing. There are new software applications that will let a user create a logic diagram and then, in an automated fashion, generate the code to program the FPGAs. This is an advancement in terms of enabling everyday engineers to define the logic they want without working through a programmer, a proxy who often doesn’t understand the engineer’s design intent. This approach is sometimes referred to as visual programming. Now don’t get me wrong. The code generated by these software applications aren’t perfect. However they often enable the programmer to just check the code instead of writing it themselves. And that can be a huge time savings for an expensive resource.

As you can imagine, either programming directly or using a visual programming approach will generate a number of design artifacts that should be centrally managed in some manner. More often than not, this type of deliverable though is managed as a generic artifact, just like a word document, and as a result doesn’t have any automated association with the FPGA item it will affect. Furthermore, none of the information or intelligence embedded in these artifacts are exposed to the broader audience. But most importantly, the logic of the FPGA is disconnected from the logic of the PCB on which it resides. Combining the two holds the potential to perform more realistic simulation. However, let’s hold off on that discussion for the integrated aspects post in this series.

Conclusions and Questions

In summary, there is a great amount of complexity in managing the design artifacts used to develop PCBs ranging from schematics, diagrams and layouts. They are each connected and change from one should propagate to the others. Today’s PLM and PDM systems manage these representations as an interconnected set, extracting the BOM from them, but infrequently extracting more granular information than that. From an FPGA perspective, most design artifacts are managed by PLM or PDM systems as unintelligent files. Instead, it is more frequent that the artifacts for FPGA programming are managed with Software Configuration Management (SCM) systems.

Time to sound off. What are you using to manage these artifacts today? Do you think PLM or PDM systems manage these design artifacts to enough granularity or is there still room for improvement? Weigh in and let us know what you think.

Mechatronics Management (Part 1): Mechanical Aspects

April 21, 2011 | Categories: Lifecycle Insights Projects, Software Applications and Systems

 

For the past three years, I’ve headed out to Phoenix AZ for the Congress on the Future of Engineering Software to talk with numerous providers and users of engineering software. The discussions are always pretty forward-looking, almost bleeding edge instead of leading edge. In the analyst briefing on System Modeling and Analysis, which was led by Allan Behren (who goes by the twitter handle @AllanBehrens), one of the engineering IT leader for For, Richard Riff, made a statement that made my ears perk up (the following is a paraphrase).

The Ford Fusion has 142 processors in it. We no longer split up systems for development, hand them off to various teams and then integrate at the end. We actually work a lot more like a software company where we compile builds on a weekly basis. Everything is so integrated we just can’t wait until the end of development anymore.

Richard, please correct me for any misstatements I might have made above.

From my perspective, Ford isn’t alone in this stance. There is so much software, processors and electronic systems in new products today that manufacturers are having to rethink their development processes. Which brings us to an interesting question: how can enterprise systems, like PDM and PLM, best support mechatronics development? Today, it seems like there’s an increasing focus on how all of the product’s items and the artifacts that describe them should be managed in one place. But there can be quite a wide range of support capabilities that are offered.

Let’s take a look at each level and understand the advantages and benefits of each.

This series of four posts looks at the management of items, data and bills of material for mechatronic products. It is split into mechanical aspects, electrical aspect, software aspects and integrated aspects.

Managing Mechanical Aspects of the Product

For the most part, the capabilities of enterprise systems like PLM and PDM in managing mechanical items, data and BOMs is one of the most mature in the context of a mechatronic product.

Managing Assemblies of Mechanical Components

Many CAD applications use what I like to call a federated approach to building up an assembly. Each mechanical component is often represented by a single part file. Those separate part files are then placed together to form an assembly, which is a separate file also. As those individual parts and assembly files change, you run into a configuration management problem. You need to know which version and iteration of each was used on a particular date for testing, a ramp-up run on the shop floor or was sent to a supplier. Most PLM and PDM systems extract and understand these relationships between these artifacts.

Managing Design Deliverables

Also, individual deliverables such as engineering drawings are separate files. These files have direct relationships to the parts or assemblies that they represent. And the same configuration problem that exists between part and assembly files also exists with their deliverables. Most PLM and PDM systems understand and manage these relationships.

Extracting Information for the Enterprise

In addition to managing configuration issues, the information in these artifacts are extracted and used for broader enterprise purposes. The structure within the assembly is often used to generate an as-designed bill of material (BOM). Additionally, the solid models of the assemblies or parts can be extracted for visualization purposes.

Conclusions and Questions

Today’s products are increasingly mechatronic. This series of four posts take a look at different aspects of mechatronics management. From a mechanical perspective, it is important to manage the configuration issues for the relationships between parts and assemblies, items and their deliverables such as drawings and to be able to extract information from these artifacts like BOMs and visualization models for the rest of the enterprise.

Now it’s your turn to weigh in. What’s missing in terms of capabilities for the management of mechanical design? Sound off and let us know what you think.

Point Solutions, Integrated Solutions and the Granularity Value Proposition

August 1, 2011 | Categories: Software Applications and Systems

A few weeks ago, I published a software review post titled Actify Centro and Microsoft SharePoint: The 3D Mashup. In it I looked at one of Actify’s new products and offered my perspective. A few days later, Oleg Shilovitsky published a post titled 3D Mashup – Reality Check where he laid out some of his own thoughts. We didn’t clash or disagree necessarily. But he offered up some alternative solutions from some of the traditional PLM providers. Which led me to a question.

Why would someone use a point solution instead of part of an integrated suite?

In the past, we’ve had some tried and true arguments both for and against going one way or the other. But actually I, and others based on their blog posts, have seen something of a change in the thinking of how to answer that question. I thought it was worthy of a post. So let’s discuss.

The Traditional Value Proposition of Integrated Suites

If you’ve been involved with software solutions for just about any amount of time, the logic behind these arguments won’t be anything new. One of the main theoretical advantages behind integrated suites is that they work together when they come out-of-the-box. You shouldn’t need an army of IT folks to stitch them together. And that should continue as new versions of these products are released, addressing the configuration management issue for the IT ecosystem you use to support your product development projects.

Now based on my experience, and this is where I’d like feedback in comments, I don’t think this value proposition has changed that much over the past ten years. Of course, there is the specific value proposition for the initiative you are facing. PLM change management should accelerate the time to complete an ECO. Global PDM should enable more global reuse, Follow-the-Sun design strategies and supplier participation. And so on. But the value proposition that would motivate you to choose something from an integrated suite instead of a point solution is that it’s integrated. And it should work seamlessly with the rest of the suite.

The Traditional Value Proposition of Point Solutions

Alternatively, the traditional value proposition behind point solutions have long been that they were best-of-breed. The idea here is that these point solutions offer more extensive and specialized capabilities than any integrated suite ever could. The logic here is that the smaller companies offering these point solutions were more flexible and agile, enabling them to respond more quickly, with less constraint and in a more innovative fashion than the larger companies that offered integrated suites.

But if you fast forward to today, from my perspective, I don’t buy it anymore. Many of the larger software providers offer integrated solutions that are almost or just as capable as most point solutions out there today. They have made so many acquisitions as well as organically developed so many solutions that they’ve caught up. Many of these larger software providers have also subdivided themselves into smaller and more agile groups or divisions that have narrowly focused in specific industries or fields of application.

The New Value Proposition of Point Solutions

So does that mean there is no real differentiated value proposition for point solutions? Should you just go out and jump into an integrated solution? Actually, my answer is a resounding not quite yet. I’ve seen quite a bit of momentum around a concept called PLM Granularity that has its roots in technology capabilities but has legs because of concerns about people’s careers. Let me explain.

PLM Granularity

So what’s the concept here? Actually, I originally heard about this concept from Oleg. And he’s written about it time and again at his blog beyondplm.com, but the fundamental idea is that you layer on different solutions that each do something very specific and well. Basically it is the point solution approach but from an ecosystem perspective. It would include something like leaving your workgroup PDM software in place. Layer on top of that a workflow. Then add some social computing solution for collaboration. Then you can add in a project management solution. You get the idea. Leave what you have in place. Add in other point solutions where needed. And integrate them as lightly as you can.

The Motivation behind PLM Granularity

So why take an ecosystem approach with point solutions? Well, I think the answer to that question is a whole lot more about someone’s history with PLM than anything else. You see, there’s a host of people out there that have championed a PLM solution. They introduced the concept to the company. They got it purchased by an executive. They were most likely the lead in getting it deployed. And it some of those cases, it failed. Not all. But not all PLM deployments are not successful. And that’s a detriment not only to the organization but to that champion’s career.

That has led some champions as well as some executives pledge a vow to never again pursue a large long scale deployment of PLM. They’re scared of it. And in some cases rightfully so. But they’re not willing to give up on technology as an enabler of better product development. They often still believe in that. So the most palatable means forward is a granular approach. Not because it offers better capabilities or will enable the organization to necessarily do more. But because it is far less risky, both for the organization and their careers. But ultimately, this is all about backlash against the big box approach to PLM.

Conclusion and Questions

The value proposition behind integrated solutions, besides initiative specific ones, has traditionally been that they are integrated in an out-of-the-box fashion. The countering value proposition for point solutions has traditionally been that they offered better best-of-breed capabilities, but from where I sit, that advantage has faded away. The new value proposition for point solutions lies with more granular solution in the ecosystem used to support product development. And the motivation behind that lies more in minimizing risk in individual’s careers than differentiated capabilities.

I’ve said my piece. And I have no illusions that you all agree with me. But I really would like to hear your perspective.

• Do you think the value proposition for integrated solutions is still just out-of-the-box integration?
• Do you think the best-of-breed value proposition for point solutions is dated?
• Do you think the motivation behind the granularity value proposition is career oriented instead of capability oriented?