Demand Management - what to capture/how to route?

[Tom Sienkiewicz]

Hi Everyone,

are there any best practices in term of what objects should be ideally captured when raising a demand, and how do you ensure the demand gets assigned to the appropriate team/person that should manage it?

OOTB, on the demand form there is Capabilities and Business Apps.

Do you expose/populate Service/Service Offering on a Demand as well?

What about Product? 

How do you typically route demands to the right people? Does it happen manually by some central team that triages all demands, or do you have some "demand teams" automatically assigned, based on any of the above objects (similar to e.g. Support Teams for a Service Offering)?

One other question re. SPW - whenever I update a Planning Item Demand there e.g. specify a Product, this does not get reflected on the underlying Demand (Model ID / Product fields stay empty). Is this intended or something not working in my PDI (I thought there should be a sync between Demand and planning item demand)?

Many thanks!

[Marcos Gianoni]

Demand Intake and Data Capture Best Practices

The goal of demand intake is to capture enough information to make an initial Qualification decision, not a full assessment.

1. What Objects to Capture on the Demand Form

While Capabilities and Business Apps are out-of-the-box (OOTB) fields, the best practice is to align the demand to the hierarchy of your strategic investments.

Field/Object	Purpose	Best Practice Use
Product (cmdb_ci_product)	Ties the demand to the value stream and Product roadmap, which is crucial for modern SPM.	Highly Recommended. This is the primary field for alignment in a Product-Centric organization.
Business Service/Service Offering	Links the demand to the operational side of IT (ITSM/CSM).	Recommended. Useful for triaging to IT Operations teams or if the demand is purely focused on improving an existing service.
Portfolio/Program	Groups demands for reporting and strategic review.	Required. Demands should be assigned to a Portfolio (and optionally a Program) for strategic alignment and governance.
Strategic Goal/Theme	Ensures the demand aligns with corporate strategy.	Required. This provides the Why and is key for early prioritization and scoring.

2. Exposing Service/Service Offering and Product

Yes, you should expose Product and potentially Service/Service Offering.

• Product: This is critical if you are implementing Product-Centric SPM. It ensures the demand feeds directly into the Product Roadmap and is reviewed by the relevant Product Manager.

• Service/Service Offering: If your routing model depends on the IT organization structure (e.g., "The team that owns Service X must review the demand"), this is a very effective routing key. Use it if your organization is still heavily organized around Services.

---

Demand Routing and Assignment

The most effective solution for routing is to use Automation based on the captured data, minimizing manual triage.

1. Automation over Manual Triage

Relying on a central team for manual triage is slow and error-prone. The best solution is to use Assignment Rules or Data Lookup Rules (best practice for simple field lookups) on the dmn_demand table.

• Assignment Rules: Create rules that automatically set the Assignment Group and/or the Assigned To based on the input fields.

2. Best Routing Fields (The "Demand Teams" Analogy)

Your analogy to Support Teams is spot-on. You should link the assignment directly to the ownership of the captured object.

Routing Field	Assignment Logic	Example Rule
Product	Assign to the Product Manager or Product Owner Group defined on the Product CI record.	IF Product is "Mobile Banking App" THEN Assign Group is "Mobile App Dev Team."
Portfolio	Assign to the Portfolio Manager or the Demand Triage Group for that Portfolio.	IF Portfolio is "Digital Transformation" THEN Assign Group is "Digital Portfolio Office."
Service Offering	Assign to the Service Offering Owner Group (often populated from the CMDB Service Offering record).	IF Service Offering is "VPN Access" THEN Assign Group is "Infrastructure Services."

Recommendation: Start by routing the demand to the Owner Group of the related Product or Service Offering for initial review and qualification. This ensures the first reviewer is a domain expert.

---

Sync between Demand and Planning Item (SPW)

This question addresses a key area of the Strategic Planning Workspace (SPW) integration.

1. The Planning Item/Demand Sync Principle

OOTB, there is a two-way synchronization between the execution entity (e.g., dmn_demand) and its corresponding Planning Item (e.g., sn_align_core_demand).

• When you update a Planning Item (in SPW), the change should reflect on the underlying Demand record and vice-versa.

• Fields like Product, Portfolio, Priority, and Timeframe are typically included in this sync.

2. Why the Product Field Might Not Sync

If you are updating the Product field on the Planning Item in SPW and it is not reflecting on the underlying Demand record, it is likely due to one of the following:

1. Missing or Custom Sync Configuration: While OOTB fields generally sync, if the Product field was added to the Demand form after implementation, or if the instance has custom sync rules, the field mapping may be missing from the corresponding Business Rules that handle the sync between the tables.

2. Product Model vs. Product: Ensure both fields are referencing the same type of Product table (cmdb_ci_product). There are separate Product fields (e.g., Model ID on Demand) that may not be the one you are updating in SPW.

3. Synchronization Business Rule: Check the "After Update" Business Rules on the Planning Item table (sn_align_core_planning_item or its extension) that push changes back to the source record (dmn_demand). You may need to inspect the script and explicitly add the synchronization of the Product field's value.

Action: Verify the OOTB Business Rules on the Planning Item extension table (sn_align_core_demand) that handles the sync to ensure the Product field is included in the scripted payload.