TI Change Management Notes (Comprehensive Overview)

Overview

  • Session goal: provide a comprehensive, high-level walkthrough of the change management process and supporting artifacts due to pending security clearance. Covers configuration workbook items, change request flow, BRD, CHARM (Solution Manager), I Service, SIT/UAT templates, CAB, deployment, and governance aspects.

  • Context notes: security clearances for participants (Ibrahim, Sambhav, Manas, etc.) are delayed; session focuses on process understanding and documentation practices that will be used once access is granted.

  • Emphasis on documentation, traceability, and governance; templates and registers are hosted on SharePoint and linked to financials.

Change Request Flow (CR) and Service Tickets

  • Ticket types and routing

    • End users submit tickets in I Service (either SR or Incident).

    • A CR may be created from an SR/Incident (conversion path).

    • Current status naming in I Service: typically, awaiting change is used (not awaiting approval).

  • Transition from tickets to CR

    • When a ticket is converted to CR, mark it as awaiting change in I Service.

    • There is a manual process that follows: requirement discussion, BRD creation, and BRD submission/signature by business users (for CRs).

  • BRD and requirement gathering

    • BRD templates are used for requirement capture and sign-off with business users.

    • BRD submission triggers the effort estimation process and routing to the DT lead.

  • Documentation and PMO role

    • PMO is responsible for maintaining a dedicated Excel tracker of efforts, linked to financials, and shared on SharePoint.

    • The tracker records efforts per CR (functional, technical, development, deployment) and keeps a monthly update cycle.

  • CHARM (Change Management) and CHARM number

    • Change management is handled through CHARM (SAP Solution Manager).

    • A CR number is assigned within CHARM (e.g., CHARM/CR flow with numeric identifiers such as 001, 002, etc.). The CHARM number ties back to the CR and I Service reference for traceability.

  • DT lead and approvals

    • DT Lead reviews/approves efforts and coordinates with business.

    • After DT Lead approval, development timelines are defined and sent to the business; UAT is scheduled.

  • Roles highlighted during flow

    • On-site SME Lead (DT Lead): approves efforts and serves as technical bridge.

    • Developer: implements changes.

    • Implementer (basis): Maheshwar (training planned for CHARM creation).

    • Change Manager: oversees governance and CAB proceedings.

  • Quick note on CR NSR (Change Request as Service Request)

    • If a small change is captured entirely within a Service Request (service configuration), BRD can be skipped; this is termed CR NSR.

  • Example references from the session

    • An example CR flow shows a CR with functional/technical/effort breakdown and approval path via DT Lead and DT Lead’s Excel tracker before sending to DT for development.

    • CR numbers start at 001 in the tracker; comparable real-world numbers (e.g., 700+) exist for other teams to illustrate sequencing.

BRD (Business Requirements Document) and Requirements

  • BRD purpose and process

    • BRD is used to capture business requirements, gather requirements from end users, and obtain signatures.

    • If CR is incident-driven (CR from incident), BRD is prepared and signed accordingly.

  • BRD content and fields (template elements)

    • Change Title

    • Change Requestor

    • Business Name (same as account/department)

    • Request Date

    • Drivers (participants involved in development; e.g., Rashid, Caesar, Haifa)

    • Description (functional and non-functional aspects)

    • Data to be shared (data sensitivity, privacy considerations)

    • Process changes (any changes to workflows or SOPs)

    • Test Scenarios (critical for UAT planning)

    • Appendix (any additional details/history)

    • Signatures (Business Owner, DT Lead, and others as applicable via DocuSign)

  • BRD version control

    • Versions are tracked (1.0, 1.1, etc.) and stored on SharePoint; each version is circulated for review and sign-off.

    • Templates are updated periodically (document versioning example: 1.0 → 1.1).

  • BRD templates and distribution

    • BRD is shared with business users (for incidents) or with business for CRs to obtain required sign-offs.

    • BRD information feeds into the effort planning Excel tracker and the CHARM workflow.

  • BRD’s role in governance

    • BRD content informs the functional/technical scope, acceptance criteria, and test scenarios to be used in SIT/UAT.

SIT/UAT Templates and Process

  • SIT (System Integration Testing) template

    • CR number field (e.g., 0001) and module selection (e.g., H2R for SuccessFactors-related items)

    • Description of the change and the I Service reference (the BRD/CR reference)

    • Creators and reviewers named on the template

    • Test scenarios and evidence (e.g., screen captures, payroll slips, etc.)

    • SIT document serves as evidence of integration-level testing and is attached to the CHARM record.

  • UAT (User Acceptance Testing) template

    • SIT/UAT templates are designed to be simple and generic for reuse across SOPs, user manuals, process policies, etc.

    • UAT document details expected functional outcomes and test results from end users (business) with sign-off evidence.

    • Business users perform UAT and provide feedback; any observations are captured and addressed in the subsequent cycle.

  • SIT/UAT flow and responsibilities

    • Development is performed after DT Lead approves efforts.

    • UAT is led by business users; SIT is conducted by testing teams with evidence for sign-off.

    • SIT/UAT documents are attached to CHARM; ensure all test evidence and sign-offs are included.

  • Documentation quality and presentation guidelines

    • Screenshots should be properly aligned (left alignment is shown in examples).

    • Documentation should be neat, with consistent headers and formatting.

    • The SIT/UAT templates are designed to be reusable for SOPs and user manuals.

CHARM, SAP Solution Manager, and Change Implementation

  • CHARM basics

    • CHARM is used to manage all changes, including the generation of change tickets, attachments (BRD, SIT/UAT), and approvals.

    • A CHARM number is generated by the CHARM tool and tied to the CR and I Service references.

  • Transport and implementation model

    • For SAP S/4HANA (HANA) changes, the deployment often involves creating a Transport and the corresponding CHARM for traceability.

    • The CHARM creation training will be delivered by Mahesh as a separate session.

  • CAB (Change Advisory Board)

    • CAB members include: on-site/offshore DT leads, functional leads, solution manager, and the Change Manager.

    • The CAB reviews changes, checks test evidence, ensures there is a representative to discuss the change, and approves or rejects deployment.

    • The CAB is a governance checkpoint before deployment; if there is no representation, deployment is not performed.

    • The CAB meeting occurs on Fridays; deployment windows typically occur on Friday afternoons; larger or longer deployments may spill over to Monday.

  • Post-deployment activities and firefighter concept

    • Post Deployment Activities (PDA) are tracked; sometimes a “firefighter” (emergency support) is required for urgent deployments.

    • A firefighter request is raised in CHARM and requires CAB approval for non-urgent deployment routes; urgent changes may be deployed with justification and discussed in a retro in the Friday CAB.

  • Roles and responsibilities tied to CHARM

    • Change Manager: oversees CHARM process and CAB governance.

    • DT Lead: approves functional/technical effort and coordinates with business.

    • On-site SME Lead: technical bridge and approval for efforts; sometimes authorizes development timelines.

    • Implementer/Basis (Mahesh): responsible for performing changes in the system.

    • UAT owner and business representatives: responsible for validating the change in UAT and acceptance testing.

  • Example discussions from the session

    • A CHARM example shows module selection, CR/OData linkage, UAT attachment, and the flow from DT Lead approval to HC (Haifa) final approvals before deployment.

Roles, Access, and Governance

  • Access, security, and credentials

    • Security clearance required before TI credentials and access provisioning can begin.

    • TI credentials include TI email, TI Teams, and TI VPN access for remote connectivity.

    • In the interim, a subset of members may proceed with limited access under supervision; full access is granted after clearance.

    • VPN is required for certain systems (e.g., HR/SFA-related systems); cloud services like SuccessFactors may be accessible without VPN but require online presence on Teams.

  • SharePoint structure and access control

    • PMO folder is restricted to PMO members (delivery managers, project managers, offshore/on-site leads).

    • Change Request (CR) folder is shared with all relevant members for access to CR documents, BRDs, SIT/UAT, and related artifacts.

    • A separate cadence/folder structure is used to host the CR documents, BRDs, SIT/UAT, and related historical changes for reference.

  • Incident management, access, and escalation

    • Incident management is linked to I Service; all changes and CR tracking relate back to I Service references.

    • Access provisioning and security roles are managed by the Basis team; KT (knowledge transfer) should specify the exact access required and the owner to replicate access.

  • Cadence and reporting access

    • Cadence reports (monthly performance reviews) are prepared by the team and shared with the management group via a dedicated mailbox; later, access will be granted to SharePoint for direct upload.

Deployment, Release Management, and Scheduling

  • Deployment flow and windows

    • Once approved by CAB, deployment is typically performed on Fridays in a defined window (between 2:30 PM and 5:30 PM); for complex or lengthy deployments, Monday deployment is possible.

    • Transport-based deployments are faster; manual deployments may require scheduling during non-peak times.

  • Firefighter and post-deployment activity flow

    • If urgent, a firefighter request may be used for post-deployment activities; the CAB must approve this path and the request is logged in CHARM.

    • Post deployment activities may include updating documentation, maintaining tables in systems (e.g., SM30), or creating new reports.

  • Evidence and documentation requirements for deployment

    • UAT evidence, SIT evidence, and BRD artifacts are attached to CHARM and referenced in the weekly/monthly review packets.

  • Cross-functional collaboration in deployment

    • HR and Finance integrations (e.g., payroll, travel & expenses) require collaboration across teams; time spent on cross-functional changes is claimed and approved as per the tracking framework.

Governance, Audits, and Quality Assurance

  • RCA (Root Cause Analysis)

    • RCA templates are used for high-impact incidents or recurring issues, and for P1 incidents where a formal root-cause approach is necessary.

    • RCA captures: problem description, impact, root cause, and corrective actions, along with evidence and affected modules.

  • Audit requirements and governance templates

    • Governance artifacts include BRD, SIT/UAT documents, SOPs, user manuals, and UAT results.

    • Approvals must be captured in CAB; communications must be recorded and distributed to stakeholders.

    • Change artifacts, test evidence, and deployment notes must be retained for traceability.

  • Documentation quality standards

    • Ensure proper formatting, version control, and alignment of screenshots and descriptions.

    • All templates (BRD, SIT/UAT, SOP) should reflect the same naming conventions and version history.

Metrics, Reporting, and KPIs

  • MPR (Monthly Performance Review) and cadence reporting

    • Cadence reports are prepared monthly with input from all team members and shared with management.

    • KPI tracking is in development: current session notes that KPI measurement will begin once KT is completed and access is granted.

  • SLA management and redefinition

    • There is a plan to redefine the SLA in I Service to reflect the scope of change management activities.

    • Example SLA baseline discussed: Critical – response within 30 minutes; resolution within 4 hours; High – response ~4 hours; resolution ~8 hours; Normal – resolution within 3 working days; Low – 5 working days.

    • Premium support engagements (e.g., Gavadi) previously had stricter SLAs (e.g., 3 hours) but are not applicable in the new scope; the SLA needs to be aligned with the contractual baseline.

  • Cross-team collaboration and reporting access

    • In the early phase, some reports are uploaded to a shared mailbox; later, access to SharePoint will enable direct upload by the team.

  • The broader governance objective

    • The governance framework aims to ensure all changes are properly documented, approved, tested, deployed, and audited with clear ownership and traceability.

Templates and Best Practices (Key Takeaways)

  • BRD template essentials

    • Change Title, Requestor, Business Name, Request Date, Drivers, Functional/Non-functional details, Data to be shared, Process changes, Test Scenarios, Appendix, Signatures.

  • SIT/UAT templates essentials

    • SIT: CR No, Module, Description, Creators/Reviewers, Test Scenarios, Evidence; UAT: Business-led validation with test scenarios and evidence; attach to CHARM.

  • UAT preparation and execution

    • Ensure required test scenarios are captured in BRD; align SIT/UAT with the business’s real-world usage.

    • During UAT, business signs off on successful outcomes and notes any observations.

  • Documentation quality guidelines

    • Use neat formatting, consistent headers, and proper alignment of screenshots.

    • Version control and shareable links on SharePoint to ensure stakeholders have access to the latest documents.

  • Practical “do and don’t” during transition

    • Do not leave work stagnant during the clearance period; stay active with ongoing KT, prepare drafts, and maintain template readiness.

    • Maintain a proactive stance by proposing improvements and capturing knowledge from the existing documentation and past changes.

  • Example scenario references from the session

    • LMS new course module upload in SuccessFactors (example SIT/UAT scenario).

    • Payroll-related changes, HR-driven changes, and cross-functional activities with Finance.

    • A BRD example includes drivers, test scenarios, and appendix content.

Practical Considerations and Next Steps

  • Training and kickoffs

    • CHARM creation training sessions will be organized by Mahesh; attendance is required for those handling changes in the system.

    • Training on I Service operations to be conducted after security clearance; plan separate KT sessions for HR/Finance integrations.

  • Access provisioning and onboarding plan

    • After security clearance, users will receive TI credentials and access to the CR folder on SharePoint; separate tickets may be required for access provisioning (3 separate tickets due to some vendor restrictions).

  • Ongoing communications and governance

    • A dedicated mailbox will be used for deployment communications; cadence reports will be generated monthly and shared with management.

    • Anticipate a transition period (about one month) to settle into the process; expect to answer questions and iterate on templates.

Quick Reference: Common Acronyms and Terms

  • I Service: Ticketing portal used for SRs, Incidents, and changing requests routing.

  • CR: Change Request; may be linked to CHARM in SAP Solution Manager.

  • SR: Service Request; a type of ticket often used for configuration changes or smaller requests.

  • SIT: System Integration Testing; validates integration points across components.

  • UAT: User Acceptance Testing; end-user validation of the change’s business impact.

  • BRD: Business Requirements Document; formal requirements and sign-offs.

  • CHARM: Change Management system in SAP Solution Manager; generates change tickets and tracks approvals.

  • DT Lead: Digital Transformation Lead; oversees technical/functional effort approvals.

  • PMO: Project Management Office; oversees governance and documentation.

  • CAB: Change Advisory Board; governance body for deployment approvals.

  • PDA: Post Deployment Activities; tasks that occur after deployment.

  • RCA: Root Cause Analysis; investigation of high-impact or recurring issues.

  • SOP: Standard Operating Procedure.

  • MPR: Monthly Performance Review.

  • KPI: Key Performance Indicator.

  • CRM/FS/FS: Functional/Technical/Development/Deployment effort categories used in the tracker.

{ ext{Total exttt{}Effort}} = ext{Functional exttt{}Effort} + ext{Technical exttt{}Effort} + ext{Development exttt{}Effort} + ext{Deployment exttt{_}Effort}

  • Example numeric references mentioned in the session:

    • CR numbers start at 001 (and can go to higher values like 700+ in other teams).

    • Example effort breakdowns: 110 hours, 95 hours (functional/technical/development/deployment components).

    • Deployment windows and timing: Friday deployments, with potential Monday fallback for long deployments.

Closing Notes

  • The presenter emphasized the importance of comprehensive documentation, version control, and governance through CAB and CHARM.

  • The team will receive targeted sessions on CHARM creation, I Service, and BRD/UAT templates to achieve a smooth transition once security clearances are in place.

  • The overarching goal is a well-governed, auditable change process with clear ownership, traceability, and collaborative cross-functional execution.