Big data real-time computing performance tuning service

1. Project background, goals and scope, and service price

1.1. Project background

Value proposition:

• Market trends indicate a growing importance of real-time computing scenarios. For example, Beijing Electric Power Company is building a real-time data mid-end, various provincial branches of the State Grid are using real-time collection solutions, and the finance industry is building real-time risk control systems.

• Customers have an urgent need for real-time computing performance tuning. For instance, the State Grid's data collection involves large data volumes, strict timeliness requirements, and complex business logic. They need to build a real-time data warehouse but lack implementation experience. They require service personnel to help build real-time tasks and improve their real-time data warehouse.

• This service helps customers implement stable and accurate real-time solutions tailored to their business scenarios. It assists with maintaining real-time tasks to ensure they run stably and accurately, thereby achieving high availability and robustness for real-time computing.

Customer pain points:

• Code is not robust and lacks exception validation and fault tolerance.

• You encounter an abnormal crash and are unsure how to locate, troubleshoot, or fix it.

• Customers do not know how to perform tuning when backpressure occurs.

• Difficulty assessing the accuracy of code results.

• Inability to guarantee job stability, leading to frequent failures, restarts, or backpressure issues.

Service positioning:

The real-time computing performance tuning service helps customers implement stable and robust real-time solutions. Based on specific business scenarios, this service is designed to tune jobs that experience exceptions or backpressure. It includes the development and implementation of tuning plans to help enterprises achieve business goals in scenarios such as real-time monitoring, real-time recommendations, and real-time anti-fraud.

1.2. Project goals and scope

The project goals include the following:

1. Researching business requirements and the data link architecture

This involves researching the real-time data link architecture based on the customer's business scenarios, including the data source format and data architecture. A preliminary assessment of the tuning feasibility and direction will be performed.

2. Job Tuning

This includes optimizing the SQL code for robustness and adding fault tolerance mechanisms. The job will be tuned based on backpressure observed during operation. This process involves tuning upstream and downstream parameters, SQL code, job parameters, and resource parameters until the job runs stably and robustly.

3. Accuracy and Stability Validation

This involves verifying that the results meet expectations and that the job runs stably.

Based on these goals, the delivery scope of this project is as follows. For detailed delivery content, see Section 2, "Project Plan, Implementation Method, and Content":

• The delivery scope for real-time computing performance tuning includes:

  • Tuning for Flink SQL/Table API.

  • Real-time job tuning for a single task with a single source table.

  • Job tuning.

  • Result validation.

• Preliminary research will be conducted with the [XXX], [XXX], and [XXX] departments of [Customer Name] Group, all located in [XX Location].

• Data scope: Task metrics identified during requirements research.

• Business system integration scope: Integration with [Customer Name]'s [XXX] system, involving a total of [XXX] interfaces. For a detailed list, see Appendix II, "List of Third-Party Business Systems for Integration".

• O&M support: Technical O&M support will be provided based on the [XXX] project technical service provided by Party B. For details on support content and methods, see Section 2.6, "O&M Support".

[Note: If the project includes both products and technical services, describe O&M support in two parts as shown. The specific O&M support service content is detailed in a later chapter. If the project does not include an O&M component, you can delete the "O&M support" section.]

1.3. Project service content, price, and service definition

Based on the project delivery scope, this Statement of Work (SOW) describes the [Real-time Computing Performance Tuning Service] provided by Alibaba Cloud (or an Alibaba Cloud partner) to Party A for a total of CNY [XXX] ([XXX] Yuan).

The price includes:

• [XXX] project technical service. For details, see Appendix V, "Project Technical Service Quotation". For specific work content and timelines, see Section 2, "Project Plan, Implementation Method, and Content".

[Note: If the project includes both products and technical services, the price items should be quoted separately as shown. If the project has no product component, the product-related descriptions should be deleted.]

The project price is based on the agreed project scope. Any work or solutions not defined in this Statement of Work (SOW) are outside the project's delivery scope. The project plan, implementation time, and workload assessment are based on the scope agreed upon in this SOW. If the project scope is adjusted, both parties must follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form," to assess the impact on the project price, plan, and workload. The change can be implemented only after the "Project Change Control Request Form" is signed.

2. Project plan, implementation method, and content

Based on the project goals, scope, and implementation method, this project is divided into four phases, totaling 13 days. The work content and timeline for each phase are detailed in the project plan below.

*T represents the contract signing date. D represents a day.

Detailed work content for each phase is described below.

2.1. Project preparation

Before the project officially begins, Party A and Party B must agree on the project management and risk management mechanisms outlined below. A project kickoff meeting will be held to ensure both parties are prepared for the project execution phase.

• The project managers from both parties will review the SOW and the responsibilities of each party.

• Both parties will review the project tasks, key milestones, timeline, and resources, making changes or additions as necessary.

• Both parties will review the project delivery and payment plan, standard invoice format, and billing procedures.

• Both parties will establish project communication, reporting, issue, risk, escalation, and decision-making mechanisms.

• Both parties will confirm the submission method, acceptance criteria, and acceptance process for all deliverables.

• Both parties will confirm the project assumptions, change management procedures, and criteria for project change requests.

• Party B will develop detailed tasks, assignments, milestones, and estimates to execute the project plan in this SOW.

• Party B will coordinate and manage all technical aspects of the project personnel.

• Party A will prepare the required office environment.

Deliverables: See Section 4.1, "Acceptance Checklist".

2.2. Preliminary research

Based on the [XXX] business department's structure, surveys and interviews will be used to gain a comprehensive understanding of the data and application scenarios for this project. This includes:

• Business requirements research: This involves understanding the user's real-time scenarios, including required features, performance metrics, data links, processing logic, data source types, dimension table types, sink table types, data source volume, and Data Quality.

Based on the detailed requirements research, an overall architecture solution for the [XXX] project will be designed by combining real-time computing theory and tuning best practices.

• Link architecture diagram review: Review the end-to-end architecture diagram, from source to sink, based on the data source format, source/dimension/sink tables, and computing logic.

• Tuning direction and feasibility assessment: Assess the tuning direction and feasibility based on the business requirements research and the link architecture diagram.

Deliverables: No deliverables are produced in this phase.

2.3. Job tuning

This phase involves checking the code snippets of the customer's abnormal jobs. Issues such as incorrect fields, timeout filters, and data latency will be diagnosed and identified. The code will be tuned and its fault tolerance mechanisms improved to enhance robustness.

The job will be tuned based on backpressure observed during operation until it runs stably and robustly. This process involves:

• DDL tuning: Check the Data Definition Language (DDL) table creation statements in the abnormal job's code. Job performance will be optimized by adding batch parameters and using other methods.

• Job code tuning: This focuses on scenarios such as deduplication, groupby windows, and aggregations to identify problems like hot spot skew and out-of-order data. The job code will be checked and job performance will be optimized by separating hot spot data and using other techniques to enhance code robustness.

• CU resource parameter tuning: This involves researching the data volume of dimension tables and the memory resources used. Abnormal tasks will be rescheduled and Compute Unit (CU) resources will be optimized by adjusting and splitting operators, increasing memory, and manually configuring resources.

Deliverables: No deliverables are produced in this phase.

2.4. Result validation

In this phase, the accuracy and stability of the job will be validated.

2.4.1. Accuracy validation

Based on user data, the accuracy and consistency of the stream computing results will be verified. This includes:

• Specific case accuracy assessment: Randomly select N job result records, associate them with the source data, and manually check the accuracy of the results against the computing logic.

• Overall data accuracy assessment: A control group will be established and the differences will be compared to analyze the accuracy and reasonableness of the data.

2.4.2. Stability validation

The job must run stably for more than three consecutive days.

• Normal Overview curve: The curve should show no failovers, no data backlog latency, and a normal Transactions Per Second (TPS) rate for data input and output.

• Stable Queue curve: The curve should show no prolonged periods where the input queue or output queue is at 100%.

• Stable JVM curve: The heap memory usage is consistent.

2.5. Trial run and acceptance

• Go-live trial run: Party B will switch to the production environment for operation according to the system go-live plan, ensuring correct and stable operation for four days. Remote technical support will be provided during the trial run.

• Project acceptance: Deliverables will be prepared for project acceptance according to the contract.

Deliverables: See Section 4.1, "Acceptance Checklist".

2.6. O&M support

2.6.1. Technical service O&M support

After the trial run phase is completed and accepted, Party B will provide one month of technical support and O&M for the [XXX] project. This support covers issues such as data exception troubleshooting and daily data O&M, and serves as the software quality assurance period.

Party B will provide flexible and diverse communication methods to ensure that Party A's personnel can promptly contact Party B's engineers.

a) IM group (DingTalk) support: 5x8 technical support is provided.

b) Phone support: 5x8 after-sales phone consultation and technical support are provided.

c) Service content includes data exception troubleshooting, daily data O&M, remote technical Q&A, and technical support. Party A is required to provide a VPN environment for remote support.

3. Organization chart and responsibilities of both parties

3.1. Organization chart

This project will be implemented according to the following organization chart. The responsibilities and division of labor for each organizational unit are detailed below.

[Note: The overall organization chart for the project team (including both Party A and Party B) should be listed, and the responsibilities and work content of each unit should be described.] (The following organization chart and responsibility descriptions are for reference and can be modified as needed.)

3.2. Responsibilities of both parties in each phase

To ensure the project progresses smoothly, both parties will undertake different roles in each phase, based on the phased tasks of the project plan.

4. Acceptance

4.1. Acceptance checklist

[Note: Based on the key activities in each phase of Section 2, "Project Plan, Implementation Method, and Content," the table below lists all completion signs or deliverables for each activity and specifies the deliverable type. Different types of deliverables have different acceptance criteria, as described in Section 4.2, "Acceptance Criteria." The payment plan is based on the acceptance and payment for the project phases and corresponding deliverables in the table below.] (The following description is for reference.)

According to the overall project plan, the acceptance deliverables for each phase are as follows:

• The deliverables in the list above must be accepted according to the agreements in Section 4.2, "Acceptance Criteria," and Section 4.3, "Acceptance Process," for the corresponding deliverable type. A designated representative from Party A must sign to confirm acceptance.

4.2. Acceptance criteria

[Note: The following acceptance criteria should be edited based on the specific project deliverables. For example, if there are no metric-type deliverables, delete Section 4.2.4.]

4.2.1. Document-type acceptance

• The acceptance of document-type deliverables will focus on the substantive content of the document to confirm that the content submitted by Party B meets Party A's requirements.

• If Party A's business processes require internal reviews before Party B submits deliverables, Party A must complete its internal reviews and reports before the agreed-upon acceptance time.

• If the document content requires modification after a review meeting, Party B will modify it and resubmit it to Party A for acceptance. A designated representative from Party A will sign to confirm receipt.

4.2.3. Customized functional module acceptance

This section defines the acceptance criteria for jobs.

• Stability acceptance criteria: The job must run stably for one week with no backpressure, errors, or business delays, provided there is no abnormal growth in the source table data volume and no product bugs.

• Accuracy acceptance criteria: While meeting the stability criteria, the job's results must be accurate and conform to the business logic.

• After the job passes stability and accuracy acceptance and all functions are normal after going live, Party B will request acceptance from Party A. A designated representative from Party A will sign to confirm receipt. Upon acceptance, Party A will stamp or sign the "Acceptance Report" (see Appendix II).

4.3. Acceptance process

• After Party B submits a deliverable, Party A has five working days to verify whether it meets the requirements. If it does, Party A's designated representative must notify Party B of the acceptance according to the method agreed upon in Section 4.2, "Acceptance Criteria." This marks the completion of the deliverable acceptance. If Party A does not reply within five working days, the deliverable is considered reviewed and accepted.

• If Party A's representative notifies Party B in writing of any non-conformities within the five-day period, Party B must provide feedback within 10 working days. This feedback must explain the proposed solution and modification timeline, and both parties must agree on the solution and timeline. If the non-conformities can be corrected without affecting the project schedule, Party B must resubmit the modified deliverable as agreed. Party A then has five working days to verify the resubmitted deliverable and provide written confirmation of acceptance. If Party A again states in writing that the deliverable has non-conformities, both parties will discuss how to resolve the issues within three working days of Party B receiving the notice.

• If Party B does not receive a written notice of non-conformities from Party A within five working days of submitting a deliverable, the deliverable is considered reviewed and accepted.

• Party A agrees to carefully review all work results and deliverables submitted by Party B for acceptance and will be responsible for the subsequent production implementation. If a deliverable is used by Party A in production or for business-related activities, it is considered accepted.

• Once a deliverable is accepted or deemed accepted, the services provided by Party B under this SOW are considered inspected and accepted, and Party B's obligations under this SOW are considered fulfilled.

5. Project assumptions

5.1. General assumptions

In addition to other obligations in this agreement, Party B's performance of services at the agreed price depends on the following assumptions. If any assumption is not met, it may cause changes to the project schedule, service fees, expenses, deliverables, or the scope of work. Any such changes require a separate written agreement signed and stamped by both parties. The project change process will follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form." If one party changes an assumption without the other's approval, preventing the other party from fulfilling its obligations, the other party will not be held responsible.

• Party A will promptly provide Party B with all necessary and reasonable documents, information, data, charts, and system permissions to enable Party B to provide the services. All such materials will be subject to the confidentiality clauses under this agreement. Party A agrees that all information disclosed or to be disclosed to Party B is true, accurate, and not misleading.

• Party A must promptly provide necessary office and meeting conditions before the project starts, including meeting rooms, desks, chairs, restrooms, daily consumables, computer facilities, telephone/fax communication, high-speed Internet connection, power strips, and network cables.

• Party B's project work delivery location should be in the area where Party A's key business users, subject matter experts, and technical personnel are located. Party A must provide all necessary security certificates and procedures for the location before the project starts. The office environment provided by Party A must ensure the personal and property safety of Party B's staff and must be free of harmful polluting gases, liquids, and solids. Outdoor environments must provide protection against severe weather conditions.

• Party B will perform work in a centralized manner at a mutually agreed workplace. However, Party B has the right to adjust the work location and method based on the distribution of Party B's project personnel and reach an agreement with Party A.

• Party B will provide the delivery services for this project during normal business hours, which are from 9:00 AM to 6:00 PM UTC+8, Monday to Friday (excluding national legal holidays). However, if Party B's personnel have special arrangements, Party A agrees to provide Party B's personnel with access to Party A's facilities to work outside of normal business hours to accommodate possible travel schedules.

• Due to some special circumstances, Party B's project personnel may need to attend regional or national employee meetings. Party B's personnel will make appropriate arrangements based on project progress to minimize conflicts between the project and meeting schedules and will reach an agreement with Party A's project manager after consultation.

• During the project implementation period, both parties will use mutually agreed communication methods. The project managers of both parties will be responsible for transmitting the written information required for this project. Optional communication methods include DingTalk, the Internet, FAX, and email.

• All project deliverables will be in Simplified Chinese, and the working language will be Chinese. All delivered works will be in Microsoft Office format (such as PPT, WORD, Excel, and Visio) and submitted as electronic copies.

• Party A and Party B must commit to the project work according to the mutually agreed work plan, personnel resource plan, and written start and end dates. If the go-live of Party A's related business systems is delayed, the corresponding project schedule will be postponed, and Party B will not be held responsible.

• Party A must provide sufficient and qualified personnel to join the project team and perform their duties as agreed in the SOW and during the project execution. If any of Party A's personnel cannot perform their duties as required, Party A must provide a suitable replacement. If the project requires the involvement of other related personnel, Party A must provide necessary support to ensure that personnel from relevant business departments participate in interviews, workshops, and meetings according to the project schedule. If the project progress is affected by personnel changes or unqualified personnel from Party A during the project execution, both parties should communicate promptly and confirm in writing. Party B will not be held responsible for this.

• Project management procedures, such as project plan confirmation, change control, and escalation handling, need to be established and documented during the project preparation phase. Party A's team should understand and approve these project management procedures.

• If a third party needs to be introduced, Party A and Party B will be responsible for signing contracts with their respective third parties. Party B is not responsible for the actions of Party A's other subcontractors or vendors (except for Party B's subcontractors), nor for any delays caused by them. Party A is not responsible for the actions of Party B's other subcontractors or vendors (except for Party A's subcontractors), nor for any delays caused by them.

• Both parties are responsible for obtaining the necessary licenses for third-party products required for contract performance, at no cost to the other party.

• If Party B needs to obtain any third-party proprietary information in a non-confidential form during the project implementation, Party A must assist Party B in obtaining approval when necessary.

• If third-party systems, vendor resources, and personnel are involved in the project implementation, Party A is responsible for coordination, including but not limited to the coordination of third-party materials and human resources. The responsibility for third-party systems lies with the third party. If the project is delayed due to third-party reasons, and the project cost increases, both parties must follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form," to assess the impact on the plan and workload, and implement the change after signing the change request.

• For the Data Quality of the raw data on which this project depends, Party A is obligated to ensure that the Data Quality in the designated integrated systems meets the standards. For data that does not meet the quality standards, Party A should improve it to meet the standards through operational or system specifications. Party B is not responsible for any impact on the deliverables caused by the raw data's quality not meeting the standards.

• During the project execution, if the reconstruction and modification of Party A's original business systems are involved due to the import of Party B's products, both Party A and Party B need to adjust the construction progress of Party B's product functional modules according to the actual business system planning and modification. If Party A adjusts the data design and business processes of related systems for its own reasons, the additional workload for Party B will require an additional fee. Both parties must follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form," to assess the impact on the plan and workload, and implement the change after signing the change request.

• Any work or solutions not defined in this SOW are outside the scope of this project. The project plan and workload assessment are based on the scope agreed in this SOW. If the project scope is adjusted, both parties must follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form," to assess the impact on the plan and workload, and implement the change after signing the change request.

• During the project execution, if some tasks cannot be completed within the planned project phase because Party A fails to properly manage the input/output deliverables that this project depends on, or delays decisions, or if Party A decides not to implement part of the scope within the planned project phase for reasons not attributable to Party B, Party B will not be held responsible for these uncompleted tasks. In this case, after Party B completes the controllable part of the work according to the SOW, these uncompleted tasks should not affect the timely acceptance of Party B's work.

• During the project execution, both parties must perform their respective duties as agreed in the SOW. If Party B discovers unfavorable factors affecting the plan's execution, Party B will promptly notify Party A. Party A must provide feedback within three days of the notification and agree on a risk control method for the unfavorable factors. If Party A fails to provide timely feedback and delays or quality issues occur during the project due to reasons not attributable to Party B, Party B will be exempt from liability. For any additional workload caused to Party B, both parties will follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• Party A must conduct acceptance on time according to the acceptance process and standards agreed in the SOW. If the review and acceptance cannot be passed due to reasons outside Party B's scope of responsibility, leading to project delays, both parties will follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form", and Party B will not be held responsible.

• At any stage of the project, if the customer requests a change to the content of an already accepted deliverable, it will be considered a change request. Both parties will follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• Neither party shall be liable for any special, incidental, or indirect damages or consequential economic damages (including loss of profits or savings) under this contract, even if that party has been advised of the possibility of such damages.

• Party B reserves the right to subcontract all or part of the services under this contract to its partners, but Party B shall still be liable to Party A as agreed in this contract.

5.2. Business assumptions

• If this project requires integration with non-Alibaba Cloud products within the Alibaba Group ecosystem (such as AutoNavi or Alipay) that are outside the contract scope, Party B is responsible for internal coordination. However, the final outcome depends on the product strategies of these other entities, and Party B is not responsible for the result. Any new requirements and costs will be negotiated between Party A and the relevant Alibaba ecosystem entity.

• In the preliminary research phase, the current status information that Party B needs for research and assessment depends entirely on Party A. Party A must provide the information promptly and ensure its accuracy. If Party A cannot provide the required information, or if the information is inaccurate, causing Party B's research and assessment results to deviate from the actual situation and thus affecting the original project delivery plan, time, and scope, Party B will not be responsible for the delivery delay. Any additional workload caused to Party B will be handled according to the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• In the preliminary research phase, if the actual research results show that the Data Quality and product application customization development needs differ greatly from the original project implementation scope, and Party B assesses that it cannot be implemented within the original scope, time, and cost, both parties should reach an agreement on the implementation method for subsequent project phases through friendly negotiation. This will be handled according to the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• In the preliminary research phase, if Party A exceeds the scope of the list of business systems for integration output by Party B, it will be considered a change request. Both parties will follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• In the preliminary research phase, Data Quality issues related to real-time computing scenarios need to be corrected through the joint cooperation of both Party A and Party B. If delays are not caused by Party B, Party B will be exempt from liability. Any additional workload caused to Party B will be handled according to the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• In the job tuning phase, issues with the upstream or downstream links of the real-time computing data source need to be investigated and corrected through the joint cooperation of both Party A and Party B. If delays are not caused by Party B, Party B will be exempt from liability. Any additional workload caused to Party B will be handled according to the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• In the job tuning phase, for the `WITH` parameters of real-time computing, Party B has the right to require Party A's cooperation in making modifications. If delays are not caused by Party B, Party B will be exempt from liability. Any additional workload caused to Party B will be handled according to the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• In the job tuning phase, adjustments to the job parameters of real-time computing need to be completed through the joint cooperation of both Party A and Party B. If delays are not caused by Party B, Party B will be exempt from liability. Any additional workload caused to Party B will be handled according to the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• In the result validation phase, for troubleshooting accuracy and stability issues, Party A needs to cooperate in verifying the reasonableness of Party B's troubleshooting and validation logic. If delays are not caused by Party B, Party B will be exempt from liability. Any additional workload caused to Party B will be handled according to the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• In the job go-live trial run phase, once Party B's system is online and enters the trial run phase, subsequent secondary debugging caused by changes in Party A's environment is considered work outside the scope of the agreement. If Party A requests support from Party B for this reason, it will be considered a change request. Both parties will follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form".

• The product quality assurance and technical service support phase begins after Party A has completed the acceptance of all deliverables and signed the "Acceptance Report" (see Appendix X). If the project cannot enter the product quality assurance and technical service support phase due to reasons not attributable to Party B, both parties will follow the procedure specified in Appendix I, "Project Change Process and Project Change Control Request Form", and Party B will not be held responsible.

• In the product quality assurance and technical service support phase, Party A agrees and understands that the subscription service for public cloud products is a continuous charging model. To cancel the service during the subscription period, both parties must negotiate and sign an agreement on the method for stopping the subscription service support. If Party A does not negotiate with Party B, or if Party A stops paying the subscription fee on its own, Party B reserves the right to handle Party A's products and data, and Party B will not be held responsible for Party A's operations, products, or data.

• In the product quality assurance and technical service support phase, Party B supports preliminary problem investigation and fixes issues related to the delivered products and applications, such as data anomalies and system functions. If after investigation, the problem is determined to be a system failure caused by third-party systems, data, or improper operation of third-party or associated systems, or technical support required due to third-party software issues, Party B is not responsible for fixing such problems and will not be held liable for such failures.

• In the product quality assurance and technical service support phase, if technical support services outside the scope of this contract are involved, requiring Party B to dispatch technical support engineers, R&D engineers, or technical experts to the site for technical services, Party A must pay Party B the corresponding technical service fees. The charging standard will be decided by both parties through negotiation based on the project situation. However, this excludes on-site travel that is necessary due to problems arising from the deployment and operation of Party B's products.

Appendix I Project Change Process and Project Change Control Request Form

Any changes to this SOW by either party must follow the project change process to take effect:

• Changes to work tasks or personnel must be submitted five working days in advance using the "Project Change Control Request Form" (see next page) for both parties to assess feasibility. If the assessment result is not feasible, this project change process will not occur, and both parties should reach an agreement on the subsequent handling method through friendly negotiation.

• The change content must be filled out completely. This includes basic information, reason for change, and a specific description of the change.

• If the project price increases or decreases, the relevant price changes must be explained, and the corresponding supplementary agreement or purchase order must be attached.

• All changes will take effect after being approved and confirmed by the designated project managers or project leaders of both parties. Changes involving the price will take effect after both parties sign a supplementary agreement or purchase order.

  Project Change Control Request Form

  Project name:		Draft date:
  Project number:		Change order number:
  Drafter/Role:

  Project change content

  Reason for change

  Description of change

  Scope of impact

  Technical impact and risk assessment

  Cost impact

  Approval

  Party A Business Owner:

  Name:
  Role:
  Date:
  Signature:

  Party B Business Owner:

  Name:
  Role:
  Date:
  Signature:

  Attachment

  [Attach contract or PO]

Appendix II List of Third-Party Business Systems for Integration

Appendix III Requirements Survey Form

Appendix IV Stability Metrics Checklist

Appendix V Project Technical Service Quotation

This quotation details the total price for the [XXX] project technical services provided by Party B, which is CNY [XXX] ([XXX] Yuan).

[Note: It is recommended to quote by "deliverable" (see Section 4.1, "Acceptance Checklist") for the quotation items (service names). This helps with early acceptance and payment collection by project phase, and with revenue recognition.]