Inception#

Hold "Alt" / "Option" to enable Pan & Zoom

This is the very first stage of the lifecycle. It may function as a standalone phase or as the initial stage of the Requirements Specification development.
All outputs from this stage are reused in the Requirements Specification.

Key Ideas

The MDM solution, starting from the concept phase, must have well-defined business value.
All involved parties - both technical and business - must understand how the solution will contribute to company's business goals, objectives, and strategy.
It is important to involve potential consumers early in the solution-shaping process.
This helps better understand their needs, the value they expect, and potential use cases for the solution.

Roles Involved#

Accountable: Program Manager
Responsible: Business Analyst, Data Governance Lead
Consulted: Data Architect, Solution Architect

Data Engineer may be occasionally consulted at this stage to evaluate technical feasibility or implement a quick Proof-of-Concept (PoC) for value hypothesis validation.

1. Input#

Foundational elements that shape the vision and scope .

Category	Input	Owner
Business Context	- Strategic goals (e.g., One customer view, regulatory compliance) - Key pain points (e.g., duplicate records, inconsistent data)
Existing Documentation	- Current-state architecture - Data quality reports - Business process diagrams - Current MDM maturity models - Existing Governance frameworks
Stakeholder Input	- Executive sponsors - Business owners - IT leads - Data stewards
Source Systems Inventory	- List of applications contributing master data (CRM, ERP, etc.)

2. Process#

Key activities that define and validate the vision and scope.

Step	Description	Know more
Stakeholder Workshops	- Identify data owners, business priorities, goals - Align expectations
Define MDM Vision and Scope	- Define the Product Vision - Clarify the core value proposition of your MDM product Customer 360 view Will it merge records? Manage product hierarchies? Act as a registry? -Define scope domains (customer/product/supplier), integrations, and users.
Assess Current Data Landscape	- Understand the AS-IS landscape - Perform high-level data profiling - Identify systems, gaps, and pain points	SAP Signavio is the tool used to document the AS- IS and TO-BE process. To get access to the tool , refer Onboarding
Define Entity and attributes	- Identify and map entities and attributes	Entity-analysis-process
Define Business Glossary	- Define key buisness terms,their meanings and relationships to ensure consistency and shared understanding of data accross the organization
Establish Ownership and Governance Framework	-Establish the Data Governance Council -Define initial governance framework (roles, policies, standards)	Establish Ownership and Governance Framework
Introduction to Business Analysis		Introduction to Business Analysis
Map "As-is" Process	-Collaborate with identified stakeholders from LoB to map the current "As-is" process described in the use case. Document the process and the attributes captured throughout.	Map As-Is Process
Attribute documentation	-Create comprehensive documentation, detailing the scoped attributes from the “As-is” process, ensure to complete the relevant templates.	Attribute Documentation
Cross-entity alignment	-Verify the attributes usage in other MDM solutions and models. This information could facilitate the process of identifying the attribute owner or provide other details as consumer systems.	Cross Entity Alignment
Assign attribute ownership	-Based on analysis (e.g., business processes), create a proposal of attribute owners. Proposal of attribute ownership should be in alignment with the master data owner principles.	Assign Attribute Ownership
Sign-off “To-be” process	-Create proposal of the “To-be” process, share it with LoB and get final sign-off of it, including process and attribute definitions.	Sign off To-be Process
User Requirement Specification	-Based on the “To-Be” process clearly define User Requirement Specification, that can be translated to the DevOps team. These requirements need to get Data Owner sign-off before any development tasks starts.	User Requirement Specification
Feasibility Analysis	- Ensures every use case is realistic,manageable and aligned with business and architectural goals	Feasibility Outcome Templates
Create High-Level Roadmap	- Timeline, major milestones, phases (Design, Build, Validate, Deploy)
Define Use Case	- Explore the current as-is state, investigate the current process where master data is used , manual workarounds,data issues, integration pain points and gather wish lists to help define the use case . Use Case Definition includes but is not limited to the following items: - Use case context, description and value definition - Business Roles involved in provision,consumption, and support - Scope definition - Business & technical stakeholders definition - SMEs, technical assistance, access/data provision Quantify benefits: improved reporting, compliance, customer satisfaction	use-case-statement
Risk & Readiness Assessment	- Assess organizational readiness, change management needs	Risk-assessment

3. Output#

Foundational deliverables that guide the rest of the project.

Output	Description	References/Templates
MDM Project Charter	- Clear statement of what success looks like and why MDM is needed aligning with the vision and scope	WS-Charter
Use Case Catalogue ,Business Case	- Initial list of business and data use cases	Use-Case-Template Use-Case-Template-Gxp
Current vs. Target State Map	- Visual showing how MDM will change the data ecosystem - AS-IS and TO-BE documents
Business Case	- Project justification with tangible benefits	[SteerCo presentations]
Entity and attribute definition	- Early definition of domains, entities, attributes and business rules	Entity and attributes definition Business Glossary
Stakeholder & Governance Matrix	- Assemble the makers , users and the sponsors of the product . Identify key stakeholders interfacing the program and group them to serve as input for stakeholder analysis and change management	Stakeholder-mapping-template
MDM Policy Document	- Create policy document defining Roles, responsibilities, decision rights	NN MDM Policies
Road Map and High-Level Project Plan	- Phases, work streams, dependencies, timelines	Road-map
Risk Register	- Register the risks that can arise during the inception phase like Lack of Executive Sponsorship,Incomplete Data Inventory,Lack of alignment from stakeholders, data stewards etc	Risk-assessment
Inception Sign-Off	- Documented approval from business and IT leadership to proceed to design phase

What happens next?#

After the inception phase , It’s not just an idea anymore—it's a mapped-out, resourced, and validated plan for building a scalable MDM Solution. Business Analysis is then performed. In current roles , responsible parties are Business Analyst and Data Architect.
Intrinsic statements from use cases will be elaborated , enriched with details from outputs to shape the Requirements Specification .

The stakeholders identified are interviewed, both in casual and workshop forms .Users and consumers in this stage will provide important insights on the Business Value of the Solution and how the solution can be developed ensuring a user centric design to the solution .

The shaping of the Use Case document(s) happens iteratively, going through interviews, reviews, and improvements based on the feedback from reviews and interviews.
Some PoCs might be implemented as a foundation for discussions.

When all the parties are aligned on the vision of the Solution/Product - it is ready for elicitation of requirements .At this point it is possible to start working on Requirements Specification

Go up

Go to Playbook Main Page
Next: Requirements Specification