While iterating on our first version of a semantic business modelization for local food systems, we realized we were misleading. We took some concrete examples and realized we had too many objects to describe a product, we also realized when working on the logistic flows that we were missing some objects and relations. So we are going to publish soon a new version of that model. But meanwhile I wanted to write a quick post on the product modelization.
Bernard Chabot, the architect who supports us in the definition of our semantic business modelization, has been working with dozens of industries, in very different domains. From garments to energy, from heavy industry to agro-industry. He realized after all those concrete use cases that there were some common “patterns”, an underlying invariant model to describe products, which is the same for any product we talk about. It took us some time to understand how exactly that model fit for simple unprocessed food products, but now this use case have become very clear, and we are happy to share with you our common reflexion.
1- As required product = the “product” you define by the objective you want to satisfy, independently from what the product does
2- As defined product = the “product” you define by what it does, the functionalities, independently from what the product is, its nature
3- As designed product = the product you define by what it is, its nature, independently from how the product is made and by whom
4- As to be built product = the product you define by how it is made and by whom, independently from where it is built
5- As to be built local products = the product you define by where is is built, independently from when it is built
6- As built products = the product built at a certain time, by a certain person and following a certain production method. An as build product is then defined by a “product batch”, and each physical product belongs to a certain product batch.
Note that for the As required product (#1) and the As defined product (#2), those are not really “products” yet, they are products “in the making”, or “potential products”, but they are not yet realized into some designed product that has a shape, a texture, etc.
You can click on the image below to open the file :
1- The objective can be for instance : satisfy my taste pleasure
2- The function I want is : to be able to aromatize pastas. In our common language we might be tempted to use a “product” name for that, like “I want a sauce”, but here the “sauce” is not a product, it’s a description of the function “aromatize my pastas”
3- The product will be : tomato sauce, which can be defined by a composition (30% onion, 60% tomato, 5% garlic, salt, pepper…), which can be qualified by its nature, referring to certain product categories, like the GS1 Global Product Classification, or others (product type = preparation / sauce / tomato sauce). Or by some characteristics, like “gluten free”, or “without salt”, or in terms of nutrients or calories. This product can be composed of other products, like onions, tomatoes, which will also themselves answer certain functions (add chilly taste, find a good texture, taste of tomato, etc.) so those products will themselves be described the same way, in a fractal mode.
4- Then this product is produced by someone, following a certain recipe. Multiple recipes can produce tomato sauce. I can cook the onions alone first, or put all the ingredients at once in the pan. The recipe will probably depend on the producer, each product has its own “secret recipes” ;-)
5- The product will be produced also at a certain location, in a specific professional kitchen, or facility.
6- And it will be built at a certain date, defining the product batch of the actual physical jar of tomato sauce, with a specific expiration date.
The case of processed food fits pretty well in that generic universal model. Let’s go one step further and see how that applies to some unprocessed product like a tomato.
1- The objective can be for instance = have a balance diet.
2- To have that balance diet I need some functions, like a diversity of nutrients, chemical free solutions, I need certain calories, and I might want some other functions like “preserve the biodiversity”, or “can be eaten for finger food appetizer”
3- To satisfy those functions, multiples products can answer the need, but let’s say the “organic black cherry tomato” is a good candidate, a possible solution that meets the functional specification. The black cherry tomato is an old variety so it contributes to preserve biodiversity, it is poor in calories, rich in nutrients, etc. The nature of this tomato is defined by a variety (from some variety catalog for instance), it is composed of 100% the fruit of the tomato plant (no additive, no chemical residue, etc.). It is small and has a size that enable to eat it without cutting it in pieces, you can put it all in the mouse. Etc.
4- The black cherry tomato from producer A will be different from the black cherry tomato from producer B, because they use different cultural methods. One makes its own seeds, where the other buys them from a seed company. One sow in February in a greenhouse, the other sow them later in the field. One use some “organic accepted” pesticides, the other only uses natron as a treatment. So the “recipe” equivalent here is the “cultural method”, how is the tomato produced, how is it “built” ?
5- The location will be the farm location.
6- And the tomato will be planted and harvested at certain dates, which define the product batch the tomato belongs to.
This way of describing products gives a lot of flexibility in terms of how the actors concretely operates: a need (product 2) can be satisfied by many different products (product 3), and each product can be provided by various producers / manufacturers (product 4). It also enable a full traceability of the product in all the supply chain (product 6).
This illustration will help you understand the modification of the general semantic business modelization that we are going to publish and comment in a few weeks :-)
Want to take part in the discussion ? Contact us or leave a comment !
Some tips to understand the v.1 of the DFC standard
Deep diving into food products modelization
A first version of our business concepts ontology
How do we describe a use case? What are our use cases? Narrowing down to what is needed for our first prototype
Starting to envision the data architecture: the different steps of the data and the impacts of different technological approaches