Product 360

Business Challenge

Delivering accurate, rich, and relevant product information across multiple channels at scale can be quite challenging. Especially when product data is incomplete, stored in siloed systems, and constantly changing. Whether a retailer, manufacturer, services provider, public  sector organization or distributor, the needs of each of these organizations to provide consumer facing systems with descriptive and tailored product information leads many of them to consider adopting a product information platform; often referred to as PIM. Informatica’s PIM platform, Product 360 (P360), is in the product domain of the larger Informatica MDM Suite. This article provides an overview of the Product 360 implementation process to ‘tame the product data chaos’. While by no means exhaustive, it summarizes the major areas where planning is needed to ensure a successful implementation.

Analysis

At the beginning of the implementation is the best time to capture critical success factors, define a project charter, and outline budgetary plans and staffing. Each organization will have different goals, but typical goals include increased channel sales volume, replacing one or more legacy systems, SKU enrichment, reducing total cost of ownership, and quality targets. Hashing out organizational specific goals with sometimes competing stakeholders is not an easy process, but it is critical to determining phasing, budget, and staffing. Like product development, establishing a minimal viable product (MVP) for the first phase can help focus efforts on the critical first business value. Defining how success will be measured can help crystalize priorities and build a common team vision. Product 360 facilitates minimum time to first value by its modular design and large critical mass of out of the box functionality.

Understanding P360 and Aligning Business Needs

Understanding what P360 can do for an organization is essential. Learning what P360 provides out of the box vs. business goals is critical in determining which extensions and customizations are needed. At a high level P360 provides:

• Full lifecycle data management in a business user friendly UI (search, add, edit, check, approve)
• Data quality rules
• Data onboarding (Imports)
• Publishing (Exports)
• Data pool synchronization (GDSN, Atrify and ECCnet)
• Catalog management
• Digital Asset Management (DAM)
• Change Auditing
• Task Management
• Product Data Governance (via Workflows, Automated Tasks, Data Quality, Dashboard KPIs)
• Taxonomy Management

Product 360 is configurable well beyond its standard out of box features. Many of the existing P360 features are designed so that their base functionality may be further extended with extensions and/or customizations whether via the provided Software Development Kit (SDK) custom Widgets, or augmentation of the existing REST Web Service APIs. The P360 platform also integrates with other Informatica MDM domain platforms such as Supplier 360 and Customer 360 to ensure a comprehensive 360-degree MDM strategy for customers.

Establish a Business Preparedness Baseline

Like all Enterprise system changes, launching a PIM implementation involves typical project risks. These can be mitigated with careful planning and guidance from experienced implementors.

Project Staffing

Decisions will need to be made on staffing options based on available in-house expertise, timeframes, and partner input/availability. A RASCI (Responsible, Accountable, Supported, Consulted, Informed) matrix is recommended to clarify roles on the implementation team. The roles below are typically staffed as part of a standard PIM implementation -- in some cases, a single person with broader skills can fill multiple roles; or multiple people will be required for a given role based on effort estimates and schedule.

Some of the more typical project roles include:

• Executive Sponsor - Critical for leadership support and guidance, especially for priorities and budget
• Business Stakeholders - Business decision makers
• Project Manager/Scrum Master/Technical Deliver Manager - Tactical leadership
• Power User(s) - Someone who can champion the needs of the end user stakeholders. This individual is also generally an expert on current systems and data, would be considered a Subject Matter Expert (SME), and typically fills the business analyst and/or quality assurance role
• IT Architects - P360, Data, Enterprise --provide strategic counsel and expertise on P360, data and enterprise integration
• Java developer - For full lifecycle extension development using the SDK
• Systems Administrators - Business and IT administration. Responsible for monitoring, configuration, security access, etc. The go forward administrators for the organization to be autonomous on P360
• Database Administrator -Usually a part time role
• BPM Developer - For building the workflow automation that is typical of the P360 defined data governance processes
• DQ Developer - For building custom data quality rules
• Business Analysts - Capture requirements, facilitate discussions; some configuration, testing and enablement

Preliminary Data Preparations

During the preliminary stages of the P360 project the product data needs to be thoroughly analyzed. This may include data profiling via Data Quality. It will require the authoring and review of a product data dictionary. Additionally, during this preparation stage it is important to review data samples (data files typically) from each of the identified data source systems used to either ingest data into P360 for one-time onboarding, daily integrations, or both. It is during this review of the data that many of the data quality validations, transformations and formulaic fields should be identified as part of the larger data dictionary. Additionally, an organization’s product data should either be aligned with existing entities or listed as requiring its own custom entities. Data relationships between the various data entities should also be identified and discussed as part of these joint data analysis design sessions.

Discovery and Typical Analysis Deliverables

The next step focuses on discovery and solution design. Usually this is best accomplished in a series of workshop sessions. These sessions can be incorporated into project phases (iterative or not) or within Agile-styled sprints of varied duration. The focus of these workshops is to discuss, align on, and document decisions based on the following topics:

• High-level functional, system, and data requirements
• Establishing a data dictionary
• Media Assets
• Business process flows and summaries
• Overall project plan, roadmaps, phases, and staffing

Architect and Design

Analysis and Architect/Design phases typically overlap, but at some point the broad brush directions determined in Analysis need to be refined into testable requirements, user stories, and high/low level designs.

Defining the Data Model

During the early detailed design sessions, the data dictionary from the analysis or discovery sessions should be reviewed and the various product data fields that will live in P360 should be associated to entities or objects within P360. This is typically done via the creation of an abstract business data entity model which will then be aligned with the physical entities of the P360 data model. This should involve design discussions to determine whether the organization is best suited to a single-tier, two-tier or three-tier data model, all of which are out-of-box in P360.  Additional topics such as how lookup values (LOVs) will be maintained, legacy system data fields, and how taxonomy hierarchy / classifications will be managed should also be part of these discussions.

Detailed Design: Business Needs Transposed to Product 360

While sometimes referred to as fit/gap analysis or as feature/function mapping, existing business processes need to be defined at a level sufficient to confirm whether P360 will support them with out of the box functionality or if feature extensions will be required. Frequently implementations introduce new business processes or functionality enabled by P360 (perhaps even the reason P360 was purchased) or adapt processes to what P360 supports out- of-the-box. Changes need to be documented and/or communicated in a such a way that the organization can efficiently change to take advantage of the new process/functionality. Data Stewards, line of business owners (data consumers) and technical people will all play a role in this Fit/Gap analysis.

One major result of the detailed design process is the iterative review and overall organizational alignment of the over-arching solution.

Pillars of a solid Product 360 Design

During the P360 design sessions, many of the documented functional use cases previously identified to satisfy the business’ needs and pain points will all be leveraged to create the foundational Product 360 / PIM solution. These topical solution design areas include, but are by no means restricted to, the following:

• Product Origination and Onboarding
• Product Data Governance
• Product Assortments
• Product Channel Based Enrichment
• Product Pricing (Channel based or other)
• Product Kitting (Bundles or Bill of Materials)
• Product Classification(s)
• Product Distribution
• Product Key Performance Indicators (KPIs)
• Product Data Quality Metrics and Dashboards
• Product asset management
• Product monitoring

Environment Provisioning

When considering environment provisioning Informatica recommends the standard IT industry convention of provisioning at a minimum 3 environments (e.g., Dev, QA, Prod).  Todays technology landscape provides a number of ways  to provision these environments including on premise hardware , hosted environments via a third-party cloud host provider, or hosting by Informatica’s Cloud Hosting Services (ICHS). When deployment configurations and updates changes are needed, Informatica recommends making those changes in lower level environments bubbling them up to Production via formalized industry SCM (Software Configuration Management) procedures, where applicable. Backing up key essential configurations via the use of common version control platforms is also strongly recommended.

Build & Test

The build and test phase typically is performed in lower level environments to construct and validate the configurations, customizations, extensions, and integration of P360 with the rest of the enterprise. This includes testing inbound, outbound data feeds per pre-defined SLAs from the Discovery & Design sessions. Performance tuning testing is recommended to isolate any systems or defined business process bottlenecks before they can impact the schedule. It can significantly reduce risk to perform dry runs of deployment and IDL in the production domain, using proxies for integrating systems (good backup/restore SOPs can make this much more efficient). Standard SDLC best practices combined with Data Governance can significantly reduce risk in this phase.

Typical Build & Test Activities

• Installations for all environments
• Configuration
• Workflow & extension development
• Import/Export development
• System Integration and performance testing
• User provisioning
• User training
• User Acceptance testing

Planning Community Enablement

During the early stages of the project, the Project Management leads should work with the business stakeholders to ensure that appropriate training leads or train the trainers are identified whether that is locally, regionally, or globally. The project management team and senior stakeholders should be aware that training may take on several forms such as instructor- led or onDemand video, along with documented training visual aids.  It is very often the case that the key training leads first take some form of core or foundational product training from the vendor in preparation for their being able to prepare training collateral that may be more specific to their own organization’s Product 360 solution.

Cutover & Steady State

When both testing and executive direction indicate P360 is ready for enterprise deployment, it is time to execute the cutover plan and deliver the first business value. Go-Live support is critical during this phase. Baselines are typically taken for metrics and then monitoring for the key metrics begins. The entire implementation cycle can be repeated in an iterative fashion for future phases.