Why PLM stuck in PDM?

April 5, 2014

plm-stuck-pdm-round-square

I’ve been following CIMdata PLM market industry forum earlier this week on twitter. If you’re are on twitter, navigate here or search for #PLM4UM hash tag on twitter. The agenda of PLM forum is here. The following session discussed one of my favorite topics- PDM v PLM. PLM: Well Beyond Just PDM by Peter Bilello. This passage is explaining what the session is about

CIMdata’s research reveals that leading industrial companies are looking to expand beyond PDM functionality to truly enable a more complete PLM strategy. This becomes even more important in a circular economy. In this presentation, CIMdata will discuss which areas are most important, and what opportunities they create for PLM solution and service providers.

My attention was caught by the following tweets coming from this session:

According to CIMdata, leading Mfrs are now looking to move beyond PDM. #PLM4um
— ScottClemmons (@ScottClemmons) link to tweet.

Peter B / CIMdata explains that it’s hard to find a ‘real’ end-to-end #PLM implementation hat works #plm4um
— Marc Lind (@MarcL_) link to tweet.

It made me think why after so many years of PLM implementations, most of vendors are still solving mostly PDM problems for customers and it is hard to move on into broad downstream and upstream adoption of PLM beyond CAD data management functions. Here are my four points explaining in a nutshell why I think "PLM stuck in PDM".

1- Focus on design and CAD.

Most of PLM vendors historically came from CAD-related domain. Therefore, PLM business for them was the expansion of CAD, design and engineering business. As a result of that, use cases, business needs and customer focus were heavy influenced by design domain. The result – PDM focus was clear priority.

2- PLM is a glorified data management toolkit

The initial focus of many PLM systems was to provide a flexible data management system with advanced set of integration and workflow capabilities. There are many reasons for that – functionality, competition, enterprise organization politics. Flexibility was considered as one of the competitive advantages PLM can provide to satisfy the diversity of customer requirements. It resulted in complicated deployments, expensive services and high rate of implementation failures.

3- Poor integration with ERP and other enterprise systems

PLM is sitting on the bridge between engineering and manufacturing. Therefore, in order to be successful, integration with ERP systems is mandatory. However, PLM-ERP integration is never easy (even these days), which put a barrier to deploy PLM system beyond engineering department.

4- CAD oriented business model

Because of CAD and design roots, PLM sales always were heavily influenced by CAD sales. Most of PLM systems initially came to market as a extensions of CAD/PDM packages. With unclear business model, complicated VARs and service companies support, mainstream PLM deployment always focused on how not to slow CAD sales.

What is my conclusion? Heavy CAD roots and traditional orientation on engineering requirements hold existing PLM systems from expanding beyond PDM for midsize manufacturing companies. The success rate of large enterprise PLM is higher. But, it comes at high price including heavy customization and service offerings. Just my thoughts…

Best, Oleg


How to make PLM UI less terrible?

April 3, 2014

handwritten-BOM

I’m coming again to this topic – User Interface. These days you can hear about it as user experience (UX). UX is more complicated thing and includes lots of factors and aspects. So, I’d like to speak first about how UI looks. Back in time when I was developing and demonstrating PDM user interfaces, the worst thing was to get in line after somebody presenting CAD and visualization software. Their UI are always looks good. It was obvious, since they can show all these cars, phones and airplanes… Opposite to that, PDM user interface is all about tables, list and values. The nature of PDM system makes this type of UI boring and not interesting. For example, take a look on the photo above. This is handwritten BOM of locomotive made almost 100 years ago (image credit) . It doesn’t look nice, but it is absolutely "must have" document in manufacturing.

To change UX concept is a complex things. It requires to make a lot of changes in the way people performing their tasks. For engineering, manufacturing and enterprise organization is a big thing. However, what about to make a change just in a way PDM / PLM UI looks like?

The following image by darkhorseanalytics caught my attention with the presentation how to make table looks less terrible. Take a look on the power of "less is more". It comes as a sequence of remove colors, remove gridlines, remove fills, remove the border, remove bolding, left align text, right align number, align titles with data, resize columns with data, put whitespace to work, use consistent precision, round the numbers, remove repetition, no more Calibri font, add back emphasize.

So, here is the table before:

table-nice-ui-before

… and here is the table with UI improvements.

table-nice-ui-after

Not sure about you, but I like the comparison and the result.

It made me think about how many places in PDM UI is actually requires clean table presentation. Think about drawing reports, bill of materials and many other things. To make them look clean and fresh will improve to visual impression about PDM product.

What is my conclusion? It is very hard to design nice and clean UI. Every company developing software applications these days must focus on how to make the UI less terrible. The ugly and annoying enterprise software UI is a thing in the past. The new UI will be designed with the a different state of mind and thinking about modern web and mobile user interface and experience. Just my thoughts…

Best, Oleg


Bill of Materials (BOM) Management: Data, Lifecycle, Process

April 2, 2014

BOM-data-lifecycle-process

In my recent post about bill of materials – Bill of Materials (BOM): process or technology challenge? I touched the variety of topics related to BOM organization – multiple BOMs and need to manage BOM located in different systems. My main question at the post was around how to make the work with multiple BOMs easier? The problem is tough and the answer is not easy and straightforward. While I was googling the internet to find what others think about this problem, my attention caught TeamCenter PLM blog post – Bill of Material Lifecycle. This posts presents multiple BOMs as a result of changes in the product lifecycle – design, manufacturing, service. Here is a passage I captured:

It is interesting to discuss on BOM lifecycle and its evolution from conceptual stage to full fledge manufactured product to maintenance. In this blog I will explain through life cycle of BOM across the product life cycle done as in house development. The BOM lifecycle can varies based on overall process of company for example some company might only manufacture as order hence they As Build design BOM and they directly CREATE Manufacturing BOM from it.

All together, it made me think that concepts of data, lifecycle and process is often can create a confusion and overlap. I want to clarify these concepts and present how they can be combined together to manage single BOM in the organization.

1- Data

Data is the most fundamental part of Bill of Materials. It combined from data about product, assemblies, parts and relationships between them. Fundamentally, assemblies and components are connected together to form the result data set representing a product. This data set can be presented in many ways – tabular, hierarchical and many other forms (eg. graph). Data about parts leads us to the place where information about product, assemblies, components, supplies and manufacturers is managed. This information can reside into one of the following systems – CAD, PDM, PLM, ERP, SCM and others.

2- Lifecycle

Lifecycle defines the difference between bill of materials of the same product, but associated with different product development periods (stages). Here is the example of some typical stages – concept, design, manufacturing, service. However, these stages are not the same for many companies and can reflect industry, specific business practices, regulation and many other aspects. It is very important to capture relationships between Bill of Materials of the same product (assembly) in different lifecycle stages. Missing lifecycle stage connection can cause a lost of very important product lifecycle information and product development traceability. In some regulated industries such

3- Process

Process is a set of activities that defines Bill of Materials data as well as changes in a lifecycle. Sometimes process can be very informal- save of assembly and parts using design system. It will product design BOM data. However, with the complexity of product development and specific organization, some processes are including changes of data, lifecycle stages as well as people involvement. If you think about ECO process, it might change few bill of materials, lifecycle stages as well as product/part information.

What is my conclusion? The problem of bill of materials management must be separated into three distinct problems: 1/ how to create data with BOM? 2/ how to control product dev stages and differentiate the same BOM across the lifecyle; 3/ how to provide tools to manage process and people to work with data and stages. All together, the problem is complicated. However, separated into these pieces it can help you to build a strategy for your BOM management regardless on tools you are going to use. Just my thoughts…

Best, Oleg


Why and when to re-think PDM?

March 10, 2014

re-think-pdm

PDM (Product Data Management) isn’t a new discipline. Nevertheless, I think, PDM is going through the time of disruption and renaissance. Cloud, social and mobile technologies are changing the way we’ve been working in the past. From that side, I can see companies that trying to re-invent PDM with a new meaning and technologies. I’ve been discussing it few weeks ago in my post -Do we need a new TLA for PDM? On the other side, analysts and established CAD and PLM vendors are trying to restate the values of PDM solutions.

One of PDM value proposition "restates" just came across my reading list over the weekend. PTC Creo article PDM Capabilities: The Right Fit for Small Organizations written by Chad Jackson of Lifecycle Insight. Chad separates PDM into 3 distinct sets of data management capabilities: CAD Data Management, Engineering Data Management and Enterprise Data Management. I captured the following passage about CAD data management.

If a team is working simultaneously on a single design, CAD data management provides a means to control the chaos. Oftentimes, one design is dependent on another design, which can fall under the responsibility of two different designers or engineers. Without some means of tracking and controlling that change, individuals can quickly lose track of what their peers are doing.

However, I specially liked the recap:

CAD data management is a no-brainer for organizations of any size. Engineering data management is a natural fit for small organization as a means to organize the chaos of engineering. Enterprise data management, while beneficial to some organizations, is not worth the effort for smaller companies. The cost is not worth the return.

The article made me think again about current state of PDM. The challenging part of PDM for the last 20 years was to justify the cost of implementation and use of PDM combined with complex engineering workflow. Engineers don’t like data management. I was talking about it many times. For most of engineers, PDM is a software that slow their work and make their life complicated. Think about an engineer waiting until updated files is synchronized from the server in the morning or release of new 3D models is taking next 15-20 minutes. To put it gently, these examples are not very rare in CAD data management eco-system. Nevertheless, I’ve seen several PDM systems in the past 15 years that succeeded to find a decent balance of value vs. disturbance to engineers. Another aspect of PDM implementation is cost. For many (especially small) organizations, the cost of most existing PDM implementation is too high. Therefore, we still can see lots of organizations managing CAD files using shared network folders and excel spreadsheets.

I want to come to questions from the title of this post – why and when companies may decide to re-think their existing PDM strategies? I’d like to separate all options in the three groups: 1-we don’t need PDM; 2-we need PDM, but it is too costly; 3-PDM is part of larger PLM/Data management strategy.

1- We don’t need PDM.

This is a typical situation in very small engineering firms or micro-engineering departments in large companies. The status quo is okay for them. They are busy with everyday tasks and don’t want to look on new tech. What can make them to re-think PDM? In my view, it will come with the influence of external factors. Web, globalization, speed of changes and other factors can turn these companies to think about PDM values.

2- We need PDM, but it is too costly.

I can see many medium-size companies in this category. Usually, they outgrew their network/file sharing capabilities and have a pressure to make some order in data management. However, for some reasons budget restrictions and value/cost justification make them feel wrong about current PDM solutions. One possible solution for these companies is to buy PDM systems bundled with CAD system they use. It will be probably the most cost effective. For many of these companies CAD-PDM bundle will be a decent solution to solve their problems. However, another option is "to re-think" and bring new PDM solution with lower TCO and improved workflow for engineers.

3- PDM is part of larger PLM/Data management strategy.

Mostly large companies are coming into this category. For them, PDM is a part in the overall solution puzzle. These companies are looking about overall business processes, connectivity, multiple systems and global IT cost. These companies can be good partners to work for the future. Some of them can be good thinker how to re-invent PDM. However, don’t expect fast decisions here. To establish right strategy for them is an ultimate priority.

What is my conclusion? In my view, PDM is going to change. However, the speed of changes in engineering and manufacturing industry is very slow. Therefore, don’t expect everything to change tomorrow. Existing systems will keep serving us for coming years. At the same, time new systems potentially can make engineers’ life easier. The focus on improvements of engineering workflow and longevity of solutions is something you should consider when analyzing opportunity to bring new or change your existing PDMs. Just my thoughts..

Best, Oleg


Part and Document Management: Why is it Complex?

March 8, 2014

parts-documents-management-plm

Parts and Documents are two different objects in engineering, product development and manufacturing. While “part” usually represents physical object, “document” usually represents specification, drawing or 3D model of part. Even it it sounds obvious, Document and Part management is not an easy and simple task.

In my post – How to manage Document versions, revisions and Part numbers, I’ve been mostly speaking about the need to have separate numbers for documents and parts. I also mentioned that bad practice to use the same numbers for both document and part, can lead to significant complexity and mistakes. At the same to implement a system or multiple system to manage Documents and Parts is complicated. Below I described potential three typical configurations you may find in companies related to document and parts management.

No PDM

Even PDM is not very new technology, you can still see many companies that not using PDM. If this is a case, you have a good chance to see documents (CAD and non-CAD) spread out in the network and shared drives. Without centralized document management system, a company is creating numbering convention how to provide document numbers. A good chance that you will see lots of Excel spreadsheets to be used for Parts and BOM management. Very often, a company will be using similar number convention for parts and mix it together with usage of OEM and supplier part numbers. You can also see homegrown system to manage Part Numbers in a separate database.

PDM + ERP

This is very typical situation where engineering and manufacturing are splitting responsibilities into silos. Engineering department is using PDM system (very often from the same vendor as CAD system) and manufacturing (as well as rest of the company) is using ERP system. Within this schema, PDM system is taking control of documents. Document numbers usually generated by PDM system according to predefined naming convention. Item masters and parts are managed by ERP. The complexity of this model is to link between documents in PDM system and parts/BOMs in ERP system. In most of the cases, the integration between them is manual or using batch import/ export procedures. Optionally, PDM system can manage parts (typically engineering parts).

PDM + PLM + ERP

It is not unusual to see both PDM and PLM systems co-exit in the same company. Similar configuration can be achieved by combination of PLM and ERP system. In the last case, PDM module is part of broader PLM offering. The specific characteristic of this type of environment is management of parts and engineering BOMs in PLM system. Sometimes, you can see PLM systems is responsible also for manufacturing BOM management. This configuration provides the most consistent way to interlink between Documents and Parts. Both numbers are available in PLM system which can use them. The weak part of this configuration is complexity of integration between PDM/PLM and ERP. Synchronization of Part Numbers and Document Numbers among all systems is a challenge that may potentially lead to data inconsistency.

What is my conclusion? The information about documents and parts is located across organizational departments and systems. At the same time, to manage them in a consistent way is very important. Regardless on the number of systems and the way to manage Document Numbers and Part Numbers to keep them separate and maintain linkage between them is the first priority. Just my thoughts…

Best, Oleg


How to manage Document versions, revisions and Part numbers

March 7, 2014

document-revisions-version-part-numbers

Identifications, Part Numbers, Documents, Revisions. Despite initial simplicity these terms are often create confusion in organizations and lead to additional misunderstanding. Design and Motion blog post When a version is just a version and a revision is more made me think again about differences between document revisions / version and part lifecycle. In my earlier post – BOM 101: 5 “Don’ts” for Bill of Materials Management, I’ve been talking about differences between Part Numbers and Document Numbers. One of my "don’t" recommendation was not to use the same numbers for documents and parts. Design and Motion article gives a good explanation why it is important. Every PDM system (article speaks about Autodesk Vault, but it will be similar for other PDMs) is allowing to use revisions and versions for CAD and other documents. Here is passage explaining the difference

A version is an iteration, something that is different than before.When programmers develop software a version is typically a minor software update, something that addresses issues in the the original release but does not contain enough to warrant a major release of the software. A revision is a controlled version. Webster’s dictionary describes a “revision” as the act of revising, which is to make a new, amended, improved, or up-to-date version. Back to the software analogy, a revision is seen as a major release of the software. Something that introduces new features and functionality, as well as fixing bugs. In the engineering world we use revisions to document the changes so that anyone can understand what was changed. Versions are usually temporary, revisions are permanent. What I mean by this is that during the design phase I will quickly build up versions of the design, however 5-years from now I will only care about one version, the one that was released.

So, typical document (e.g CAD assembly or drawing) will have document number and additional version / revision. One of the common mistakes (especially in small companies) to use document number as identification for parts. This is wrong. The right identification for parts is Part Number. Parts have no versions and revisions. The lifecycle schema for parts can contain revision as a property as well as reference to document (including document revision). In order to manage differences between part and lifecycle, companies are using interchangeability model. Usually, unique part number is identifying part until both parts can be mixed in the same bin location. As soon as next design or other change will make a change, new part number will be assigned to the part. Two parts can be considered as "interchangeable". It means the functional and physical properties are equivalent in performance, reliability and maintainability. Based on that, two parts can be used without requiring special procedures (such as selecting for fit or performance) and without altering the part itself or any other part. In addition to Part Number, lifecycle status can be applied to the part to identify the level of maturity. Typical examples of lifecycle statuses are – pre-release, production, last time buy, obsolete and some others.

Management part lifecycle is completely different document versions and revisions. These are separate processes. The alignment between them can be set by assignment of specific document revision to be related to design of a specific Part (Part Number). This relation can be set inside of PDM/PLM system (in case system manage both documents and parts). In case part lifecycle managed by another system (e.g. ERP), that system will be responsible to establish relationships between released documents (drawing) representing a specific Part number.

What is my conclusion? Despite visible simplicity, it is absolutely important to separate document and part lifecycle in every PDM / PLM implementation. Document number and Part number cannot be identical. The special mechanism allowing linking between specific Part (number) and released document (including revision) should be implemented. It is important to set this rules from the early beginning to prevent future part / documents management mess. Just my thoughts…

Best, Oleg


Bill of Materials (BOM): process or technology challenge?

March 3, 2014

bom-process-vs-technology

The importance of Bill of Material in product development and manufacturing hardly can be undervalued. BOM is a cornerstone of almost all processes and activities – from early requirement and design and to manufacturing, services and support. Therefore, efficient BOM management is an absolutely important element of product development processes. PLM vendors are coming with different solutions to manage BOMs. Together with vendors’ solutions, manufacturing companies are developing practices (and sometimes a complete solutions) how to manage Bill of Materials.

I’ve been discussing the idea of "single BOM" for the last few years as a possible way to simplify BOM management. My earlier post – Severn Rules towards Single BOM is almost five years back (2009) raised very interesting debates. All of them are still relevant in my view. I wanted to highlight one very insightful post by Jim Brown here. Jim speaks about different aspects and advantages of single BOM management. As part of this conversation Jim introduced a concept he called – associated BOMs. Here is the passage I specially liked:

Companies have spent a lot of time and effort making logical connections between different BOMs, and developing tools to help develop and synchronize different BOMs. For example, PLM, MPM, and Digital Manufacturing software helps companies translate an engineering BOM into a manufacturing BOM and then further into a BOP. In fact, they have gone further upstream to match conceptual BOMs and requirement structures downstream to BOMs. Maybe you would call these “workarounds” to the real answer of a single BOM. But I would propose a different view based on history and my observations. Perhaps engineers have done what we do best – addressed the problem in the most practical way as opposed to the most elegant way to solve a problem.

I think, Jim’s post is absolutely relevant today. After few years of discussions on this topic, one of my hypothesizes is that companies are not ready for single BOM solution… yet. At the same time, I do believe companies can take realistic steps into single BOM management already today. The variety of ways companies are managing bill of materials can surprise even people with lot of experience in manufacturing and PLM. After many years, I’m always surprised to find "yet another way" to manage bills, configurations and associated manufacturing and production information.

My attention was caught by Teamcenter PLM blog few weeks ago – Bill of Materials concept. Author, posted a very good summary about different types of BOMs. Together with eBOM, mBOM, sBOM and few others, it outlines the idea of Master BOM as a centerpiece of BOM Management capable to provide "single source of truth" about BOM. The following passage explains the idea:

To overcome this challenge, the concept of Master BOM has come. Master Bill of Material can be defined as single source of BOM having all aspect of information for various configuration and discipline. Hence Master BOM by definition is single source of truth for all BOM. Industry is still struggling to find the exact solution in term of defining and managing Master BOM. Also it become more complex due to the facts that different BOM types are managed in different systems. PLM vendors including Siemens PLM has come various solution and tools, but still required to show the success and maturity of managing Master BOM as a single source of truth across various BOM lifecycle and discipline.

This post and exchange of comments made me think about potential two challenges in BOM management – technology and process. The way and technology to support and implement the idea of "master BOM" is quite complicated as well as PLM implementation attempts to integrated product data under the umbrella of "single point of truth". At the same time, the idea of "master" or "single" BOM management faces multiple political challenges including discussions about internal and external company processes. In my view, modern data management technologies (especially coming from web and open source) can introduce some advantages in BOM management. It can be related to scalability of data management solutions as well as improved collaboration features. Would it be enough to overcome process challenges? This is a good question to ask these days.

What is my conclusion? After decades of development in PDM, PLM and ERP, companies are still struggling with BOM management. The topic is quite complicated and introduce many technological and process challenges for companies. Future pressure around competition, customization and cost can bring BOM management challenges back. It will be interesting to see what (technology or processes) improvement will allow to unblock future of BOM management? No specific conclusion. Just thoughts today…

Best, Oleg


What metadata means in modern PDM/PLM systems

February 26, 2014

meta-data

Metadata is "data about data". If you stay long with PDM industry, you probably remember how earlier EDM/PDM software defined their role by managing of "data about CAD files" (metadata). However, it was long time ago. Wikipedia article defines two types of metadata – structural and descriptive. Here is a quote from the article:

The term is ambiguous, as it is used for two fundamentally different concepts (types). Structural metadata is about the design and specification of data structures and is more properly called "data about the containers of data"; descriptive metadata, on the other hand, is about individual instances of application data, the data content.

In my view, CAD/PDM/PLM is using both types. Since design is very structured and contains lots of rich semantic relations, metadata about CAD files stored in PDM system is structured. At the same time, descriptive metadata such as file attributes, information about people, project, organization can be applied to individual instance of CAD data (files) as well.

Since early EDM/PDM days, lots of changes happened in the definition and usage of a word metadata. Some of them are very confusing. The traditional use and definition of files (for example, in context of CAD files) is changing. Sometimes, we want to to keep "file" as a well-known abstraction, but underlining meaning is completely different and point more on "data" or "design" rather than actual files. Also, introduction of web based systems are changing physical use of files. The usage of file accessed via mobile application located in Dropbox is completely different. In many scenarios you will never get access to these physical files.

DBMS2 article Confusion about Metadata speaks about some additional aspects of metadata management that getting more relevant these days. It includes data about mobile devices usage (telephone metadata) and document data. Document data is getting more structured these days and often cannot be distinguished from structured RDBMS data. Here is interesting passage that describes the transformation of database and document based data.

[data about data structure] has a counter-intuitive consequence — all common terminology notwithstanding, relational data is less structured than document data. Reasons include: Relational databases usually just hold strings — or maybe numbers — with structural information being held elsewhere. Some document databases store structural metadata right with the document data itself. Some document databases store data in the form of (name, value) pairs. In some cases additional structure is imposed by naming conventions. Actual text documents carry the structure imposed by grammar and syntax.

Modern data management systems and especially noSQL data bases such as document and key-value databases can introduce new types of metadata or data. IoT (Internet of things) brings another level of complexity to data management. I can see many others to come.

What is my conclusion? I think, the term meta-data is getting outdated at least in the scope of design and engineering. Originally used a lot in EDM/PDM systems managing metadata about CAD files is not relevant anymore. Design data originally stored in CAD files becomes more transparent and connected to external to design world. The whole data paradigm is changing. Just my thoughts…

Best, Oleg


Do we need a new TLA for PDM?

February 14, 2014

pdm-cpd-grabcad-disruption

Product Data Management (PDM) is not a new buzz. Lots of things where written and spoken about how to manage CAD files, revisions and related data. Decades were spent on how to create a better way for engineers to "collaborate" or work together. Nevertheless, I can see few companies are trying to disrupt PDM space and introduce some kind of "PDM renaissance" these days.

GrabCAD blog – PDM is a technology of the past, CPD is the future is a good example of PDM disruption. GrabCAD is coming with Workbench cloud application to help engineers to share CAD data, manage file revisions and collaborate. GrabCAD article claims a new approach called CPD (Collaborative Product Development) to become an an alternative to PDM and PLM that don’t work the way you [engineers] do. Article has a strong marketing flavor. At the same time, it provides a good background of why do you need PDM and what are current challenges with many of existing PDM systems. Here is a passage that summarizes what is wrong with existing PDM:

Your team is distributed… PDM requires a central server and often makes it hard to access files remotely, You work from home, PDM requires a VPN to access files, You want to spend time designing not filling out forms… PDM requires forms and configuration and overhead for each project, You want to get going immediately… PDM requires installation, configuration, and training, Your team want to be engineers not act as IT admins… You need to collaborate with non-CAD users outside your company … PDM requires someone to configure, manage, and maintain, PDM requires every user to have a paid seat, You have a limited budget… but PDM requires large upfront license, service and hardware expenses.

It made me think again about problems with existing PDMs. I can classify all of them using two main groups – (1) complexity of use; (2) complexity to administer. In my view, the need to pay for license is a separate story and not really important for the purpose of this discussion. Many PDM seats in the past were promoted and sold as bundle with CAD licenses.

Rest of PDM problems mentioned by GrabCAD blog are very annoying. At the same time, I want to defend few existing PDM systems with successful user experience mimicking Windows Explorer interface. So, speaking about usability, PDM systems seen some success in the past also by combination of Windows Explorer user paradigm with CAD user interface (integrated plug-ins). GrabCAD Workbench developers are actually agree with that as well – you can see GrabCAD Workbench integration with SolidWorks (I assume GrabCAD is doing work with other CAD systems as well). However, here is a new problem I can see these days – engineers work is going far beyond Windows Explorer. Web, mobile, global – these are characteristics of modern work environment. GrabCAD brings new web-based user experience, which is what people are looking for these days. Existing CAD/PDM vendors have hard time to adopt their existing systems. So, native web is a good differentiation factor for Workbench. We’ve seen some PDM/PLM system provided web access in the past as well. However, devil is in details. What is really matter is how well CAD/web integration works. In the past, I’ve seen lots of difficulties to integrated both web and CAD/desktop environment. These days technologies are different. Also, we can see CAD is moving to web/cloud, which is another good reason to look for PDM/web interface.

The significant differentiation of GrabCAD workbench comes from the side of administration. GrabCAD is not only native web, but also cloud based application. By brining cloud, GrabCAD is solving all problems related to IT, servers, configurations, etc. In my view, this is a place where Workbench is bringing major improvement, comparing to existing PDMs.

Now let me come to the question I raised in the title of my post – do we need a new acronym for PDM? I have to say, CPD (Collaborative Product Development) is not a completely new term. A little bit Google work and I found few records of "collaborative product development", cPDM, etc. by CAD/PDM/PLM vendors in the past decade. Here are few links – Lockheed Martin Space Systems Selects PTC’s Windchill As Collaborative Product Development Standard, Dassault Systemes Announces IBM to Sell Complete SmarTeam Portfolio for Collaborative Product Data Management Across the Supply Chain, IBM and Dassault Systemes Introduce New Release of ENOVIA Portal to Enhance the Collaborative Product Development Process. I’m sure you can find more. So, new acronym is not very new, actually.

What is my conclusion? Do we bring new meaning to PDM by introducing it as CPD? Do you think engineers care? Meh… So, what does matter? In my view, engineers don’t like to be disturbed by data management systems. Everybody needs to manage data, but nobody wants to spend time on this and lose productivity. This is where future PDM systems should go. GrabCAD Workbench clearly brings some improvements here. TLAs doesn’t matter much, but needed for fresh marketing. So, leave it to marketing fellows. Just my thoughts…

Best, Oleg


CAD-PDM Integration, Transparency and Cloud Pain Killer

January 28, 2014

cloud-pdm-integration

CAD/PDM integration is a very important topic. It is a piece of software that helps to establish a connection between core engineering world using CAD systems and rest of the world using design data. It was a place where lots of data management innovation happened in the past. It is also one of the most frequently debated topic, especially when it comes to how manage connectivity between CAD and PDM/PLM system. It created lot of successes to companies introducing data management to engineering departments and probably created as many failures to companies that didn’t do it well or messed up with management of PDM and CAD releases.

In my view, it remains hot topic these days. Cloud brings new stream of innovation into CAD-PDM space. Cloud and CAD files management is heavily debated among different communities these days. Navigate to read my What end of local storage means for CAD? and catch up on CAD, PLM and Future Cloud File Systems. One of my active opponents in the discussion about how to introduce cloud to CAD data management is GrabCAD’s Hardi Meybaum – Debunking the cons to CAD file sharing tools.

Earlier this week, GrabCAD made an announcement about GrabCAD Workbench availability for SolidWorks. It came aligned with SolidWorks World 2014 that is taking place these days in San Diego, CA. The following two articles provide good coverage of what SolidWorks GrabCAD Workbench integration does – GrabCAD workbench rolls new CAD file management features and Busy Week in the Cloud: GrabCAD and Autodesk 360 . Here is an interesting passage

…GrabCAD Workbench provides a cost-effective and easy-to-implement PDM/PLM alternative for small- to mid-sizes businesses. GrabCAD Workbench now also offers a SolidWorks add-in and neutral file translator, opening up even more options in file types for users. Workbench users can now upload and download files as well as resolve conflicts from within SolidWorks…

SolidWorks user community is hot PDM opportunity for the cloud. I remember my post two years ago SolidWorks, Cloud and Product Data Management speaking about potential cloud infusion of PDM in SolidWorks eco-system.

The interesting part of GrabCAD Workbench / SolidWorks plugin is the way it was integrated in SolidWorks. Below I put few screenshots of different PDM systems providing integration to SolidWorks. All of them are integrating PDM plug-in immersively into CAD (SolidWorks) environment to simplify user experience:

GrabCAD:

GrabCAD-SolidWorks-Add-in-copy

SolidWorks EPDM (formerly Conisio)

pdmworks_enterprise1_lg

SmarTeam:

solidworks-smarteam

Siemens TeamCenter:

Teamcenter-Integration-for-SolidWorks

It made me think about the way cloud is probably going to be introduced to engineering community of CAD users – painless plug-in connecting CAD system you are familiar with to the cloud infrastructure, servers and eco-system. The beauty of the approach is that it helps to hide from engineer "cloud nature of the system". CAD user experience remains the same – familiar to engineers for many years. The potential danger is plug-in behavior in case of network low speed and cloud connectivity outage.

What is my conclusion? Data management transparency is a key for success. To serve users with familiar user experience and to sneak cloud servers into CAD system is a very nice approach that can provide a lot of potential. It holds the same risk old PDMs have – failure of servers or disruption / slowdown of CAD user experience. If it happens, user will boot out PDM system of CAD environment doesn’t matter of future cloud potential. It happened in the past with old PDM systems and won’t be different these days. Just my thoughts…

Best, Oleg


Follow

Get every new post delivered to your Inbox.

Join 218 other followers