Module2:

Configuration item:
A Configuration Item (CI) is any component of your IT environment that you
want to manage. This could be hardware, software, or even a service.
Key points:
 CIs are tracked in a CMDB (Configuration Management Database).
 Each CI has details like name, type, owner, version, and status.
Example:

1. CI = Laptop
[Link] = Amazon warehouse database that knows who owns which laptop,
where it is, and what happened to it
[Link] Request = “Order a laptop”

Sample of CI Classes
 These are different categories of items you can track.
 Examples shown:
o Server (Computer) → e.g., the physical machine in your data
center.
o Network Gear → e.g., Wi-Fi router, switch.
o Storage Device → e.g., USB drive, SAN storage.
o Virtual Machine → e.g., a VM running Windows/Linux.
o Application → e.g., MS Teams, Payroll app.
👉 Real Example: If you’re in a college:
 Computer Lab PCs = Computer CI
 Projector = Hardware CI
 Wi-Fi router = Network Gear CI
 College website = Application CI
Table Schema Map
 This shows common fields every CI has (like a form template).
 Examples:
o Name = Server01, Router1, PayrollApp
o Manufacturer = Dell, Cisco, Microsoft
o Install Date = When it was installed
o IP Address = [Link] (for network devices)
o Serial Number = Asset tracking
o Support Group = IT Team that manages it
👉 Real Example:
If your college projector is a CI:
 Name = "Classroom Projector-1"
 Manufacturer = "Epson"
 Install Date = "2022-06-15"
 Support Group = "IT Support Team"
CI Class Manager (Bottom section)
 This is the tool in ServiceNow where you browse, search, and manage
different CI types.
 Like a catalog where you choose what type of CI you want to create.
👉 Real Example:
If you’re adding a new printer in college, you go to CI Class Manager →
choose "Printer" class → fill details like name, model, location.

1. What is CMDB?
 CMDB = Configuration Management Database
 Think of it as a giant organized catalog of all important items (CIs) in
your organization.
 It not only stores each CI, but also tracks relationships between them.
  Helps IT teams see the whole picture: what exists, who owns it, how it’s
connected, and how it impacts services.

2. Parent → Child Relationships

 CMDB uses inheritance so you don’t repeat information unnecessarily.
 Parent CI → common attributes
 Child CI → inherits parent attributes + adds specific ones
 Example: Car Manufacturer
 Level  CI Attributes
 Vehicle (Parent)  Wheels, Engine, Chassis
 Inherits Vehicle + Doors, Seats, Fuel
 Car (Child)
Type
 Electric Car  Inherits Car + Battery Type, Charging
(Grandchild) Time

Why CMDB is useful

1. Track everything in one place → no lost laptops, servers, or software
2. See relationships → which servers run which apps, which software is on
which laptop
3. Manage changes → know which CIs are affected if a server fails
4. Avoid duplicate data → thanks to parent-child inheritance

Structure of CMDB
1. Base Configuration Item Table (root level)
 Think of this as the top-most table: “Everything that can be tracked.”
 Includes: both technical and non-technical items.
 All other CI tables inherit from this.
2. Configuration Item (CMDB CI) Table
  This table is only for technical items (IT stuff).
 Examples: computers, servers, printers, network gear, applications.
 It extends from the Base CI Table, meaning it inherits basic properties
(like name, owner, location)
3. Non-Technical Items
 If you want to track non-IT things (like chairs, meeting rooms,
contracts), they also extend from the Base CI Table, but not from the
technical CI table.

Why “Stick to Out-of-the-Box”?

 ServiceNow already gives 500+ prebuilt CI classes.
 Before creating your own, check if it already exists.
👉 Example:
 You want to track “Projectors” in your office. Instead of creating a new
table, check if ServiceNow already has a Peripheral or Printer-like
device class.
 Saves time and keeps things standard.
CI References (Connections)
Every CI connects to foundation data:
1. Group → Who supports it.
o Example: A server is linked to the “Infrastructure Support” team.
2. User → Who owns it.
o Example: A laptop CI is assigned to John Doe (employee).
3. Location → Where it is.
o Example: A router CI is located in Hyderabad Office, 2nd Floor
Server Room.
4. Cost Center / Company → Who pays for it.
o Example: A printer CI belongs to Finance Department, Cost
Center 301.
EXAMPLE:
 o Imagine your college is using ServiceNow CMDB:
o Base CI Table → “Things in college”
o Configuration Item Table (Technical) →
o Server = College website server
o Computer = Lab PC
o Network Gear = Wi-Fi router
o Application = Student portal
o Printer = Library printer
o Non-Technical Items →
o Classroom furniture
o Projectors
o Bus assets

The Lab PC CI is owned by IT Faculty (User), supported by Computer Lab

Team (Group), located in Lab-2 Building A (Location), and billed to
Department of CSE (Cost Center).

CI Relationships in CMDB (stored in cmdb_rel_ci).

Every item (CI) in CMDB must have at least one relationship.
 Relationships show how things depend on each other.
 Upstream = Parent (what this item depends on).
 Downstream = Child (what depends on this item).
🔹 Real-Time Example 1: College Wi-Fi System
 Wi-Fi Router (Parent / Upstream)
o Provides internet connection.
 Lab Computers (Child / Downstream)
o Depend on the Wi-Fi router to access the internet.
👉 Relationships:
  Router → Computers = "Computers depend on Router."
 If the router fails, all lab computers lose internet.
🔹 Main Actors (Personas) in CMDB
1. CMDB User (Read role)
o Can only view/read the CMDB.
👉 Example: A college professor can log in and see which lab
computers exist, but can’t change or delete anything.
2. CMDB User (ITIL role)
o Can create, update, or delete CIs, and associate CIs with tasks.
👉 Example: The IT support staff in a college can:
 Add a new printer to CMDB (Create CI).
 Update details when a lab PC’s RAM is upgraded (Update
CI).
 Delete old projectors that were discarded (Delete CI).
 Associate a “Lab PC” CI to an “Incident” ticket if a student
reports that the PC is not working.
3. System (ServiceNow itself)
o Auto-discovers CIs (using Discovery) and updates them.
👉 Example: If a new Wi-Fi router is connected to the college
network, ServiceNow Discovery finds it and automatically creates
a CI for it.
4. System Administrator
o The “super admin.” Creates new CI classes, maintains attributes,
imports/reconciles CIs.
👉 Example: In a restaurant chain, the sys admin may:
 Create a new CI Class called Kitchen Appliance.
 Add attributes like power usage, warranty, vendor.
 Import a list of all ovens, refrigerators, and coffee machines
into CMDB.
5. CMDB Admin
 o A lighter version of sys admin. Can only create CI classes (not
manage relationships or imports).
👉 Example: In the same restaurant, a CMDB Admin could create a
class for Delivery Vehicle but cannot manage how it relates to
other systems (like fuel cards or GPS).

🔹 CMDB Platform Roles and Actions

1. Read CI
 Can only view configuration items.
👉 Example: A professor can see what computers exist in the lab but
cannot change them.
2. Create CI
 Add a new configuration item.
👉 Example: IT staff adds a new Wi-Fi router into CMDB when it’s
installed in the college.
3. Update CI
 Change the details of an existing CI.
👉 Example: When a lab computer’s RAM is upgraded, IT updates the
CI record with new specs.
5. Delete CI
Remove an outdated CI.
👉 Example: A library printer that is no longer working is removed from
the CMDB.

5. Associate CI to an Active Task

 Link a CI to an incident, problem, or change ticket.
👉 Example: A “Wi-Fi Router” CI is linked to an incident ticket when
students report internet issues.
6. Associate CI to New or Existing Change Request (CR)
 Attach a CI to a change request.
👉 Example: Before upgrading the payroll app, the ITIL user links the
Payroll Server CI to the change request.
7. Subscribe / Unsubscribe
 Get notified about CI changes.
👉 Example: A finance manager subscribes to the “Payroll Application
CI” so they’re alerted when there’s downtime.
8. Create New CI Class
 Add a new category of CI.
👉 Example: Sys Admin creates a “Kitchen Appliance” CI class for a
restaurant chain to track ovens, refrigerators, and coffee machines.
9. Manage CI Attributes
 Decide what details (fields) should be stored about a CI.
👉 Example: For a Projector CI, the attributes could be: Resolution,
Lumens, Warranty Expiry.
10. Maintain Suggested Relationships
 Define how different CIs are related.
👉 Example: A Payroll Application CI → depends on → Payroll
Database CI.
 If database goes down, payroll app will stop working.

11. Identify and Reconcile CIs

 Clean up duplicates and match discovered data.
👉 Example: ServiceNow discovers 2 entries for the same server → Sys
Admin merges them into one correct CI.
12. Import CIs
 Bulk upload new items into CMDB.
👉 Example: Upload a list of all new lab computers purchased this
semester from Excel into CMDB.
13. Create and Manage Dynamic CI Groups
 Create CI groups based on rules.
👉 Example: Automatically group “All servers in Hyderabad Data
Center” or “All laptops with Windows 11”.
🔹 Role Responsibility Summary
 System Administrator (big boss)
o Can do everything, including:
 Create CI classes
 Manage CI attributes
 Maintain suggested relationships
 Import & reconcile CIs
 Create/manage dynamic CI groups
 CMDB Admin
o More limited: Can only create CI classes (with personalized
dictionary role).
 CMDB User (ITIL role)
o Day-to-day IT staff: Create, update, delete CIs, associate CIs to
tasks, subscribe/unsubscribe.
 CMDB User (Read role)
o Only view CIs, nothing else.

CMDB USE IN IT PROCESSESS

1. Incident Management – Fixing problems fast

Scenario: A server in your company’s data center stops working.
 CMDB Role: Shows which business apps depend on that server.
 Real-life example: Imagine the server runs your company’s email
system. Without it, employees can’t send emails. The CMDB helps IT
quickly see, “Oh! Email and HR app are affected,” so they prioritize
fixing it immediately.
 Impact: High-priority services are restored faster.

2. Change Management – Assessing risks before making changes

Scenario: IT wants to upgrade a network router.
 CMDB Role: Shows what depends on that router.
 Real-life example: The router supports office Wi-Fi, VoIP phones, and
printer connectivity. IT can see the risk: if the router goes down, multiple
services are impacted.
 Solution: Schedule upgrade during off-hours or set up a backup router.

3. Problem Management – Finding the root cause

Scenario: Employees keep reporting slow login times for a business
application.
 CMDB Role: Shows what infrastructure the app relies on.
 Real-life example: CMDB reveals the login server is shared with another
app, which is causing overload. IT identifies the root cause and fixes it.

4. Request Management – Delivering things efficiently

Scenario: You request new software on your computer.
 CMDB Role: Tracks which device you have and its specs.
 Real-life example: You ask for Photoshop. CMDB tells IT, “Lavanya’s
laptop has enough memory and license availability.” IT installs it
automatically without errors.

What are Dynamic CI Groups?

 A Dynamic CI Group is a group of configuration items (CIs) that
updates automatically.
 The group is created based on filters or rules instead of manually picking
items.
 Unlike static groups, you don’t have to update it yourself—it’s always
current.

2. Real-life Example
Scenario: You want to track all Lenovo laptops in your company.
 Filter rule: “Manufacturer = Lenovo”
 Dynamic CI Group: Automatically includes every Lenovo laptop in
your CMDB.
 If a new Lenovo laptop is added, it automatically joins this group.
 If a Lenovo laptop is retired, it automatically leaves the group.

1. Incident Management – Lenovo Laptop Outage

 Scenario: Windows patch crashes Lenovo laptops.
 Dynamic Group: Manufacturer = Lenovo AND Class = Laptop
 Use: Service desk picks this group → all impacted laptops are
automatically linked.
 Benefit: Saves time, no manual selection of hundreds of laptops.
2. Change Management – Server Upgrade
 Scenario: Hyderabad data center needs Linux patch.
 Dynamic Group: Location = Hyderabad AND Class = Server
 Use: Added to the change record → CAB sees all affected servers and
dependent apps.
 Benefit: Accurate risk analysis, better planning.
3. Problem Management – Lenovo Monitor Issues
 Scenario: Recurring display issues on Lenovo monitors.
 Dynamic Group: Manufacturer = Lenovo AND Class = Monitor
 Use: Link group to problem record → analyze recurring incidents.
 Benefit: Helps trace root cause across all affected monitors (driver,
firmware, etc.).
4. Request Management – Software Rollout
 Scenario: Zoom rollout for Lenovo desktops.
 Dynamic Group: Manufacturer = Lenovo AND Class = Desktop
 Use: Request workflow automatically installs Zoom on all group devices.
  Benefit: Ensures correct devices are updated, automated process.

What is a Principal CI Class?

 It’s like a filter that controls which types of CIs (Configuration Items)
can be linked to ITSM tasks such as:
o Incident
o Problem
o Change
 Ensures that only relevant items are selectable, avoiding mistakes.
Controlled by:
1. Principal class flag (True/False) → marks a CI class as “principal.”
2. System property → defines which task tables (Incident, Change,
Problem) follow this filter.
Imagine Amazon’s website:
 Task table = “Your Shopping Cart”
 CI classes = product categories (Laptops, Mobiles, Books, Furniture)
 Principal CI Class = filter on what you can add to your cart
Example 1 – Buying Electronics only:
 Scenario: You are in the “Electronics” section.
 Principal class filter: Only Electronics (Laptops, Mobiles, Tablets) are
selectable.
 Result: You cannot add a book or chair to this electronics-only cart.

ITSM Real-Life Example

 Incident: Laptop is not working → you should only link it to CI class =
Computer, not a Printer or Server.
 Problem: Printer keeps jamming → link only CI class = Printer.
 Change: Upgrading a server → link only CI class = Server, not Desktop
or Application.
1. Incident Management – Trading App Crash
 Scenario: Trading application stops working.
 Principal Class: Application
 Effect: You can only select Application CIs like “Bond Trading App.”
 Benefit: Avoid selecting unrelated items like monitors or laptops →
focus on what actually matters.
Analogy: Imagine a car dashboard: if your engine light is on, you only check
engine parts, not the tires.

2. Change Management – Payroll App Patch

 Scenario: Updating Payroll application.
 Principal Class: Application
 Effect: Only applications (Payroll, HR System, CRM) can be linked to
the change request.
 Benefit: Prevents linking unrelated things like “Network Printer.”
Analogy: When fixing your phone software, you only touch apps or OS, not
the phone case.

3. Problem Management – Database Slowness

 Scenario: Multiple incidents about slow database.
 Principal Class: Database
 Effect: Only Database CIs like OracleDB or MySQL Server can be
linked.
 Benefit: Root Cause Analysis is easier and accurate.
Analogy: If your internet is slow, you check router/modem, not your fridge.

4. Child Class Example

  Scenario: Application is Principal, but child classes (Web App, Mobile
App) are not marked principal.
 Effect: Users cannot select child classes automatically.
 Fix: Admin marks child classes as Principal = True.
Analogy: Parent = “Fruit,” Child = “Apple, Banana.” If only Fruit is allowed,
you cannot pick Apple or Banana unless allowed.

5. Non-Principal Tables
 Scenario: System property applies only to Incident, Problem, Change
Request.
 Effect: Service Request tasks are not restricted → users can select any
CI.
 Benefit: Gives flexibility to enforce restrictions in some processes and
allow freedom in others.
Analogy: VIP section in a restaurant applies only for dinner. Breakfast is open
to everyone.

What are Independent and Dependent CIs?

Type Meaning Example

Independent Can exist on its own. Doesn’t A Linux server, a network
CI rely on any other CI. switch, or a laptop.
Cannot exist without another A business service, application
Dependent CI CI. It relies on a relationship service, or database that runs
with another CI. on a server.

How They Work

 Independent CI: Identified by its own attributes (IP, name, serial
number).
 Dependent CI: Identified by its relationship with another CI. You cannot
have it without the parent CI.
Real-Time Examples
Scenario: Online Banking System
Independent CIs:
 Linux Server → Linux100
 Database Server → DB01
 Network Switch → SW-01
Dependent CIs:
 Online Banking Application → Depends on Linux100 server
 Customer Service Portal → Depends on DB01
 Payment Gateway Service → Depends on Linux100 server
Relationships:
 Linux100 hosts Online Banking Application
 DB01 hosts Customer Service Portal
 Online Banking Application depends on Linux100
Explanation:
 If the Linux100 server goes down, the Online Banking Application
(dependent) will also be impacted.
 But Linux100 can exist without any services running — it’s
independent.

Why This is Important in ITSM

 When planning a Change Request, you must know dependent CIs:
o If a server goes down, which services will be impacted?
o Helps in impact analysis and avoiding business disruptions.

What is the CMDB Foundations Dashboard?

It’s a dashboard in ServiceNow that gives insights into the health and quality
of your CMDB (Configuration Management Database) and CSDM (Common
Service Data Model).
 Helps track best practices, customizations, data quality, and ITSM
metrics.
 Organized into 4 tabs with prebuilt reports.
2. Tabs and Simple Examples
A. Best Practices
 What it shows: Reports on general CMDB rules.
 Examples:
o Hardware CIs missing serial numbers (like a server without a
serial number).
o Services missing owners (like “Online Banking Service” without a
responsible person).
 Real-Time: If the dashboard shows a printer with no serial number, IT
knows it needs to fix the record.
B. Customizations
 What it shows: Custom tables and attributes in CMDB.
 Examples:
o A custom table for “Smart Doorbells” or “IoT Devices.”
o Use of custom fields like “Warranty Expiry Date” for servers.
 Real-Time: Helps track custom setups and ensure they follow standards.
C. Data Management Practices
 What it shows: Data quality metrics.
 Examples:
o Duplicate CIs (two records for the same server).
o CIs missing names or locations (e.g., a switch with no location).
o Active CIs not updated in the last 90 days.
 Real-Time: IT sees that two records for “Linux100 server” exist →
merge them to prevent errors.
D. ITSM Processes
 What it shows: Metrics linking CMDB to ITSM processes.
 Examples:
o Incidents without a CI linked (like a ticket for a server crash but no
server selected).
o Changes without a CI (like a patch applied but not linked to any
server).
 Real-Time: If an incident is created for “POS system” but no CI is
linked, IT can quickly correct it to know which system is impacted.

CSDM

What is CSDM?
CSDM is like a blueprint that tells you:
 How to organize your CMDB (Configuration Management Database).
 How to connect services, applications, and infrastructure together in a
standard way.
 How to report on services in a business-friendly manner.
Think of it as a map that shows how your IT stuff (servers, apps, networks)
supports your business services (like email, payroll, online banking).

🔹 Why CSDM?
Without CSDM:
 Each team may call things differently (one says “Email App”, another
says “Mail Service”).
 Reporting is inconsistent (can’t easily say “How many users depend on
this server?”).
 Hard to show IT’s value to business.
With CSDM:
 Everyone uses the same definitions.
 Easier to link IT components → Applications → Business Services.
 Service-level reporting becomes accurate.

🔹 Real-time Example 1: Online Banking Service

 Business Service: "Online Banking" (what customers use).
 Application Service: "Core Banking Application" (runs transactions).
 Application: "Database App", "Web App", "Mobile App".
 Infrastructure (CMDB items): Servers, Databases, Network Devices.
👉 With CSDM, you can trace:
If the database server goes down, it affects → Database App → Core
Banking Application → Online Banking Service → Customers.
So reporting can say:
"This outage impacts Online Banking Service, used by 50,000 customers."
🔹 CMDB vs CSDM
Aspect CMDB CSDM
A database (system of record) for A framework / blueprint that
all Configuration Items (CIs) tells you how to organize, model,
What it is
like servers, apps, routers, and manage those CIs inside
services, etc. CMDB.
Structuring data (relationships,
Focus Storing data (technical records).
service modeling).
Broader: connects IT assets →
Scope Technical foundation for IT assets. Applications → Services →
Business outcomes.
Guidance (something you
Nature System (something you “have”).
“follow”).
Used by architects, admins, and
Used by IT teams to track and
Usage ServiceNow teams to standardize
manage CIs.
how data is modeled.
Can be customized, but too much Provides best practices to keep
Flexibility
customization = mess. CMDB healthy and consistent.
Improves reporting accuracy
Can generate reports, but quality
Reports because of standardized
depends on how data is modeled.
mappings.

🔹 Real-time Example
Example: Hospital IT System
 CMDB:
o Stores records like:
 Server-01 (Windows Server, hosting Hospital DB)
 App-01 (Patient Management System)
  Network-01 (Router for hospital LAN)
 CSDM:
o Provides guidance on how to link them:
 Business Service: "Patient Care Service"
 Application Service: "Patient Management App Service"
 Application: App-01
 Infrastructure: Server-01, Network-01
👉 Without CSDM: CMDB is just a list of items.
👉 With CSDM: You can see the relationships and say:
"If Server-01 fails, Patient Management App fails → Patient Care Service is
disrupted → Doctors can’t access patient records."

🔹 CSDM IS
The Common Service Data Model (CSDM) is:
 ✅ A CMDB Framework – A blueprint to structure and organize CMDB
data.
 ✅ Standard terms and definitions – Everyone uses the same language
for services, applications, and infrastructure.
 ✅ Best practices for CMDB data modeling and management –
Guidance on how to connect CIs, apps, and services.
 ✅ Core CMDB tables & recommended mappings – Defines how
Business Services, Application Services, Applications, and Infrastructure
relate.
 ✅ Guidance on service modeling – Helps you show how IT supports the
business.
 ✅ People and Process focused – Not technology, but how people should
design, align, and manage data.
👉 Analogy: CSDM is like a city blueprint. It tells you where the roads, parks,
schools, and houses should go so the city grows in a planned way.
🔹 CSDM IS NOT
The Common Service Data Model (CSDM) is not:
  ❌ Not a final solution – It’s guidance, not the “end product.”
 ❌ Not a process or implementation guide – For ITSM, ITOM, SPM,
APM, EM, etc. It supports them but doesn’t replace their processes.
 ❌ Not a set of reports – Although it improves reporting quality.
 ❌ Not code or a plugin you install – It’s a framework, not software.
 ❌ Not an automatic fix for past CMDB issues – If your CMDB is
heavily customized or messy, CSDM won’t “magically” clean it up. It
requires effort to align.
👉 Analogy: CSDM is not the construction crew. It won’t build the city for
you. It just gives you the urban planning design—you still need to put in the
work.
🔹 One-Line Summary
CSDM is a blueprint for structuring CMDB data with standard definitions
and best practices. It is not software, code, or an instant fix for bad
implementations.

CSDM Domains:

1. Foundation (Base Data)

👉 Think of this as the basic setup before the restaurant can operate.
 Example: Restaurant location, employees, suppliers, customer details.
 Without this, nothing can run.

2. Design (Planning the Service)

👉 Deciding what services (dishes) you want to provide.
 Example: Creating the menu – starters, main course, desserts.
 Aligning with customer needs (vegetarian, non-veg, spicy, healthy
options).

3. Build (Prepare Resources)

👉 Bringing together the technical items needed to make the service.
  Example: Kitchen setup, stoves, utensils, raw materials, recipes.
 This ensures the backend resources exist to deliver the menu.

4. Manage Technical Services (Operate & Maintain)

👉 Day-to-day running and ensuring services are healthy.
 Example: Chefs cooking dishes, waiters serving food, checking stock,
maintaining hygiene.
 Monitoring quality (food taste, freshness) and fixing problems (replace
spoiled ingredients, repair oven).

5. Sell/Consume (Customer-facing Service)

👉 Where the customer actually consumes the service.
 Example: Customers see the menu card (service catalog), place orders,
and enjoy the meal.
 Pricing and value are clear (dish cost, service charge).
In short:
 Foundation = Setup restaurant basics
 Design = Decide the menu
 Build = Prepare kitchen & resources
 Manage = Run and maintain operations
 Consume = Customers order & eat

How CSDM applies in ITSM:

 CSDM ensures everything in ITSM (Incidents, Problems, Changes) is
linked to services properly.
 Service = What the restaurant provides → e.g., Food Delivery Service
 Service Offering = Specific dishes → e.g., Burger, Pizza, Salad
Example:
 1. A customer complains (Incident) that their pizza is cold → linked to
Food Delivery Service and Pizza offering.
2. Restaurant finds that oven temperature is inconsistent (Problem) →
linked to Kitchen equipment service.
3. Restaurant upgrades the oven (Change) → still tracked under Kitchen
technical service.
✅ Result: Every issue, change, or improvement is connected to the right
service, making operations clear, efficient, and customer-focused.

1. Incident Management
 Scenario: “Email not working”
 Service: Corporate Email Service
 Service Offering: Outlook Web Access
 CSDM Benefit: Incident is linked to the exact service → can report:
“Outlook Web Access caused 20 incidents this month.”

2. Problem Management
 Scenario: Multiple email incidents
 Service Offering: Outlook Web Access
 CSDM Benefit: See underlying apps & servers → easier root cause
analysis (e.g., overloaded mail server).

3. Change Management
 Scenario: Patch for Email Server
 Service Offering: Outlook Web Access
 CSDM Benefit: Know business impact before approval → affects 5,000
users.

4. Request Management
 Scenario: Upgrade to Premium Mobile Banking
  Service Offering: Mobile Banking – Premium
 CSDM Benefit: Requests are linked to service → smooth fulfillment and
traceability.

CSDM Dashboard - Maturity Levels

1. Foundation ✅
 Basic data exists: users, products, business units.
 Example: You know who the users and business units are.
2. Crawl 🐾
 Services start linking to Applications.
 Example: “This Incident is linked to Application X.”
3. Walk 🚶
 Technical Service Offerings linked to support/change groups.
 Example: “Incident linked to Service Offering Y, supported by App Z.”
4. Run 🏃
 Advanced CMDB alignment, custom tables in use.
 Example: “Incident linked to Service Offering Y, App Z, impacting
Business Unit A.”
5. Fly
 Full business alignment, advanced reporting, end-to-end visibility.
 Example: Complete view of service impact on business outcomes.