SPK and Associates co-founder Chris McHale speaks with PLM expert Oleg Shilovitsky, founder of BeyondPLM.com, to get his insight on the difficulty of BOMs across engineering disciplines. The pair will soon follow up with another podcast talking about the difficulty of managing the BOM across the enterprise. So with that introduction, here is Chris and Oleg’s second podcast episode of “Talking Beyond PLM” followed by a transcript.
Transcript:
Narrator: You’re listening to the SPK and Associates podcast.
Chris: Hi, this is Chris McHale, co-founder and COO of SPK and Associates, which is a technology services company dedicated to accelerating product development in manufacturing companies. I’m here with Oleg Shilovitsky, who is a well-known blogger on product lifecycle management topics for the last 5 years. Oleg and I are presently producing a podcast once a month, where we dive a little bit deeper into one of his key topics from recent blogging posts.
So, Oleg, would you just take a moment to introduce yourself?
Oleg: Yes, sure. Hi, this is Oleg Shilovitsky. I’m a blogger and consultant in the PLM space. And I write my blog about PLM and related technologies. You can read about these at beyondplm.com.
Chris: Okay, great. Oleg, today I thought we would focus on the broad topical area of the growing difficulty of managing BOMs in the product development lifecycle area. It’s divided into two areas. One is the difficulty of managing BOMs across engineering disciplines, such as mechanical EE and software. And then also the growing difficulty of managing a BOM across the enterprise or across the product lifecycle, for example, from design into build, release, maintenance, service and so on.
Since this is a pretty broad area, I thought we would divide this up into two podcasts and today we would focus on the difficulty of BOMs across engineering disciplines, and then follow up with another podcast shortly where we talk about the difficulty of managing the BOM across the enterprise.
So you’ve mentioned that you’ve been doing some blogging about this in the last month, or really over the last several months, and you’ve gotten a lot of interest, a lot of commentary on this topic, which is always a challenging topic. And I thought I would just start by asking you in this area of managing a BOM across engineering disciplines, what are you seeing as the key challenges or holes today? If you could just start to set the stage for our audience by just describing what are the challenges and what are people faced with today.
Oleg: Sure. Again, bill of materials is such a fundamental topic. And as I mentioned, discussion about bill of materials always can bring a lot of questions and commentary. And this is really a complicated topic. So if you think about anything that engineering and manufacturing are doing, you really cannot go and do anything without bill of materials. However, the biggest challenge and the biggest complexity of the bill of materials recently in engineering came from the complexity of products itself. If you think about products, they are not mechanical or electronic or software.
So today every product that you create, it’s a combination of all this sequence. It’s obviously some mechanical products assembling, and it’s electronic and electrical parts. And today even more relevant, we have software pieces much more integrated in the product. So this is the root cause that we have a real complexity of product information and BOM in particular. And if you will start speaking to somebody in the organization and you start speaking about bill of materials, there’ll be immediate question that you will get, “Well, what bill of materials are you talking about? Is it an electrical bill of materials or mechanical bill of materials?” So these kinds of questions are commonplace.
And the second type of questions that always are coming together is how to manage them in a certain consistent way, then you can represent the bill of materials of a product.
Chris: Okay. Just a quick follow-up question on setting that stage. There’s obviously these engineers, I would suggest anyway. Typically they are possibly sitting in different groups. You’re got mechanical engineers often in one group, EE and then software in another group. Obviously they come together in terms of developing a product, but they tend to be different people and they often are reporting to different people. And they even tend to have different personalities, if you will. I was wondering if you have comments on that in the softer area of just bringing different kinds of engineers together and the challenges that that brings about, before we dive into the tools and the technical ways that the bill of materials can be managed.
Oleg: Yes, sure. That’s a very good question, because it certainly defines the level of responsibilities and the organizational structure in the company and then, indeed, people are responsible for different things. A mechanical engineer is responsible for how the product will be billed in terms of structure, and its form factor is significantly involved. And today I almost had to bring any product without circuit boards or electronics that are heavily involved in and software is coming.
I think that we need to look at how these people are working together and what level of impact each group has in their development process. So clearly mechanical parts are traditionally considered as the function that will give a significant impact on everything else because you can change the form factor of the product and the result. You will have to change electronic board. You will have to change fixtures. You will have to change some components that probably will not completely [inaudible 00:06:51]. So that’s the most traditional way to think about ways that mechanical products will impact electronics. But obviously there are some other examples.
So what I think is important is for people to work together, and it’s really difficult to do because they are using different tools.
Chris: The area that you typically refer to or the tool that’s typically referred to as PLM, or product lifecycle management solutions, grew up in mechanical CAD area. So it initially was doing a lot of data management in the mechanical CAD files. And so it tends to be oriented more in that discipline, if you will, although I think pretty much every PLM tool out there today will say, “Well, we manage other things. We managed the BOM and the data from other disciplines.” And there would be differing views as to how successful that is. But that is, I think, what most are saying.
So the thing I would like to hear your opinion on is there is this philosophy, and it’s especially growing now as the product is becoming more and more complex. There is this philosophy growing that each of the engineers in the engineering areas, who, as you’ve mentioned, have their own tools, should really manage their own data with their own standalone data management tools that plug in and integrate beautifully with the design tools that they’re using. So for example, in mechanical CAD, if they’re using SOLIDWORKS, use a product data management system that integrates beautifully with SOLIDWORKS, if they’re on the software side, software developing an IDE, use a software configuration and management tool that marries into that beautifully.
So again, the philosophy is it lets them do their own thing with their own tools and their own data management. And then at some points that are identified, then bring that data into a more centralized tool like PLM. I’m just wondering what your thoughts are about that, and that would be compared to the philosophy of, no, everything should be in PLM, and PLM should have a breadth that’s able to manage all of that. So if you have any thoughts or your comments on that.
Oleg: Sure. I was going to answer on this question. I think we need to go and understand a little bit about the industries that they are talking about because it’s not all the same across all the industries. As you think about traditional PLM industries like aerospace, defense, automotive, or even industrial equipment, the form factor was a significant influencer of the kind of CAD systems that are dominant in this industry. So this is what produced the vision of PLM but it also was something that connected the two M-CAD in a very significant way. For these industries, traditionally the influence of electronics was much less significant.
And also in terms of groups of development and people that develop the OEMs are very involved in the mechanical development much more than electronics, where in some cases for the outsource to supply, etc. It’s really at the core philosophy of PLM teams. Now, in part, though, the teams, the companies that are in the electronic industry, the high tech industry, they’ve been using electronic design tools for years, of course. And all of these tools, they have their own data management solutions. They may call it PDM or not, but they do have separate data management solutions. This is sort of reality that I think is in the industry today. They’ll have mechanical CADs, their own PLM systems, and electronic and electrical CADs and their own PLM systems.
And as much as the product is getting more complex, companies are asking more questions about how to get them working together and separately because a lot of growing complexity are coming some of the changes in how to manage the overall lifecycle. And there is a link between these groups. And to make them working together, it’s a challenge for a company. That’s why a company comes in with the questions of how to manage the cross functional changes and do it more efficiently.
Chris: So that’s an interesting point. Those are interesting points, Oleg. I’d actually like to dive in a little bit deeper on some of the differences between industries because it strikes me that in certain industries, such as you mentioned, aerospace or automotive, there was the prominence, if you will, most important engineering area tended to be mechanical for a long time. But then, as time has gone on, in really every industry but in these in particular, too, the electronic and also the software components have grown quite drastically at times.
And I’ve noticed myself, it’s an interesting thing to watch an organization grapple with a very different kind of engineering growing in prominence and how to pull that data together and pull those teams together in order to have them produce something that is of high quality and you can use it efficiently as well.
Since PLMs tended to be this form of mechanical-CAD-oriented tool or solution initially, what do you see right now as the pros or cons or capabilities of PLM in being able to manage the bill of materials, incorporating also the EE pieces or components, as well as the software components. Do you think that this is being done well or not at all? What’s your opinion about that?
Oleg: No. It’s a great question. I think I would separate between two topics here. First of all, I would be speaking about mechanical parts and electronics. I think these are two disciplines that there is a huge demand for the right configuration and bringing this information together at the end. I think the demand of customers is a more cohesive way to manage this information together.
At the same time, if we come back to a question of software, I don’t think there were conclusion among customers on how to do so because software tools and software ALM tools, application lifecycle management tools, were developed significantly over the last 5-10 years. And they are really mature and provide good solutions coming from also open source solutions and some proprietary solutions. So I don’t think companies are ready to make a conclusion how to manage software in PLM systems. So I would expect hear greater conversations in coming years also between vendors and also among customer to understand how to do it in the right way.
Chris: I noticed your first comment related to mechanical and EE together because what you were talking about there are still things that have to fit together, from a product perspective, that have to sit together and work together. With software, it’s always insane as well. You’re out there developing your code, and then eventually a binary shows up, to be simple, and either gets [inaudible 00:15:14] on if it’s embedded or included as part of the product. And so it tends to operate a little bit out there by itself.
And some of the companies that I’ve seen, they actually will go so far as to really leave that with the ALM off to the side. And then, when they get down to releases or, at least, milestone releases or milestone builds, they’ll just say, “Hey, give us a binary and we we’ll put that in PLM and have it be there.” Is that the kind of thing that you’ve seen too, or have you seen more integration? I’m just curious and, I think, our listeners might be curious as to what the different examples of that that you’ve seen out there.
Oleg: No, I think you defined it very well. I think you defined it good in terms of connecting the mechanical pieces and electronic pieces because I really think that should play together, and it’s software, it’s easier. I mean, the software baseline in terms of bill of material management are important because you really want to know what software builds you want to put in a particular product. So again, it’s still eventually you’ll have to integrate. But the level of integration of this information, bill of materials will be defined, I would say, later – the software and the electronics and mechanical parts.
Chris: Yeah. And one thing that’s interesting is that, and this is maybe a little off-topic, but both PLM and ALM over the years developed their own requirements management modules, for lack of a better term, within each of those tools or solutions. And they’re slightly different because the software requirements management tends to be a little more involved, and there’s usually test cases and things like that that need to marry up to those requirements.
And there’s less of that that’s written in terms of testing on that mechanical side. What have you seen regarding the management requirements in some of these various customers you’ve been involved with? Is it done really in PLM? Is it done completely separately? Is it done in ALM? Just curious what your experience of that has been.
Oleg: Yeah, that’s a great question because management of requirements is one of the critical topics, if you will, being how to close the loop between requirements and actually product that’s manufactured after all. So I think, again, there are multiple tools to manage requirements and some of them more applicable for software space, for software development. There are tools, there are open-source tools and there are some proprietary tools.
And there are tools that used to manage requirements in your own space. If you look on major PLM proprietors, they have requirement management tools, and some of them are done in partnership with other companies. Some of them are acquired. So this is definitely a topic on the table. I see it mostly implemented for larger manufacturing companies there, the higher level of complexity and many people involved and greater complexity of communication and collaboration within the teams. I think the smaller companies have tendency to use an Excel spreadsheet to manage requirements or some other traditional office tools. You can see it more often. They do not tell you that this is not important but they just have different priorities in terms of implementations of tools.
Chris: Right. I have seen in some industries, for example, life sciences and I’m sure, to some degree, automotive, I’m not familiar with that, that the whole compliance question becomes pretty critical. And when it comes to requirements and testing and so on, there’s a lot of traceability reporting that’s required by the governing body that a particular industry is answering to. And so the whole requirements test case traceability question becomes quite time-consuming. If it’s done on spreadsheets, it can be really time-consuming. But it is very time-consuming and a huge effort in and of itself. Have you see much of that or any comment on that?
Oleg: I agree completely. I think bill of material management, which describes all aspects of the product and also tracing back to requirements is the most important and instrumental thing. You should think about compliancy and regulation, and requirements for compliancy and regulation is growing. The demand of companies for better bill of material management across disciplines is growing. It’s not only in aerospace and defense, but it’s also in consumer goods and it’s also in food industries, the medical industry and equipment, and pharmaceutical. So you can see a lot of regulated industries that requires better management of BOM and traceability between requirements and actually performing products.
Chris: It almost seems, and this is a little bit off the wall, but because product complexity is growing, and we’ll talk next time, we haven’t even gotten into the whole aspect of managing the BOMs across the enterprise, it’s almost as if the PLMs, DLMs, ARPs, BOM modules or BOM capabilities, within each of these tools, it’s almost not up to the task in a way because each of them are focused in their own areas of the company, so to speak. In this case, we could even talk about it across engineering disciplines. It almost seems as if there is a need for yet another tool. I hate to say it, but something, which can sit above the systems and really manage that BOM and be so much more flexible in terms of how it looks at the BOM and views the BOM and manages the BOM through the lifecycle and across the engineering disciplines. So what do you think about that idea?
Oleg: Yeah. It’s a great point and a very valid question. I’ve heard about this many times and the question of, do we need another solution for enterprise to manage bill of material – I don’t think there is a consensus. There is no consensus between customers and the results between vendors here. I would guess for customers it goes directly to the organizational structure because today, multiple bill of material is often a reflection of the organizational structure of teams in the engineering department. And there should be some sort of agreement between teams how to manage that. And we know it’s hard to get an agreement between people because people like to own something that they do. And they don’t like when somebody’s touching what they’re doing.
Between vendors, it’s a big question of competition because if ARP and PLM vendors are competing in the space for money of customers, obviously they will pretend to manage more information, and bill of materials is perfect way so they can compete. They probably can see some attempts from PLM vendors to introduce more manufacturing-related bill of materials functionality. And it obviously comes across, some opinions of ARP vendors, that ARP is the best place to manage manufacturing BOM. So we will see this topic coming across. There’s a competition between vendors.
Chris: In a way, as the product lifecycle expands or grows or becomes more complex, and people are managing the service side of things, when we start introducing the Internet of things and trying to get smart devices out there that you’re needing even more information about or specific BOM information about. I just see this growing in complexity and becoming an ever-expanding problem.
Oleg: Yes, I think the real complexity of products will introduce a greater complexity of requirements to the tools and the bill of materials tools in the first place. So eventually it will come down to the ability of a company to manage information in the right way. So you need to release a product, then companies will have to have the right bill of material information to get this product released and manufacture it. And that’s that, it will come eventually to this notion.
Chris: Okay. Well, we could go on and on about BOMs and engineering disciplines, but I think we’ll probably leave it at that point for today. And the next podcast, what I’d like to do is explore with you, Oleg, the management of the bill of materials across the enterprise or across the lifecycle of the product and the challenges that are encountered there. So thanks so much for your time today, we really appreciate it, and for sharing your knowledge and your ideas with us. And we look forward to the next event.
Oleg: Thank you for inviting me. I look forward to discuss this topic more. And thank you very much.
Chris: Okay, thanks, Oleg.
Narrator: You’re listening to the SPK and Associates podcast.
