NPI Solution Definition December, 2006
New Product Introduction Solution Definition
Kimberly Simms WPC Services Solution Management Geoff Bernard WPC Tech Sales
-
NPI Solution Definition
CONTENTS 1
Solution Overview ................................................................................................... 4
2
Business Problem ................................................................................................... 4 2.1
Scenario 1: Large Consumer Electronics Retailer ..................................... 5
2.2
Scenario 2: Large CPG Manufacturer ........................................................ 7
3
Value Proposition .................................................................................................... 9
4
High Level Systems Architecture.......................................................................... 10
5
WPC Solution Components .................................................................................. 12 5.1
Data Model ................................................................................................ 12 5.1.1
Entity Models.................................................................................... 12
5.1.2
Item 12
5.1.3
Party 13
5.1.4
Hierarchy Model................................................................................ 14
5.1.5
Relationship Modeling ....................................................................... 14
5.2
Users, Roles, and Authorization ............................................................... 15
5.3
Business Processes .................................................................................. 16 5.3.1
New Product Introduction .................................................................. 16
5.3.2
Item Maintenance ............................................................................. 17
5.4
Integrations ................................................................................................ 18
5.5
Other.......................................................................................................... 20 5.5.1
Dashboards ...................................................................................... 20
5.5.2
Validation Framework ........................................................................ 20
ii
6
NPI Asset............................................................................................................... 21
7
Implementation Approach and Methodology ........................................................ 22
8
Appendix................................................................................................................ 23 8.1
Definitions and Acronyms ......................................................................... 23
iii
NPI Solution Definition
1
Solution Overview
New Product Introduction (NPI) is a core process that is widely applicable across many different industries. Currently, many of these enterprises have NPI processes that are inefficient, error-prone, and often result in data inaccuracies, high lead times during new products introduction to market, and limited ability to monitor business processes. The goal of NPI solutions is to address these issues by providing business process management functionality that supports collaborative authoring and validation of the product information. In addition, the solution needs to support a robust and flexible data model to reflect changes in the business. Given these requirements, an NPI solution is more than just a workflow to support the overall business process; it includes a data model, business process, integration, and validation framework. This paper describes at a high level the value that companies can achieve in deploying an NPI solution based on WebSphere Product Center (WPC), which is currently at Version 5.3.1.
2
Business Problem
The system environments for most companies do not easily support the complex process of introducing a new product to multiple sales channels. The challenges faced by most companies include: § Iterative process between a retailer and a supplier to obtain information that is required to set up a new product § Manual, paper processes to facilitate a new product introduction process internally § Multiple data sources or item repositories to manage product information. For example: 4 Silo solutions are created to support different departmental needs 4 Manual data entry in each solution that is time consuming and labor intensive 4 Identification of known silo solutions (many not be known) 4 Inability to support large volumes of data introduced on a weekly or monthly basis where the updates can’t get to all the required systems in a timely fashion § Intellectual corporate properties where validation rules are typically not properly documented, executed consistently, and are largely individual based § Inability to track and review the state of an item in an NPI process § Lack of data governance policies and enforcement The following two scenarios illustrate NPI solutions implemented with WPC.
NPI Solution Definition 2.1
Scenario 1: Large Consumer Electronics Retailer
A large consumer electronic retailer wanted to increase the product information data quality and reduce the time required to get new products to market. The key problems associated with the existing NPI process include: § Multiple methods of communications used to obtain and facilitate product information. § Re-keying of Item information in multiple systems (labor intensive and error prone). § Outdated Item details. § Individual applications and processes with customized validation rules for product information type attributes. Using customized validation rules caused inconsistent behavior and costly maintenance requirements. § Multiple independent product information silos existed across the enterprise. § Customization of each new attribute to the existing item master. The problems identified in the existing NPI solution were used to define the requirements for an NPI solution based on WebSphere Product Center. By using WPC, the company effectively reduced the complexity and duplication in the product information authoring process by creating a single repository for product information. This solution includes the following features and functions: § § § § § § §
Creation of a single item master for ~400,000 items. Controlling external communication, through a vendor portal and Global Data Synchronization solution. Ownership of product information is put back on vendors for the data through electronic submission. Ability to update item details quickly, while keeping information current through workflow and standardized business processes. One source of record of product information across the businesses and channels. One application or process includes customized validation rules through a structured validation framework. Each new attribute in PIM is easily configurable which eliminated the need for complex customization.
5
NPI Solution Definition The following figure illustrates the high-level architecture for the PIM solution using WPC.
Vendor Portal
Operational Data Catalogs
WebSphere Product Center
GDS
Hierarchies
WebSphere Items Product Vendors Center Users & Roles
Data Pool Workflows & Custom Tools:
Validation Framework
EAI
EAI
Catalogs
Other downstream dependencies
Senior VP of Merchandising
The high-level solution scope depicted in this architecture using WebSphere Product Center includes: § Custom validation framework. § Workflows to manage item creation, item maintenance, and data model modification. § Customized data model to support item and vendor entities, as well as GDS needs. § Integration with WebSphere Portal. § Integration with the WebSphere GDS Application. § Integration with downstream solutions including RMS (through EAI solution).
6
NPI Solution Definition
2.2
Scenario 2: Large CPG Manufacturer
A CPG manufacturing company wanted to implement an NPI solution that reduced the time and effort needed to create item information for new product launches. In addition, they wanted to increase the quality of the available product information. The key problems associated with the existing NPI process include: § Duplicate data entry resulting in high data maintenance costs and increased risk of data alignment issues. § Slow new product launches caused by an increase in the time spent collecting and entering new item data, and redundant communications. § Inefficient data synchronization with downstream solutions. § Lack of data ownership and accountability. § No formal data validation during the data collection. § No formal workflow. § Poor or missing product information. § Inability to support data synchronization. § Misalignment of data standards in legacy and common systems. The problems identified in the existing NPI solution were used to define the requirements for an NPI solution based on WebSphere Product Center. By using WPC, the company created a solution that increased product data quality and decreasing costs associated with the creation of the new item information. This solution includes the following features and functions: § Consolidation of master data. § Use of workflow to standardize and optimize business processes. § Implementation of validation framework to ensure data consistency. § Improved integration with downstream solutions through an integration framework and EAI solution. § Leveraging a more flexible data model to support future changes.
7
NPI Solution Definition The following figure illustrates the high-level architecture for the PIM solution using WPC. Operational Data Catalog - SAP
WebSphere Product Center
EAI
Catalogs
Hierarchies
Items WebSphere Customers Product Center Vendors
Workflows & Custom Tools:
EAI
PLM/ Materials Master
Manugistics
Validation Framework Other Downstream Systems
The high-level solution scope depicted in this architecture using WebSphere Product Center includes: § Management of ~5000 items. § Data model to support product, vendor, and customer data (un-related). § Workflows to support item creation and materials enrichment. § Custom validation framework. § Integration with materials master. § Integration with SAP. § Integration with other downstream solutions.
8
NPI Solution Definition
3
Value Proposition The ROI of an NPI solution based on WebSphere Product Center is measured using the following metric: 1. Increased revenue though reduction in time to market for new products. Time to market for a retailer is critical in order to remain competitive in the marketplace. The greatest revenue potential for a new product is during its first few weeks on the store shelf. Failure to capitalize on this short window of opportunity results in significant lost revenue. The risk is even higher for promotional or seasonal items. § If the product appears too late on the shelf, the opportunity to sell the product at a higher price is lost, and might only be sold at a marked down price resulting in a potential loss for a retailer. § If the product isn’t available for purchase when the customer expects it to be, the customer will most likely shop elsewhere. This could result in future sales losses as well. Manual exchanges of Excel spreadsheets which is common for many industries can be time consuming and inefficient. The use of a collaborative workflow in WPC can have a tremendous impact on time to market. 2. Reduced costs through improving merchandising productivity. Inefficient processes require more people and take longer to execute, and when time and labor costs are multiplied together, it becomes evident that efficient processes, requiring less people, can reduce costs. § Reduction in capital expenditures: When a centralized repository is positioned to support the NPI process, capital costs are reduced as maintenance and hardware expenses for redundant systems are no longer needed after they have been decommissioned. § Removal of penalty payments: Poor NPI processes can result in invalid data (errors and duplicate data). Invalid data can impact reporting for a company, and when statements regarding annual revenue are found to be inaccurate, retailers are charged for every error that is made. The implementation of validation rules and automated processing, as part of an NPI process, can help eliminate these issues, altogether. 3. Increased data quality by standardizing processes used to create and maintain item information as well as reducing the possibility for duplication by providing a single source for item information. These processes can also include standardized validation and approvals, further reducing the opportunity for inaccurate product information to be used.
9
NPI Solution Definition
4
High Level Systems Architecture
This section includes two diagrams that illustrate the WebSphere Product Center solution components for a typical NPI solution in the retail and manufacturing industry. The following diagram depicts the typical architecture for an NPI solution using WebSphere Product Center in the manufacturing environment.
Operational Data Catalogs Vendor Portal
WebSphere Product Center
EAI
Replenish & Forecast
Hierarchies
WebSphere Items Product Vendors Center Users & Roles
EAI
EDI Referential Data
GDS
Catalogs
(Small %)
Workflows & Custom Tools:
Reporting Procurement
Data Pool
Senior VP of Merchandising
New Product Introduction Workflow Automated Data Validation
Review
Senior VP Specialist of Merchandising Item
SKU Setup
Categorization
Enrich
Senior VP Specialist of Merchandising Senior VP Specialists of Merchandising Item Item
10
Approve
Automated: Publish
Senior VP Mgr/Approvers of Merchandising Category
Data Warehouse
NPI Solution Definition The following diagram depicts a typical architecture for an NPI solution using WebSphere Product Center in the manufacturing environment.
Regional ERP Solutions
WebSphere Product Center Hierarchies
Items WebSphere Product Center Users & Roles Vendors
Workflows & Custom Tools:
Reporting
EAI
Specification System
EAI
Catalogs
GDS
Senior VP of Merchandising
New Item Creation Workflow Automated Data Validation
Approve
Enrich
Automated: Publish
Senior VP of Senior Merchandising VP of Merchandising Senior VP of Merchandising Department Approvers Department Analysts
11
Data Warehouse
NPI Solution Definition
5 5.1
WPC Solution Components Data Model
In WebSphere Product Center, data modeling is one of the major components of the NPI solution. There are three major areas to consider when developing the data model: § Core entity definitions and the attributes which support them § Hierarchies and the attributes which support them § Relationship modeling 5.1.1 Entity Models There are two entities that are core to an NPI solution, Item and Party. Specific solutions may include additional entities such as location. 5.1.2 Item An item is the primary entity to support an NPI solution and can be fairly complex, due to some of the following reasons. Item Definition: Although this seems simple, it is one of the biggest challenges many companies face. Across and within an industry, this definition can vary. For example: § A grocery retailer’s view of an item is very different from a fashion retailer. A grocery retailer typically manages items at the SKU level, whereas in fashion industry, it is typically at the SKU-Style-Size level. § Within an organization, the definition of an item can also vary based on how dependent systems interpret an item. As a best practice, IBM recommends that a company provide a common definition of the item and use EAI/ETL tools to translate and transform items to support downstream systems. § Packaging Hierarchy: This is more common for manufacturers, but retailers will have a requirement to support it, if they are participating in GDS. The packaging hierarchy relates each item to how it is purchased, shipped, and actually sold on a shelf. The typical configuration is a Pallet-Case-Each, however there are many variations of this. § Inheritance Requirements: The requirement for inheritance is seen more commonly in high-tech and fashion verses in the grocery and office supplies industry. The differences are largely due to the need to re-use large amounts of defining data across multiple products.
12
NPI Solution Definition Based on all of these complex factors, the primary key or actual model of an item in WebSphere Product Center may differ for each company. For an NPI solution, WebSphere Product Center is typically positioned as the source of record for all referential item information; therefore a larger number of attributes are usually required to support it. The number of attributes also tends to vary by industry as well. For example, high-tech manufacturers and retailers typically require this largest number of attributes because there are so many defining factors, which make up a product. However, an office supply company may not have as many attributes as products are not as complex. Other factors, which have a direct impact on the number of referential attributes to be stored on an item, include: § Support for downstream system dependencies: In most cases, an ERP or operational solution is downstream from an NPI solution in WPC. Many times, the dependent system will require specific attributes, before a new item is introduced, which then become required for item creation in WebSphere Product Center. § Sales Channel Support: When WebSphere Product Center is positioned to feed data into an eCommerce or Print catalog solution, different hierarchies, and attributes required to support the item in that sales channel may also be required. § Item Types: A company can carry different types of items, which may have additional required attributes. For example, an item, which is considered hazardous, may require an additional set of attributes based on country requirements. § Localization: A direct impact on the number of attributes is also tied to the number of languages and countries the company supports. WebSphere Product Center localization capabilities support this type of requirement, and integration with translation services has been implemented to support the population of these individual attributes. WPC has native capabilities through the use of WebSphere Product Center specifications to support most of the varying requirements around item referential attributes. 5.1.3 Party The semantics of Party can vary by industry and solution. For the purposes of the NPI solution, the following definitions apply: § § §
For a retailer: Party = Manufacturer For a manufacturer: Party = Retailer For a distributor: Party = Retailer and/or Manufacturer
13
NPI Solution Definition When modeling a party in an NPI solution, WebSphere Product Center is not usually positioned as the master or source of record for this information. This is because the ownership of this data is typically related to a financial organization within the company, with many other use cases required to support it For example, POS, trading terms and conditions. Therefore, the data attributes, which define a party, are typically fairly minimal, and are also considered referential. Some examples include address and contact information. 5.1.4 Hierarchy Model The number of hierarchies (also called category trees) to support an NPI solution varies. Most companies look to recognize a standard representation of how products are organized in a company, and then implement other supporting hierarchies to meet supplementary business needs. At the highest level, in an NPI solution, one or more of the following hierarchies are required: § § § §
Bricks (GS1 standard classification) with both manufacturers and retailers. Industry standard (for example, IRI, UNSPSC, UDEX, and eClass) used across all industries. Buyer hierarchy where product classification is based on how items are purchased for both retailers and distributors. Seller and merchandising hierarchy where the product classification is based on how items are sold and reported on (often, in addition to a Web site user experience hierarchy) and used across all industries.
In most cases, WebSphere Product Center’s native hierarchy capabilities are sufficient to develop the hierarchies required to meet the majority of a company’s NPI solution requirements. 5.1.5 Relationship Modeling There are two main groups of relationships that are core to an NPI solution. § The relationships that exists between Item entities and parties. § The relationships that exist among the item entities. This section describes these relationships as they relate to an NPI solution. Item-Party Relationships
Between item and party, there is a 1-to-many relationship. For example, for a retailer, one item can have multiple manufacturers and for a manufacturer, one item can be supplied to multiple retailers. In addition, a distributor can have three relationships: 14
NPI Solution Definition 1. Multiple manufacturers can supply an item. 2. A buyer can be supplied with multiple items. 3. Multiple buyers can be supplied an item. These relationships can be modeled in WebSphere Product Center either through a party hierarchy, linking a party and catalog item together, or through the use of multi-occurrence attributes on an item record.
Inter-item Relationships
Inter-item relationships typically exist in an NPI solution and include some of the following: •
Substitution Items: Items, which could be sold in place of an item. (Two different brands: private label product and known brand)
•
Cross-Sell and Up-sell: Items which are complimentary to an item (Printer + toner + paper)
•
Bundling: Grouping of similar or complementary items. (Shampoo + Conditioner in special packaging)
•
Packaging: Items sold as either a pack or an each. (One pen verses ten pens)
These relationships can be modeled in WebSphere Product Center either through linked catalogs or through the use of multi-occurring attributes on an item record.
5.2
Users, Roles, and Authorization
For an NPI solution, the following roles are usually required by most industries: § Category Manager: Determines what the product assortment is for a specific category. This individual may or may not have a large role in WebSphere Product Center, but they are usually key when determining what new products will actually be introduced or carried within an organization, as well as approving them after they are defined. These individuals usually have read/write access to all data. § Item Specialist: Responsible for enriching item information through data entry. There can be multiple item specialists for each department or one to facilitate information gathering across departments. Security is usually applied at the item specialist level to restrict read/write capabilities of data to the specific category for which they are responsible. 15
NPI Solution Definition § §
Approver: This person can be a category manager, or another individual who is required to review an item, prior to publishing to downstream systems. These individuals usually have read/write access to all data. Administrator: This person is responsible for maintaining validations and attributes to define an item. They usually have access to the source code of a solution and can configure or modify it, accordingly, although typically this role has limited access to modify actual data.
Roles and security can be configured within the native WebSphere Product Center users and roles framework.
5.3
Business Processes
The most common business processes implemented in an NPI solution include New Product Introduction (NPI), and item maintenance. Each of these solutions are explained the following sections. 5.3.1 New Product Introduction An NPI workflow is often complex due to the number of individuals and the roles assigned to them. In WebSphere Product Center, a workflow usually begins after an item gone through approval to be carried or developed. A typical NPI workflow is built by leveraging the workflow functionality existing in WebSphere Product Center. Occasionally, a custom tool is built to support increased complexity. At a high level, a typical NPI workflow consists of the following steps: 1. Create: The creation of the item, and its relationship to other items. Item information can come from a variety of sources, including data pools, or a vendor portal. This step in the process typically includes verification that an item doesn’t already exist, SKU and GTIN development, and relationship generation to other items. The relationship to other items can include cross-sell, up-sell, replacement, and accessories. A category manager or an item specialist is the typical role performing this step, and can also be automated in the appropriate situations. 2. Enrich: The enrichment step is when the core attributes (non-category dependant) of a product are updated. This step can be done at the same time as the creation step (Step 1), if the roles performing the create (Step 1) and enrich (Step 2) activities are the same. This step can also be moved, and
16
NPI Solution Definition performed after the classify step (Step 3), if the same individuals are updating both core and category specific data. An item specialist is the typical role performing this step, and can also be automated in the appropriate situations. 3. Classify: After the item has been created and enriched with its core attributes, the item is typically classified into one or more hierarchies. These hierarchies can include merchandising, buyer, or sales channel specific hierarchies – all of which support specific functions within an organization. After an item is classified, a separate enrichment process is frequently required to enrich category specific attributes, if they exist. A category manager or an item specialist usually performs this step, and can also be automated in the appropriate situations. 4. Approve: The final step in the process is the approval step. This step can also involve many people, but it is important to structure the approval process appropriately, so it does not hinder the process of making the product available for sale. A category manager or other more senior resource often leads this activity. For more information on the New Product Introduction business process, please refer to the NPI white paper and presentation available in the Services Repository. 5.3.2 Item Maintenance Item maintenance frequently covers multiple areas but in the context of an NPI solution it generally includes the process where product information is modified after it has gone through the NPI business process and approval. The item maintenance workflow is typically built by leveraging the workflow functionality existing in WebSphere Product Center. Occasionally, a custom tool will be built to support increased complexity. A typical product maintenance process consists of the following steps: 1. Search and Identify Item: A user (typically an item specialist) performs a search against all active or inactive items, to identify an item requiring modification. Searching is usually done by UPC, but can be done by manufacturer or other keywords. 2. Modify Item Information: An item specialist typically perform this role, and is permitted to modify the data they are responsible for in a specific category.
17
NPI Solution Definition 3. Approve: The final step in the process is the approval step. The approval step frequently involves many people and therefore it’s important to structure the approval process so that it does not hinder the process of making the product available for sale. A category manager or other more senior resource typically owns this activity.
5.4
Integrations
Each NPI solution has a specific set of integrations required that are specific to the business processes supported, as well as the existing IT environment. Generally, integrations are required for adding data to the solution at the start of the item data authoring process, as well as publishing out product data that has been fully authored and approved. In WebSphere Product Center, these operations are typically done through import and export scripts, leveraging various types of transport mechanisms including FTP, MQ, JMS, HTTP, JDBC (only outbound data), and Web services. For outbound integrations (publishing data to downstream systems) the use of an EAI solution is considered a best practice. Using these best practices allows the creation of flows and transformations outside of WebSphere Product Center for easier management of the data externally. In addition, it can significantly simplify the solution and give better performance by reducing the number of export jobs that need to be run in WebSphere Product Center. The following table provides short descriptions of the most common integrations implemented as part of NPI solutions across various industries.
No. 1
Integration Name Vendor Portal Integration
Data Modeling Description For a retailer, one of the benefits of an NPI solution is to increase the electronic exchange of product information and reduce the number of manual processes with vendors. Putting ownership of new product information back on the vendor through a vendor portal supports this goal. A vendor portal allows manufacturers and distributors to supply product information to a retailer in an electronic format. The information is either manually entered through portlets, or uploaded as a spreadsheet through a portlet.
2
GDS, IRI, or
Vendor portals are considered upstream for retailers and downstream for manufacturers. GDS (Global Data Synchronization), IRI (Information
18
NPI Solution Definition EDI Integration
3
Materials Master/PLM Solution
4
ERP/ Merchandising System
5
Pricing Systems
6
Data Warehouse
7
eCommerce Systems
8
Order
Resources, Inc), EDI (Electronic Data Interchange) are all additional sources for retailers to obtain product (and more) information from a manufacturer/distributor electronically. These types of sources look to leverage industry standards, and provide common formats to retailers across the board in which manufacturers and distributors comply with. GDS, EDI, and IRI solutions are considered upstream for retailers, and downstream for manufacturers. Manufacturers typically have a PLM solution (sometimes called a materials or ingredients master). PLM systems are almost always upstream from WebSphere Product Center and manage the raw materials and actual lifecycle for the physical creation of a new product. After the PLM processes are complete, this information is then passed to WebSphere Product Center for further enrichment of item characteristics, including the establishment of item identifiers, and so on. PLM solutions are not usually found in retailer and distributor environments. An ERP and merchandising system such as Retek or SAP typically deal with transactional data verses referential data. Across all industries, in a true NPI solution, this type of solution is typically downstream from WebSphere Product Center. This allows for the base, referential item information to be created first, and then the operational aspects through the merchandising system (for example, Inventory, ordering, and pricing). Pricing Systems (such as Manugistics), if separated from a Merchandising system, are also typically downstream from WebSphere Product Center regardless of industry. Pricing data can be considered transactional when dealing with promotions or market conditions. This is the case in all industries implementing an NPI solution. Data Warehouse (such as DB2 Data Warehouse, and Terradata) solutions are typically downstream from WebSphere Product Center, as these solutions support overall reporting and analysis of enterprise data, both referential and transactional in nature. This is the case in all industries implementing an NPI solution. eCommerce solutions (such as WebSphere Commerce) are downstream from WebSphere Product Center for both retailers and distributors, and occasionally in a manufacturer’s environment. Order management solutions (such as Yantra), as well as
19
NPI Solution Definition Management, Procurement, and Replenishment Systems
5.5
procurement or replenishment solutions are often downstream from WebSphere Product Center, as these solutions support transactional data, and require referential data to support a transaction. This is the case in all industries implementing an NPI solution.
Other
There are some additional components that are commonly developed as part of an NPI solution. These components are intended to provide additional visibility into the authoring process of item information and ensure a higher level of data quality. 5.5.1 Dashboards Many companies are looking for a more detailed look into the state of an item in their NPI workflow process. This functionality can be obtained by creating a custom tool that provides a dashboard showing the status of the workflows and the items in them. By quickly visiting the dashboard, a user can review an item or item set to see what step in the workflow process the item is in, and how long it has been in that step. In addition, the dashboard can enable the user to move the item on to the next step, given the appropriate permissions. The reporting and time tracking of item states that is captured in the dashboard can also be used to do analysis of the workflow process to identify bottlenecks. Currently, WebSphere Product Center dose not have the native tools to deploy dashboard functionality. However, custom tools can be used for this purpose. 5.5.2 Validation Framework To prevent rewriting validations, which are performed in many places (for example, imports and workflows), and to standardize how validations are written and implemented, a validation framework should be developed as part of an NPI solution. The validation framework provides guidelines and a centralized location in the solution to develop validations performed throughout the solution. For more information on validation framework best practices, please see the Validation Framework Presentation in the Services database.
20
NPI Solution Definition
6
NPI Asset
Within the IBM BIS (Business Information Solutions) team, an NPI asset specifically designed for retailers based off of the Retek data model (Item variants and item families) has been developed to help accelerate NPI solution implementations. The solution is made up of the following components: § Buyer dashboard. § Item family management user interface. § NPI workflow template. § Data model based off of Retek’s definition of item variants and item families § Import and export framework. § Use of validation framework. § Eclipse framework to support configuration and customization of data model and workflow pieces. The following diagram illustrates the overall solution architecture of the retail NPI asset.
Example of a New Product Introduction Data Flow in a Retail Environment WPC: Retail NPI
Operational Data Catalogs
User Interfaces Buyer Dashboard
Vendor Portal
Item Family Management
Workflow
(Small %)
GDS
Approve
Enrich
EAI / ETL
EDI Referential Data
EAI / ETL
Setup
Data Model Components Retail Data Model
Meta Tooling
Validation Framework Eclipse Deployment
Data Pool
Replenish & Forecast
Procurement
Senior VP of Merchandising
New Product Introduction Workflow Automated Data Validation
Review
Senior VP Specialist of Merchandising Item
SKU Setup
Categorization
Enrich
Senior VP Specialist of Merchandising Senior VP Specialists of Merchandising Item Item
21
Approve
Automated: Publish
Senior VP Mgr/Approvers of Merchandising Category
Data Warehouse
NPI Solution Definition
7
Implementation Approach and Methodology
The implementation of an NPI solution is a large endeavor and therefore, it’s recommended that the delivery of the solution is planned using a phased approach. A phased approach helps to mitigate risk, and increases user acceptance. There are many options for defining the phasing of the solution; the two most common approaches are by data and functionality. Option 1: Phasing by Data Depending on the size of the company, data should be considered as an aspect to phasing, particularly for companies with a significant amount of data. For many companies, data is organized and maintained by category. In most solution rollouts, existing legacy systems are not typically decommissioned immediately upon the deployment of a new NPI solution. Legacy systems currently managing product information are usually phased out over time to minimize risk to the organization. Therefore, the option to phase by a category of data is a good approach to take in order to reduce risk. This approach will allow functionality to be tested out on a small set of data, while minimizing the potential impact to an organization. Non-migrated category data can typically continue to be created and maintained in the legacy environment, and phased into the new NPI solution over time. This type of approach works well for all companies regardless of industry, and can be coupled with the phasing of new functionality as well. Option 2: Phasing by Functionality Phasing by functionality can be defined in two manners: § Phasing by WPC Functionality: Phasing through the gradual introduction of new features such as workflow processes, custom tools, reports, data model expansion, and integration components is always something to be considered. This approach works well when different groups are introduced to WebSphere Product Center, and functionality can be separated into groups. In addition, this works well when functionality can be easily separated from nice-to-have features, from mission critical features. Higher priority items should always try to be addressed first in this case. § Phasing by Application Components supporting new functionality: The primary application components of an NPI solution include: WebSphere Product Center, GDS, and WebSphere Portal. These should be separated out into phases for deployment to avoid unnecessary risks of rolling out too much functionality at one time. The following approaches can be taken: § Phase 1: PIM, Phase 2: GDS or Portal
22
NPI Solution Definition In this approach, the core components of the WebSphere Product Center solution need to be implemented before changing integration touch points. IBM recommends this approach since it helps to ensure that the core data model used to define an item is defined in order to enable up or downstream integrations. In addition, rules and validations need to be defined to ensure that clean data is coming in or going out. §
Phase 1: GDS or Portal, Phase 2: PIM In this approach, GDS or Portal is addressed first as a recipient or source of product information. For a retailer, this approach is successful since the upstream integration is modeled, and can feed into the existing item master solution. For a manufacturer or distributor, this approach works as a downstream recipient of product information from a legacy system. If there is a pressing need or near term requirement to participate in GDS, this may be the preferred approach. In both industry cases, the integration work should be reusable when the WebSphere Product Center implementation is out into place.
8
Appendix
8.1
Definitions and Acronyms
Acronym CPG EDI GDS IBM IRI NPI OM PIM UI WPC CPG GDS IBM NPI DW PIM UI WPC
Definition Consumer Packaged Goods Electronic Data Interchange Global Data Synchronization International Business Machines Information Resources, Inc New Product Introduction Order Management Product Information Management User Interface WebSphere Product Center Consumer Packaged Goods Global Data Synchronization International Business Machines New Product Introduction Data Warehouse Product Information Management User Interface WebSphere Product Center
23
® © Copyright IBM Corporation 2006 IBM United States of America Produced in the United States of America All Rights Reserved The e-business logo, the eServer logo, IBM, the IBM logo, OS/390, zSeries, SecureWay, S/390, Tivoli, DB2, Lotus and WebSphere are trademarks of International Business Machines Corporation in the United States, other countries or both. Lotus, Lotus Discovery Server, Lotus QuickPlace, Lotus Notes, Domino, and Sametime are trademarks of Lotus Development Corporation and/or IBM Corporation. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries or both. Other company, product and service names may be trademarks or service marks of others. INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PAPER “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. Information in this paper as to the availability of products (including portlets) was believed accurate as of the time of publication. IBM cannot guarantee that identified products (including portlets) will continue to be made available by their suppliers. This information could include technical inaccuracies or typographical errors. Changes may be made periodically to the information herein; these changes may be incorporated in subsequent versions of the paper. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time without notice. Any references in this document to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation 4205 South Miami Boulevard Research Triangle Park, NC 27709 U.S.A.
