The Practical PLM Newsletter - Issue 1, December 2015
/
IN THIS ISSUE
- Introduction - Welcome to the First Issue!
- Business - Triangle Package Leverages PLM to Unify Enterprise Processes
- Business - The Business Case for PLM: How To Measure Value
- Best Practices - Don’t Mind the Engine Light
- Application - Interview with Dave Ewing on Requirements Management
- Tech Tips - Using the Aras JavaScript API GridContainer Class
- Learning - Webinars, Conferences, Training, and More
- Events - ACE 2016
INTRODUCTION
Welcome to the First Issue of the Practical PLM Newsletter
We are thrilled to launch the Practical PLM monthly newsletter. This newsletter is in direct response to the countless conversations we’ve had with engineering and manufacturing companies on their approach to product lifecycle management (PLM).
The conversations exposed a common frustration with the practicality of PLM, confusion about its role in the organization, and ultimately the value it would deliver. This frustration is exacerbated by the constant demand for improved efficiency, meeting schedules and delivering quality. And yet, in the midst of this all, most acknowledge that there’s room for improvement. But how do you make real changes with so much in motion?
Therein is what the Practical PLM newsletter is all about. It is singularly focused on helping engineering/manufacturing companies achieve the promise of product lifecycle management (PLM) by exploring strategies and practical steps that can be acted upon. But we don’t want to take our eye of the ball … that being, the importance of ultimately driving business value that yields measurable revenue contributions and/or reduced expenses.
PLM is a combination of intentional business strategies, best practices and technology. Hence, this monthly newsletter will look at business drivers, processes, along with considerations for various technologies.
The Aras PLM platform is a cornerstone of this trifecta. Aras is the fastest growing PLM vendor today … and for good reasons. We’ll be doing “deep dives” into their technology, capabilities and out-of-the-box applications.
This newsletter will be authored/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 depending on holidays.
We look forward to your feedback, comments and criticisms. As appropriate, we’ll respond in follow-on newsletters.
BUSINESS
Triangle Package Selects PLM to Unify Enterprise Processes
Based off of press release from October 30, 2015 - This recent announcement reiterates the importance of processes. We contend that product lifecycle processes are a vital part of a company’s intellectual property. For many companies, these processes have evolved over years and have cultural, competitive advantages and operational nuances steeped in.
Capturing and refining these processes to ensure repeatability and improved efficiencies is what Triangle Package will be doing. However, ultimately it is about addressing key business issues. In the press release they cite …
- identifying and rectifying issues during the pre-production stage
- reducing scrap
- avoiding manufacturing delays
For more information, the press release can be read here.
The Business-Case for PLM: How to Measure Value
Are you responsible for driving added revenues or reduce the cost of goods and/or overhead expenses? Do you have P&L responsibilities or hope to have someday? Then if PLM is not part of your strategy, you may want to reconsider. PLM is just as vital as your ERP solution and some will argue that it is the most important aspect for any engineering/manufacturing business.
Product Lifecycle Management
As the name suggests, PLM is basically the processes and activities designed to support a product’s lifecycle. This cycle might originate in sales and progress all the way thru obsolescence. Certainly ERP folds in as a transactional mechanism to support the treatment of released items … for example, ordering, inventory, scheduling, etc. But the dynamics of a product lifecycle is inherently far from transactional. The activities require a real or perceived central repository of product data coupled with mechanisms to treat work flows, processes and collaboration. And since each company blends in a combination of their own business requirements, cultural, and industry nuances, it is vital that this platform is flexible and can grow with the needs of the organization.
Over the years, companies often extend PLM as their needs evolve. It might start with a better way to manage CAD drawings and assemblies … hence a product data management (PDM) solution. As the business grows, functional extensions are added such as other data bases to support engineering change and related non-CAD files, utilities to support data extractions and transfers, along with spread sheets and emails to support pseudo workflow processes.
And as much as everyone might adjust, make due, accept, and resign themselves to “what is”, there is no doubt that numerous improvements are possible.
But treating those possibilities as tactical efficiencies or “eliminating key strokes”, etc., invariably add more to an evolving cobbled collection of precariously assembled components. This process is not sustainable.
So how then to escape this evolutionary spiral?
Consider starting with the P&L (profit and loss) statement as a frame of reference to identify value.
PLM Can Reduce Costs
At the gross margin segment of a P&L, there is clear opportunity to drive shorter sales cycles as well as reduce the cost of goods. Shorter sales cycles potentially represent improved sales and simply doing more for less. And, it can be argued that better sales tools, estimation techniques, specification development methods, etc., can all contribute to shorter sales cycles depending on the nature of the industry.
Tactics such as “reusing parts” and “reducing cost of quality” translate into reducing the cost of goods sold. Redesigning parts that already exist and that now require a new vendor, etc., clearly adds to expenses. And, if the engineering change cycle isn’t as automated or complete as possible, the potential for scrap and/or returning stock drives additional expenses and extends time to market.
On the lower half of the P&L are multiple overhead expenses that contribute to operating the business. The simple one is the “total cost of ownership” or TCO. This is the expense of maintenance, subscription and upgrades for example. If you are using software from any of the big global PLM vendors, the monthly or yearly fees can be disproportionate to the value they ultimately drive. Even if you have a homegrown system, the required man-power to maintain and support the DYI activities can be more expensive than people think.
Since PLM is commonly initiated or operated within the engineering, planning, production and possibly segments of manufacturing, the immediate business value is most likely going to come in the form of a reduction in the cost of goods and cost of quality, as well as potentially lowering the cost of ownership.
What if implementing PLM along with best-practice processes can cut the cost of goods by 5% by the second year? That is a dramatic value proposition that would get anyone’s attention.
And There’s More … PLM Can Drive Revenue
But, there is money being left on the table; PLM is under-utilized in driving a shorter sales cycle time. Depending on the nature of the business, existing engineering and released data is ideally suited to readily supporting sales automation mechanisms, configurable quoting options, and prototyping/evaluating cycles.
So the encouragement to evaluate PLM solutions is to step away from tackling the tactical issues and features. Pretend you have to sit in on your next company’s board meeting (or maybe you already do) and present the value proposition for pursuing a PLM solution. It’s amazing how remaining details fall out of this approach.
BEST PRACTICES
Don’t Mind the Engine Light
Errors, delays, and cost of quality are proportional to the number of separate data repositories used to manage a product. In a recent discovery call, we quickly learned that the organization was using three separate and disconnected repositories to support their product lifecycle activities.
Autodesk Vault was used for the CAD workgroup. Once designs were released, renditions were manually created and then loaded into SharePoint. The bills we exported to a spreadsheet and manually entered into their ERP solution. Purchasing would go to SharePoint to access and print the rendered drawings. These would be associated to purchase orders.
The engineering change process was comprised of email routing with attached Word and Excel files.
Imagine if your CRM solution was comprised of one database for accounts, another for contacts and yet another for opportunities.
Sprinkled throughout the discussions, the engineering manager we were taking to, used such expressions as …
- “we are admittedly doing double entry if not triple”
- “have serious concerns about drawing access”
- “we have no idea what the status of a change or effects parts are”
Separate data repositories and disconnected processes inherently create challenges. The “engine light” is flashing. This is an ideal opportunity to explore the value of a product lifecycle management solution.
APPLICATIONS
Requirements Management - Interview with Dave Ewing (Aras Product Manager) by Martin van der Roest of the vdR Group.
Martin:
To start, give us a summary overview of Aras’ Requirements Management module.
Dave:
Requirements Management is another one of our applications that pairs with Aras Innovator and is part of the subscription model. Its primary capabilities are twofold. You can create individual requirements and requirement documents that are a collection of requirements. Typically, you are generating a requirements document or documents as you are designing a product or perhaps documenting regulatory requirements. That is the type of usage we see from our various customers.
Martin:
Profile the kind of organization and their activities that the Requirements Managements module supports.
Dave:
Requirements Management is an application that doesn’t get enough play across all industries and all sizes. For the most part, you see the largest instances of it in aerospace, automotive, and high-tech manufacturing. It’s the likes of Airbus, Boeing, Ford, GM, Lockheed Martin, and others with highly complex products.
If you don’t have a grasp on your requirements as you start designing and building these products, it’s very hard to make sure that you are staying the course as far as what those requirements dictated. You also see the same need in the chemical manufacturing or processing based industries. From a food and drug perspective, requirements are critical to be able to execute a quality product whatever that might be. We are encouraging a lot of folks to use it.
As for the activities, typically you see authors and consumers of requirements. Your requirement author might be your product or project engineers, depending on how your company is organized. Or, you might have specific requirement team members that handle that. They gather the information from customers and regulatory bodies and document them accordingly.
On the consumer side, you have your design engineering side of the world and manufacturing. They are then consuming those requirements and executing according to them. You know if your requirement says it needs to be 10 inches wide, the CAD people pick it up and make sure the design is 10 inches wide. In manufacturing, you might have a call out for a specific process, say anodizing. Then the manufacturing folks would use the proper anodizing process to achieve that specific anodizing requirement.
Martin:
With a couple of our partners, we are running into a number of build-to-order and/or engineer-to-order organizations. Is that a place for requirements management? If so, play out the possible use case we might encounter.
Dave:
Yes, I think Requirements Management fits right in. All of them have to start with requirements somewhere. If you are taking a build-to-stock perspective, your marketing team may be defining what the product needs to be. And that information is transferred to the product design team. If you have a highly complex engineer-to-order product, whatever that example might be, you may have a standard baseline. Starting from that design and those requirements that were set by the market and the industry, the customer says, “Okay I would like these modifications!” Capturing both levels of requirements is key to being able to validate that you’ve met all of those requirements. That leads to quality from a customer perspective, whether that’s a B2B or B2C environment.
Martin:
Ultimately, requirements management drives quality … which in turn strikes me as being a key value proposition.
Dave:
Absolutely, products continue to grow in complexity. There is mechanical and electrical coupled with more software on top of that. It’s imperative that you get those requirements written down in an actionable sense. Using Excel and Outlook to do that falls apart fast as the complexity takes off. It’s very hard for a human being to try to keep track of all of that. You need a system that allows you to capture the requirements, relate it to the different systems and/or parts, and that you can trace back and make sure that everything has been done.
Martin:
Dave, talk a bit more about “how it works” and the primary use cases.
Dave:
Well, there are two fronts that I talk about in a use case.
The first is capturing those regulatory requirements. Maybe it’s the FAA or FDA. They publish those documents that you can obtain from their website and they contain various requirements. In Aerospace seating, AC21-49 serves as a collection of requirements addressing the electronics that might be in a seat. You would take all those requirements in that document and author those as individual requirements in your PLM requirements solution. Then roll those together in a requirements document.
Martin:
So, are you suggesting that with the Requirements Management module you get a number of these standards already accessible or buried in for later access?
Dave:
The standards aren’t provided to you in an Aras requirement format, or an XML format. You know the regulatory body and the customer are providing you a PDF for a word file. Translating those into your requirements solution is a smart thing to do because those specs from the FAA or FDA or NTSB, aren’t changing daily. If you put the effort in one time, you are able to reuse those requirements many, many times over, in many products, and many R&D efforts.
Martin:
So what is the second use case?
Dave:
The second use case is related to the product, capturing the information for marketing, design, and manufacturing. And, most importantly, validating that those requirements have been met. Your internal design requirements are going to guide how you design the product; they can span many different domains. If you have a purely mechanical product, it might be one set of information. But, as you start to put electronics and associated information together, it is key to capture the requirements of how they need to operate also.
Now you have those two streams of requirements that come together and are consumed by the product design team. The validation portion of the use case is in the back end as you are going through a design review process; every company does that a little differently, but we generalize it. You can start to trace your requirements through the design process and check to see if each one has been met. A user can trace both forward and backward to insure that the intent of every given requirement is met. You can use reports in different ways to gather all that information. Every company will do it a little differently.
Martin:
Is there a provision that allows these requirements to be fed into test documentation?
Dave:
Yes. Absolutely, that is one of the examples we have in our demo database. You can reuse those in that manner and pull them into different documents. Because Innovator uses XML for interchange, it’s very straight-forward to build integration and whatever your document authoring tool might be. Let’s just say it’s Word. It’s a straight-forward effort to pull the information from requirement number 123 into your test requirement document and be able to issue that.
Now one of the areas that we are suggesting is to build your test plan right inside of Requirements Management. Now you can just link requirements back and forth, and have further traceability. Every company might need to walk before they run. As with everything else in Innovator, there are many ways to skin the cat, so we can help you build your business process, whatever that may be.
Martin:
I am going to veer off a little, but I wanted to call attention to the Tech Docs solution that I know is coming out around the New Year. Will Tech Docs have a role in being able to be the recipient of these requirements for creating test documentation?
Dave:
Yes, I think so. You bring up a standard use case. I anticipate that Tech Docs will have connections. From a Change Management perspective, if my requirement changes, I need to change those tech documents. So, I do need a connection between the two and that’s a very standard case and an important one.
If a requirement changes significantly, you may need to change your test plan. If you are not capturing that, your testing finds out. The test team tends to be the end of the design cycle where they don’t have a lot of time to make changes. You could be setting them up for failure, if you didn’t capture the necessary information. That goes right back to that value of why you should be capturing requirements and why you should be managing them during the entire lifecycle of the product design.
To capture the value and to make sure your team has the information they need, make sure the changes are propagated. We think that is the key reason to integrate Requirements Management into PLM and to not have that information sitting out on an island.
Martin:
It seems like it would be a very compelling combination of solutions.
Finally Dave, give us some thoughts on the factors a company should be thinking about in setting something like this up?
Dave:
Well, as far as the literal set up in terms of the software, you need a subscription. This is just a matter of downloading the package and performing the installation. It’s actually a very straight-forward process. It creates the items types and all the necessary relationships.
Last time we talked about Change Management and taking a critical look at your processes. I think this is the same kind of thing. Take a critical look at your requirements process. Does the out-of-the-box requirement solution fit that bill? You may need to tweak the process a little bit in what lifecycles you might want the requirement. Those things would need to be upgraded from our general out-of-the-box solution to something that fits your business processes.
From there we tend to be practitioners of lean, agile or scrum. I’d suggest you would want to use it for a while … say six months. Then use that as a point where you can look back at what’s working, what’s not, make the first set of tweaks, and be able to apply those rapidly, so your business is able to upgrade. The software is resilient and can upgrade with you, and you can get the most value out of the product.
Martin:
What are the version considerations for the Requirements Management module?
Dave:
You can run it on 11R2. We have a service pack upgrade that we will be pushing out with 11 service pack 5.
Martin:
Dave, are there any other comments you would like to offer?
Dave:
Yes, from a general perspective we encourage our customers to go with a connected PLM solution. This connection is something we have been looking at as we look at model base systems engineering (MBSE), technical documentation and quality documentation. Specifically, how do these solutions have to play together to pass information back and forth? The link from a requirements item to testing documentation link is very important, as are all of the other links made in a product design. So there will be some upgrades coming forward in requirements as we look into version 12. From that aspect, we certainly would be encouraged to have ideas or thoughts or use cases from our customer base and our partner base that says, “Hey, these are some of our use cases.” It would be nice if folks want to reach out to give us some information and join us at ACE2016. Information is great! We like to hear from the customers and help them out and try to build going forward.
Martin:
Dave, thanks for taking time to share your insights and views with our readers.
TECH-TIPS
Using the Aras JavaScript API GridContainer Class
Dare you to try to do this with less than 20 lines of JavaScript
Now here's one for those hands-on people. This is a cool approach that's super efficient and only requires a little scripting. I dare you to try to do this with less than 20 lines of JavaScript with {insert your legacy PLM system name here} :-)
Purpose
The standard item search grid in the Aras Innovator client is a member of the JavaScript API GridContainer Class. Using a method that returns the rows selected by a user in an ItemType action may be a more efficient way to process items selected by a user. The ItemType action for this example only runs a Client Method once for all selected item in the search grid - versus a standard Item action which executes the Client Method on each selected item in the search grid.
Example
In this example, a Client Method is created to return the selected items from the Part search grid and set the make_buy property of each selected Part to "Buy". The Client Method uses the GetSelectedItemIDs JavaScript method to return the selected item id's in a concatenated string.
1. Create a new Client Method (in this example the Method is named ActionAccessPart).
2. The following JavaScript code will obtain the selected Part items from the search grid and edit each Part to assign the make_buy property to "Buy":
//Main grid is object of type GridContainer Class (control)
var g = top.main.work.grid;
//get selected ids and convert to an array
var myids = g.GetSelectedItemIDs(",");
var myarray = myids.split( ",");
//Get each item in a loop and then set property
for(i = 0; i < myarray.length; i++){
var itm = this.newItem("Part", "get");
itm.setID(myarray[i]);
itm = itm.apply();
itm.setAction("edit");
itm.setProperty("make_buy", "Buy");
itm = itm.apply();
}
//Rerun the search grid to update contents
top.main.work.doSearch();
alert("Parts Modified")
3. Create a new ItemType Action
4. Assign the Action to the Part ItemType:
5. Test the Results:
Aras subscribers can get more in the Aras KnowledgeBase (Aras KB) located in the Subscriber Portal http://www.aras.com/subscriberportal/tech-tips/
LEARNING
Upcoming Webinar
The Business Case for PLM: Finding Immediate Value
Save the Date: Friday, January 15, 2016 at 11:30 AM PST – Register Here
When most people think about PLM, the last thing that comes to mind is “immediate value.” A recent survey found that 25% of managers responsible for product are hesitant to invest in PLM due to poor previous experiences. And, 70% of companies with dedicated PLM solutions have scraped major portions of it due to either low acceptance or budget overruns.
Join Martin van der Roest and Hiep Tran and learn how to overcome these challenges by focusing on small incremental “wins” that organically drive the process transformations needed to fully realize the power of PLM. As companies face increasingly globalized value chains, competitive pressures, and data silos, there is an urgency to find real and immediate value in PLM.
Register here
Save the Date: Friday, January 15, 2015 at 11:30am
ACE 2016
Aras Customer Event, Detroit, MI - March 15 - 17, 2015
Join the Aras community on March 15 - 17 for ACE 2016 at the Detroit Marriott Renaissance Center. ACE 2016 is a great place to network with Aras users and partners, hear about next generation PLM strategies, see the latest solutions and find out what Aras has in store for the future. For more information, check it out 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 depending on holidays.
Your editors are Martin van der Roest and Dick Bourke. Your comments/questions are welcome and can be directed to martin@vdr.com or dickb@bourkeconsulting.com. If applicable, we will respond in a following newsletter.
Practical PLM 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/or reduced expenses.
PLM is a combination of business strategies, best practices and technology. Hence, this monthly newsletter looks at business drivers, processes, along with considerations for various technologies.
The Aras PLM platform is a cornerstone of this trifecta. Aras is the fast growing PLM vendor today. The vdR Group is a full service partner of Aras.
Copyright © 2015 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 is …
The vdR Group, Inc.
1592 North Batavia