Getting Back to the Business of Engineering
For some time now, we have wanted to speak directly to the value of PLM as it relates to the profit and loss (P&L) conditions of a business. So, to kick off, we'll probe the topic further by mapping the value of PLM directly to P&L. We can play with benefit statements, KPIs and other metrics all we want, but there’s nothing quite like seeing the impact on the financials. If we add anything to the conversation about the business of engineering, it’s the idea that P&L needs to be looped into the mix.
Along these same lines, we'll identify numerous value propositions and trends linked to PLM and learn why waiting to implement PLM functionality is not an option. Rather, for engineering and manufacturers organizations to compete, drive profitability, and stay fleet footed, PLM is a must.
We'll then go on to discuss Model-Based Design and offer some "cut-to-the-chase" insights.
Finally, we close with an interview with Ben Desmarais of The vdR Group. Ben participated in a significant PLM implementation this year in which Agile (D3's PLM Partner) project management was applied. The project has been a huge success; the Agile methods were an invaluable component of the effort. Ben shares some insights and highlights of the business value gained for this customer.
Can PLM Measurably Increase Revenues?
PLM isn't just about efficiencies; it should be part of your top-line revenue strategy
by Martin van der Roest
As a business owner for 30 years, I’ve developed a few guiding principles about making business decisions. One of these principles is based on understanding the impact of a decision on the P&L, and visa-versa, identifying what proactive steps I can take to affect changes to the P&L.
So what are the benefits of PLM, and how does it affect time to market, reuse, scrap, quality, etc. And can we map the contributions of PLM to the P&L...what would that look like?
Let’s start with a gross dissection of the P&L. As I see it, there are fundamentally three key sections. These include the sections for gross profit, operating expenses and net income. Gross profit is comprised of overall revenues and the associated cost of goods (COGS). I’ve always looked at operating expenses as primarily fixed costs we’ll incur regardless of how much business we do…such as lease, insurance, phone, debt service, etc. And finally, the net income shows the bottom line for the reporting period.
I want to focus on mapping PLM to revenues, COGS and operating expenses. I also recognize the complexities and the spectrum of attribution. “Binary” events in the roiling sea of activities may or may not be discernable. Hence, the points I make below represent a framework that might catalyze ideas for your own business and its unique characteristics.
PLM and Revenue
The big question is, how can PLM measurably contribute to revenues? Simply put, increased revenues can come from selling more, charging more, or both. Charging more strikes me as a marketing consideration. Can the market bear a higher price? With respect to PLM, I don’t see an attribution relationship here.
However, I do see a connection between PLM and increased revenues. Let me highlight a couple of key metrics:
There is absolutely no reason to extend PLM into the sales efforts. Leveraging CPQ (configure, price and quote) functionality can increase the number of quotes that can be produced in the same amount of time and resources. Repeatable and smart processes that leverage existing part data, configurable options and variants will be the key to shorter sales cycles. This is clearly one of PLM’s strengths.
Also, applying methods to ensure quoting accuracy will minimize laborious reviews, checks and downstream fumbles that can drive higher COGS.
PLM to drive increased revenues is real. Would an uptick in a few percentage points be worth it?
PLM and Cost of Goods Sold
Reuse, reduced scrap and rework, and increased warranty expenses are among the several “leakages” that contribute to inflated COGS. Collectively, we might refer to these items as the cost of quality. And this has historically been what PLM has been touted to respond to.
PLM done right, inherently optimizes part reuse and ensures accuracy and visibility that in-turn minimizes errors in what is made, ordered and assembled. I’ve read countless articles and presentations that identify a laundry list of all the things PLM can achieve. It can be mind-boggling and overwhelming. But rather than get tangled up in these features, consider that ultimately, it is about PLM’s ability to establish a single repository of data overlaid with repeatable processes. By doing this, the cost of quality will improve. In fact, this is the single KPI (key performance indicator) that can be tracked prior, during and after the deployment of PLM.
PLM and Operating Expenses
On the lower half of the P&L is the consideration for a boatload of operating expenses. Trying to map PLM into this area seems to get a bit foggy and mushy. In other words, measurable attribution can be challenging and potentially unproductive.
I’d say the contributions of PLM and the right PLM (plug for Aras) will show up as improved efficiencies and a lower total cost of ownership (TCO).
Alan Mendel, a principal at LeverX, is a longtime friend of mine. We had a serendipity encounter on a plane flight recently that allowed us to visit over several hours. He is truly a guru in the PLM space with nearly three decades of experience working in manufacturing, consulting with software vendors and now, helping customers implement PLM based on SAP’s platform.
I shared some thoughts with Alan about operating expenses. He commented, “Because of PLM’s ability to help individuals do more for less, companies could redirect resources to strengthen such activities as product research and new product development.”
Excellent point. Redirecting resources could help drive additional revenues, but would most likely have minimal impact on reducing operating expenses.
On the other hand, the TCO for PLM can be a worthwhile exercise to drill into. TCO is the expense associated with maintenance, software licenses or subscriptions and upgrades for example. Even if you have a homegrown system, there is the associated labor expense to maintain and support the DIY activities. In fact, the TCO can be more expensive than people think and it’s worth a second look.
Pro-Forma P&L Driven by PLM
Let me play out a sample scenario. Let’s say that a company currently does $100M in revenues and has a cost of goods at $60M that includes about $3M in scrap, rework, warranty, or what we called the “cost of quality.” Hence, the cost of quality is about 5% of materials. As I suggested above, it’s hard to correlate lower operating/overhead expense to PLM, so I’m leaving it out of this scenario. Thus, we’re just talking about revenues and COGS.
PLM Attribution Mapped to Gross Profit (*Numbers are in $1M)
Further, let's speculate that by implementing a PLM solution, revenues can be bumped up by 5%, and the cost of quality can be dropped to 3% versus 5% of materials. So, a 5% increase in revenues can potentially produce an 8% increase in gross profits.
Based on this sample scenario and other work we have done, I strongly recommend that organizations start and/or refactor a PLM initiative with the prime directive to drive increased revenues and reduced COGS.
Yes, there may be a slight uptick in operating expenses, but I would guess that the impact on the net profits would be minimal.
We talked about the “business of engineering,” a term used by Aras as well as CIMdata. I believe that by addressing PLM while considering the P&L, reinforces the theme of the “business of engineering.” Moreover, it repositions PLM as a top-line strategy that will demand executive management’s attention.
Yes, it’s great to have secure vaulting of drawings, seamless integration points between apps, and automating workflows/process. But, without a clear correlation to the top-line, these nifty “features” strike me as just distractions and illusions of progress.
Investing in PLM is No Longer an Option
Accenture's recent white paper stresses the value of PLM and digital data
“As it stands, companies are missing the opportunity for an $8B bottom line impact. PLM investments could generate up to 50 percent higher returns if companies apply a sharper prioritization toward digitalization and pursue PLM programs as a means for true transformation.”
We talk with 10s of companies per week. And the recurring theme is the same. Companies continue to use emails, spreadsheets, and unstructured file folders to “manage” the organization’s product lifecycle activities. Of course, the impact varies depending on the type of industry they are in. But we believe the “opportunity cost” associated with doing nothing is significant. Accenture shares this view and recently published a white paper that illuminates this “cost” and offers some ideas as to what to do about it.
Doing Nothing is Deferred Pain
The article offers up four action steps to help organizations get their digital s*&t together.
Action Step #1 Let the business define your digitalization agenda.
To stay competitive, identify what parts of the business need to be digitized, such as product data, processes, or both? We did a segment in PPLM Newsletter #4 that speaks to what we called the PLM Maturity Quadrant and made a case for doing both.
Action Step #2 Prioritize the investment in PLM capabilities that enable digitalization.
The digital world requires a seamless integration of data across the value chain, so investment should focus on those capabilities that enable such integrations and drive future business growth.
Action Step #3 Drive true transformation.
To capture the full benefits of PLM, existing processes and associated technologies must evolve. Establish feedback metrics to track the improvement on a process level and continually measure the value and progress throughout the transformation journey.
Action Step #4 Join forces between business and IT.
PLM inherently is a cross-departmental solution. Leverage IT leadership and senior management sponsorship to align priorities. When IT and the business collaborate to identify areas that can drive growth, the business will be equipped to invest strategically rather than tackle isolated point solutions that don’t create long-term value.
Model-Based Design and Model-Based Enterprise
Reinforcing the value of Digital Thread
Introduction by Dick Bourke
What manufacturing company hasn't faced unnecessary rework, confusion on the shop floor and thus missed delivery dates? The cause can repeatedly be traced to unclear, ambiguous documentation often found in 2D drawings.
Help is at hand, fortunately. An evolving solution for authoring product definition and design intent, sourced at the CAD models, is gaining recognition. The solution is Model-Based Definition (MBD), a foundational element of a comprehensive initiative called Model-Based Enterprise (MBE) that brings the benefits of good, complete and usable CAD models to an organization and its suppliers.
In a recent discussion, Jennifer Herron, CEO of Action Engineering, asserted, “As a key benefit, MBE is an enabler for bringing the culture of discrete manufacturing into a rapid deployment of innovative products through unambiguous definition of the product."
Applying the Agile Project Management Methodology
An Interview with Ben Desmarais, Project Manager at the vdR Group
PPLM: Ben, you recently participated in a significant Aras PLM implementation effort that spanned most of this past year. The Agile project management technique was used. Give us a net-net of what it meant to use this approach.
Ben: Yes, it was a significant effort. In fact, I can’t imagine not having used the Agile approach. For this project, the so-called “water fall” approach would have been a disaster.
We were able to deliver a working solution on time and on budget. I know it can sound trite, but maintaining our commitments regarding schedule and expenses while delivering a successful solution was a real home run for the customer and the team.
The Agile methodology helps everyone stay focused on the project goals, starting by working with the customer to establish what we call “user stories.” These stories are prioritized and queued up into “sprints.” What I liked about this, is that after each sprint the customer received working features that can be used immediately.
Stepping back, let me highlight the key business benefits by using Agile. The first is visibility. Agile provides opportunities for customer engagement before, during, and after each sprint. Delivering working features regularly boost the customer’s trust in the team’s ability to get things done.
The second is quality. Testing is integrated throughout the process and enables early and regular inspection of new features. A completed feature can be used immediately. If an issue is found, it’s resolved in the next sprint.
The third is our ability to turn on a dime. Change is expected and accepted. Because features are completed within a sprint, the focus on subsequent sprints can be changed to include features that have become more important, or maybe were needed sooner than later.
PPLM: Give us some highlights of the key components of the Agile approach.
Ben: Sure. I’d say the key components of the Agile approach are requirements capture, sprint planning, daily SCRUM meetings, incremental updates, testing and customer feedback.
Let me drop into some of the details.
Capturing requirements are done with what we call user stories. Each story is a statement of, “As a (role) I want (something) so that it gives me (benefit).” Each story provides enough information for the implementation team to scope the work and develop more in-depth requirements and tasks.
Once we get the user stories and tasks, we go into a sprint planning. Sprints are a short period during which we do the development work, conduct testing and field feedback from the customer. So, for the sprint planning, we determine what requirements we want to tackle balanced with what we can deliver that provides the customer with usable functionality. This latter part is subtle, but this is what makes the Agile philosophy so powerful. The basic theme is to deliver functionality within a two to three-week period. The customer can experience a steady and ongoing series of incremental updates rather than wait for months to see what’s going on.
The daily SCRUM meetings during a sprint give everyone a chance to update the team on their progress. Each team member reports on what was done in the last 24 hours, what they plan to complete that day and any issues they may have run into. The moderator of the meeting or SCRUM master is instrumental in this process. These meetings are intended to be about 15 minutes in length, and a good SCRUM master makes sure we stay on track and determines if follow-on drill downs need to be scheduled.
PPLM: That’s a great overview. What would you say are the critical items that are vital to the success of using Agile?
Ben: It’s not fair to say one item is more critical than another. All the items in the Agile process are important and build on each other. The whole process is vital. However, if I were to say which one stands out the most, it would be the incremental updates and customer involvement.
With incremental updates, the customer can see new features after every sprint. In the traditional “water fall” approach, the customer typically may not see anything for months. When they do, some of the requirements may have changed. With Agile, the requirements are fresh and can be exercised by the customer after each sprint.
Customers need to be involved, a critical need for which there is no replacement. By involved, I mean they need to participate in the user story development, sprint planning, and provide immediate feedback after each sprint. So, customers need to make sure they can allocate resources to this process. We cannot afford to let the delivery of a sprint sit for days or weeks without feedback that is disruptive to the whole process.
PPLM: Can these Agile techniques be applied to other activities besides software implementation projects? I’m thinking about product selection, hiring, etc.
Ben: The Agile process is very common to software development. Most developers are aware of Agile. The Agile process can be used for many other initiatives. For example, building a custom home uses the Agile process. The customer is involved in all decisions and can see incremental updates from the building foundation to the finishing touches. They may not call it Agile, but the components I just talked about represent Agile.
Another great example would be the product selection process. You can use sprints to clarify requirements, review candidate software solutions, meet daily to get status, determine show-stoppers, and make a final selection.
PPLM: For our readers, how would you recommend they get started with the Agile approach?
Take a “crawl, walk, run” approach. Start with a low-risk initiative that can be pursued in a short period. Pull together the stakeholders. Develop the user stories. Then plan two or three sprints, with each sprint being about one to two weeks in duration.
PPLM: What else should we know about Agile?
Ben: Agile is not new. It’s been around for over a decade and parts of it even longer. I didn’t mention everything about the Agile process. For example, sprint planning meetings and sprint review meetings can get involved.
Find a good book or search the internet. There are no shortages of resources available. In fact, just for the fun of it, use the Agile approach to establish Agile in your business.
This Practical PLM article is authored and edited by The vdR Group, Inc. along with contributions from selected partners including Aras PLM, a D3 Technologies partner.