Navigating Through ServiceNow's CSDM 4.0: Crawl, Walk, Run and Fly Phases

Embarking on the Common Service Data Model (CSDM) journey—from Crawl to Walk, Run, and ultimately Fly—is both insightful and challenging. One of the biggest hurdles is distinguishing technical services from business services. ServiceNow recommends starting with application services and business applications in the Crawl and Walk phases while incorporating technical services and business services in the Run and Fly phases.

While this structured approach works well when business and technical services are clearly defined, it can challenge organizations undergoing an operating model transformation. In such cases, starting with technical services can create complexity instead of clarity.

For organizations where transformation coincides with ServiceNow CSDM implementation, a useful approach is shifting the focus toward business capabilities and business services. In this article, I share insights and techniques that have helped uncover and differentiate business services and technical services—ensuring alignment with CSDM principles while maintaining operational feasibility.

CSDM framework primarily focuses on digital services, often using IT-centric terminology. This can make it difficult to map business service offerings to application services without creating unnecessary complexity.

Simplifying Business Services and Offerings

A simple and effective approach to structuring business services and offerings is first to ensure?alignment with business capabilities.

Business capability data is typically found in enterprise architecture repositories, strategic business plans, and organizational capability frameworks. Many organizations document these in tools like ServiceNow APM (Application Portfolio Management), ArchiMate, Business Process Modeling tools, or internal strategic documentation. Consulting with Enterprise Architects (EA) and business stakeholders is crucial to obtaining accurate data.

Once the data is available, the next step is effectively mapping?business services?and?offerings. From there, break down services based on value-adding factors, such as:

• Ownership
• Support groups
• Geographical coverage
• Tiering
• Customer commitments

If none of these factors justify creating service variations, it's best to standardize business service naming conventions while introducing a clear distinction between a business service and an offering.

Additionally, reviewing existing request catalog items can help group services logically, serving as a starting point for understanding service variations.

Common Misconceptions: Offerings vs. Requestable Items

Many organizations mistakenly equate offerings with requestable items in service catalogs. However, CSDM differentiates these concepts:

• Offerings: Define how a service is delivered to customers. (Example: Self-service IT portal access)
• Requestable Items: Represent specific components available within an offering. (Example: Requesting access to the self-service portal or a software license request)

Business Services vs. Technical Services

Understanding the difference between business services and technical services is critical for effective service modeling:

1. Business Services

• What they are: Customer-facing services aligned with business capabilities.
• Who uses them: End users or business units.
• Example: Customer Payment Processing Service supporting financial transactions for an e-commerce platform.
• Key Data Points: Business capability alignment End-user impact Service Ownership

Business Service Offering Example Based on Location:

• Business Service: Customer Support Service
• Offerings: North America 24/7 Support Europe Standard Business Hours Support Asia-Pacific Regional Support
• Key Differentiators: Geographic coverage, availability hours, language support

Business Service Offering Example with No Variations:

• Business Service: Email Service
• Offerings: Single Standard Offering: Corporate Email Service Note: I have particularly found value in adding some metadata such as offering as a suffix e.g. Email Service Offering. This usually helps differentiate it in a dependency map.
• Reasoning: No variation is required as the email service is globally standardized with the same support, ownership, and access for all users.

2. Technical Services

• What they are: IT-delivered services that support business services.
• Who manages them: IT teams (not directly consumed by end users).
• Example: Database Hosting Service supporting a business service like Customer Payment Processing. Technical Services Offerings Examples with variations: Database Hosting Service – APAC (Geography based) or Database Hosting Service 24*7 (SLA based). A point to remember that technical services variations have a certain purpose to serve in terms of automation using CSDM Sync. This will be elaborated on in the next article!

Conclusion

Successfully progressing through the run-and-fly phases of CSDM requires a structured approach that Prioritizes business capabilities, aligns business services with enterprise architecture, and differentiates technical services effectively. By focusing on practical service modeling techniques, organizations can reduce complexity and ensure seamless CSDM implementation that supports both IT and business transformation.