Fields marked with a * are required


BigLever Software: Third Leg to the Platform Design Stool?

References Cited

Product Lifecycle Management (PLM)

iStock_000017304724SmallProduct configurability: that’s well worn ground, isn’t it?

Think about it. We’ve been talking about how to use software tools to enable organizations to design and deliver configurable products for well over a decade now. Over that time, a two-sided approach has seemed to have crystalized in the industry.

  1. On one side, you have configuration software solutions. You feed these kinds of software tools all of the alternatives and options that are available for a specific product. Then, based on certain selections, it can spit out the configured BOM and 3D model of a variant. Very useful tools for organizations who get their customers close to the configuration of the product.
  2. One the other side, you have modularity and platform design tools. With these tools, you designate exchangeable modules that fit together in a product platform per specific variants. These are great tools to drive increased reuse across a platform.

Now I’ll be honest. For many years, anytime I heard about a solution that could enable next generation configurability, I just waited to categorize it into one of these two definitions. And, in fact, that’s how my conversation with BigLever started. At the end of the conversation, however, I found that they’ve carved out a unique niche in this picture. Yes. That’s right. There’s a third thing that belongs.

In this post, I detail the capabilities provided by BigLever and offer commentary and analysis on the value it provides.

Capabilities of BigLever’s Tools

So, what the heck does this software solution do? It actually requires a process discussion to explain it. Let’s start there.

Nothing necessarily revolutionary here. Today, just in simple spreadsheets or documents, engineers and designers outline the high level capabilities a product must provide to the customer. Now, there’s some bleed over into requirements. But I would say these tend to be high level requirements, not highly detailed measurable ones.

As a next step, the aggregate feature profile is put together for products.

So again, this isn’t a Bill of Material made up of parts. This is a Bill of Features that describes everything the product can do.

OK. So you now have a Bill of Features for a specific product. How is that helpful? Well, the value is generated from the connection to things all across the engineering V.

Just to make sure its clear, each feature is connected to things across the entire engineering V. That could be concept sketches, a branch of requirements breakdown to functions to items, a systems level text procedure document, a simulation result and much more. Basically, any deliverable that is generated during the course of the engineering V development process is connected.

Once you create a Bill of Features, you aggregate all of the deliverables across the entire engineering V process for the entire product, taking reuse to a completely different level. The extend of which is felt very broadly.

Done correctly, such a solution could provide incredible value in allowing the organization to just focus on net new items. For the company, that would certainly reduce development costs, but more importantly it could dramatically reduce the amount of time required for development.

Commentary and Analysis

What’s my take?

To close the loop, I do see this as a third leg of the product configuration stool. It provides an abstracted layer to identify which capabilities or features are most important for a product that can drive the configuration of an existing product or the basis of a development plan for a new product.

In addition to that, I think this kind of solution, outside BigLever, doesn’t really exist today. Almost every other solution falls into one of the other two categories. And, as a result, it really doesn’t compete with other tools used in today’s development process.

So I do see a lot of value that this solution can provide. The caveat? For such a solution to work, it needs to be connected to many other enterprise systems. It needs to be associated with ever deliverable that could be reused. Obviously, that’s isn’t required. However, to get the full value of such a solution, those integrations are needed.

Recap and Summary

  • BigLever allows a company to define all of the features in all of their products in a universal list.
  • The solution then allows engineers to create a Bill of Features for each product.
  • Each feature is connected to a myriad of deliverables across the entire engineering V process. This includes deliverables like sketches 3D models, requirements, functions, simulations, test procedures and much more.
  • A Bill of Features identifies what deliverables can be reused across the entire engineering V process and what needs to be created net new.

There you have it, a brand new contributor to the configurability story. What are your thoughts? Is this a new solution? Do you think this more closely mirrors a system engineering approach that other solutions to date? Sound off and let us know what you think.

Take care. Talk soon. And thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required


  • ernoj

    Conceptually I like BigLevel’s way of thinking. If you examine the 3DEXPERIENCE platform it works as they have described in one platform.

    To do this right you need the granular, configurable data model. From there the structures (all of them: Requirements, Logical Diagrams, CAD/BOM, etc) all connect to that common configuration definition and connected to each other for traceability. This provides the way to tell which components in the structures can be on or off (effectivity) at any time. Ideally the effectivity rules are written for you by the system but that is for another discussion.

    I believe that this is the way of the future and the only way to really do practical digital twinning and digital thread. The duplication involved with clone and own would render any of the connections to difficult, time consuming and costly. The only way to do it is grow max case structures across multiple domains.