For e-commerce professionals and those involved in digital transformation, product information management (PIM) is arguably the most important system to consider. It maintains consistency and quality across all sales channels. When organizations consider implementing a new PIM system, a key question is whether full implementation is worth the risk or if a proof of concept (POC) implementation is the more prudent course.
For PIM, skipping the proof of concept (POC) may seem like the fastest way to save resources, but it will likely cause costly rework, delays, and overwhelmed, angry employees. A POC is more than just a test; it's a strategic insurance policy that helps avoid business and technical misalignment.
In approximately 50% of cases where PIM is implemented by large enterprises such as Acer or Bridgestone (both of which are our customers), a proof-of-concept (POC) project is conducted before we proceed with the full AtroPIM implementation.
Why Bother with a POC?
A PIM proof of concept (POC) is a brief, highly targeted initiative that provides validation that the selected software platform will meet your specific business and technical requirements prior to substantial investment. The POC transforms the project from a theoretical concept into a practical reality.
A POC should be strongly considered when:
- Planning Complex Workflows: A POC ensures that the platform can process unique or intricate product data workflows for your organizations (e.g., custom, multi-layered language localization, dynamic data inheritance, or intricate approval processes).
- Assessing Specific Functionality: When your requirements get more tailored, industry-specific, or custom beyond the boundary (e.g., pants with pockets business rules) for complexity, a POC is critical to assess the risk of incompatibility to the platform.
- PIM as a Strategic and Scalable Tool: When PIM is considered a strategic tool, expected to rapidly cascade across different brands, and regions, or channels, the POC should validate the system's architecture and possible performance, and scalability prior to widespread adoption.
In addition to all the intricate elements described above, a POC becomes mandatory in one important case:
When you have a feeling that PIM could not work for you.
This feeling usually comes from:
- No Internal PIM Experience: Your people are new to PIM and have not yet assessed the technical feasibility and usability.
- Major Stakeholder Doubt: Key business owners, especially in Marketing, Product Development, etc., are not convinced that the system will really resolve their issues.
What’s Possible to Work on a PIM POC?
A focused POC allows your team to get hands on the system and validate a few critical foundational elements with a small chunk of your data.
1. Data Model Flexibility (almost always)
Verify that the PIM system can accurately model your intricate product structures. You can do this by constructing a sample product hierarchy and establishing custom attributes and attribute groups. You can also test intricate variant/SKU management for complex products, such as apparel with a size/color matrix.
2. Business Process Flexibility and Access Management
Determine if the system can accommodate your specific content creation and quality workflows. You can use a simple data enrichment workflow (e.g., going from Draft to Ready for Web) to establish user roles and permissions, as well as defined data quality rules (e.g., mandatory fields for completeness).
Implement key user roles that mirror your organizational structure (e.g., product manager, content writer, approver, system administrator). Ensure that each role has the appropriate visibility and editing permissions for specific data elements, such as attributes, categories, and channels.
Verify that the system can restrict access based on subsets of data. For example, ensure that a content writer for region X can only view and edit products assigned to the X category or language version of the data, thereby testing the security model's granularity.
3. System Integration Funktionality for Data and System Integration (in rare cases)
Test the technical feasibility of PIM connectivity with other key enterprise systems. Test integration, latency, and data mapping. Establish a fundamental, read-only API connection to a master data ERP system or an assets DAM system to see if hosted data becomes visible.
This is the most difficult aspect to verify because you need to develop the integration before testing. Consequently, the cost would be incurred here in most cases, as opposed to the "normal" use case, not the "POC" case.
When Can You Skip the POC?
Under certain justified circumstances, an organization can confidently bypass a formal proof of concept (POC), especially when the risk is low and rapid, uncomplicated implementation is the goal.
Specifically, POCs are often not needed when:
- Small Scope, Phased Rollout: Your initial rollout is intentionally limited in scope to a small number of SKUs, a few core attributes, and a single, non-critical channel (e.g., a basic e-commerce site). You plan to expand functionality in later phases.
- Industry-Recognized, Standard Solution: You have selected a PIM system that is a proven leader in your industry and comes with standard, publicly documented integrations for all common systems in your tech stack (e.g., connectors for major ERPs or e-commerce platforms).
- Business Process Focus: You have determined that the main challenge lies in defining and agreeing upon your product data requirements (a business problem) rather than in the technical capability or feasibility of the PIM software itself.
- High Internal Expertise: Your team has prior experience successfully implementing the specific PIM platform you are considering, giving your company a high degree of internal expertise and confidence in the platform.
- Simplified Data Model: Your product data structure is inherently flat, simple, and non-variant-based, requiring minimal customization to the PIM's default data model.
- Open-Source with Developer Support: You are adopting a highly active, open-source PIM platform and have a strong, in-house developer team comfortable with direct platform customization and troubleshooting, reducing reliance on vendor-proven methods.
In these situations, it is a better use of your time and resources to focus on your requirements documentation and initiate a small pilot implementation rather than create a formal standalone POC.
There is a bridge between PIM implementation and customer experience. A POC is an engineering stress test that ensures the bridge won't collapse under the pressure of your business demands.