CAD: Engineering Bundles vs. Granular Apps?

August 7, 2014


Packages, bundles, product suites, integrated environments. I’m sure you are familiar with these names. The debates about best of breed solutions vs. single-vendor integrated suites are going long way back in the history of CAD and PLM. Some companies are ready for functional trade-off and afraid of additional integration cost. For other companies performance and functionality are absolutely important to innovate.

Service oriented architecture and web technologies are bringing a sense of granularity into application and product world. In my view, Develop3D article – Why granularity is going to rock the future brings a very important perspective on the future of products. Al Deans speaks about granularity in data management. The complexity of product and data is growing. More people should work collaboratively on the same information (what was bundled before as a single CAD file). Here is my favorite quote:

When you’re working on a system that’s remotely located on a server, whether that’s over your internal network or across the wider web, you’ll need to manage and exchange finite packets of information, features, sketch entities and such. the rise of collaborative working systems, such as Catia V6, will mean that users are working on the same data, in parallel, at the same time. If not at the same time, there will be times when design changes, down to feature and maybe sub-feature level, will need to be managed and rationalised. To do that, you need to manage and keep track of those individual parcels of data and oackets of change. That’s going to require a level of granularity that’s way beyond what most data management systems are currently capable of.

Last year I watched Tech4PD video capturing debates between well known PLM pundits – Jim Brown and Chad Jackson – CAD Granularity vs. Integrated Suites. Navigate here to watch the recording. I voted for granularity. It was well captured by Chad Jackson statement. Here is the passage:

Granular CAD applications enable many roles in the enterprise, expanding the use of the 3D asset company-wide. Granular apps are better at enabling individual roles.

Latest blog post on Lifecycle Insight (again by Chad Jackson) – No More Excuses: It’s Time to Merge MCAD and ECAD caught my attention by something that I see as opposite to principles of granularity. Chad is debating the need to bundle and unite the functionality of MCAD and ECAD applications. I found his conclusion in a slight controversy with previously introduced concept of "granular CAD applications":

Why are there two separate toolsets at all? And that’s where, despite the lack of enthusiasm and interest in the topic, I think there is potential for disruption and innovation. There shouldn’t be two toolsets. You should be able to conduct mechanical and electrical design in a single CAD application…. Call it Hardware CAD (HCAD). Call it Electro-Mechanical CAD (EMCAD). I don’t care. But don’t tell me such an offering wouldn’t be intriguing. In my eyes, there is no reason that a combined MCAD-ECAD application shouldn’t be available. Large existing software providers have their reasons for inaction. But that means there is a ripe opportunity for disruption from smaller companies.

I want to elaborate more about the last point related to disruption and innovation. I explained my point of view in the blog post last year – The Future Unbundling Strategies in CAD/PLM. I want to repeat some of my assertions from the last year:

1. CAD and PLM is too big to sustain as a one big aggregated solution provided by a single vendor. This is a polystate diversified space that needs to be covered by multiple solutions, features and vendors.

2. Vendors are never good enough to see what exact problem customers want to solve. Especially when it comes to large manufacturing companies and complicated supply chain eco-systems. That’s way armies of consulting services as well as diversified products must be applied to provide a final solution.

3. Customers often don’t know what problem to solve. For most of the situations product development is a complex problem. It requires the team of people to work on. In addition to that, large organizations are involved into politics and confrontation related to usage of different enterprise software and tools.

What is my conclusion? I see a very strong potential in unbundling of existing large product suites. Take a piece of functionality, re-invent it, provide bigger value to a customer. Cloud technologies and future focus on data will be an imperative to make it successful. Vendors’ focus is shifting towards services. It is about how to satisfy customers each day. Selling of expensive bundles can be a thing in the past. Just my thoughts…

Best, Oleg

Thoughts about PDM/PLM jumbos and PLM glue

December 10, 2013


PDM v. PLM. This topic is usually raising lots of questions. Still is… People are getting confused by names and functions. Few years ago, I wrote 3 posts comparing PDM and PLM from different aspects – data, process and integration. Recently, Chad Jackson made me think about PLM and PDM topic again by his write up of Enovia capabilities. You might read my PDMish, PLMish and other CADPDLM bundles following Chad’s post.

Aras blog is bringing PDM v PLM topic again. Navigate to PDM or PLM? Yes. story by Peter Schroer – CEO and President of Aras. Peter draws a clear functional line between PDM and PLM. The following passage put all "dots" in comparison between D and L in product development.

PDM doesn’t provide product configuration management (effectivity) or enterprise process management. It doesn’t keep the design in synch with product workflows or requirements management, it doesn’t manage non-CAD and non-file based data very well, and it doesn’t track where that part or assembly fits in to the entire system lifecycle process. While PDM is useful, it doesn’t help make supply chains more efficient, it doesn’t improve quality or customer satisfaction, and it doesn’t help increase revenue.

The recipe I captured in Aras’ blog is suggesting PLM to play the role of glue that connect PDM (engineering) and extended enterprise (rest of the company).

PLM, or product lifecycle management, is the glue between PDM and the extended enterprise. PLM takes product data and puts it in the correct context for each user. For some users the CAD file is the center of their universe, but for many others CAD-based data is just a small subset of the entire set of product information they work with.

The last things about "glue" made me think about future integration strategies in PDM/PLM world. It was a time when everybody had a dream of a single PLM system used by everybody in the company providing a holistic set of functions. However, nowadays the number of "single PLM" believers are going down.

So, what comes next? Few weeks ago, I’ve been discussing the idea of Future unbundling strategies in PLM. Thinking more, I can see future separation of giant systems into small services as something more feasible. I can see how small features and functions are getting traction in a company to fulfill a specific need – change management, configurations, engineering BOM, etc.

What is my conclusion? I can see more tools and service diversity in the future. It is very hard to provide ready to go out-of-the-box set of functions. Compared to that, I can see set of services to make product development, collaboration, data management and communication more efficient. Some of tools can be cloud- and some of them – on-premise based. Social platforms will play a role of one-big-system-glue. Just my thoughts…

Best, Oleg

Why cloud won’t solve CAD/PDM/PLM integration problem tomorrow?

October 17, 2013


All roads lead to Rome. Sometimes, I have a feeling whatever discussion happens in CAD, engineering and manufacturing world, it will lead to PDM and PLM. My earlier conversation about pros and cons of having special CAD file sharing tools started here, ended up on GrabCAD blog by Hardi Meybaum here with a conversation about what system should be used in organization to manage data, users and workflows and how to integrate these systems. Here is the passage:

In addition to the cons Oleg brought up I actually see a bigger issue – integration. A good thing about a generic/horizontal file sharing tool is that everyone is using the same system so it’s easy to manage data, users and workflows. Conversely, a manufacturing company might have someone who only needs to access very specific CAD data once or twice a quarter. Does this person really need access to your manufacturing-specific tool to get it? I think overcoming this problem is going to be an important obstacle to address in the next 3-5 years.

Another interesting point raised by Hardi, was the role of VAR is changing cloud/SaaS software role. In the past I discussed the future of PLM VARs last year here – What is the future of PLM VARs? My main point was that technical experience will become one of the main differentiation factors for future SaaS VARs. GrabCAD blog practically in the same way.

The benefit of VARs repositioning within the CAD space is that most of them have offered value implementing rather complicated engineering systems to customers already. They understand the customer well and have software knowledge within the company. I believe the new model for VARs in the next 5 years will be reinvention – some will become software companies providing specific integration like Zapier and others will focus on very specific workflow integrations between horizontal products.

However, let me get back to CAD, PDM, PLM and integration topic. While CAD File Sharing is highly demanded by almost all organizations these days, customer requirements are moving very fast from pure need to share information to questions and requirements how to control CAD data and manage change processes.

In the early beginning, PLM vendors and implementers were trying to get deep associations with CAD roots. This is not true anymore. One of the latest trend is to focus PLM on the business level of the company and how to improve company business processes. In one of my early articles CAD data and PLM, I described this position talking about CAD Rootless PLMs and importance of integration between CAD and PLM.

At the same time, the center of integration gravity is still positioned on integration of CAD and PDM. The complication of this type of integration is related to multi-CAD nature of CAD data. Companies are using different CAD systems. Some of CAD systems can dominant, but you always can find data from multiple CAD systems in every organization. GrabCAD post mentioned that as well. In the early days, PDM vendors were focusing on how to develop plug-ins for every CAD. This is still true for many vendors. However, next trend, in my view, would be future openness of CAD systems toward providing interfaces integrating to many PDM systems. You can read more about it in my post – Multi-CAD integration: Yesterday, Today and Tomorrow .

Last, but not least topic is related to Cloud/SaaS solutions. This is a place where Hardi Meybaum of GrabCAD believe the most. Here is an interesting passage from GrabCAD post:

It will only be solved once there is enough adoption in the general market for the next generation of SaaS CAD tools like GrabCAD Workbench, Autodesk PLM360, TeamPlatform. At that point the integration challenges will evolve.

I can see a clear point of movement to the cloud / SaaS trajectory. However, in my view, despite a significant growths in design domain, co-existence will be probably the right word to describe the reality of coming few years. I want to stress this point – CAD will be the latest application in the list of PDM, PLM and other business services to move to the cloud. What is interesting to me is how vendors are going to support this “cloud transition”. Companies clearly won’t be able to move all in a single shot. You can take a look on how I can see a transition in my blot post – PDM/PLM Evolution: Final Step and Cloud / On-Premises Integration.

What is my conclusion? Integration is a complicated and important topic. However, to think integration will disappear with movement to the cloud is too naive position. Cloud/SaaS can clearly simplify some technological aspects of integrations. However, the complexity of design, data management and processes in an organization will be very hard to overcome only by the change of technological foundation. The "transition phase" will be another reason why vendors and customers will have to deal with integration for coming decade, at least. Just my thoughts…

Best, Oleg

3 steps how to put PLM / ERP each in their place

March 14, 2013

PLM and ERP integration. Endless topic. My PLM blogging friends – Chad Jackson and Jim Brown decided to discuss it again at their Tech4PD video blog. Even if it is presented as a debate, I found much more similarity between their statements about PLM/ERP integration rather than differences. They both agree PLM and ERP systems are taking a big part of engineering information environment, both systems are important, PLM and ERP are complimentary in terms of their business functions.

There are differences in the positions, of course. Jim is advocating for single source of products data integrated with ERP, CRM and other systems. PLM is the master of product data. From Jim standpoint, the data from PLM system is integrated and represents as product master data to all other data management systems. Chad agrees, the integration needed, but think low-touch integration is more secured and can be less risky. His (Chad’s) opinion is that total integration proposed by Jim is a too big shot to take. Chad advocates for simple integration and so called "one time information push". From Chad standpoint to keep integration simple is an easier and less risky path to integrate data. If you have few minutes, I’d encourage you to watch the video for few minutes (especially if you want to see how Jim takes a swim with polar bears).

So, a simple conclusion after 7 min of video – data needs to be integration between PLM and ERP. Well, it gave me sort of disappointment. Ask anybody in the industry they will tell you about needs to integrated information between PLM and ERP. I like the way Jim present the need – we have to have a comprehensive solution. At the same time, Chad put it down in a very pragmatic way- complex integration won’t work. We need to have something simple in place. The debates between Jim and Chad made me think about possible steps to resolve the complexity of integration between PLM and ERP.

1. Move from "data ownership" to "data publishing". This is an important shift. Enterprise system integration people spent decades debating "data ownership" topic. It is all about "master" and about how to establish a logic of data ownership. The concept of data publishing takes the data ownership upside down. You shift the focus on how to use data. The access can be provided using multiple ways (APIs and variety of data formats). My personal preference to use linked data and RDF/RDFS model (format) for that purpose.

2. Move from "data mapping" to "data description and connection". In other words, link everything. In the original concept of data integration (Chad called it "data push"), the focus is on how to map data located in one system to another system. The whole purpose is to take data in one system, convert (map) and put in another system. After you accomplished "data publishing" concept, you don’t need to transfer data. You just find right data using model qualifiers. It simplify the business logic and helps to establish more reliable data integration mechanisms.

3. Include links to data elements from other systems. Think about this option similar to links on web pages. If you need to extend data or navigate to related data, you just follow the link, which takes you to the right place.

What is my conclusion? I can see PLM and ERP integrations fail in many companies because it relies to old and outdated integration principles. These old principles relies on data ownership and business of protecting data in a boundary of enterprise applications. It is going to change soon. The new one doesn’t move the data while provide an open and reliable mechanism to build an integration system similar to web. Just my thoughts…

Best, Oleg

PLM and Global Product Development Strategy

December 13, 2011

Manufacturing business become global even for very small companies these days. It is not unusual to see a company of 100-150 employees having multiple locations using suppliers world wide. How these businesses can survive globally and what systems they need to use? What solutions are available today to support global product development? I decided to put some thoughts about that as well as share some articles related to this topic I had a chance to read earlier this week.

Global PLM system deployment

To support global product development is one imperative objectives for every PLM software provider. Obviously, PLM mindshare vendors are thinking about that. Navigate your browser to the article in Cadalyst few days ago – Break Down the barrier to Global Product Development written by Brian Shepherdof PTC. Brian’s view on global product development and role of PLM can be summarized in the following passage from the article:

Product lifecycle management (PLM) is a key component of GPD. PLM enables geographically dispersed individuals and groups to work collaboratively on products and product development processes through a seamless, integrated information flow.

I found the notion of "integrated information flow" interesting. Later in the article Brian is talking about 5 challenges to achieve global product development – distributed design, collaboration across the enterprise, share data securely, manage complex programs, manage change and achieve scalable performance. The approach PLM mindshare vendors are proposing (and PTC is clearly one of them) is to organize a single environment for people to work collaboratively.

The question I wanted to raise and discuss is how to drive global deployment of such a complicated system as PLM across multiple locations, divisions and departments. This is can be a multi-year complicated and expensive project. None of the challenges mentioned in Cadalyst article are covering this topic, and it surprised me a bit. One of the main problems I see is related to a nature of heterogeneous environment in every global organization.

The Reality of Heterogeneous environments

The global organization is normally heterogeneous. The reason for that is related to the fact how most of global organizations were created. I can see two typical cases – establishment of remote manufacturing facility or acquisition of another company, which includes both engineering and manufacturing functions. In both situations, the biggest problem is to integrate multiple heterogeneous systems into a single one. Alternative is to keep working systems for some time and establish a new system gradually. This process can be complicated and expensive. In many situations, companies are leaving with existing systems for a very long period of time.

Global Part Numbers and Global Development Strategy

Thinking about how organization can shift successfully to a global model, I’m coming with my 3 elements of potential global development strategy:

1 – share data across locations;
2 – establish global identification for items and documents
3 – integrated engineering and manufacturing environments

Steve Amman of Zero-Wait State wrote about why use of intelligent part numbers is a wrong way to think about when you want to establish a global environment. Here is an interesting passage from Steve’s post – What is so difficult about product development strategy? Let’s start from Part Numbers…

The old way is to try to create or use an existing divisions “intelligent” part numbering scheme that was set up before we had modern PDM, PLM and ERP systems. Part numbers can be coded with prefixes and suffixes to represent different part types, product lines, and commodity codes and a whole bunch of other translations for the numbers so they can be organized mostly on a spreadsheet. The more information you are trying to code into the part numbers, the more you trap yourself into this old methodology.

As an alternative, Steve is proposing to use the power of PLM meta data to classify information instead of intelligent part numbers. This is can be a complicated goal if your global PLM environment is not established yet. An alternative to this approach can be the establishment of sharing network with the information resided into existing systems.

What is my conclusion? I think, global product development startegy is hard. I can see companies are working years to achieve that. Even very well organized companies are crashing to deliver the results in a short period of time. Taking steps into sharing data, create an overall identification and integrate two most complicated systems – engineering and manufacturing can take a company in the right direction. Just my thoughts…

Best, Oleg

Autodesk, Aras and Integrated PDM / PLM story

December 7, 2011

Back to the beginning of this year, I came with the post – Integrating PLM and PDM. Wrong question? My initial thoughts about integrating PDM and PLM was driven by growing interest to integrate existing software assets in the companies. However, thinking more I can see some additional aspects of PDM / PLM integration in a longer-term perspective. Few weeks ago, I postedFrom PDM to PLM: Unify vs. Integrate. I can see some examples of "integrate trend" happens now. I wanted to discuss two examples. Both Aras and Autodesk, in my view, are trying to integrate existing PDM systems with agile and flexible PLM environments.

Aras Enterprise PLM

If you haven’t had a chance to review it, Aras EPLM is a new packaged offering coming from Aras and expanding SolidWorks Enterprise PDM horizons by providing additional process oriented applications in Aras PLM. I recommend you to take a look on Aras EPLM on-demand webcast. Based on the information I found on the website, the functional scope of Aras EPLM related to Item and BOM Management, Product costing, Supply Chain processes, Project management and Change Management.

The clear strategy of Aras is to provide a complementary solution to SolidWorks and EPDM. I believe SolidWorks customers are looking for this solution as the opportunity to keep SolidWorks EPDM, to have an additional functionality and eliminate probably more expensive and unclear migration towards future Enovia V6 solutions DS is planning to deliver in the future.

Autodesk Nexus PLM

Another interesting example that just came last week – Autodesk made the announcement of Nexus PLM. Thre is little information and hands-on experience available about Autodesk PLM. You can navigate to my earlier posts aboutAutodesk Nexus PLM and Autodesk PLM strategies. At the same time, from the top slide presented by Steve Bodnar, Autodesk VP of PLM, we can learn that Autodesk is building their PLM strategy as a combination of two products – on-premise PDM (Autodesk Vault) and cloud based future product (Nexus PLM).

Looking on the scope of solutions Autodesk is promising to deliver as part of Nexus PLM, you can see some similarity with Aras EPLM Solution.

PDM / PLM Integration: pros and cons

If I think about possible advantages of combined solutions PDM+PLM, the one that stands clear to me is the interest to leverage existing software assets and re-use implementations cost already made by customers. When I think about the way Aras and Autodesk articulate what they do, I can see lots of similarities.

In that context, the cost of integration between PDM and PLM becomes one of the most important elements. Mindshare PLM vendors like Siemens PLM and Dassault are driving customers towards unified solution. They are trying to convince customers that unification will reduce the total cost of ownership and optimize the implementation. At the same time, if cost of integration is low, the type of solution proposed by Autodesk and Aras can have some grounds.

What is my conclusion? PDM / PLM integration looks like an interesting trend. We are going to see to see more examples, in my view. What is the fundamental reason behind it? I think many companies are having trouble to drive their IT infrastructure towards unification. It requires longer projects and expanded budgets. If PLM companies find an efficient way to integrate and access data between systems, it can definitely provide a competitive advantage on the market. Last one cannot be guaranteed, but it sounds as an interesting opportunity. Just my thoughts…

Best, Oleg

Image: dan /

Total Integration and the Future of PLM

August 12, 2011

I’m still cleaning my post-vacation backlog of feeds and messages. One of the articles by UK Eureca Magazine caught my attention, since it was named exactly as my blog – Beyond PLM. This article is an interview with managing director PLM Software, Robin Hancock about the company’s vision for the future of PLM.

One of the main topics discussed in the article was a topic of "integration" or so-called "total integration". Here, my favorite passage:

Charting the development of PLM, Hancock says, "In the old days it was all about product design. Now, while you’re designing and developing the product and getting people to collaborate around it, you’re also designing and developing your plant and your manufacturing capability concurrently. Because the pressure is to get more competitive, more highly configured products to market at a lower price and higher quality, more quickly, doing those things concurrently is the next big value proposition for manufacturing and engineering companies. But change is difficult and the last thing you want is some ‘big bang’.

Siemens PLM is planning their future HD PLM approach to help realize the potential of the total integration. Here is a visionary video Siemens PLM released a year ago:

The discussion about "the total integration" and "big bang" approach made me think about the following 3 trends I can see in a modern PLM technological and application development: Multiple System Approach, Vertical Integration and Continuous Implementation.

Multiple System Approach

The reality of manufacturing companies is simple – people stopped believing in a single system that solves all problems. Businesses understood that they need to have a blend of systems representing their unique approach of running product development. I can see multiple reasons why it happened. Among the most important ones I can see system complexity, implementation cost and high demand for fast ROI.

Vertical Integration

Customers have a strong demand for vertical integration. The days were systems could work disintegrated finally over. The question of integration between design,manufacturing, supply, execution and other elements of the overall system chain is obvious and businesses are ready to spend a lot of resources to make it work.

Continuous Implementation

This trend related to the potential implementation cost. The demand of users is to drive this cost down as much as possible. Opposite to a ‘big bang’ approach, this one is focusing on how to implement multiple small projects into a sequence of successful deployments.Each has their own cost, ROI value proposition. All of them together allows to decrease the overall implementation cost and project risks.

What is my conclusion? It seems to me, the understanding of the "integration value" is important to successfully implement PLM systems. This is not a short term project, but a long journey. I think, in the past "integration" was a "step child" in PLM product family. PLM companies focused on their own product lines and dismissed integration opportunity. However, future is integrated. Just my thoughts…

Best, Oleg


Get every new post delivered to your Inbox.

Join 260 other followers