A集团能力中心（Capability Centre）内部资料概览

 1|Service Level Agreement (SLA)
 2|Between China Capability Centre and Mainland China, Hong Kong and Macau Entities
 3|Effective Date: The first of October 2025.
 4|Version: Draft 2
 5|Introduction
 6|This Service Level Agreement (“SLA”) is entered into between the China Capability Centre (“CCC”) and the Mainland China, Hong Kong, and Macau (“MCHKM”) Entities to establish the scope, delivery standards, and responsibilities pertaining to the provision of centralized business support services. This SLA is a subsidiary agreement to the Master Professional Services Agreement (“PSA”) dated July 17, 2023, among API Group, Inc. and its Affiliates, which governs all recharges between group entities. This SLA incorporates by reference all terms of the PSA and constitutes a separate contract between the Receiving Party and the Providing Party regarding the Services outlined herein. Accordingly, this SLA serves as a foundational framework for inter-entity recharges within the MCHKM region.
 7|The Service Recipient and the Service Provider are referred to as “Party” individually and collectively as the “Parties.”
 8|A) All defined terms in this SLA have the same meaning as in the PSA unless stated otherwise.
 9|B) References to Services below pertain exclusively to those specified herein, not under other SOWs between the Parties.
10|C) Terms in the PSA shall prevail over conflicting terms in this SLA, unless explicitly agreed otherwise.
11|Scope of Services
12|The CCC undertakes to provide the following services to the MCHKM Entities:
13|General administrative and operational support services
14|Finance Function:
15|Responsible for managing accounts payable and receivable, staff reimbursement, fixed asset management, accounts reconciliation, and compliance with all relevant statutory requirements.
16|Operations Function:
17|Deliver efficient and standardized execution of core business processes, ensuring timely and high-quality service delivery. Continuously optimize operational workflows to improve accuracy and cost-effectiveness, while maintaining regulatory compliance and seamless service continuity.
18|Technical support services
19|Technical Support includes all specialized assistance required to maintain and operate the Service, which directly impacts revenue. Support will be provided by qualified personnel such as engineers, draftspersons, and product development specialists. This support covers resolving technical issues, reviewing and updating designs or specifications, and ensuring the Service performs as intended.
20|Product sourcing services
21|Source Function:
22|Centralize sourcing and supplier management to maximize cost savings through strategic purchasing and volume leverage. Provide transparent procurement support, contract administration, and supplier relationship oversight to secure quality goods and services aligned with organizational objectives. Man

 1|Offshore Competency Centre Creation Framework
 2|Phased guidance for planning, transferring, stabilising, and improving offshore finance capability centres
 3|This document is designed to help teams plan the move, select the right scope, prepare the operating model, execute knowledge transfer, and build a sustainable future-state service. Input to this document was provided by country CFO’s, Finance Process Owners and team members from the international finance team alongside documented lessons from pilot transfers in the UKI, CCC and GCC.
 4|1. Core design principles
 5|Start with the end state: define what the centre will do, what remains onshore, and how the service will be owned.
 6|Move the right work first: prioritise transactional, repeatable, well-defined processes.
 7|Standardise before you migrate: reduce local variation and define exception paths.
 8|Stabilise before you optimise: do not redesign heavily during the initial transfer period.
 9|Measure both quality and delivery: performance discussions should be fact-based.
10|Treat offshore as one team: relationship quality materially affects outcomes.
11|Make ownership explicit: unclear RACI and handoffs are a major failure point.
12|Plan for people impact beyond the directly affected team: adjacent functions will feel the change too.
13|Design for sustainability: talent, development, and leadership matter as much as cost.
14|Build for improvement: use progressive SLAs, scorecards, and feedback loops after go-live.
15|2. Stage overview
16|Stage
17|Focus
18|Gate question
19|Stage 1
20|Strategy, Case for Change and Sponsorship
21|Do we have an approved case for change, funding, sponsors, and a named accountable owner?
22|Stage 2
23|Process Selection and Wave Planning
24|Have we selected the right first-wave processes and documented what should be retained, deferred, or hybridised?
25|Stage 3
26|Current-State Assessment and Baseline
27|Do we understand the as-is process, baseline performance, dependencies, and key risks well enough to transfer safely?
28|Stage 4
29|Target Operating Model and Detailed Design
30|Is the future operating model designed, agreed, and measurable?
31|Stage 5
32|Readiness, Enablement and Transition Planning
33|Are all core enablers ready for training and transition?
34|Stage 6
35|Training, Knowledge Transfer and Handover
36|Has the offshore team demonstrated proficiency and formally taken ownership?
37|Stage 7
38|Go-Live, Hypercare and Stabilisation
39|Is service stable, controlled, and owned by the new team without excessive dependency on the old one?
40|Stage 8
41|Continuous Improvement and Future-State Maturity
42|Do we have an active improvement engine and a credible path to a more mature, flexible capability model?
43|3. Detailed framework by stage
44|Stage 1: Strategy, Case for Change and Sponsorship
45|Purpose: Establish why the centre is being created, what success looks like, and who will sponsor and govern the change.
46|Gate question: Do we have an approved case for change, funding, sponsors, and a named accountable owner?
47|Key steps
48|Define the business rationale and target outcomes such as capacity, quality, resilience, standardisation, efficiency, and scalability.
49|Understand the high level resource requirement to support the business case (number of heads moving)
50|Set the future-state vision for what the offshore centre will own, what will remain onshore, and how both teams will work together.
51|Agree the scope boundaries at a high level and confirm whether the move is finance-only or part of a wider shared-services model.
52|Build the business case, budget, and implementation funding.
53|Appoint executive sponsors, an onshore accountable owner, workstream leads, and decision forums.
54|Set clear success measures, milestones, and tolerances for risk, service disruption, and control impact.
55|Elements to consider at this stage
56|Lens
57|Key considerations
58|Process
59|- Define the outcomes the centre is expected to deliver.- Identify candidate processes at a high level and group them into likely waves.- Clarify whether the objective is lift-and-shift, improve-and-shift, or a blend.
60|People & Organisation
61|- Identify directly and indirectly impacted teams, not only the people whose roles may move.- Clarify who will lead the retained onshore team and how roles may change.- Plan for reskilling and future roles where possible rather than treating the programme only as a cost action.
62|Technology & Data
63|- Complete an early view of system feasibility, access constraints, and major technology dependencies.- Check whether ERP, billing, ticketing, reporting, and collaboration tools can support remote execution.
64|Risk, Control & Compliance
65|- Assess labour law, redundancy, SOX/control, audit, data handling, and local language constraints early.- Identify any activities that are too sensitive, judgement-based, or locally embedded for early migration.
66|Governance
67|- Establish steering committee, programme governance, escalation paths, and decision rights.- Define a named onshore owner for relationship management and end-to-end accountability.
68|Key deliverables
69|Approved business case and budget
70|Future-state vision statement
71|Initial scope and wave hypothesis
72|Programme governance and sponsor structure
73|Headline success measures
74|Exit criteria
75|Executive sponsorship is confirmed.
76|The case for change, target outcomes, and funding are approved.
77|There is a named owner for the retained service and the transition programme.
78|Common pitfalls
79|Starting without a business case or budget approval.
80|Treating the move purely as a headcount exercise.
81|Failing to define who owns the service end-to-end.
82|Stage 2: Process Selection and Wave Planning
83|Purpose: Choose the right work to move first and sequence migration in a way that protects service, controls, and stakeholder confidence.
84|Gate question: Have we selected the right first-wave processes and documented what should be retained, deferred, or hybridised?
85|Key steps
86|Assess each process against suitability criteria such as volume, repeatability, complexity, criticality, judgement, control sensitivity, and maturity.
87|Prioritise standard, transactional, repeatable work for the first wave.
88|Avoid or defer customer-facing, judgement-heavy, control-sensitive, or highly local activities until the model is proven.
89|Confirm upstream and downstream dependencies and how adjacent teams will be affected.
90|Create a phased migration roadmap rather than attempting a full transfer at once.
91|Elements to consider at this stage
92|Lens
93|Key considerations
94|Process
95|- Score each process for volume, repeatability, complexity, maturity, automation opportunity, and exception level.- Confirm defined inputs, outputs, and clear process steps; if work relies on interpretation, treat it as higher risk.- Use onshore process leads in selection decisions.
96|People & Organisation
97|- Assess business-facing touchpoints, customer sensitivity, and language dependence.- Consider talent availability in the offshore location for each process family.
98|Technology & Data
99|- Check whether process execution depends on local systems, poor workflow support, or weak data quality.- Assess whether automation or AI could improve suitability before migration.