Supplier 360

Business Goal

As many retail, manufacturing, logistics, service providers, and distribution organizations continue to grow and diversify their product portfolios or supply chains there is an ever  growing need to allow companies to more seamlessly integrate their platforms with their data providers and subsequent supply chain networks. Informatica’s Supplier 360 (S360) platform, part of the Master Data Management (MDM) suite, helps customers achieve these very objectives. The ability for an organization to provide its network of suppliers with an easy and efficient means to self-register, become an approved vendor and begin to supply their products to a prospective organization is imperative in such a competitive marketplace. Each organization requires an ability to onboard suppliers in an expeditious manner and reduce time to market for products, while reducing the overhead costs of onboarding individual suppliers and allowing for greater data governance of the data submitted by these suppliers. Organizations increasingly have a need to manage supplier relationships, whether parent / subsidiary relations, primary / secondary / tertiary supplier relations, or supplier to broker relations, as well as supplier to product relationships. All of these critical goals can be achieved leveraging S360 and the MDM suite.

Business Preparedness

Prior to kicking off the actual S360 implementation it is beneficial for an organization’s key business stakeholders to prepare, plan, strategize, compile, and consolidate their key critical business objectives and requirements. This can be further enhanced via the adoption of a readiness assessment, which allows for the various relevant topical business use cases or user stories to be discussed in a round table setting where the essential business and IT stakeholders can align on key objectives, critical business pain points that require resolution, and ensure that areas where further due diligence is required are noted. As a result, action plans should be developed to ensure critical organizational feedback from various departments is captured to ensure the success of the future S360 implementation.

Getting Started with the Supplier 360 Journey

Once an organization has determined it is ready to kick off its Supplier 360 MDM implementation there are numerous project aspects to understand, plan and execute to ensure a timely and successful rollout of the S360 platform. Many of these critical project implementation factors are described below.

Staffing

As part of the pre-project planning, it is essential to understand the various mandatory and option project roles that will be required throughout the project and during various critical stages of the project. It is equally critical to understand, create and follow a project RASCI matrix which will highlight the various project resources who should be involved in these activities for at least one of the following categories: Responsible, Accountable, Supported, Consulted or Informed of each of the key project activities and/or major tasks.

While not comprehensive, below is a depiction example of some of the key essential project roles for a successful S360 roll out:

• 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 dataand would be considered a Subject Matter Expert (SME). Typically fills the business analyst and/or quality assurance role.
• IT Architects - S360/MDM, Data, Enterprise -- provides strategic counsel and expertise on S360, data and enterprise integration.
• Java Developer - For full lifecycle extension development using the SDK and/or extending of web service APIs.
• Systems Administrator - Business and IT administration. Responsible for monitoring, configuration, security access, etc. The go forward administrators for the organization to be autonomous on S360.
• Database Administrator - Usually a part time role.
• ETL Developer - For building transformations while ingesting data from integration layers or prior to sending data to enterprise service buses or prior to sending via point-to-point communications.
• BPM Developer - For building the workflow automation that is typical of the S360 defined data governance processes.
• DQ Developer - For building custom data quality rules.
• Business Analysts - Capture requirements, facilitate discussions, and some configuration, testing and enablement.

Discovery

During the early stages of the project the review and discussion of the information compiled during the pre-kickoff business preparedness and readiness assessment sessions will prove invaluable. The project team working with the organization’s key business and IT stakeholders can collaboratively discuss the previously identified business pain points and noted business needs. The project’s business analysts and solution architects can work together to facilitate and author the functional requirements from these workshop sessions. These Discovery review sessions with the stakeholders should culminate in a series of documented project artifacts that convey the following:

• Functional Requirements - During the discovery sessions, documented business needs and pain points will be translated into project-driven functional use case requirements and user stories. These identified requirements will form the foundational needs of the business from which the subsequent solution design is authored upon to explicitly address those needs.
• Data Requirements - Data Analysis and Data Quality Profiling Reviews: Identify and profile data sources. This may include existing platforms that store vendor data or financial systems where often in many organizations any new prospective vendor is initially created. The team should collaborate with stakeholders to identify and prioritize data cleansing needs, data trust and matching requirements, etc.
• Data Dictionary - The project team in collaboration with the business will author a document that represents the desired business and system data fields and elements that need to be part of the future supplier domain data model.
• Business Process Flows - Leveraging the feedback and inputs from the business the team should be able to author business process flow activity diagrams. In some instances the business stakeholders and business analysts may have already done this step as part of their preparation, if that is the case the project team should review these process flows during these Discovery sessions ensuring both completeness and clarity on any process behaviors where there is perceived ambiguity.
• Project Plan and Roll Out Strategy Documents - During the Discovery workshops the Project Manager and team delivery leads should be collaborating on several critical documents. While the overall project plan is perhaps most obvious, the management team should also be preparing a data migration plan for the one -time data onboarding, cutover and Go-Live checklists, community enablement plan, and the framework for the future supplier onboarding program that is required.

Solution & Design

The next step is to transpose the functional business requirements to solution design and system and platform requirements.

During the iterative Discovery sessions, the project will segue from analysis-laden activities to more in-depth design and more detailed solution-based activities. Some of the key activities and topical design areas as part of the solution design will include the following key topical functional areas of focus:

• Data Modelling - Solution architects will take the authored data dictionary and compose a high-level data entity model. The entity model will be iteratively reviewed with stakeholders and as it becomes solidified will then be translated into a more granular detailed domain object model used to build and augment the outof-box Supplier 360 data model accordingly.
• Hierarchy Management - Collaborative sessions will be conducted to review business requirements for managing hierarchies and relationships. Desired behaviors and interactions with the hierarchies will be identified so that the solution architects can determine the optimal way various hierarchies should be represented within the data model and via the S360 user interface.
• Data Security - Identified security requirements will be transposed to security feature capabilities and behaviors of the S360 MDM platform.
• Match and Merge - The business requirements for matching data records between systems are aligned with the faceted search capabilities of Supplier 360, whether via fuzzy matching, exact matching, or the design and future building of additional match and merge rules via Data Quality, etc.
• Trust Requirements as Data Quality and Systems Rules - The identified data trust requirements, largely based upon the reliability of data in upstream source systems, will be documented as part of the overall solution design and will, in many cases, be established in the subsequent build as data quality rules or validations.
• Versioning and State Management - Identified business requirements will be articulated in the solution design addressing how and when versioning will occur, how versions are validated and accepted, where and if any versions can be deleted, etc.
• Data Governance and Stewardship - The business process flow and activity diagrams created during the preparedness and analysis stages of the project will be translated by the solution architects into one or more system workflow diagrams leveraging related platform peripherals such as BPM and Data Quality along with the core features of Supplier 360 as part of the implemented solution.
• Development of high-level solution architecture
  • Solution Design Document built based upon traceable functional business requirements
  • Conceptual/logical data model
  • Enterprise Architecture diagram
  • High-level data flow for batch and real time inbound/outbound data
  • High-level integration architecture
  • Infrastructure Architecture

Build

The build and test phase are typically performed in lower level environments to construct and validate the configurations, customizations, extensions, and integration of Supplier 360 with the rest of the enterprise. This includes testing inbound and outbound data feeds per pre-defined SLAs from the Discovery and Design sessions. Performance tuning testing is recommended to isolate any systems or defined business process bottlenecks before they can impact 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 and 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 in preparation for their being able to prepare training collateral that may be more specific to their own organization’s Supplier 360 solution.

Preparing the Supplier Onboarding Strategy

One of the most critically important aspects of a successful Supplier 360 rollout is the preparation of a comprehensive supplier onboarding strategy. Planning supplier onboarding will involve the creation of training content. Some of this content will be in the form of recorded video tutorials and the uploading of documents and templates for suppliers to review and use. During the Supplier 360 project this content should be authored and reviewed on an iterative business by the project stakeholders. Additionally, supplier templates for data ingestion will need to be defined and approved. While there are a variety of approaches to take when identifying these supplier templates (e.g., vendor long form, vendor short form, vendor pricing updates form, etc.) they could be defined generically or by channel, region, etc.

Leading up to a successful Go-Live there are some additional considerations to factor, one of which is whether there will be a beta or pilot release to a small percentage of identified suppliers. Informatica recommends that a cross-section of suppliers always be leveraged for any beta or pilot rollout so that feedback comes back to the organization from large scale, mid-size, and smaller more localized suppliers to ensure a full spectrum of supplier feedback is received. What is an issue for a larger supplier (e.g., outsourced brokers providing subsets of the supplier’s data) may or may not be an issue for the smaller scale supplier (e.g., less IT capacity). Suppliers from different industry verticals should also be considered during the planning phases. Again as an example, a dairy supplier, meat vendor, apparel vendor and general merchandise supplier will not all interact or be providing the same information or be required to provide the same industry certifications in order to be successfully approved as part of their self-registration process.

Lastly, it is imperative that the supplier onboarding plan aligns with the business’s desired timetable where feasible and practical. Assessing and managing the expectations of the business stakeholders and ensuring alignment on the go forward strategy for onboarding the full network of suppliers is essential regardless of the total volume of suppliers. No matter the size of the organization’s supplier network, the onboarding strategy must be practical and feasible to execute successfully. Factoring in the incremental rollout to its network of suppliers is essential for the organization. A big-bang rollout is generally ill advised, whereas an incremental rollout allowing for greater feedback directly from the suppliers in the early iterations will ensure the business can quickly implement feedback and pivot on any desired changes to the supplier onboarding process prior to ramping up to larger volumes of suppliers being onboarded.

Cutover & Go Live

As the project approaches successful business stakeholder acceptance (via User Acceptance Testing), the Project Manager and Delivery leads can commence the execution of the previously reviewed cutover and Go-Live plan. This will include ensuring production environment and infrastructure is in place, the data migration of source system data has been ingested into Supplier 360’s MDM environment, verification of the final deployments and approved configurations, smoke test verifications ensuring integrations will work once the “switch is flipped”, and that systems scheduled for decommissioning or sunsetting are taken offline where applicable.