I’m starting the next level of OpenBOM Basics series of blog articles. In my first series (OpenBOM 101), I covered the main features of OpenBOM in my 101 videos. You can watch them on openbom.com/pricing page or Youtube Channel.
Today, I want to talk about fundamental elements of OpenBOM data management. I will be talking about 5 things – (1) multi-tenancy; (2) data sharing; (3) reference-instance model; (4) catalogs and (5) bill of materials.
1- Multi-tenant data model architecture
Data modeling architecture is extremely important, especially during the times when you have multiple engineers, companies, contractors suppliers working together. In OpenBOM data is securely isolated, for each user, team and company. It means that when you login to your account, you see only your data of course. However, because of multi-tenant data architecture (similar to Google) you can easily share information between users, teams and companies. No export/import/copy of data is needed.
OpenBOM data modeling granularity levels includes catalogs, bill of materials, BOM levels, properties and views. More about it later.
2- Real time modeling and Data Sharing
OpenBOM model is real time and includes both definition of data (properties) and actually data (catalogs, parts, BOMs). Which means that you can expand OpenBOM data model in a flexible way at any moment of time by creating new properties, views and other related elements of data.
OpenBOM allows easy sharing of information. The simplest way to share data is the use button “Share” in BOM, Catalog, Order BOM, etc. You can share data for read, edit or you can use Team-View feature to provide more granular access to data by limited access to specific columns and setting up view filters.
3- Reference-instance model
OpenBOM is using universal model to store and manage data about product. It’s called reference-instance model. The idea of this model is to create a granularity around two elements Item reference, Itema Instance and Bill of Materials.
In terms of flexibility and simplicity, OpenBOM model is designed to be real-time and instance level accessible. It means, I can define a BOM and modify definitions of properties on the fly. This is important since it makes it very similar to so much loved Excel and spreadsheet. At the same time, it is structured since this data can be reused.
A reference is an abstract object that can be modeled in OpenBOM. This object has a set of properties and represents any part, assembly, or component (terms are sometimes different in different companies). I prefer standard and engineering parts. However, if you have a better name, please let me know.
So, reference can be a nut, a bot, a screw, an electric motor, or any piece of equipment you buy, manufacture, or outsource. OpenBOM is using catalogs to define references and configure data properties.
An instance is an actual part used in a specific product (engineering product or built product) or an entire product you build. So, if you create a skateboard, which has 4 wheels, then you have 1 reference of a wheel and 4 instances of a wheel.
A picture below shows how data is managed in OpenBOM to support Reference-Instance Model.
As you can see on the picture, references are represented as nodes, while instances are represented as links. OpenBOM allows you to create and customize properties on both reference and instance model. As an example, you can add a property to a catalog (Eg. Cost) and all Items of this catalog will get this property immediately regardless of what BOM this item is used. At the same time, you can add instance property (eg. Reference designator) to a BOM, which will be only used for electronic BOMs and won’t be available and used for mechanical parts. Bottom line – you can define any product data using this model.
Properties are building blocks of information in OpenBOM. Current release of OpenBOM supports nine types of data – Text, Number, List, Multi-selection List, Reference, Image, Checkbox, Currency and Date.
More about it OpenBOM property and property types.
BOMs and Catalogs
These are two fundamental elements of OpenBOM information model. Catalog(s) are used to store information about Items and BOM are used to create a structure of item instances.
The following picture gives you an idea how it works.
What are fundamental best practices of managing data in OpenBOM. The picture below shows you 3 possible options (model).
The first model is a simple flat BOM created (or imported from a spreadsheet). Not much sophisticated, but it gives you an ability to track history, share data and make calculations.
The second model is what was the main option to create a BOM in OpenBOM. However, new release gave few additional options, such as create a BOM with already assigned catalog. It gives much-wanted simplification when you create a BOM (no need to go and assign catalog).
The third option is the most comprehensive and it just became available in the last June 9th release of OpenBOM. You can now create a BOM directly from BOM catalog item. The advantages of this mode are that together with the most comprehensive data model organization it simplifies the workflow and eliminate the need to double enter BOM Part Number and Catalog after and during their creation.
Below is a summary table, pros, and cons.
This article gives you some idea about how OpenBOM manages information, data architecture and best practices of planning your data management in OpenBOM.
A typical data management planning workflow in OpenBOM includes – defining (or selecting) properties, planning and creating catalogs, creating BOMs (either by importing Excels of using CAD plug-ins). Once you are done with these tasks, you can move forward and do other important things such as rollup cost, planning purchases and more. I will talk about it in other articles.
Best, Oleg @ openbom dot com.
Let’s get to know each other better. If you live in the Greater Boston area, I invite you for a coffee together (coffee is on me). If not nearby, let’s have a virtual coffee session — I will figure out how to send you a real coffee.