3.3.2. Example Value Stream: Request to Fulfill Service Request
💡 First Principle: An effective value stream for standard requests leverages pre-defined models, automation, and clear workflows to deliver services quickly, consistently, and with minimal manual effort.
Scenario: A user needs access to a specific software application. They go to the self-service portal, find the software in the catalog, and submit a Service Request. Because this is a pre-approved Standard Change, the request automatically triggers a Deployment Management script that installs the software on the user's machine and updates the Service Configuration Management records. The user is notified automatically upon completion.
This value stream describes the steps taken from a user requesting a standard service to its fulfillment.
Detailed Flow: Automated Software Request
| Step | SVC Activity | What Happens | Practices Involved |
|---|---|---|---|
| 1 | Engage | User browses service catalog, finds "Microsoft Visio," clicks "Request." Portal captures user ID, device info, and business justification. | Service Request Management |
| 2 | Engage | System checks: Does user's role permit this software? Is license available? Both pass → request auto-approved. | Service Request Management, Access Management |
| 3 | Obtain/Build | Standard Change triggered (pre-authorized, no CAB needed). Deployment script queued for user's device. | Change Enablement (Standard Change), Deployment Management |
| 4 | Deliver & Support | Software deployed to device during next connection. CMDB updated with new software CI linked to user's device. | Deployment Management, Service Configuration Management |
| 5 | Engage | Automated notification: "Microsoft Visio installed successfully. Click here to launch." Feedback survey link included. | Service Request Management |
| 6 | Improve | Monthly analysis: Average fulfillment time for software requests is 4 hours. Goal: reduce to 1 hour via on-demand deployment. | Continual Improvement |
Detailed Flow: Access Request Requiring Approval
Not all service requests are fully automated. When business approval is needed:
| Step | SVC Activity | What Happens | Practices Involved |
|---|---|---|---|
| 1 | Engage | User requests access to "Financial Reporting System" via portal. System identifies this as a sensitive resource requiring manager approval. | Service Request Management |
| 2 | Engage | Approval request routed to user's manager. Manager receives email with approve/deny buttons and context (who, what, why). | Service Request Management |
| 3 | Engage | Manager approves. Request status updated. User notified: "Pending fulfillment." | Service Request Management |
| 4 | Deliver & Support | Access provisioned in the application. User added to appropriate security group. Audit log updated. | Service Request Management, Information Security Management |
| 5 | Engage | User notified: "Access granted to Financial Reporting System. Bookmark: [link]." | Service Request Management |
Request Types and Fulfillment Paths
| Request Type | Example | Typical Path | Automation Level |
|---|---|---|---|
| Information | "What's the VPN server address?" | Knowledge article returned | Fully automated (chatbot/FAQ) |
| Access | "Grant me access to Project X SharePoint" | Approval → Provisioning | Semi-automated |
| Resource | "I need a second monitor" | Approval → Procurement → Delivery | Manual with workflow |
| Standard Service | "Install approved software" | Standard Change → Deployment | Fully automated |
| Feedback | "The new expense system is confusing" | Logged → Routed to service owner | Manual review |
Practice Interactions in This Value Stream
⚠️ Common Pitfall: Requiring CAB approval for standard, low-risk requests. This creates unnecessary delays and frustration. If a request type is pre-defined, low-risk, and frequently executed, make it a Standard Change with pre-authorization.
Key Trade-Offs:
- Self-Service vs. Agent-Assisted: Self-service portals scale efficiently but require upfront investment in catalog design and workflow automation. Agent-assisted requests are flexible but create bottlenecks.
- Automation vs. Flexibility: Fully automated fulfillment is fast and consistent but can't handle edge cases. Build escalation paths for requests that don't fit standard models.
- Speed vs. Security: Auto-approving all requests is fast but risky. Classify requests by sensitivity and apply appropriate controls without over-engineering low-risk items.
Reflection Question: Why is the relationship between Service Request Management and Change Enablement (specifically Standard Changes) critical for an efficient value stream? What would happen if every software installation required a Normal Change?
