What are Contract Grades?

A service level agreement refers to an agreement or contract mutually agreed between the enterprise providing the service and the customer on the quality, standard and performance of the service.

A service level agreement refers to an agreement or contract mutually agreed between the enterprise providing the service and the customer on the quality, standard and performance of the service.

Chinese name

Service level agreement

Foreign name

Service Level Agreement, SLA

Object

Between the service provider and the customer

Involve

Service quality, level, performance

Attributes

A mutually agreed agreement or contract

What is a service level agreement

A service level agreement refers to an agreement or contract mutually agreed between the enterprise providing the service and the customer on the quality, standard and performance of the service.

Contents of a typical service level agreement

A typical service level agreement includes the following:

The provisions of the participating parties on the validity of the services provided and the agreement; the time provisions during the service provision, including testing, maintenance and upgrades; the provision of the number of users, locations and / or the corresponding hardware services provided; Instructions, including conditions for escalation to a higher level of support. Provisions for expected response time to the fault report should be included; a description of the change request process. May include expected time to complete routine change requests; provisions for service level objectives; provision for service-related charges; provision for user responsibilities (user training, ensuring proper desktop configuration, no unnecessary software, no obstruction to change management Process, etc.); a description of the process for resolving disagreements related to the service.

Service Level Agreement Service Level Agreement System

Service Level Agreement System: "Navigation Map" for Service Level Management

In order to clarify the respective responsibilities of the business department and the IT service department, the service level manager needs to sign a service level agreement in response to the service level requirements that the two sides have reached. At the same time, in order to ensure the full implementation of the service level agreement, the IT service department also needs to sign an Operation Level Agreement and an Underpinning Contract with internal and external suppliers, respectively. These three agreements constitute a service level agreement system that supports the operation of the service level management process, and is a written basis for clarifying the rights and responsibilities of the parties. This also constitutes a "navigation map" for the smooth operation of the service level management process. The structural relationship between the three agreements can be represented by [Figure 1].

Service level legend

A service level agreement is an agreement reached after the IT service department and customers have reached consensus on key service goals and the responsibilities of both parties in the process of service provision and support. Service level agreements should be in a language understood by both the business and IT service departments, rather than in a technical language. This can facilitate the communication between the business department and the IT service department, reduce friction between the two parties, and also facilitate later review and modification.

Operation level agreement refers to the agreement between the IT service department and a specific IT function department or position within the organization to provide and support the service provision and support of a specific IT service item (such as the availability of the mail system, the availability of the fax service, etc.) Agreement. After the IT service department signs a service level agreement with the business department as a whole, in order to ensure that the agreed service level objectives can be achieved, the customer's business needs need to be converted into specific service items, and these service items and the corresponding internal IT function departments Or post the operation level agreement.

A support contract is an agreement between an IT service department and an external supplier on the provision and support of a particular service project. For example, the IT service department often needs to rent communication lines and equipment from external suppliers in order to achieve the availability level goals of the communication system determined in the service level agreement. At this time, in order to ensure the stability and reliability of communication services, the IT service department needs to sign corresponding support contracts with external suppliers.

It should be noted that service level agreements and operation level agreements are usually only a written description of their respective responsibilities and service goals within the IT service department and between business units, rather than a formal legal contract, and the support contract is usually an IT service Formally legally binding contract between the department and an external supplier.

Service level agreement

After establishing the service catalog, the most reasonable service level agreement architecture must be designed to ensure that all services and all IT system users are covered. There are three main approaches to building an SLA:

Service-based

Each service level agreement is formulated for a service, unless different users have different special requirements for the same service. In this case, different indicator systems need to be set up under the same service level agreement. When signing a service level agreement, you need to take into account the scope of the user and let different user scope representatives sign. Or you can sign different agreements separately to avoid unnecessary trouble.

User-based

After ensuring that a service level agreement only addresses a single user group internally, then this agreement will include all services used by the user, and can include all services and all users.

From the user's point of view, they may be inclined to this protocol, all their requirements are contained in the same document. Generally, it only needs to sign once. This is relatively simple, but for the service level management project promotion team, the workload may increase.

Multi-level service level management

After the initial stable implementation of the service level agreement for a period of time, you can choose to adopt a multi-level SLA structure as required. Such as the following three-tier structure:

1. Company level: Contains a broad category of service level management issues suitable for all users. It is suitable for relatively stable services, and the system will not change and upgrade frequently.

2. User level: contains all service level management issues related to individual user groups, regardless of the services used by this user group.

3. Service level: For a special user group within China Mobile Communications and a special service related to this user group.

Service level agreements define the basis for formal understanding and communication between developers and customers. Simon Jackson explores why your project requires a service level agreement.

Service Level Agreement (SLA)

Used to manage the performance of the service. Although it may not yet be a common part of your development project, SLAs can be used to improve the quality of the development process, reduce the risk of project failure, and strengthen relationships with customers. SLAs are professional-publishing and relying on acceptable standards shows that the company understands its business and its customers. This article will explore service level agreements in software development: why you need them, and tips for creating such an agreement.

What is a service level agreement

The SLA Information Zone's Web site describes SLAs as "documents that define the relationship between the two." The SLA sets the benchmark for the elements of the development process, which is considered important to maintaining the relationship between the development team and the customer.

Although not a formal contract, the SLA can be used as part of a formal transaction. The difference between a contract and an SLA is the purpose and rigor of the text. The contract is to formalize the relationship and has legal effect; the SLA is used to improve the relationship and has no legal effect. However, if the terms of the SLA cannot be achieved, then you will hurt or destroy the relationship, just as if the contract was not performed.

Why implement a service level agreement?

Software development has a bad reputation for delivery. The 2003 CHAOS report of the Standish Group of Companies shows that when requirements and budgets are encountered for development difficulties, more than half of IT projects are "questioned."

There are various reasons for a project to fail, but various studies have shown that standards are critical to the success of a project, such as user participation and clear requirements. SLA is a tool that takes these principles out of books and puts them into practical projects.

Equally important is strengthening relationships with customers. Writing an SLA requires an understanding of professional software development and true accountability to customers. You know what you want, and you insist on it, giving your customers a reason to believe in your abilities and knowledge.

Why should service level agreements be included?

The main factors for project success include: project selection, client involvement, formal project management and requirements management.

Depending on the size of the project, scheduling, and risks, you also want to consider software development best practices, such as quality assurance and unit testing.

It's also important to include what customers think is important. You may not always agree, but if necessary, asking questions, listening, and negotiating are important.

Remember, SLA defines relationships; it is based on agreement and understanding. By gaining user input, you are strengthening relationships and improving the entire process.

Choose project method

At first, it seemed unreasonable to choose a project method that suits the project. Instinctively, we are looking for a real way, which is the perfect way to effectively achieve project success. After listening to the rhetoric of any preacher, you will begin to believe it. Cricket nitpicking always exists, but-if their processes are so good, how come so many other processes?

It is important to ignore the words of the pseudo-religious and focus on the client and the project. Every client and every project is different-no method is a panacea.

There are many alternatives, so you should choose one that suits your specific requirements. Scott Ambler, a pioneer of agile software development methods, stated in his article "One Size Fits None" that "doing this requires an understanding of the project and an understanding of the advantages and disadvantages of the various methods."

The SLA must state the chosen method of the project and the associated characteristics and performance standards. Customers may not be very concerned about which method they choose, but they will care how it will affect the project.

Customer involvement

The motto of "early release, often release" is often much bragging but less practical. What this means is that the customer should not hear any adverse accidents during the implementation of the project: such as "we exceeded 50% of the budget" or "we need at least two more weeks".

Strategies for engaging customers include meetings, shared workspaces, and formal problem management.

meeting

Regular meetings, preferably once a week, are often not taken seriously by developers, although they may become the backbone and savior of the project. If used properly, they can help solve problems, strengthen relationships, and deepen the team's understanding of customer requirements. But if used incorrectly, they can waste time and hurt confidence.

The SLA must determine the frequency and content of the meeting in order for the meeting to be effective. These include a fixed agenda, designation of a chairperson, timekeeper, clerk, notification of action items and distribution of minutes.

For how to organize a meeting, visit the (professional) host in your area. These meetings have fixed rules; for example, they must start and end on time, and the speakers' speeches must follow the schedule. As a result, they do not degenerate into chattering personal monologues.

Shared workspace

Projects bring a lot of information-documentation, discussions, issue notes, contact information sheets, and incidents. Centralization and sharing are key factors in coordinating projects and keeping users engaged.

To be truly effective, the entire project team must be able to obtain resources from possible sources-from the office, home, or on-site. A web-based intranet is a good solution.

Problem management

This is the most important but least practiced part of customer relationship management. In the course of any project, many questions, problems and suggestions arise. Capturing, preserving, prioritizing, and processing these things is extremely important to drive a project that a client considers successful. There are still examples of delivering content that customers want, but still failing. This may be because the project requirements have changed, or because it is not fully documented. We listen to our customers' opinions, and solve problems as soon as they arise, so that we can maximize our chances of success. Email is not a good tool for this task. I often see customer relationships rapidly deteriorating due to false content in emails. A single, centralized issue register should be maintained, perhaps in the corporate intranet. Technology is not that important, but everyone should be able to see the registration information for these issues and monitor and review them frequently.

Formal project management

In general, project management requires different software development skills. Nevertheless, senior developers are often required to manage budgets, plan resources, recruit staff, manage customer relationships, and other matters in addition to leading development. This is not just unreasonable, it is often fatal to customer relationships.

Project management comes at an additional cost. This includes customers who are sometimes reluctant to meet, especially if their past project management performance is poor. SLAs that define project management outcomes and standards will help alleviate their concerns to some extent.

Requirements management

Understanding what customers need is an important part of delivering value. This is complicated because, in some cases, customers may only have an unstructured idea of what they want. In all cases, they rely on the technical experts of the development team to advise them. The approach to requirements management is the foundation of software development methods. For example, agile software development methods often assume that customers do not have a complete understanding of what is needed. The so-called waterfall development approach starts with a formal and static and well-defined requirement. Requirements management is therefore closely related to the choice of project approach.

The SLA must recommend the method of requirements management and how to deal with the changes required during project implementation. This includes a change control process, which places functional requirements on the second release or requote of the entire project.

Software "best practices"

Software development has specialized practices; the correct use of these practices can improve software quality and productivity. These practices include nightly builds, feature reviews, defect metering tracking, code comments, documentation, quality assurance, changes, peer reviews, unit tests, and user acceptance tests.

Not every SLA requires all of the above; it's up to the technology, experience, and creativity of the project, the client, and the project team. Don't be afraid of new ways of doing things-success is an innovative process.

Service Level Agreements in Practice

Like most performance measures, SLAs should be SMART: Specific, Measurable, Achievable, Realistic, and Time-bound. I will use a benchmark for functional evaluation as a practical example to illustrate the above. The first part of the benchmark is quite simple: "We will evaluate the functionality of the software."

The above statement raises some obvious questions: what is functional evaluation and why is it needed? Who conducts the assessment? How is it measured? When will it be evaluated? So it must not be SMART-compliant-because it conveys too much information.

To improve it, the first thing to do is to make this statement more specific, stating what, why, and how. "Functional evaluation is used to check the integrity of the software to see if it meets established requirements and whether it meets business needs. This will ensure that the software released can meet customer expectations.

"Before the first evaluation, the provider must summarize the requirements in a small point, accept the inspection of the customer, and get the customer's approval.

"Functional evaluation includes a meeting of the entire project team-that is, including the development team and the business team. During the meeting, the development team will state how each requirement is implemented in the software, using the latest development version of the software To explain.

"The customer is responsible for determining whether each function has been implemented correctly." This is much clearer. Specifying the requirements also allows the development team to check whether the standards are achievable and realistic.

These determinations depend heavily on the capabilities of the development teamtechnology, knowledge, experience, and time. The above statement still does not fully meet the SMART standard: it does not have a time limit, nor can it provide a basis for the determination of performance. Need more details:

"Three functional evaluations will be performed: the first time is when the code is 50% complete, the second time is when the code is 75% complete, and the last time is after the software enters formal testing (QA). Of the resolved functions, 90% will be recognized by customers as being completed. "

In this case, planning should be based on milestones in the build phase. More specific dates can be provided to the project plan through these points. We also need to state a clear, measurable standard. If this is not possible, problems may arise during the development process, during the specification, or during the communication process.

This is now the goal of the project and an early warning system. It will again ensure that customers understand that they will be asked if the project requirements have been met and give them the confidence that you will be delivering software that is good value for money. Using it, you can show that you know the common problems in software development-incomplete or incoherent requirements-and show that you are determined to solve it.

Apply service level agreement every day

Of course you will "get what you measure", but SLA is not simply used as a method of measurement. By setting achievable and realistic benchmarks, it has become a tool for improving software development and enhancing customer management. Although the quality of software development has improved in the past decade, there is still much to be improved; SLA is one way to solve the problem.

monitor

Easily monitor SLA prerequisites

Signing the SLA will have the following forms: IaaS, PaaS, and SaaS, which are infrastructure as a service, platform as a service, and software as a service. Companies should ensure that they monitor all signed SLAs.

Third party monitoring

Auditing is an important step to ensure security, guarantee the commitment and responsibility of the SLA, and maintain demand compliance. Enterprises can use third-party monitoring. If businesses run business-critical applications in the cloud, this service should be regularly reviewed to ensure compliance, and vendors are urged to keep pace with SLAs.

Transform SLAs to help business results

Although the cloud computing market is growing rapidly, most of the IT in SMEs is not mature enough to support infrastructure-based SLAs to help voluntary development. Instead of rushing to sign agreements, companies should choose the SLA that best fits their business needs.

If the enterprise is in a hurry, choosing the infrastructure-level SLA directly may generate a lot of phone bills within the company. For example, if an enterprise wants 99.999% high availability, the service provider will provide more redundancy and disaster recovery, and the cost will increase significantly.

When focusing on frugal business-level SLAs, cloud computing SLA monitoring should be logical and feasible, not just infrastructure-level SLAs. ^[1]