Change Management
Purpose
Change Management provides a clear, shared process for changes to customer services. It makes sure that scope, effort, commercial impact, customer approval, implementation, and closure are clear before the change is completed.
This page is the reference process. The Jira workflow supports the process, but it does not replace the responsibilities described here.
When a Change Request Applies
Create or convert a ticket to a Change Request when one or more of the following apply:
The request creates a new price or changes an existing recurring price.
The request changes the architecture, supported scope, or SLA.
The request requires more than four hours of effort.
The request affects data locality or the security posture.
The request needs a product or partner that VSHN does not currently provide to the customer.
If none of these apply, keep the ticket as a Service Request and follow the Service Desk Workflow.
| Team-initiated and VSHN-initiated changes are created directly as Change Requests by the Product Owner. They are customer-visible from the start. If VSHN must act regardless, for example for a security or end-of-life change, do not wait for customer approval. Inform the customer of the change instead. If the change has a commercial impact, involve Account Management and complete the Pricing step before implementation. Record the commercial basis, price, and quote reference in the Change Request. |
Responsibilities
| Role | Responsibility |
|---|---|
Service Desk | Triages incoming Service Requests, identifies qualifying Change Requests, converts them, and routes them to the customer’s Product Owner. |
Product Owner | Owns Analysis, Approved, Implementation, and Closed. Establishes the requested outcome and constraints, chooses the path, creates and links implementation work, and makes sure closure gates are passed. |
Solution Architect | Owns Solution Design. Designs the solution and creates or extends the solution documentation. |
Team | Owns Estimation. Produces the engineering estimate. |
Account Management | Owns Pricing and Waiting for Customer Approval. Prepares and presents the commercial proposal, then manages the customer response. |
Customer | Approves the commercial proposal before implementation when approval is required. |
Workflow
Change Requests are customer-facing tickets. A Service Request can be converted to a Change Request in place so that the original request and its clarification remain in one thread.
The normal workflow starts with New → Analysis.
Choose a Path in Analysis
In Analysis, decide which path applies. Use the corresponding Jira transition.
| Path | Use this when | What to do in Jira |
|---|---|---|
Standard change | The change uses an existing product or catalogue item and its price follows from the catalogue. Solution Design and Estimation are not needed. | Use Start Pricing. Continue with Pricing. |
Custom change | The requested change needs a technical solution design before it can be estimated and priced. | Use Start Solution Design. Continue through Solution Design, Estimation, and Pricing. |
New solution | The request needs a product, service, or partner that VSHN does not currently provide. | Link the Change Request to the appropriate Customer Project in the requirements-engineering process. Then use New Solution: Close. Do not use the Change Request to design or deliver the new solution. |
Before closing a Change Request as a new solution, confirm that the customer has been informed that the request will be handled as new-solution work. Do not promise delivery, scope, price, or timing until that work has been assessed.
All change paths that require commercial approval continue through Pricing → Waiting for Customer Approval → Approved → Implementation → Closed.
The workflow permits returning a request when more work is needed:
Waiting for Customer Approval to Pricing when the customer negotiates or requests a variant.
Pricing to Analysis when more technical clarification is needed.
Analysis to New when the ticket turns out not to be a Change Request.
Pricing to Estimation when the effort must be revised.
Estimation to Solution Design when the design must be revised.
Solution Design to Analysis when the requested outcome, scope, or constraints must be reconsidered.
Working Through the States
| State | Responsible role | What must happen |
|---|---|---|
New | Service Desk | Decide whether the Service Request is a Change Request. If it is, convert it and route it to the customer’s Product Owner. |
Analysis | Product Owner | Establish the problem, desired outcome, and constraints. Decide whether VSHN offers the request and choose the standard-change, custom-change, or new-solution path. |
Solution Design | Solution Architect | Design the solution and create or extend the solution documentation. The design must be reviewed and considered buildable and supportable. |
Estimation | Team | Produce the engineering estimate. Record the estimated effort before moving to Pricing. |
Pricing | Account Management | Determine the commercial charge for the Change Request from the estimated effort and the customer’s agreed rate. If the request changes a product price, involve the responsible Product Manager. Decide whether to provide a quote or in-ticket confirmation, and present the proposal to the customer. Record a short commercial summary, the estimated effort, commercial basis, price, and quote reference where applicable. |
Waiting for Customer Approval | Account Management | Wait for the customer’s decision. Keep the ticket current and respond to questions or return it to Pricing when the proposal changes. |
Approved | Product Owner | The required customer approval is recorded. Create and link the implementation item. |
Implementation | Product Owner | Ensure that the linked implementation item is completed. Record the implementation work and acceptance evidence in the Change Request or linked work items. |
Closed | Product Owner | The Change Request is complete, rejected, expired, or closed as a new solution after the Customer Project is linked. Confirm that the closure gates are passed, then record the resolution and a brief closing explanation. |
Assignment and Handover
| The state is the queue; the assignee is the claim. |
When a Change Request moves to a state owned by another role, it becomes unassigned. The responsible role claims the request from its queue by assigning it to themselves.
Service Desk triage routes a new Change Request to the customer’s Product Owner. If the responsible Product Owner is unclear, post the ticket link and current state in #productowners. A Product Owner acknowledges it, identifies the customer’s responsible Product Owner, and helps route it to the correct owner.
For Pricing and Waiting for Customer Approval, an Account Manager claims the Change Request. If a Change Request in either state is unassigned or overdue, post the ticket link and current state in #account-management.
For all other states, use #productowners to resolve an unassigned or overdue Change Request. The Product Owner routes the request to the correct owner; Account Management supports commercial questions but does not take ownership of Product Owner or technical work.
Commercial Approval
Before asking the customer for approval, make the proposal understandable without internal context. It must state what VSHN will provide, the effort and constraints that affect delivery, and the applicable price or quote reference.
Customer approval is given through the Service Desk customer portal or in writing by email. If approval is received by email, Account Management records it in the Change Request and attaches the evidence. Verbal approval is not sufficient.
| Do not start implementation before the required approval is recorded. |
Record the customer contact, approval date, approved scope, and agreed prices in the Change Request. If the scope, price, or commercial basis changes after the proposal is sent, return the Change Request to Pricing and provide an updated proposal.
No Customer Response
Waiting for Customer Approval has a target time of 10 days. If the customer has not responded, Account Management sends a reminder before expiring the Change Request. Record the Expired resolution and inform the customer in the ticket.
Implementation and Closure
Implement only the approved scope. If implementation reveals a material change to scope, effort, price, security posture, or delivery constraints, return the Change Request to Analysis or Pricing as appropriate.
Closure Gates
| Close a Change Request only after every applicable closure gate is passed. Closure is never automated because the billing check needs a person. |
Solution documentation and the knowledge base are updated.
Monitoring, backup, and alerting cover the change.
Any recurring price is active in Odoo with the correct start date.
Any one-time work is invoiced or attached to the correct sales order.
The customer has been informed in the ticket.
Security and data locality relevance have been checked.
Follow the Customer Communication Guidelines throughout the Change Request.
Pending Decisions
The following points are not yet decided. Until they are resolved, raise questions with the Product Owner before progressing the Change Request.
State target times: Confirm the target time for each state and when escalation to
#productownersor#account-managementbegins.New Solution handoff: Define how to select the appropriate existing Customer Project when it is not apparent.