We implement a PIM without the project getting complicated halfway through

What is the CRITERIA Framework?

The CRITERIA Framework is the proprietary PIM implementation methodology we use in all our projects. It consists of six phases in order: Insight, Design, Build, Execute, Delivery, and Optimize. Each phase has a clear objective, concrete activities, and a deliverable that the client can review before moving to the next one.

It is not a framework built from a book. It is what we have learned in over seven years implementing PIM in fashion, home decor, industrial distribution, pharmacy, auto parts, and food. Each phase solves a problem we have seen repeated in real projects.

If there is one thing we know for sure, it is this: PIM projects do not fail because of the tool. They fail because someone skips a phase to “start faster.” This framework exists so that doesn’t happen to you.

The 6 phases of the CRITERIA Framework

1. Insight — Understanding where you stand.
2. Design — Designing the data model before touching anything.
3. Build — Configuring the PIM and planning integrations.
4. Execute — Loading real data, integrating, and training the team.
5. Delivery — Going live without surprises.
6. Optimize — Stabilizing, measuring, and improving.

Phase 1 · Insight: How organized is your product universe today?

Insight is the discovery phase. Nothing is configured here yet. All we do is understand what you have, where you have it, and how mixed up it is.

Why this phase matters more than it seems

Most companies believe they “have their data in order.” Then we open the spreadsheets, look at the ERP, check the marketplaces, and the truth emerges: the same product loaded three times with three different names, photos in four Google Drive folders, technical specs that no one knows who approved, and a master Excel file that hasn’t actually been a master for two years.

We don’t say this as a criticism. We say it because it happens in 90% of the projects we start. And if you don’t discover it now, you will discover it late — when you are already loading dirty data into the new PIM.

What we specifically do

• We assess the product universe you are going to enter into the PIM: how many actual SKUs, how many variants, how many discontinued items still in circulation.
• We map the data sources: spreadsheets, ERP, website, marketplaces, points of sale, printed catalogs, online catalogs. Everything that currently stores product information somewhere.
• We audit digital assets: product images, lifestyle photos, videos, technical specs, PDF catalogs, logos, certifications, 2D and 3D plans, video tours, animations. We review formats and nomenclature. And we evaluate if adding a DAM makes sense.
• We list the product data that exists today: attributes, categories, variants, images, documentation, families, or attribute sets.
• We identify source systems: ERP, spreadsheets, databases, whatever triggers data today.
• We analyze current flows of how product info is managed and published. Who loads, who validates, who publishes.
• We evaluate current channels and objectives: eCommerce, marketplaces, catalogs, POS. This is where the difference between what you have and what you want starts to show.
• We identify key problems and business objectives. A PIM isn’t implemented just for the sake of it — it’s implemented to solve something specific.

What you get from this phase

A functional and technical analysis document of your product information ecosystem. With that, you know, in black and white, where you stand. And we know what project we are going to do.

Phase 2 · Design: How is the data model designed before touching the PIM?

Design is the phase where the PIM data model is designed, existing data is cleaned, and taxonomies are defined. It is the phase that yields the most results, and the one that is most underestimated.

Why this phase matters more than it seems

The data model is the only thing that outlives the tool. If tomorrow you change from Akeneo to Sales Layer, or from Plytix to Pimcore, what is preserved is the model. That is why this is the real asset of the project, not the software configuration.

A well-known fashion company skipped this phase to “move faster.” Three months later, they were redoing the taxonomy inside the PIM with the data already loaded. It took them twice as long and they paid for consulting hours they could have saved.

What we specifically do

• Cleaning, standardization, and enrichment of the data to be migrated. This is where duplicates, unit inconsistencies (is it in cm or mm?), and attributes loaded with ten different spelling variants (“aluminum”, “Aluminum”, “alu”, “Alu.”, “ALUMINUM”) appear.
• Taxonomy design: categories, families, technical classifications. How your catalog is organized into a tree that makes sense for your business and your channels.
• Asset centralization: images, renders, technical specs, videos. All in one place with clear criteria.
• Normalization of file nomenclature according to SKU or logical code. An image cannot be named IMG_3847.jpg — it must be named so the system can find it automatically.
• Definition of the target PIM data model: attributes, data types (text, number, list, boolean, reference), variants, relationships (cross-sell, upsell, accessories, spare parts).

What you get from this phase

The PIM data model document and the taxonomy approved by all areas that use the data. With that signed off, only then does it make sense to start working with the tool.

Phase 3 · Build: How is the PIM configured and integrations planned?

Build is the technical phase where the PIM is parameterized according to the approved model and integrations are designed. It is the phase where the project stops being a PDF and starts having a screen.

Why this phase matters more than it seems

Integrations are the point where most PIM projects fail or end up with technical debt forever. Not because of technical difficulty — but because of a lack of prior design.

“Who is the master of the precio attribute, the ERP or the PIM?” That question must be answered here, not when you are already in production and two systems are fighting to overwrite the same data.

What we specifically do

• PIM parameterization: attributes, families, product types, cross-sell and upsell relationships, variants.
• Configuration of users, permissions, workflows, and data quality validations. Who can edit what, who approves what, and what automatic controls run before publishing.
• Design and mapping of inbound integrations: how data enters from the ERP, spreadsheets, or via API or batch. Which ERP field corresponds to which PIM attribute.
• Design of outbound integrations: eCommerce (Shopify, VTEX, Magento), marketplaces (Mercado Libre, Amazon, Falabella), printed or digital catalogs, internal apps.
• Definition of export channels and data transformation profiles. Each channel requires different things: Mercado Libre has specific attributes by category that Shopify doesn’t even record.
• Functional validation of the model in a staging environment before operating in production.

What you get from this phase

The PIM environment already parameterized and a technical blueprint of integrations. Documented. With diagrams. So that anyone can understand how the system is built without having to call you on the phone.

Phase 4 · Execute: How is the actual catalog loaded and the team trained?

Execute is the phase where integrations are run, the actual catalog is ingested, and the client’s team is trained. It is the phase where the client starts to touch the tool.

Why this phase matters more than it seems

Adoption is the most underestimated point of the entire project. Technical implementation is the easy part. The hard part is getting the team that loads, validates, and publishes products daily to actually use the PIM, understand it, and change their way of working.

We have seen perfectly implemented projects that after six months were underutilized at 30% because no one trained the team well. The tool was there — the data culture was not.

What we specifically do

• Implementation of integrations ERP → PIM and PIM → outbound channels.
• Ingestion of an initial batch of real products for testing. Not made-up test data — products from your catalog.
• Configuration adjustments based on the results of ingestion and validation. Cases always appear that the model didn’t 100% account for.
• Data consistency tests and coverage of the use cases defined in Phase 1.
• Education and training at three levels: end users (those who load daily), super users (those who validate and resolve internal doubts), and administrators (those who configure and maintain).

What you get from this phase

A functional environment validated with real data, tested integrations, and a team trained to operate. If something that doesn’t work appears in this phase, you still have time to correct it without impact on production.

Phase 5 · Delivery: How to do the go-live without surprises?

Delivery is the go-live phase: the transition to production of the already validated PIM system. It is the phase that generates the most expectation and the one that goes best when the previous ones were done well.

Why this phase matters more than it seems

If the five previous phases were done conscientiously, the go-live should be boring. And that is what we want. A boring go-live is a successful go-live. “Exciting” go-lives are the ones that end with the team working on a Saturday at two in the morning to unblock something that wasn’t foreseen.

What we specifically do

• Final review of data and configurations. Last pass before the switch.
• Validation of integrations in the production environment. Everything that worked in staging, now with real data running.
• PIM system go-live.
• Checklist for correct publication in destination channels. Ensuring each channel is receiving what it should, in the corresponding format.
• Activation of technical and operational monitoring to detect any anomalies in the first few weeks.

What you get from this phase

Your PIM system in production and your catalog published. If the planning was rigorous, you notice it because things keep working — not because something stopped working.

Phase 6 · Optimize: What happens after going live?

Optimize is the post-go-live support, stabilization, and continuous improvement phase of the implemented system. It is not an optional phase. It is the one that defines whether the project was an investment or an expense.

Why this phase matters more than it seems

The first 30 to 60 days after a go-live are the most critical. Edge cases appear that no one had foreseen, integrations that behave differently in production, operational doubts from the team that is only now using the system for real.

If you have support during that period, the system stabilizes and starts generating value. If you don’t, problems accumulate and adoption drops.

What we specifically do

• Post-go-live technical and functional support during the first 30 to 60 days.
• Issue resolution and fine-tuning of the configuration.
• Review of system use and adoption: who is using the PIM, who isn’t, where the bottleneck is.
• Incremental improvement plan: new attributes that appear, new channels being added, flows that can be automated.
• Measurement of project impact against the business objectives defined in Phase 1. Return rate, time-to-market, attribute coverage, completeness by channel.

What you get from this phase

A stabilization report and a proposal for continuous improvement. PIM is not a project that ends — it is an asset that evolves with your business.

Why does this framework work?

Because each phase solves a specific problem we have seen repeated in real projects:

• Insight prevents you from starting without knowing what you are migrating.
• Design prevents you from putting dirty data into a clean system.
• Build prevents integrations from becoming technical debt.
• Execute prevents the tool from being ready while the team is not.
• Delivery prevents chaotic go-lives.
• Optimize prevents the project from losing traction after six months.

No phase is optional. And if a provider offers to skip any “to save time,” that is the first sign that the provider hasn’t implemented enough projects.

What now?

If you are evaluating a PIM implementation and want to see how this framework would apply to your case, we can start with a diagnostic session. In 60 minutes, we will look together at what phase your operation is in today and what you would need to get to the next one.