[debian-edu-commits] [Debian Wiki] Update of "DebianEdu/Documentation/en/ITIL/Delivery" by PetterReinholdtsen

Debian Wiki debian-www at lists.debian.org
Tue May 12 20:30:06 UTC 2015


Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "DebianEdu/Documentation/en/ITIL/Delivery" page has been changed by PetterReinholdtsen:
https://wiki.debian.org/DebianEdu/Documentation/en/ITIL/Delivery?action=diff&rev1=8&rev2=9

  = Service Delivery =
  
- The main purpose of service delivery is to ensure proactive operation and ICT service delivers appropriate support for users. The purpose of service delivery is to focus on your organization's needs. It is active learning, with use of ICT tools in the different subjects, the school needs. This chapter describes in order:
+ The main purpose of service delivery is to ensure proactive operation and ICT service delivers appropriate support for users. The purpose of service delivery is to focus on your organisation's needs. It is active learning, with use of ICT tools in the different subjects, the school needs. This chapter describes in order:
  
   * Service level management
   * Economy management
@@ -29, +29 @@

  
   * Agreement between the user and operations of what's actually measured. This must be seen from the users' perspective and not ICT service perspective.
   * Measurement and unambiguously on the measurement values included in SLA
-  * Decide realistic targets for service level (there is no point in promising more than one can hold)javascript:;
+  * Decide realistic targets for service level (there is no point in promising more than one can keep)
   * Continuous focus on the control of the service - monitoring and periodic reporting of results achieved
  
  === Planning ===
@@ -42, +42 @@

  
  === Implementation ===
  
- A service catalog with all services included in the SLA It must prepared. A service will often be a application/program in this directory. It will often be different requirements for different services, and reflected in different objektives in the agreement. It will often be different requirements for different services, and it will be reflected in different targets in the agreement.
+ A service catalogue with all services included in the SLA It must prepared. A service will often be a application / program in this directory. It will often be different requirements for different services, and reflected in different objectives in the agreement. It will often be different requirements for different services, and it will be reflected in different targets in the agreement.
  
- To establish and continually adjust the users' expectations can't be overstated. Often users have exaggerated expectations to the system and the services included. ICT service responsibilitity is to adjust expectations down to realistic levels before the service-level agreement (SLA) is signed. The operating management must also ensure that all users actually are notified and know about the expected service level through the agreement.
+ To establish and continually adjust the users' expectations can't be overstated. Often users have exaggerated expectations to the system and the services included. ICT service responsibility is to adjust expectations down to realistic levels before the service-level agreement (SLA) is signed. The operating management must also ensure that all users actually are notified and know about the expected service level through the agreement.
  
  For the structure of the SLA, see [[#Delivery--content-service-level-agreement|section in the service level agreement]].
  
@@ -62, +62 @@

  
  ==== Service time ====
  
- In which time the agreement applies, like Monday to Friday 8:00 a.m. to 4:00 p.m., any special requirements for certain times (for example exams), routines to order expanded time.
+ During which time period would the agreement be valid (like from Monday to Friday, from 8:00 a.m. to 4:00 p.m.), any special requirements at defined dates and times (for example exams) and routines to order an expansion of the service time limits.
  
  ==== Availability ====
  
  Access to the services. Is best measured as the time, period, one or more services have been unavailable, for example a calendar month. Different levels for different services may be agreed, for example depending on the degree of importance for users.
  
- Important to emphasize that this is availability within the agreed period of service, not the overall availability all day, all week and all year round (called 24/7/365). For example, it may be agreed that the system should be available between the hours. 8 to 18 on workdays, after that and on weekends it is more uncertain whether one can use the computer system, unless otherwise agreed.
+ Important to emphasise that this is availability within the agreed period of service, not the overall availability all day, all week and all year round (called 24/7/365). For example, it may be agreed that the system should be available between the hours. 8 to 18 on workdays, after that and on weekends it is more uncertain whether one can use the computer system, unless otherwise agreed.
  
  Availability is also if one gets support via phone or email. For example, can the Service Desk be reached between the hours 08 and 16 at day time, or all day. May one have the possibility of support in the afternoon and evening, or in specific weekends?
  
@@ -106, +106 @@

  
  ==== Sanctions and possible incentives ====
  
- Rules for pricereduction if the agreed service is not met. Escalation procedures and rules for cancellation of agreement by continuous violations of guaranteed service level. Possible incentives for achievement or better than expected service.
+ Rules for price reduction if the agreed service is not met. Escalation procedures and rules for cancellation of agreement by continuous violations of guaranteed service level. Possible incentives for achievement or better than expected service.
  
  See Appendix A for SLA.
  
  == Financial Management ==
  
- Organizations rarely have a full overview of their ICT spending. A 2001-survey of Norwegian municipalities showed that only 1 of 8 municipalities had an ICT budget. Probably it is not better for school. Putting in place an ICT budget is important. Often users think they pay too much for a service they are not happy with. This creates many times conflicts between users and the ICT department.
+ Organisations rarely have a full overview of their ICT spending. A 2001-survey of Norwegian municipalities showed that only 1 of 8 municipalities had an ICT budget. Probably it is not better for school. Putting in place an ICT budget is important. Often users think they pay too much for a service they are not happy with. This creates many times conflicts between users and the ICT department.
  
  It is very useful for both the operations center and users to document the real ICT costs. Without it is difficult to budget appropriately. Not least, it is difficult to make a cost/benefit assessment of existing ICT solutions. Rector should know the ICT budget as well as she knows salary budget, or the budget of teaching aids.
  
@@ -142, +142 @@

  
  Not all municipalities have accounting that shows ICT costs broken down by each school. There may be practical reasons for this, such as discounts and the like that the municipality gets centrally. Therefore it is important to do some planning so that you get an overview of what costs have been for operating and procurement when the accounts should be assessed against the budget.
  
- Some organizations may have cumbersome and costly accounting procedures. You get fast extra charge to pay bills by delays, or if you have many who shall approve a payment. It is important to agree on good billing practices in the procurement and the operation. For both having control, as well as handling payments on time without long decision paths.
+ Some organisations may have cumbersome and costly accounting procedures. You get fast extra charge to pay bills by delays, or if you have many who shall approve a payment. It is important to agree on good billing practices in the procurement and the operation. For both having control, as well as handling payments on time without long decision paths.
  
  === Implementation ===
  
@@ -242, +242 @@

   * Procedures and routines for handling operational services
   * Security, integrity and availability of data
  
- Availability can be measured in several ways. But before we show examples we'll point out what may be difficult targetving figures. If we should make systematic efforts to availability, we have to clarify what the different things mean. What means for example a percentage of availability.
+ Availability can be measured in several ways. But before we show examples we'll point out what may be difficult targeting figures. If we should make systematic efforts to availability, we have to clarify what the different things mean. What means for example a percentage of availability.
  
  Let's say a "computer with computer program" is a service. If the computer program does not work one day, then the service unavailable if all the other programs work fine. What if the computer program is unavailable for a classroom, but available on the rest of the school (because of an underlying service). This is difficult matter to clarify and work on in practice.
  
@@ -299, +299 @@

  
  === Design improvements ===
  
- An operations department will be served by correcting systems that provide much operational messages. It may be users getting much spam. Then it may be okay to install files for spam. There may be a lot of extra work with students who constantly forgets their password, and teachers who send the inquiry to the central drifsstaben. To avoid extra emailing and double work so the teacher can give the student a new password.
+ An operations department will be served by correcting systems that provide much operational messages. It may be users getting much spam. Then it may be OK to install files for spam. There may be a lot of extra work with students who constantly forgets their password, and teachers who send the inquiry to the central sysadmin staff. To avoid extra emailing and double work so the teacher can give the student a new password.
  
  This was a some examples of design improvements to lighten the work of operation and allows users become more satisfied. A well-run operations department has a list of prioritized improvements in design making operation easier. The priorities is usually done based on an assessment of the inquiry to the service, stored in the message log, and an assessment of the work that must be done to treat the requests.
  
  === Planning for availability ===
  
- It means having realistic expectations to the ICT service based on what operations costs. Plan for what's expected accessability. For example, when schools require one should be on air in less than one hour after the server crashes, one must have a standing pre-installed machine in reserve, to be inserted as replacement for the faulty machine. It's made during one hour to copy your backup files to the backup machine.
+ It means having realistic expectations to the ICT service based on what operations costs. Plan for what's expected accessibility. For example, when schools require one should be on air in less than one hour after the server crashes, one must have a standing pre-installed machine in reserve, to be inserted as replacement for the faulty machine. It's made during one hour to copy your backup files to the backup machine.
  
  Is a diskless or thin client broken a prepared small warehouse of machines and monitors is needed at the school. The school ICT contact can retrieve and install a replacement machine. This can be done easily without waiting days in ordering equipment.
  



More information about the debian-edu-commits mailing list