The Practical PLM Newsletter - Issue 6, June 2016

"Pursuing the Promise of Product Lifecycle Management"
Practical PLM Newsletter - Issue 5, April 2016

IN THIS ISSUE

• Introduction - PLM as the Bridge-Builder
• Business - You Can’t Scale the Business without PLM
• Best Practices - Model-Based Definition
• Application - How do PDM Solutions Fit into a PLM Strategy?
• Technology - Integration Technology Primer
• Learning - Upcoming Webinar: Liberating Autodesk Revit Data

---

Introduction - PLM as the Bridge-Builder

Single Source of Truth Paradigm Inherently includes Application Integrations

PLM is the glue that holds part and product data together.  If your organization wants to achieve “single source of truth” capabilities, PLM is designed to achieve this goal.

The reality is that data is authored and modified via numerous sources and applications.  So, PLM must support the ability to integrate with these various sources.  That is what this issue touches on.

In the Business section below, we stress that without PLM it is nearly impossible to efficiently scale the business for growth.  Supporting this assertion is the need to have a flexible data structure.  Dick Bourke, noted analyst and co-editor of this newsletter, recently penned an article about the importance of product definition in CAD systems.  You’ll find his contribution in the Best Practices section.

In the Application section, we outline some thoughts on how PDM fits into a PLM strategy.  Interestingly enough, this remains a recurring topic.  We thought it was time to better articulate factors that can contribute to a decision.

Hiep Tran is our CTO.  He has been with The vdR Group for over 25 years and understands the issues of integrations and applications coexistence.  We discuss with him application integration considerations you will want to be aware of.

Finally, we highlight a couple of educational topics.  We’ve provided a link to a recent webinar addressing technical documentation.  Also, we are excited about an upcoming webinar that will speak to an integration between Autodesk Revit and Aras Innovator.  If you are using Revit, you will definitely want to be in on this webinar next month.  We want to share the concept of “intelligent parts” and what this means for accelerating the quoting cycle, establishing an accurate bill of materials sooner than later and driving improved decision making metrics.

BUSINESS - You Can’t Scale the Business without PLM

Structuring Data for Reuse and Establishing Repeatable Processes

Look at the diagram below, a generic data structure that highlights that part and product data are comprised of numerous components.

What’s not shown are the ongoing changes that occur.  Parts change along with associated documentation, specifications, calculations, and so on.  Hence, there are revisions and rolled up versions.  In reality, this should be a three-dimensional image that reflects changes over time.

Now think about your company’s environment.  We would bet donuts-to-dollars that most data components are stored in file folders, spreadsheets, Access databases, emails and even sticky notes.  Part number, project, or some other tribal conventions known to a handful of folks in the shop miraculously connect them.   So, HOW IN THE WORLD DO YOU MANAGE THE DATA?

You assign staff to walk through the quoting process (you know who you are!).  Those individuals are the workflow process… it’s like pushing a shopping cart around the office.  You have folks dedicated to tracking customer orders.  Or, you don’t worry about until it comes to shipping and know that the delivery team will pull it all together.  These are mitigating efforts and typically reactionary processes. 

It begs the questions … without hiring more people, can you turn around quotes faster, get to a 100% accurate bill sooner, reduce scrap and rework, or continue to meet customer delivery commitments?

As you can probably sense, this is fundamentally not sustainable, especially if you want to double the size of the business.  It’s simply not scalable.

If your company already has a PLM system, then something is not working.  As Peter Schroer, president of Aras mentioned in his PLM Underground blog earlier this year, these systems “were never deployed.” 

If PLM is not in place, then that’s the significant opportunity.  The ROI is often no more than a year. And, in the following years, the PLM investment returns multiples through shorter sales cycles that drive incremental revenues, reduced cost of goods and greater operating efficiencies.

BEST PRACTICES - Model-Based Definition

Explanation of Model-Based Definition and Why it Matters

By Dick Bourke

The stakeholders of PLM systems expect accurate product documentation.  Such is not always reality.  The dire results of inaccurate product documentation can affect all levels of stakeholders’ activity: strategic, tactical and operational, and maybe all levels at once.  Excessive scrap and rework may trigger excessive costs and delayed shipments. Perhaps, even loss of customers.

Fortunately, in the realm of 3D CAD models and 2D drawings, Model-Based Definition (MBD) is an evolving solution for generating information that is clear, unambiguous and repeatable for all stakeholders in a single source over the lifecycle of a product.

An example of a properly annotated 3D CAD model. (Image courtesy of Action Engineering.)

Read the full article written by industry expert Dick Bourke – assisted by Jennifer Herron, CEO of Action Engineering, recently published on the Engineering.com site.

APPLICATION - How do PDM Solutions Fit into a PLM Strategy?

Integrating Autodesk Vault or SolidWorks EPDM with PLM

By Martin van der Roest

We regularly hear from organizations that are using or thinking about using a product data management (PDM) solution such as Autodesk Vault or SolidWorks Enterprise PDM (EPDM) to manage their CAD drawings and parts (items).  Users want to know how these PDM applications fit into a PLM strategy.  “Does PLM replace PDM?”  “Should we stop the PDM evaluation process and just go to a PLM solution?”  “We implemented PDM, but the company wants to implement PLM.  Our CAD users don’t want to change.  Can they work together?”

For starters, there is a role for each solution.  It is not a question of one-or-the-other.  Coexistence can be a preferred strategy for certain situations.

Ultimately, it boils down to integrating PDM with PLM or bypassing PDM and integrating the various CAD systems with PLM.  Either decision has a similar total-cost-of-ownership (TCO) associated with it.

For a PDM to PLM integration, the expenses will typically be a function of the number of CAD users connected to the PDM, even though there is only one connection between the PDM and PLM environments.  This latter point is one of the advantages of a simple point-to-point integration between the PDM and PLM platform… it’s independent of how many CAD users there actually are.

Alternatively, If all the CAD users are directly connected to the PLM environment, then the expense is based on the number of connectors required.  Third parties and not the CAD vendor typically develop these CAD connectors.

I’d suggest there are three primary conditions that would drive a decision.  They are…

• CAD vendor’s vertical applications are heavily leveraged
• CAD (AutoCAD, Inventor, and SolidWorks) functionality and capabilities are enhanced with third-party add-ons
• custom development added to existing PDM platform

I’ll take AutoCAD, for example, to address the first condition above.  Dozens of available vertical applications address civil, building, electrical, etc. that have been built on top of the AutoCAD engine.  No doubt impressive, but each application may have its nuances for libraries, data structures, linkages to external dependencies, and so on.

Having been involved in CAD integration technologies for over two decades, the reality is that no one does a better job of integrating CAD tools with data management than the CAD software vendor themselves.

The second condition noted above is similar to the first condition.  Although third party add-ons are required to adhere to certain operating conditions as defined by the CAD vendor, we continue to see functionality that creates challenges for these third party developers of the CAD integration with PLM.

Finally, the third condition noted above, suggests that the incorporation of additional custom functionality and development represent an investment that might be lost if the PDM solution were to be replaced with a PLM platform.

If a decision is made to operate without a PDM platform, the integration between the CAD and PLM systems is straightforward.  The PLM system now operates as the PDM for the CAD users.  The CAD users operate within their environment and see the PLM environment as if it were a file folder with additional features and capabilities.  Hence, the impact for CAD users to learn a new system is minimal.

Likewise, integrating a PDM solution with PLM is also straightforward.  A point-to-point integration is independent of the number of CAD users involved.  But, it's important to synchronize the life cycle stages and workflow processes (change management) between the two systems.  In this scenario, the PDM could retain work-in-process (WIP) files and only push out “release” candidates to the PLM by a change process.

TECHNOLOGY - Application Integration Technologies Primer

An Interview with Hiep Tran, CTO, The vdR Group

PPLM - Hiep (pronounced “hip”), talk about some of the key technologies that an organization will want to be aware of as they consider an integration between something like Aras PLM and other enterprise solutions like CRM, enterprise content management (ECM), enterprise resource planning (ERP), etc.

Hiep - Three primary approaches can be considered.  These are…

• drop zone
• direct connect
• enterprise service bus

The drop zone concept is to export a data file from a source environment into a neutral area (file folder) that the target application retrieves and reads.

The direct connect model leverages application program interface (API) modules.  There is an API specific to the source and target applications.  These APIs talk to each other.

Then there is the enterprise service bus (EBS), referred to as the “hub and spoke” model.  BizTalk from Microsoft and WebSphere from IBM were some of the solutions developed years ago that popularized the hub and spoke idea.  Each application connects to the hub.  At the hub, mapping and processes are defined, among other operations.  By doing this, one application can theoretically communicate with several.

PPLM - That’s a good way to categorize the possibilities.  Given the last two approaches, why would someone want to use a “drop zone” model? 

Hiep - Interestingly enough, many companies are still using legacy enterprise solutions that have limited API capabilities to support a direct connect option.  However, export and import options are typically available.  These can operate on a scheduled basis.  So let’s say, at the end of an Aras engineering change workflow, parts and bills are updated.  We can export a data file into a neutral, but a secure file folder.  The target application can pick it up and then import the data.  There can be some limited hand-shaking such that the target application can acknowledge receipt of the data and successful import.

Using the drop zone approach is also great for prototyping.  When we know that the direct connect or EBS can do the job, we can simulate the processes without doing the work on the integrations.  It’s a very efficient approach.

And, it’s worth noting that when real-time (or near real-time) transactions are not critical, then the drop zone approach makes sense. 

PPLM - You used the term Enterprise Service Bus.  Is that a product name like the Microsoft’s BizTalk or is it a generic expression?

Hiep - It is a generic term that has evolved from the hub and spoke architecture concepts and incorporated additional functionality. 

PPLM - Let’s talk a bit about the direct connect options.  We hear terms like REST, SOAP, etc.  Clear up the alphabet soup and their relevancy for integrations.

Hiep - First, let me recap the term, API, or Application Programming Interface.  APIs are a set of code and functionality that does the talking between two systems.  The conventions operating via the Hypertext Transfer Protocol (HTTP) protocol for the APIs are characterized by such methods as REST and SOAP.

Aras uses web services known as SOAP or Simple Object Access Protocol.  This messaging protocol allows programs that run on disparate operating systems such as Windows and Linux to communicate using HTTP and its Extensible Markup Language (XML).

REST stands for Representational State Transfer.  It is a stateless, client-server, cacheable communications protocol, and typically uses the HTTP protocol.

PPLM - What’s different between the two?

Hiep - SOAP requires an envelope format and a specific set of XML tags to be included in the message.  When you send that message to Aras Innovator for example, the format of the payload will have to be very specific to the SOAP package.  The good news is that this is a well-known standard.

In contrast, REST is much simpler to put together and is a little more freeform in that the call format is done partly on the URL itself.  The URL is the string that you sent to an HTTP target. And, the body of the message sending back and forth would be used typically as a JSON (Java Script Object Notation) format.  REST tends to be easier to develop.

PPLM - Are there other conventions that we should be aware of?

Hiep - Based on the HTTP protocol, those are the two most well-known methodologies for communicating from an API point of view.

PPLM - Given these integration options for exchanging data, how does federation work in an integrated scenario?

Hiep - Think of federation as almost a pass-through type of integration.  Via the federation approach, data from an external source is represented to a user as if that piece of data already exists in Aras Innovator.  For example, pricing and vendor data for a part is typically managed within an ERP environment.  Rather than duplicate that data in PLM, we can use federation to pull this data as needed.

PPLM - With Aras supporting the SOAP conventions or Web Services, would that protocol convention be used to facilitate the federation?

Hiep - That is one way to facilitate the federation.  The federation framework has many layers, and if you ask one of the layers to talk to one of the external systems, you are not bound to speak to using one type of API, you can use SOAP, REST, or you can use a database query connection to get data back.

PPLM - So, let’s say I have a part item with a cost attribute, but I want that cost to come directly from the ERP solution.  Would I have a method in the attribute to retrieve that information?  And how do I retrieve that information?

Hiep - To support federation inside of Aras Innovator you have something called triggers.  To view a cost attribute from the ERP system, there needs to be a trigger that retrieves the cost attribute before it appears to the user.  This trigger is a piece of code that reflects your business logic for getting the data from the ERP system.

Depending on what type of API is available, you can establish a database query, a web service call or you invoke a REST call and get the data that you need.  Once the data is retrieved, that same trigger code can transform, convert, reformate however you want it and present it to the user within that user presentation.

PPLM - This all sounds like a great way to get the data you need, but eliminate duplicate data and the associated synchronization issues that go along with it.  Thank you Hiep for your helpful insights.

Learning - Previous Webinar

Aras Innovator Demo Series - The Latest on Technical DocumentationAras conducted a recent demonstration of their new Technical Documentation module.  The term “technical documentation” can be a bit misleading.  This powerful module is all about driving content reuse – ideal for creating field service manuals, data sheets used on your company’s website, manufacturing assembly instructions and so on.

 The module is similar to Adobe’s Framemaker, but instead, portions of a document can be directly linked to items in Aras such as part attributes, images, specs, etc.  If item data is updated, it can automatically be reflected in the associated document(s

Check out the 30 minutes recording here.

Learning - Upcoming Webinar

Liberate Revit Data through “Intelligent Parts” to Drive Company-Wide Efficiency 

Save the date for July 26, 2016

The rigid and siloed structure of Autodesk’s Revit data has been a long-time source of frustration for companies in the architecture, engineering, and construction (AEC) space.  Revit projects and family data rarely “play nice” with enterprise-wide solutions such as ERP, PLM or even simple document management.  While many AEC companies have invested heavily in enterprise solutions, it has proved difficult to seamlessly harmonize with the Revit environment.  Join PacifiCAD and The vdR Group as we introduce an exciting new approach to instilling an “intelligent parts” paradigm to liberate the value of Revit data.

What will you learn in this webinar?

•  create a secure and controlled Revit data library that acts as the “single source of truth” for Revit families and types
• enrich Revit data with pricing options, documentation, specs, etc. as derived from enterprise applications
• optimize data reuse, and drive down-stream efficiencies
• gain visibility into Revit projects, changes, revision history and redlining
• dynamically produce schedules, costed BOMs, and specs against Revit projects
• drive improved BOM accuracy
• accelerate the quoting process

Register for the webinar here.

Contact

This Practical PLM newsletter is authored and edited by The vdR Group, Inc. (vdR) along with contributions from selected partners.  It is scheduled to be published the second Tuesday of every month.  Delivery dates may vary.

Your editors are Martin van der Roest and Dick Bourke.  We welcome your comments/questions.  You can direct them to martin@vdr.com or dickb@bourkeconsulting.com.  If applicable, we will respond in a following newsletter. 

Mission
Our mission is to help engineering/manufacturing companies achieve the promise of product lifecycle management (PLM).  We do this by exploring practical action steps that drive business value and that yield measurable revenue contributions and reduced expenses.

PLM is a combination of business strategies, best practices and technology.  Hence, this monthly newsletter looks at business drivers, best practices, application, and education.

Aras is the technology vehicle of choice for vdR.  vdR is a full-service partner of Aras.

Copyright © 2016 The vdR Group, Inc., All rights reserved.

All trademarks belong to their respective holders.  Content, responses and opinions expressed are not necessarily shared by Aras.

Our address

The vdR Group, Inc.
1592 North Batavia
Orange, CA92867

You can opt-out of this newsletter here.