Clarity on PLM

I had the chance to talk with … Kalypso‘s managing partner Bill Poston and new Kalypso partner Andreas Lindenthal about the recent merger of their companies. PLM implementation experts are in high demand, with most many “big name” consulting firms carrying small teams. In this case, two smaller specialists in product innovation and PLM are coming together to make an even stronger team.

What do they Do?

Kalypso is an innovation consulting firm. They help companies set the right strategies, develop the right business processes, and implement the right software to improve their product innovation performance. Kalypso specialized in a number of aspects of innovation including:

• Business & Innovation Strategy
• Front End of Innovation
• Portfolio & Pipeline Management (PPM)
• Development & NPI (new product introduction)
• Value Management
• PLM Technology
• Leadership & Learning
• Intellectual Property Management

Metafore is an very experienced PLM implementation consulting firm. Both firms have rich backgrounds in management consulting, systems integration, and PLM.

Benefits of the Merger

What is the value of the combined team? As I mentioned earlier, PLM consultants are in high demand. More importantly, it is often difficult to find good business consulting in this area. The largest consulting firms typically provide a large breadth of services (strategy, process definition, implementation, development) but lack depth in PLM resources. The smaller firms often have very deep PLM systems skills (although frequently in a single vendor’s system) but lack a breadth of consulting services. Kalypso offered both depth and breadth, even before the acquisition. So although Kalypso is a “smaller” consulting firm, they already had one of the largest independent PLM teams in the industry. The addition of Metafore extends that advantage.

But the new, combined entity is not just a bigger version of Kalypso. Instead, Metafore adds deeper skills in Siemens PLM solutions (namely Teamcenter) as well as more experience with smaller vendors including Aras, Arena Solutions, and Omnify Software. This complements Kalypso’s traditional strength in Oracle (Agile), Dassault Systemes (Enovia / MatrixOne) and PTC (Windchill). The merger also gives Kalypso more programming power, including access to offshore developers.

Who do they Work With?

Kalypso works with manufacturers of all industries, and has done some interesting innovation work in the service industries as well. The first time I met Kalypso in fact, was due to their unique expertise in PLM for CPG (consumer packaged goods) and the food industry. The addition of Metafore’s team provides Kalypso with more breadth in industries such as automotive, A&D, and industrial manufacturing.

Implications for Manufacturers

For existing Kalypso or Metafore clients, the merger will mean access to extended resources and a more capable partner. For those looking for product innovation or PLM expertise, the combined offering provides a compelling alternative to the big consultants that may not have the deep skills you need, or the small firs that may not have the breadth of services (or the top-tier talent) that Kalypso offers.

So that’s what I hear from the expanded Kalypso team, I hope you found it useful. What do you think? What else should I have asked them?

Note: In the interest of full disclosure, I am a paid member of Kalypso’s Board of Advisors. I don’t feel that I would have written the article in any different way if that weren’t the case, but I felt that disclosing this information was the proper thing to do.

What I learned this week … came from PLM Processes: Flowchart vs. Rule-based? from Oleg in PLM Twine. He discusses rule-based business processes for PLM, which immediately set off red flags in my head based on past experience. Oleg made me think about two different experiences I have in the same context, and it made me shudder. Why? I have seen rules go wrong too many times. And I have seen workflow processes go wrong just a many times.

Workflow Warnings

As Oleg knows, I am bit of a process weenie. Years at Andersen Consulting (the part that is now Accenture) will do that to you. I am 100% in favor of defining processes as a part of implementing business change and supporting technology. But here are some tidbits that I think are worth sharing:

• Define All Processes - Technology implementations should be process driven. Unless you define how the technology helps the business, you won’t get the most out of it.  
• Automate Some of Them - Not all processes should be workflows. While workflow is a great tool to automate and enforce processes, don’t overdo it. I have seen people implement workflow for workflow’s sake. It should be used as needed to improve efficiency and process adoption, but don’t workflow everything.
• Don’t Sweat the Exceptions – There are times where humans need to step in to make decisions and alter workflows. Don’t try to handle every exception condition. If you can identify them and send an alert, great. But most importantly make sure you have flexibility to alter a workflow based on business needs. This is where I see rules-based processes go wrong. Companies try to make rules cover too much, get too complex, and end up being hard to maintain, outdated, and eventually ignored.

The combination of workflow and rules can be very powerful, but can also lead to a resource sinkhole of if not approached cautiously. This is true for the process / rule authors and those that execute them alike.

Implications for Manufacturers

Define your processes. Use workflow where it makes sense. Keep it simple. Don’t try to do too much. Don’t forget that in many scenarios people make better decisions in context than any pre-determined set of rules can handle – don’t tie their hands. If you have standard operating procedures that you need to follow, you may need to document process exceptions. But don’t entirely lock them down in the system. Exceptions will happen, and if the system doesn’t accommodate the real world it will just happen outside of the system in an unmanaged way.

So those are my quick reactions to Oleg’s post, I hope you found it interesting. His post is worth reading if you haven’t already. But I get scared when I see the opportunity for things to go astray. And workflow and rules are a great candidate for bad things to happen. And this is from a self-admitted process weenie!

A quick peek into some research on … the technology behind PLM applications, and what today’s CIO needs to know to support it. The research from Tech-Clarity, Enabling Product Lifecycle Management: The CIO’s Guide to Supporting a PLM Initiative,  points out unique implementation and support challenges the CIO and their team must be aware of in order to get the most business value out of PLM.

The Research Findings

The CIO’s organization is getting more involved in PLM implementations. While many Engineering IT teams have managed CAD and other engineering software and supporting infrastructure, PLM is getting more attention from the enterprise IT team because it has become – (wait for it) – an enterprise application. I know, it only makes sense. Implementing enterprise class applications has different considerations than installing design tools, and enterprise IT typically has more experience with systems that span the organization and the supply chain.

Having said that, PLM is not ERP. Nor is it CRM, SCM, or any host of other business-oriented enterprise applications. PLM, by the nature of the processes and data it addresses, comes with some unique information technology challenges. Here are some of the considerations discussed in the report:

• Protecting IP – PLM data is concurrently highly confidential, and much more valuable when shared broadly. Intellectual property is more likely to be shared as collaboration expands, and a lot of that collaboration is outside of the control of the corporate firewall.
• Huge Files – Engineering and product development data is different than large volumes of transactional data. There are some potentially significant issues arising from managing and collaborating on large files in order to support PLM.
• Scalability – PLM is expanding to more people, a broader view of the product, to more of the product lifecycle, and supports more processes. Implementations needs to plan for expansion along multiple dimensions, which could potentially create an exponential demand on IT infrastructure.
• Architecture - PLM vendors are moving to enterprise architecture, providing support for the challenges above but also introducing new challenges. The good news, though, is that these challenges are ones that the many corporate IT groups have already addressed.

PLM also brings about integration challenges. Companies have to be ready to support frequent, bi-directional, real-time integration between PLM. If not in the first phase, potentially sooner than they think. See more on ERP-PLM integration in the Evolving Roles of ERP and PLM report and Mythbusting ERP-PLM Integration post. PLM integration with ERP and the rest of the manufacturing systems ecosystem is becoming more important and more prevalent.

Implications for Manufacturers

The good news? The PLM industry has learned from large scale PLM deployments, and has developed technology and best practices to address these issues. IT professionals today are not blazing the trail when they implement PLM. PLM is becoming much more mainstream. But it is also evolving to more of an enterprise application than just product data management (PDM), and moving into the enterprise realm. There is help available, from peer manufacturers that have undergone the transiiton and experienced consultants alike.

So that was a quick peek into some recent research on getting PLM technology right, I hope you found it interesting. Does the research reflect your experiences? Do you see it differently? Let us know what it looks like from your perspective.

Please feel free to review more free research and white papers about PLM and other enterprise software for manufacturers from Tech-Clarity.

I had the chance to talk with … Tim Frost of Burner Systems International (BSI) about their adoption of Product Data Management (PDM) to improve engineering and new product development performance. Tim explained to me that one of the primary goals for their adoption of PLM was getting a handle on their product data. But BSI also wanted to expand collaboration outside of Engineering and improve their time to market. The case study, Tech-Clarity Business in Focus: Burner Systems International – Improving Collaboration with Product Data Management, describes BSI’s experience from recognizing the need for action due to increased complexity in their business all the way through today’s benefits and plans for the future.

What do they Do?

BSI is a supplier to the OEMs that manufacture gas appliances. Like most suppliers, they compete very aggressively with their competition. They compete based on innovation, but most importantly on agility. They need to be able to react quickly to customer needs and bring the right component to market. Due to increased competition, growth by acquisition, and globalization BSI faced a huge challenge. As Tim tells me “We ended up with plants all over the globe, and we had to integrate engineering functions and data.”

What did they Do?

Recognizing the increased complexity, BSI took action. “You can use folders and you might get away with it for a while, but with multiple revisions you can’t manage it,” Tim explains. The solution was to implement a Product Data Management (PDM) system.  Just as importantly, they wanted to improve collaboration across departments. Tim describes how they implemented a PLM system (which includes PDM) that can be used by engineers and non-engineers alike. We discussed how departments like Quality, Manufacturing, Purchasing, and Sales get involved in the product design and development process.

What are the Results?

The new PDM system has shrunk cycle times and helped them make fewer manufacturing errors. According to Tim, those errors can cost up to $100,000 each. BSI is pleased with the results. “We know that we are faster in developing new products, I would estimate 25% faster,” Tim says. “We know that we are better prepared for launching production due to better input and collaboration from Manufacturing, and we know that we are less likely to make bad parts due to out of date drawing revisions.” The project is a success, and BSI is looking to further their gains by continuing to go beyond PDM to a more full PLM solution, leveraging the infrastructure they have in place.

 Implications for Manufacturers

 Burner Systems is a great example of a smaller company that desperately needed to get product data under control. At the same time, they have managed to achieve even more strategic benefits through collaboration and improved time to market. PDM is often the first step in a broader PLM Program.

So that’s what I hear from BSI, I hope you found it useful. What do you think? What else should I have asked them? A summary of the report is available from the Tech-Clarity site, and the full report is available for free from Siemens PLM, the provider of the Teamcenter Express software that BSI uses (and the sponsor of the report). Please feel free to review more free research and white papers about PLM and other enterprise software for manufacturers from Tech-Clarity.

I had the chance to talk with … Razorleaf during a research project earlier this year. Razorleaf helps manufacturers leverage PLM, Design Automation, and other enterprise technologies to improve product development and engineering processes. During the conversation, it was clear that they really understand how enterprise technology can be applied in an engineering environment. They are ready to step in and deliver the enterprise services required to implement PLM. But how much of the “PLM” ecosystem is really ready and capable to implement PLM? In my experience, too few.

What Razorleaf Does

Talking to the people at Razorleaf, I recognized the approach and skillset they use to implement engineering solutions. Yes, they know the products. But they also know how to help companies transform their processes, change their business, align their organization, and all of the other lessons learned from implementing systems like ERP and supply chain management. I recognize these in part from my research, and in part from spending a number of years with Andersen Consulting (now Accenture) implementing enterprise applications. These solutions require more thoughtful implementations than engineering tools, because improving the productivity of an individual is not enough. They have to improve the way the overall business works together. Not an easy task, but that is where the value comes in. This is what Razorleaf does.

How Razorleaf Fits in the PLM Ecosystem

Why did it strike me that they had this knowledge? Because too few resellers in the engineering software market have these skills. What comforted me, though, was that it is exactly those resellers that call on Razorleaf to help their clients. The good news is that the resellers know – or maybe it is their manufacturing customers – that there is more to a PLM implementation. This is likely the reason that other companies such as Kalypso (an innovation consultant with strong enterprise and PLM skills) is on the scene at so many PLM implementations. I find frequently that companies like these are pulled into implementations early on to help augment the skills of the software resellers (and even the vendors themselves).  It also helps explain the importance of a resseler like NovaQuest (a Dassault Systemes reseller with significant PLM experience)

Impliciations for Manufacturers

Why is this important to the manufacturing community?  If you are implementing PLM, make sure that those doing the implementation understand the different between implementing software tools (CAD, CAM, CAE, etc.) and enterprise applications like PLM. It can be the difference between a technically successful implementation that provides little or no business value (what I like to call a failure) and improving your business performance through the use of PLM technology.

So that’s what I hear from Razorleaf (with some additional perspective thrown in, I think it might be as much “What I Learned” as “One-to-One this time). I hope you found it useful. What do you think? What else should I have asked them?

I had the chance to talk with … several ENOVIA SmarTeam customers during my recent research. I talked with them for my paper on how mid-sized manufacturers have leveraged product innovation and PLM to get through challenging economic times and come out better during the recovery. See my Research Rap: Small to Midsize Manufacturer in an Economic Downturn? Innovate! for an overview of the findings from the study (along with a link to the study if you are interested). The customers offered some very good perspective on the use of PLM by small to medium-sized business (SMB), which drives home a point that often gets lost in the grander discussion of enterprise PLM. Smaller companies need the basics of PLM, without the overhead of a large “enterprise transformation” sized implementation project.

What do they Offer?

I wrote about SmarTeam in my blog on Manufacturing Business Technology earlier this year, so I won’t reiterate the basics of their offerings. Instead, I would like to focus on the needs of smaller companies and what I learned from the manufacturers I spoke to for the study. It actually matches up nicely with a recent blog conversation on PLMtwine on PLM Action Plan for Dummies.

What does an SMB Look for in PLM? Controlling Data

In short, the companies I spoke with were looking to gain control of their product data. In the PLMtwine blog, Oleg lists that as step number 1.  The driver for each of the manufacturers interviewed was different, but the need to find a way to quickly get their product data in control was key. For one lighting manufacturer, the business driver was a significantly depressed local economy and the need to move to a new market (both geographically, but also with a more sophisticated product set). For a manufacturer of ladders, the challenge was a significant financial setback in their business, the need to run very lean, and the extension of their business into a multi-site, global operation as they moved production to Mexico. Despite the driver, the need was a way to control the complexities of their product data in an easy way, and share product data across their organization.

What does an SMB Look for in PLM? Controlling Change

The next core capability that smaller companies were addressing was tightly aligned with controlling data, controlling engineering changes. I would normally say controlling “processes,” but in this case it was clear that engineering change (followed by release to manufacturing) was the big pain they were addressing with PLM (as opposed generic “process control.” Engineering change is a messy process in many businesses, and one that leads to manufacturing confusion and errors. Although I have been in recent conversations on the priority of developing a strong process versus applying technology to solve the problem, the truth is that both are very valuable. The companies interviewed all discussed the importance of the engineering change processes, and pointed to significant improvements through the use of PLM technology (ENOVIA SmarTeam in this case).

SMB Wish List for PLM

Smaller manufacturers have many of the same PLM needs as larger companies, but far  fewer resources to achieve them. So what does an SMB look for in PLM? Based on my interview with the SmarTeam customers, they were looking for:

• Rapid Implementation
• Ease of Use
• Pre-populated Best Practices
• Pre-defined Templates and Data Models
• The Ability to Start Small (and add new capabilities when they are ready for them, what I call a “PLM Program” approach)
• Stability and Ease of Technical Implementation
• Integration with Product Designs (CAD, for the most part)
• Easy Integration to ERP

So that’s what I hear from SmarTeam’s customers, I hope you found it useful. What do you think? What else should I have asked them?

I had the chance to talk with …Joel Lemke and his team at NovaQuest recently about their business plans and their strategy to help companies gain value from PLM. NovaQuest is a relatively new company, formed by IBM and Dassault Systemes veteran Joel Lemke (along with a host of other talent). Their quest is to help Dassault better implement Enovia PLM solutions, particularly in under-served markets such as small to midsize businesses (SMB) and “non-traditional” industries. This company has a lot going for it, and fills an important role in the Dassault Ecosystem.

What do they Offer?
To be brief, they offer product lifecycle management (PLM). In specific, the sell and implement the Enovia product line from Dassault Systemes (DS). On one hand, this puts them into a large pool of DS resellers. How NovaQuest sets themselves apart, however, is through a dedicated focus on:

• PLM as opposed to CAD
• SMB
• Non-traditional markets

The first point has a lot to do with history. Many of the DS resellers – really most CAD resellers – come from a very strong CAD background. When it comes to selling, implementing, and supporting CAD these companies have all of the talent and experience they need. CAD, however, is a tool. PLM, on the other hand, is an enterprise application. Without getting too far up on my soapbox on the differences, suffice it to say that the skills and resources you need to bring to a tools implementation are different than those you need to bring to implement and extract value from PLM. In my mind, it’s kind of like bringing a knife to a gun fight.

Who do they Work With?
The second differentiator that NovaQuest touts – aside from their PLM expertise – is their unique focus. Most of the early adoption of PLM comes from what I call “metal benders.” These are typically companies that center their product development process around complex, mechanical designs (and hence, a lot of mechanical CAD). Other industries, what the PLM market likes to call “non-traditional” PLM industries, focus their product development process on differently. Frequently, designing the supply chain is as important as designing the product. Product compliance typically takes a more central part. And the design may be centered around a formula or recipe instead of CAD model and bill of material (BOM). This puts even more emphasis on PLM as an enterprise application as opposed to a product data management (PDM) vault with some extra bells and whistles.

The third point of differentiation is based on company size. NovaQuest plans to help smaller manufacturers, the SMBs, achieve their PLM goals. I the same may that a lot of early PLM work was done in the “metal benders,” much of the early PLM success was in larger companies. NovaQuest plans to capitalize on the growth of PLM in smaller-sized manufacturers.

How does this Fit into the Ecosystem?
One of my firm beliefs is that targeting the right market is a critical component of success. That is probably true in any business, but I have lived through this personally in the software industry. The challenge is to balance addressing a differentiated, targeted segment of the market while still assuring a large enough population of potential customers. NovaQuest is clearly differentiating themselves based on their three-way focus on PLM, non-traditional markets, and SMB. I expect that they will do business outside of this niche as well, given that they have the experience and knowledge required for the more traditional PLM targets. With a combination of focus on flexibility, coupled with a strong team, NovaQuest is well positioned for success in the PLM market. It will be interesting to see how well they can capitalize on the opportunity.

So that’s what I hear from NovaQuest, I hope you found it useful. What do you think? What else should I have asked them?