Preparing to Adopt AIPreparing to Adopt AI

This topic is too important to suggest anything other than – BE ALERTED of its IMPORTANCE. Based on the Jan-2026 Boston Consulting Group article As AI Investments Surge, CEOs Take the Lead. “About 90% of CEOs believe that by 2028, AI will redefine what success looks like within their industry. “ Further stating “… that end-to-end transformation maximizes ROI on AI investments.”

This forecast of AI adoption by companies in the Retail, Consumer Products, Consumer Packaged Goods, and even Discrete Manufacturing industries MUST form what Oleg Shilovitsky presented as Product Memory.

Product Memory is the overall amassing of select digital content from the vast number of silo systems that are intimated (intelligently integrated) to ensure that ALL common data fields remain consistent between silo systems. The reason for this should be obvious – but for those that need clarity of this requirement, you need to consider that ALL silo systems that share data fields with other systems (considered common data) are expected to pass this common data in combination with data unique to each silo system.

For example, an obvious record would be the Product ID or the Item # or the SKU or whatever term is used per silo system. Another example could be the Retail $ Price (from the Assortment Planning silo system), passed to PLM to become Retail $, passed to PIM to become Retail.

If the Retail $ Price is used in the Assortment Planning system to calculate the Margin and its value is changed in the PIM system, then it MUST be passed back to PLM and Assortment Planning to ensure the value is consistent.

This is because each of these systems serves a purpose and if the Retail $ Price has been reduced because an authorized user reduced the Product’s Retail price, then those assessing the Product’s Margin may choose to eliminate it from the market. Even if they choose to keep it in market, the data posted to Product Memory would have been “last one in wins” – meaning the Retail pricing would be that of the PIM system (last system to post its common + unique data fields) would overwrite the “common Retail $ Price” unbeknownst to those of the other silo systems.

Therefore, BEFORE a silo system can be integrated with the Product Memory – it MUST be intimated with ALL upstream and downstream systems. This includes the proper data governance as it applies to access (Read, Write, Update) to shared / common data across silo systems. If the (previously discussed) Retail $ Price can only be set by Merchandizing (or Product Line Management), then it would be secured as uneditable in PLM and uneditable in PIM – thereby eliminating the need to pass its changed value back to PLM and Assortment Planning when changed.

Once this has been achieved, it is then possible to integrate (unidirectional) each silo system with the Product Memory. Since all data is being harmonized, it is necessary to map each silo (source) system with Product Memory through a form of what DSG calls the Meta-Layer – responsible for applying all common attribute mapping requirements and reviewing data values to enforce rules of equivalence.

As a quick note: common attribute mapping is the process of transforming (relabeling; formatting) attributes to comply with the profile of the Product Memory. An example could be as noted previously PLM using Retail $ as its attribute label, while Product Memory has Price. That is a label difference, but it could be that PLM has Description of 2,000 characters, whereas Product Memory has the exact same label but has only 264 characters – requiring that the size be truncated (not reworded). It could also be how Product Memory store pick-list values or date fields become text, etc…

The enforcing of rules of equivalence is a bit more obvious. If the Product ID is the “key” value and the Item # in ERP or the SKU from ecommerce must be equivalent to an existing Product ID, then any record that doesn’t match fails and is send back in error. These rules of equivalence occur less often than 1% of the integrations – but must be put in place “just in case”.

As silo systems become intimated with their upstream and downstream silo systems, they qualify to be included in feeding Product Memory. It is recommended that the trigger of data from these silo systems be done either in real-time or based on a schedule (per hour; per 12 hours; per day).

What gets sent through the Meta-Layer and passed to Product Memory should include:

• Common Data Fields – those data fields that map between silo systems. One example is the Product ID or Item # or SKU as referenced previously. Not all data fields that map must be equivalent between silo systems, using Description (truncated from PLM to Product Memory) as an example.
• Unique Data Fields – those data fields are considered of value to pass to the Product Memory but are unique to this specific silo system. An example might be the Customer Region (from the ecommerce facility pertaining to the customer’s location if located in the United States).

As we finish this quick review of how Product Memory can become an active member of the technology stack of a Retailer, Consumer Products, and/or Consumer Goods company, it is necessary to touch on one area of product data that has been missing in most PLM systems. That missing data element is “why” change occurs; what is the basis for a given decision to replace a specific part in an assembly; what was the basis of replacing a material or material type.

In some instances, this data exists as a required “field” in an ECO, but most often this information isn’t tightly coupled to the change process. Based on the review of a wide range of companies, the “why” is often found in emails, meeting minutes, or messaging – feeding the decision process. The decision is recorded, but (unless otherwise required) the reason (the “why”) is nowhere to be found in the existing PLM system.

For that reason, and in the advent of Agentic AI, it is strongly recommended that AI agents be formed to interrogate Office tools (emails, documents, messaging) to identify where a given ECO or Part number or a Product ID is referenced. This “finding” needs to be assessed as per its associated relevance and (in specific cases) validated by someone that was part of the dialog, message, or meeting to then have that specific content (i.e. document) placed in Product Memory with the necessary association.

Putting all of this together in the above diagram results in a harmonized data model being fed into Product Memory, where anything that has product or business relevance is aggregated. With that formation of multi-source (silo) systems data, AI can be unleashed to seek out correlations of data (cause-effect) that couldn’t have been possible because the density of the data is too far reaching.

The results of such a form of data panacea is that (for example) a $200M company can easily see $2M in annual net economic value (combined cost savings + revenue/margin uplift) once mature, with payback on the initial harmonization investment often in 6–18 months and 3–10x ROI over 3 years.

Add to that the value benefit of AI triggering alerts when data is inconsistent or formulating declarative insights for product and business operations will result in better demand forecasting, dynamic pricing, and product optimization (e.g., correlating PLM attributes with e-commerce sales/returns) yield 3–15% revenue uplift (or $6-30M) or 10–20% sales ROI improvement for that same $200M company.

Continuous AI analysis (enabled only by harmonization) supports real-time anomaly detection, predictive analytics, and cross-functional recommendations—unlocking 15–30% productivity gains in manufacturing/engineering and up to 186% ROI in AI-enabled PLM cases (payback in less than 1 year).

To summarize: The key is to (1) intimate the silo systems to ensure data consistency across all silo systems participating in the lifecycle of a product; (2) formulate the integration of each silo system based on both common and unique data that can have influence on the product’s ability to create revenue and as per the business operations; (3) configure the Meta-Layer to ensure proper mapping and validating of data as it is prepared for posting to Product Memory; and (4) formalize Product Memory to serve as the data repository for AI to execute a continuous learning model for Product and Business Insights.

If this makes sense and your company isn't making moves toward this highly beneficial profile, then contact Digital Solution Group to help you get things defined, including the business ROI to get it approved. Email: brion@digitalsolutiongroup.net or call: +1-603-566-5382