Desktop Managed Service

(1)

Page 1 of 30 1 2 3 4 5 6 7 8 9 10 11

Desktop Managed Service

12

GHG PROTOCOL PRODUCT LIFE CYCLE

ACCOUNTING & REPORTING STANDARD:

ICT SECTOR GUIDANCE

DOCUMENT DETAILS

Reference: Version: V0.2

Last Updated: 28/10/11

(2)

Page 2 of 30

1. INTRODUCTION

1

1.1. DOCUMENT PURPOSE

2

This document is the ‘Service Application’ chapter for Desktop Managed Services (DMS), which forms part of the ‘ICT 3

Sector Guidance’ annex to the GHG Protocol Product Life Cycle Accounting and Reporting Standard (abbreviated to 4

‘Product Standard’ in this document). 5

1.2. HOW TO USE THIS DOCUMENT

6

For ease of reference, the structure of this document follows as closely as possible that of the Product Standard, i.e. the 7

major sections of the Product Standard (and, where it makes sense, certain sub-sections) are replicated. The aim is to 8

provide maximum clarity with minimum duplication. 9

10

The main sections from the Product Standard most pertinent to providing guidance for DMS have been used, and are as 11

follows: 12

13

 Establishing the Scope of the Inventory 14

 Boundary Setting 15

 Allocation 16

 Collection Data and Assessing Data Quality 17

 Calculating Inventory Results 18

19

The verbatim ‘General Requirements’ from the Product Standard for each of the above sections are included as an aide

20

memoire in this draft, and will be removed in the final version of this chapter. 21

22

The following sections from the Product Standard are considered general to the guidance provision for all ICT 23

services/applications (i.e. there is nothing to specific to say on these topics for a given service/application) and are 24

therefore omitted from the service/application chapters: 25

26

 Data Management Plan 27  Assessing Uncertainty 28  Assurance 29  Reporting 30

 Setting Reduction Targets and Tracking Changes Over Time 31

 Appendices - all 32

33

The above are covered in the ‘Introduction’ chapter. 34

35

1.3. RATIONALE FOR PROVIDING SECTOR GUIDANCE FOR DESKTOP MANAGED SERVICES

36

The ‘Service Applications’ initially selected as requiring ‘Sector Guidance’ on the Product Standard have been chosen 37

largely on grounds of high customer demand and of broadness of coverage. DMS meets both criteria as it forms a large 38

portion of the ICT services sold and, by its nature, is comprised of many underlying ICT services, e.g. desktop/laptop 39

hardware, LANs, WANs, datacentre hosted servers and other equipment, and ancillary services such as helpdesk and 40

deskside support. 41

42

Some of these underlying services are defined as Infrastructure (‘Building Blocks’) and described in other chapters 43

comprising the overall ‘ICT Sector Guidance’ for the Product Standard, e.g. . ICT Hardware and Equipment 44

45

They are referenced in this document as appropriate to the context. 46

(4)

Page 4 of 30

2. ESTABLISHING THE SCOPE OF THE PRODUCT INVENTORY

1

2.1. REQUIREMENTS

2 3

The following are the general Scope requirements from the Product Standard. 4 5 6 2.2. INTRODUCTION 7 8

The Studied Product for which the GHG is performed relates to a Desktop Managed Service (DMS). This covers the 9

lifecycle of the whole service. 10

11

The definition of a Desktop Managed Service is aligned to the Gartner definition of the Desktop Managed Service. In 12

summary, it can be broken down thus. It can include some or all of the following components. 13

(5)

Page 5 of 30 1

The Service Desk may provide / provides Incident, Problem, Change and Release Management and a Single 2

Point of Contact for all IT issues. The Service Desk may also provides remote assistance to users, and can 3

manage and maintain any User self service provision – allowing users to fix common IT issues (such as 4

password lockouts) without the need to log a call. 5

6

The End User Device service covers / may cover the provision and management of the desktop device, 7

including desktops, laptops, thin client terminals and mobile devices through the full lifecycle from procurement 8

– using (for example) an online catalogue to select and order - through to recycling, re-use or ultimate disposal. 9

During the device lifetime, the latest configuration management tools can be used to ensure a common 10

standard across the IT estate and ensure the device is kept up to date with the latest security enhancements. 11

This element may also include advanced third and fourth line (remote) support for desktop issues. 12

13

Desk Side Services ensure that users have the right level of support, wherever they may be. Where Remote 14

Assistance by the Service Desk (where provided) is not enough desk side support teams can visit the end user 15

to help resolving any software issues, providing hardware fixes or replacements or providing support for any 16

planned upgrades, changes or moves as required. 17

18

The End User Infrastructure service can include the hosting (if required), management and ongoing 19

optimisation of the infrastructure that supports the desktop service. This could include Directory, Email, File & 20

Print, Mail Relay, Security and Internet Proxy services. The service can encompass elements expected from a 21

comprehensive infrastructure management service including Operating System and application updates, 22

service backup and restore, availability management, capacity management, performance management, 23

software and hardware support. This component can also include management and support for the desktop 24

printer infrastructure. 25

26

Service Delivery Management can include Service Level Management, Service Reporting and strategies for 27

Continuous Improvement – providing a single point of authority and management interaction dedicated to 28

ensuring quality of service. 29

30

2.3. UNIT OF ANALYSIS

31 32

The Unit of Analysis in the context of a Desktop Managed Service is the provision of Desktop Services (as per 33

definition) to Supported Users per year. This relates to how a DMS is usually costed and sold by vendors. 34

35

Within this Unit of Analysis are the apportioned elements of the DMS, as defined in the Boundary section introduction 36 3.1 37 38 - Service Desk 39 - Deskside Services 40

(6)

Page 6 of 30 - Service Delivery Management

1

- End User Device 2

- End User Infrastructure 3

4

There is the potential for Allocation where these elements are potentially shared (e.g. End User Infrastructure), this is 5

covered in the Allocation section. 6

2.4. FUNCTIONAL UNIT

7 8

As the Product is a Service rather than a commodity, the Functional Unit definition is dependent on the shape and scale 9

of the Desktop Managed Service. For example : 10

Number of Users Supported. 11

Make / Model and Usage Profiles of the End User Devices. 12

More minor factors (relating to emissions) such as whether the End User Infrastructure/Service Desk are shared. 13

14

In that regard, the definition of the functional unit will be based on variables. At the top level. 15

16

The Magnitude : The number of Users Supported. 17

- And for each user or user group a list of supported Devices. 18

- Expected tickets per user (Requests and Incidents) 19

20

The Duration : The length of Service. 21

- And whether there is a refresh planned either prior to, or during the service. 22

- With usage profile within this (usually office hours) 23

24

The Quality : The Service Levels which apply for the Service. 25

- The type of engineering support (on site, mobile) 26

- The response/fix times for the support service (Service Desk / Engineering) 27

28

The Geography of the Service must also be considered and whether the Service is delivered over several countries / 29

geographies. However, this is covered under calculation where the (consistent) energy output is varied by the emissions 30

factor for each country. 31

32

Taking into consideration all of these variables will drive the output. Example parameters are provided in section 2.4 33

Reference Flow below 34

35

2.5. REFERENCE FLOW

36

The magnitude, quality and duration parameters are all based on the technical performance characteristics and service 37

life of the studied product. 38

39

As the Product for the DMS is a Service and not Commodity based, the Reference Flow is variable depending on the 40

criteria selected for the DMS. 41

42

Examples of two types of DMS are provided below which demonstrate the breadth of possibility in terms of defining the 43

Reference Flow of the Service (Product). 44 45 46 47 48 49 50

(7)

Page 7 of 30 Type 1 :

1

5 year contract 2

5000 Users in total, split thus; 3

2500 Users office based (Each with a Desktop) 4

2500 Users mobile (Each with a Laptop) 5

Average of 1 Ticket per user per Month (split 0.25 / 0.75 Requests/Incidents) 6

5 Office Locations (All UK) – 500 Users in each 7

Local Desktop Engineering Teams at each office 8

Mobile Desktop Engineering Teams supporting Mobile laptop users 9

Dedicated Service Desk (housed in one of the 5 UK locations) – 24 x 7 Service 10

Local IT Infrastructure 11

Standard SLAs (see below on explanations on how Service Levels can impact the Environmental Aspects of a DMS) 12

Usage Profile / Hours of Support Cover (office hours – 08:00 – 18:00 Monday to Friday) 13 14 Type 2 : 15 5 year contract 16

UK 18

1000 Users Office Based (each with a Desktop) 19

1000 Users Mobile (Each with a laptop) 20

France 21

2000 Users Mobile (Each with a laptop) 23

Germany 24

USA 26

1000 Users Mobile (Each with a Laptop) 28

Locations : 1 Office Location : UK, France, Germany. 4 Office Locations USA (500 users in each) 29

Local Desktop Engineering Team in Each office Location 31

Mobile Desktop Engineering Teams supporting Mobile laptop users in each supported country 32

Dedicated off site multi-lingual Service Desk (UK based) 24 x 7 33

Dedicated off site Infrastructure (two hubs, USA and Europe (UK)) 34

Standard SLAs, with enhanced SLAs for 20% of the workforce considered “VIPs” (evenly split between the user 35

groups). 36

Usage Profile (office hours, Monday to Friday 08:00 – 18:00) (for each country) 37

38 39

Of course this is by no means an exhaustive list of possibilities, many derivatives can be driven, the above examples 40

are for demonstrative purposes only. This is therefore to be used as guidance. 41

42

Examples of how calculations can be derived from example scenarios are worked through as part of Section 8, 43

Calculating the Inventory Results. This framework can therefore be used as the basis for building any bespoke 44

derivative DMS (Product), by changing the variables or adding to the examples provided. 45

46

Service Levels and Use Profiles 47

48

Service Levels can vary the Environmental aspects of a Desktop Managed Service. 49

50

Tight SLAs with high penalties for failure will usually drive higher costs, bigger delivery teams and potentially more 51

resource hungry infrastructure to support the SLA. All of this will contribute to greater GHG emissions. 52

(8)

Page 8 of 30 1

Examples : 2

Service Desk – Call answering Service Level Agreement. If say, the SLA is tough to achieve, e.g – 99% in 10 seconds, 3

it will drive a bigger headcount on the desk and therefore greater emissions. 4

If the “Time to Close” Service Level is tight, example, 1 hour to replace a laptop, then again this may drive. 5

1) A bigger team to deliver the service. 6

2) A much bigger spares stock to supplement the immediate availability of replacement laptops. 7

Again, this drives greater GHG emissions. 8

9

For Use Profiles a standard “office hours” type service, say 08:00 – 18:00 Monday – Friday will usually have a much 10

lower emissions profile than a 24 x 7 service, where additional staff will be required in the support space, potentially on 11

numerous shift patterns. This would, in most circumstances, increase the emissions. 12

(9)

Page 9 of 30

3. BOUNDARY SETTING

1 3.1. REQUIREMENTS 2 3

The following are the general Boundary Setting requirements from the Product Standard. 4 5 6 3.2. INTRODUCTION 7 8

For the purposes of setting boundaries, the component elements and deliverables of a Desktop Managed Service must 9

be defined. Physical products are an integral part of the Service (in simplistic terms, an estate of Printers, Desktop PCs, 10

Laptops and/or Thin Client devices) but overarching these are the support, infrastructure and Service Management 11

functions which must also be considered. 12

13

In that regard, the Desktop Managed Service can be summarised with the following components – 14 15 - Service Desk 16 - Deskside Services 17

- Service Delivery Management 18

- End User Device 19

- End User Infrastructure 20 21 22 23 24 25 26 27

(10)

Page 10 of 30 1

3.3. DEFINING LIFE-CYCLE STAGES & IDENTIFYING ATTRIBUTABLE PROCESSES

2 3

The life cycle stages for the Desktop Manage Service are shown below. 4

5 6

Stages 1 and 2 7

The first two stages, Material Acquisition and Preprocessing and Production are directly related to the physical Products 8

used in providing the service (PCs, Laptops etc) leveraged from Chapters within the Infrastructure (Building blocks) 9

Section of the ICT Sector Guidance. 10

In this regard, they could come from any or all of the following Chapters under Infrastructure – 11

- End User Devices 12

- Servers and Network Equipment 13 - Ancillary Devices 14 - Software 15 16

This will capture the embodied emissions for the building blocks of the service (the tangible supported Products) and 17

thus can be re-used in this chapter. 18

19

Stage 3 20

The third phase of the Life Cycle, Product Distribution and Storage is partially dependant on the outputs of the 21

Infrastructure / Hardware products. The definition is as follows - 22

23

“The product distribution and storage stage starts when the finished studied product leaves the gate of the production 24

facility and ends when the consumer takes possession of the product” Section 7.2.1 of the Product Standard 25

26

In the context of ICT, the production facilities or factories will usually dispatch finished Products to Distribution Centres. 27

This Chapter will set the boundary from the point of the Products arriving in the Distribution Centre before final dispatch 28

to the End User, then moving into the Use phase. 29

(11)

Page 11 of 30 1

The process map for this section may therefore contain details of : 2

- Transportation of Supported Products from Distribution Centre to Customer Location 3

- Setting Up of a Programme/Project Rollout Team 4

- Transportation of Supported Products to Individual User location(s). 5

- Physical Installation of Products (for Users and Support Teams) 6

- User Acceptance of Products* 7

- Training of Users* 8

- Recruitment / Readiness of Desktop and Service Desk Teams 9

10

*may be deemed insignificant for measurement purposes. 11

12 13

Stage 4 14

The In Use stage is built based on some key assumptions around the Desktop Managed Service. 15

These relate to definitions of the Functional Unit as described in the Scope section, but can be summarised to : 16

- Magnitude. In this case the size of the supported estate and the scale/complexity of the types of equipment and 17

applications supported. 18

- Use. Expected life/length of service and also the scope of the supported hours per week. 19

- Quality. Within ICT, this could be the Service Levels, support structures in place and Customer Satisfaction 20

which has an effect on the size of support teams. 21

22

This phase would reasonably include: 23

- Engineering visiting assumptions – emissions related to staff movements, most impact by car 24

- Tickets per user (based on stable estate, e.g. 0.5 to 1 ticket per user per month) 25

- Emissions factor on medium use of Desktop/Laptop Equipment in a time period, for example 10 hours a day, 26

Mon – Fri. 27

- Impact of service desk, for example 1 Service Desk Seat per 200 users supported (also based on tickets per 28

user) 29

- Impact on supporting infrastructure and associated emissions / timings 30

- Clarity around scalability on size and geographies (for different emissions factors) 31

- Any impact of hardware refresh for instance (if the life/length of service is not intrinsically linked to the life of the 32 equipment supported) 33 34 Stage 5 35

“The end-of-life stage begins when the used product is discarded by the consumer and ends when the product is 36

returned to nature or allocated to another product’s life cycle.”- Section 7.2.1 of the Product Standard 37

38

Depending on the circumstances specific to the Desktop Managed Service and local legislation on decommissioning of 39

services / collection & disposal of relevant ICT equipment, there will be a placeholder (in terms of the calculation 40 section) covering : 41 42 - Collection of Equipment 43 - Recycling of Equipment 44 - Disposal of Equipment 45 46

(including shared infrastructure equipment and service desk equipment where appropriate) 47

48

The decommissioning / standing down of support teams at service end is not considered a major factor to generation of 49

emissions. 50

(12)

Page 12 of 30 3.4. DEVELOPING A PROCESS MAP

1

The process map below shows the five key stages for the Desktop Managed Service (DMS). 2

Stage 1 & 2 : As previously described in this section, stages 1 and 2 (Material Acquisition and Pre Processing and Production) are taken from the 3

hardware chapter. As the material and significant building blocks of the DMS in an emissions context is based on equipment/hardware, it is 4

appropriate the process content comes from the hardware chapter. 5

Stage 3 : The first part of this stage is also taken from the hardware, this sub-stage covers the transportation of the manufactured hardware from 6

the production location to a distribution location. 7

8

The remaining steps in this Stage covers the Programme and Project element of deploying the DMS prior to go live. This could involve a number 9

of stages. A typical flow is depicted below. Depending on the size and geography of the deployment this could be a significant contributer to 10

emissions. For example, if there are thousands of users over several countries, the emissions from the transport of equipment and the travel 11

impact of project / engineering teams will need to be trapped. 12

13

Stage 4 : The Use phase is where the biggest emissions will almost always be made. The constituent parts (Equipment, Service Desk, 14

Engineering, Infrastructure) are the biggest and most material contributers. The Service Management piece is not material and hence is not 15

included as a contributor. 16

17

Stage 5 : The final stage, End of Life, specifically relates to equipment, in that the decommissioning of teams will not be a material emissions 18

consideration. Therefore, the hardware related steps cover collection, re-use/recycling and disposal along with their associated transportation 19

emissions. 20

21

Where there is an early refresh of equipment (compared to the expected life of the equipment) a proportionate 22

credit may apply for embodied emissions if say equipment has a 5 year life expectancy, but is refreshed after 3 23

years, with the incumbent equipment being recycled into a different process. 24

25

With regard to recycling, e.g. – of components, metals or plastics, again there may be a credit to consider, however 26

the credit with be almost negligible considering it is a small percentage of the recycling stage, which only 27

constitutes a tiny percentage of the overall (Infrastructure) product lifecycle. Manufacturers Product Carbon 28

Footprint calculations may be a good source to consult for this purpose, but even these may not be accurate or 29

measured in the same way compared to peer manufacturers calculations. 30

(13)

Page 13 of 30 Ta k e n F rom Hard ware Cha p te r 1 2 3

In reality, for any DMS service of any size, there would be, in the lifetime of the service, different parts of the estate 4

being refreshed at different times and therefore there may be several lifecycles (and therefore Process Maps) active at 5

different stages at any given time. 6

For example, Servers may have a 5 year life, compared to a 3 year life for Desktops and Laptops. 7

3.5. NON-ATTRIBUTABLE PROCESSES

8

Non-Attributable processes for this process predominately relate to : 9

- Embodied Emissions for Engineer Cars / Transport, only the “In Use” Emissions for their vehicles will count. 10

- Lighting / Heating for Users of the Desktop Managed Service. Lighting / Heating for Support Staff who are part 11

of the DMS will be counted. 12

- Support Staff non-Business related travel , e.g. - commuting 13

14 15

3.6. TIME BOUNDARY

16

As the studied Product is a Service and not a commodity, the Time Boundary is variable for each phase, dependent on 17

the shape, requirements, size and rollout plan of the Service. 18

(14)

Page 14 of 30

For the Infrastructure Hardware, the building blocks of the DMS, there will be some time boundaries pre-defined in the 1

Hardware Chapters, especially in the embodied Phases 1 and 2 and to a lesser degree Phase 4 (Use), although Use is 2

predicated on the Use profile of the Equipment / Service. E.g. – Monday to Friday, 08:00 – 18:00 hrs 3

(15)

Page 15 of 30

4. ALLOCATION

1

4.1. GENERAL REQUIREMENTS

2

Allocation refers to the apportionment of emissions where more than one product/service shares a common 3

process. The following are the general Allocation requirements from the Product Standard. 4

5 6

7 8

The following methods shall be used to avoid or minimize the use of allocation: 9

(16)

Page 16 of 30 1

4.2. RECOMMENDED ALLOCATION APPROACH

2 3

ICT services today increasingly use shared infrastructure and shared support arrangements (e.g. service desk, 4

remote support). The advent of Cloud computing has accelerated this trend. Sharing can happen in various ways - 5

e.g. between different services used by the same customer, between the same type of service used by different 6

customers - and makes it highly likely that some allocation will be required when assessing the GHG emissions of 7

all but the most simple services. A DMS is normally a complex service, wide in scope, and with a number of 8

common processes and shared infrastructure for which allocation may potentially be required. 9

10

The Product Standard identifies three methods for avoiding or minimizing the need to allocate. The following table 11

provides guidance on use of each of those methods in the context of DMS: 12

Method

Process subdivision: Common processes should be sub-divided where possible (or, more meaningfully, viewed as being sub-divided for the purposes of this exercise). However, as the trend in ICT is increasing commonality and sharing (e.g. to reduce costs), this may be a limited option.

Unit of Analysis redefinition: For example, if the ‘Unit of Analysis’ chosen were service per user per year then the emissions (operational and embodied) generated by equipment shared by users using the same service (e.g. LAN switches, file servers) would need to be apportioned across all users of that equipment (say according to usage or time spent). This is likely to be complex to calculate and imprecise. This can be avoided by defining the whole service (e.g. all users of it over a given time period) as the Unit of Analysis.

System Expansion: Considered not applicable. 13

(17)

Page 17 of 30

Complete avoidance of allocation for DMS is unlikely to be achieved, however, even if the ‘Unit of Analysis’ is 1

redefined, as almost any DMS will have service elements shared with either one or more other instances of the 2

DMS service, and/or one or more non-DMS services. 3

4

The Product Standard identifies three allocation methods: 5 6 - Physical, 7 - Economic 8 - Other 9 10

The ‘Physical’ method does not seem appropriate to DMS (or most other ICT services). The ‘Economic’ method 11

may have some merit in the absence of other more specific data, i.e. in certain circumstances, value/cost can map 12

reasonably closely to energy usage/CO2 emissions (e.g. payment for Cloud services usually relates directly to the 13

amount of usage of those services which in turn correlates with the energy consumed/CO2 emitted of the equipment 14

supporting those services). The ‘Economic’ method though can be imprecise (e.g. the relationship between power 15

consumption and unit of workload is rarely linear) and probably works best at the macro-level. 16

17

The most appropriate allocation methods for DMS fall under the ‘Other’ category, and largely involve pro-rating of 18

usage of the shared component. The following table lists frequently encountered shared components of DMS and 19

provides guidance on allocation methods: 20

21

Shared Component Recommended Allocation Method(s)

LAN In-use power consumption of active equipment (e.g. switch): Either % of

data volume passing through or % processing time

Embodied C02 of active equipment: As for In-use (be sure to factor in use of the equipment for other purposes pre- and post- use in DMS)

WAN Use C02 figures from Telecom chapter (i.e. based on data transferred). No

additional allocation necessary (as Telecom figures have this built in) Servers (e.g. email, directory, database,

application)

In-use power consumption: % of processing time (+ % of cooling etc power for servers hosted in datacentres and server rooms - or use use PUE factor if known)

Embodied C02: As for In-use (be sure to factor in use of the equipment for other purposes pre- and post- use in DMS)

Client device (e.g. desktop, laptop) In-use power consumption: % of processing time

Office Based Support Staff (Service Desk and Desktop Engineer) infrastructure

[Includes ICT/telephony equipment (e.g. servers, desktops, LAN) and building power consumption (e.g. for heating, lighting)

In-use power consumption: % total calls

Deskside services (e.g. break –fix, IMACs) C02 emitted in travel: Where a call-out is clearly related solely to the DMS instance (e.g. replace a broken desktop where that desktop is only used for the DMS, then no allocation is required). All other circumstances, apportionment may be guided by distance travelled (for example).

22 23

(18)

Page 18 of 30

5. COLLECTING DATA AND ASSESSING DATA QUALITY

1

2

5.1. GENERAL REQUIREMENTS

3 4

The following are the general requirements from the Product Standard. 5

6

7 8

9

5.2. DATA COLLECTION APPROACH

10 11

(19)

Page 19 of 30 Directly Measured and Activity Data

1 2

The Product Standard defines two typical methods by which data can be gathered: 3

4

1. Directly measuring or modelling the emissions released from a process; 5

2. Collecting activity data and emissions factor for a process and multiplying the activity data by an emissions 6

factor. 7

8

The first method is not directly applicable to the calculation of GHG emissions for DMS (or any other ICT service), 9

as all relevant data is activity data (predominantly electricity consumed, but also fuel used in service operations) 10

11

Process and Financial Activity Data

12 13

The Product Standard further defines two types of activity data: 14

15

1. Process activity data: Physical measures of a process that results in GHG emissions or removals.e.g. energy 16

consumed, distance travelled, hours of operation 17

2. Financial activity data: Monetary measures of a process that results in GHG emissions. 18

19

Data gathered in the DMS context is expected to be largely process activity data. 20

21

General guidance on collecting emissions factors data is covered in the ‘Introduction’ chapter. The wide variation in 22

electricity emissions factors across the world is likely to have a major impact on the calculation of the GHG 23

emissions of a DMS supplied to an multi-national organisation compared with one based in a single country. Also, 24

with the increasing take up of Cloud-based services even previously single-country based organisations may find 25

that the emissions factors used for their on-premise equipment may differ widely from those used for the Cloud-26

hosted services (as the datacentres may be in another country and/or powered by a different electricity mix from 27

the ‘grid average’, e.g. high use of renewables). 28

29

Primary and Secondary Data

30 31

Primary data are process data from specific processes within the product lifecycle. Examples relevant to DMS 32

include: 33

o Kilowatt hours of electricity consumed by equipment used in the service; 34

o Litres of fuel used by service engineers while travelling to customer sites. 35

36

Secondary data are process data not from specific processes within the product lifecycle. Examples relevant to 37

DMS include: 38

o Kilowatt hours of electricity consumed by equipment of the same general type used in the service, 39

based on rule-of-thumb industry knowledge; 40

o Litres of fuel used by service engineers while travelling to customer sites based on data obtained from 41

supporting similar services. 42

43

The Product Standard stipulates that “Primary data are required to be collected for all attributable processes under 44

the financial control or operational control (as defined by the GHG Protocol Corporate Standard) of the company 45

undertaking the product inventory.” 46

47

Primary data is clearly likely to be more accurate than secondary data and is always preferred. However, primary 48

data can not always be obtained, or is not cost-effective to collect, and therefore secondary data can be used to fill 49

the data gap. 50

(20)

Page 20 of 30 5.3. DATA COLLECTION

1 2

The following table identifies the data normally required to be collected for the GHG assessment of a DMS, 3

guidance on obtaining it, and notes relating to the data types and quality outlined above (see process map in 4

‘Boundary Setting’ for a definition of the processes entailed in each stage): 5

6

Data Sources Notes

Emissions in Stages 1 & 2 (aka ‘embodied carbon’) for operational equipment (i.e. that running the ‘live’ service) including that used to run the Service

See guidance in the ‘Infrastructure’ chapters for all the relevant equipment types (e.g. client devices, servers), applying suitable allocation factors for shared equipment.

The data is likely to be a mix of Primary and Secondary data, depending on whether LCAs have been carried out for the equipment. The emissions contributions for these stages are normally amortised over the lifetime of the service (i.e. 5 year duration then 20% is allocated per year). Any replacement equipment installed during the service lifetime (especially via a technology refresh

programme) must also be included. Note that equipment vendors include ‘in-use’ (Stage 4) emissions in their LCA figures. The assumptions used for this contribution vary considerably between vendors, e.g. lifespan of equipment, hours per year used, GHG emissions factors. The ‘in-use’ element of vendors LCA figures should therefore not be used (unless there just happens to be a good fit between the LCA assumptions and the service being assessed). Instead, follow the guidance for ‘Stage 4 – Live Equipment’ below.

Emissions in Stage 3 (Service ‘set-up’)

A range of sources, e.g.

- ‘Embodied carbon’ of equipment used in development and testing - as for Stages 1 & 2;

- In-use electricity consumption of equipment used in development and testing - as for Stage 4

- Fuel used for transporting equipment from manufacturing plants to final locations (inc. that to any intervening distribution centres) - Fuel used in travel of staff to carry out ‘set-up’ activities (e.g. equipment installation, user training)

Mix of primary and secondary data. The emissions contribution of this stage is likely to be small relative to that of stages 1, 2 & 4, and may not turn out to be materially significant (say less that 1% of total) and is potentially omittable. This will depends upon a number of factors, e.g.:

- Degree of variation from ‘standard’ service (i.e. higher development & testing overhead for more customised services)

- Geographic spread of users (i.e. the larger the number of sites spread over a large geographical area the higher the transport/travel overhead - Distance from equipment

manufacturing plants to user locations and datacentres Emissions in Stage 4 - Live

Equipment

The electricity consumption of all live equipment (with allocation factor applied for shared equipment – see ‘Allocation’ section). Ideally, the actual consumption

Mix of primary and secondary data. Should include power consumed by mobile

(21)

Page 21 of 30

should be measured, e.g. using a power meter for each piece of equipment, using standard meter readings where the ICT usage can be separated from non-ICT usage (e.g.office lighting) . In reality, this may not be practicable or cost-effective, so some form of sampling can used (e.g. power meter readings taken from a representative sample of equipment types/usage profiles). Alternatively, use of vendor-supplied power consumption figures is permissible, providing their usage assumptions are a reasonable fit to those of the service being assessed (e.g.active/idle ratios, workload) or at least can be appropriately calibrated.

For any DMS, equipment will include:

- Servers (on-premise and in datacentres) - Storage devices - Firewalls - LAN equipment - Desktops/laptops - Printers - Ancillary devices

For equipment hosted in a special environment (e.g. datacentres, office server rooms) a factor will need to be added to cover the power consumed for cooling etc. PUE, developed by the Green Grid, is the metric typically used for datacentres, which is a ratio of the power used by the ICT equipment to total usage, e.g. if the PUE is 1.7, then 70% must be added to the power consumption calculated for each server. (Note that further, more accurate, metrics are being developed by the Green Grid and are likely to supersede PUE).

equipment (e.g. laptop), whether in an office environment or at the users home, or on the move. In practice, especially for highly mobile users, this will be difficult to measure accurately, therefore using vendor-supplied figures may be the most appropriate data source.

For datacentre element also see guidance in ‘Infrastructure – Data Centers’ chapter

GHG emissions factors GHG emissions factors need to be applied to the power consumption figures calculated for Stage 4. These will vary according to electricity generation method and normally ‘grid average’ is used (which varies between different countries). Therefore, for a DMS with users and ICT infrastructure components located in more than one country, appropriate emissions factors will need to be applied. These can be found at refer to where in document this is referenced (either Appendices or in Intro)

Emissions in Stage 4 - WAN Usage

See guidance defined in ‘Telecomms and Network Services’ chapter

Mix of primary (e.g. data volumes) and secondary data.(e.g. emissions per unit of data).

(22)

Page 22 of 30

factors. Such as Geographical spread of the DMS and how centralised / decentralised the architecture is.

Emissions in Stage 4 – Service Support Staff

The electricity consumption of all equipment used to support the Service, e.g. - Service Desk and Desktop Engineers (‘embodied carbon’ covered under Stage 1 & 2). Data sources as for ‘Emissions in Stage 4 - Live Equipment’ plus an allocation of non-ICT Service Support Staff office energy consumption, e.g. heating, lighting (as, unlike customer offices, the Service Support office based staff are regarded as being dedicated to the purpose of supporting the ICT services, like the datacentre)

Primary data where measurable, e.g. supplier premises.

If not, then proxy data (secondary) should be used.

Emissions in Stage 4 – Engineering

The travel mileage/kilometrage of all staff supporting the service, for each type of vehicle/fuel type used. This is likely to be predominantly for support engineers travelling to user sites for IMAC or break-fix purposes.

Primary data(using Defra fuel conversion factors)

Emissions in Stage 5 - See guidance defined in ‘ICT Hardware and Equipment’ chapter

TBA 1

The following elements of excluded from the DMS GHG emissions calculation: 2

3

1. Power consumed by non-ICT usage by Users in offices and in homeworker or mobile users homes, e.g. 4

heating, lighting 5

2. Emissions from manufacturing/usage of consumables, e.g. printer paper, printer ink) 6

3. Emissions from the manufacture of engineering support vehicles 7

4. Travel of staff working on the service to their normal place of work (i.e. commuting) 8 9 10 11 12 13 14 15

(23)

Page 23 of 30

6. CALCULATING INVENTORY RESULTS

1

6.1. REQUIREMENTS

2 3

The following are the general requirements relating to Calculating Inventory Results, of the Product Standard 4 5 6 6.2. INTRODUCTION 7 8

In the context of a Desktop Managed Service, the inventory items for calculation are listed in the Data Management 9

Plan which in turn references the processes listed in the Process Map. 10

11

Stage 1 (Material Acquisition & Pre Processing) and 2 (Production) calculations: see guidance in ’ICT Hardware and 12

Equipment’ chapter. 13

14

Stage 3 Calculations (Product Distribution and Storage) – 15

Setting Up of a Programme / Project Rollout Team* 16

Transportation of Supported (physical) products from Distribution Centre to Customer Location 17

Transportation of Supported (physical) Products to Individual User Location(s) 18

Physical Rollout (Installation) of physical products (for Users and Support Teams) 19

Recruitment / Readiness / Training of Support, Engineering and Service Desk Teams* 20

Training / User Acceptance of Users* 21

22

* these may be non material in terms of an emissions impact but included for completeness. 23

24

Stage 4 Calculations (Use phase) 25 Use of Equipment 26 Service Desk 27 Infrastructure 28 Engineering 29 30

Stage 5 Calculations (End of Life) 31

(24)

Page 24 of 30 Collection and drop off of equipment (including transportation impact) 1 Re-Use / Recycling 2 Disposal 3 4

The Product Standard proposes the following calculation formulae for indirect emissions. 5

6

GHG Impact (Kg CO2e) = Activity Data (Unit) x Emission Factor (kg GHG/Unit) x GWP (Kg CO2e/Kg GHG) 7

8

When direct emissions data has been collected, an emission factor is not required and therefore the basic calculation 9

equation is: 10

GHG Impact (Kg CO2e) = Direct Emissions Data (Kg GHG) x GWP (Kg CO2e/Kg GHG) 11

12

In the context of a Desktop Managed Service, the activity data could, for example, be KWh (when considering power 13

use of hardware) or Kilometres travelled, when considering driving miles of engineers. 14

15

Please note : As the Global Warming Potential (GWP) is based on 100 years and the GWP for CO2 is 1, then this does 16

not need to be multiplied further to get the CO2e Kg total. So the next section has accounted for this. 17

18

The next section, on calculation, will use the first scenario covered in section 2.4 as the basis, providing some example 19 calculation outputs. 20 21 Type 1 : 22 5 year contract 23

2500 Users office based (Each with a Desktop) 25

2500 Users mobile (Each with a Laptop) 26

5 Office Locations (All UK) – 500 Users in each 28

Local Desktop Engineering Teams at each office 29

Mobile Desktop Engineering Teams supporting Mobile laptop users 30

Dedicated Service Desk (housed in one of the 5 UK locations) – 24 x 7 Service 31

Local IT Infrastructure 32

Standard SLAs 33

Usage Profile (office hours, Monday to Friday) 34

35

6.3. CALCULATING THE GHG EMISSIONS

36 37

Stage 1, Stage 2 (and partial stage 3) Processes – 38

For the hardware related to this Service, the calculation for emissions will need to be driven from the Hardware chapters 39

(under Infrastructure) so it is not demonstrated here. 40

41

In this example we are assuming the following hardware – 42

2500 Fujitsu Esprimo 9900 Desktops 43

2500 Fujitsu Lifebook S781 Laptops 44

100 Hewlett Packard P3015 Printers 45

25 Servers Fujitsu TX300 46

5 Storage / Backup Arrays 47 25 Switches 48 25 Routers 49 50

As well as this there is also the consideration for hot swap spares, in this example, we are assuming (from an embodied 51

perspective) that there are an additional 50 desktops, 50 laptops and 5 printers. 52

(25)

Page 25 of 30 1

In the context of this example, for these phases, it is assumed the total emissions will be : 450,000 Kg CO2e (calculation 2

driven by the Infrastructure chapters). As this is a 5 year contract (and the term is back to back with the expected life of 3

the equipment), the figure will be amortized over the term, therefore 90,000 Kg per annum. 4

5

Phase 3, Product Distribution and Storage 6

7

Process a) Setting up of a Project / Programme Project Rollout Team 8

In this example, the emissions relating to this are negligible and therefore ignored. In some circumstances, for example 9

on global Desktop Managed Service contracts, there may be requirements to fly people around the world to recruit and 10

train new members of staff which would give some material value to calculating/measuring the impact. For this example 11

it is assumed the service provider will pull from a pool of already existing project people, meaning there is little value in 12

measuring or calculating the CO2e impact. 13

14

Process b) Transportation of Supported (physical) products from Distribution Centre to Customer Location. 15

In this example, the equipment is already in UK Distribution Centres, but transport needs to be arranged to get to 16

Customer Locations. 17

Criteria applied to the example scenario are as follows : 18

19

Distributed From one location. Regional Locations for Delivery (5) Number of delivery vehicles required. (50) Average Journey (KM) (200km)

Type of vehicle Articulated 3t-33t Loading 45% (UK Average) Fuel is diesel 20 CO2 CH4 N2O Total Direct GHG CO2 CH4 N2O Total Direct GHG Total KMs travelled kg CO2 per vehicle km kg CO2e per vehicle km kg CO2e per vehicle km kg CO2e per vehicle km Total kg CO2 Total kg CO2e Total kg CO2e Total kg CO2e 10000 0.84788 0.00095 0.00881 0.85763 8,479 9 88 8,576 21 Source (Defra GHG Conversion factors spreadsheet, 2010) 22 23

The above calculation is taken from a Defra’s spreadsheet freely available on their website. There are multiple options 24

for transport, with different vehicle sizes and loadings. The unit of calculation in this case is KMs, although litres of fuel 25

consumed is also a method to calculate the emissions. 26

It splits the emissions into the different GHGs and provides an answer in CO2e. 27

28

So for this section, the total emissions are 8,576 kg CO2e 29

30

Process c) Transportation of Supported (physical) Products to Individual User Location(s) 31

32

In some circumstances, there may be staging locations within the customer environment and a further step is required 33

to deliver kit to the individual locations. In this example, the kit has been delivered direct to the 5 office locations, mobile 34

users will also have to attend their nearest office to collect their laptop. Therefore the emissions for this example are nil. 35

36

Process d) Physical Rollout (Installation) of physical products (for Users and Support Teams) 37

(26)

Page 26 of 30 1

In some scenarios this could potentially involve significant travel time in visiting a large number of sites or users. In this 2

example, the users will be congregated at the 5 key locations during rollout. 3

Assuming there are : 4

25 rollout engineers 5

Rolling out on average 10 pieces of equipment per working day per engineer. 6

With an average travelled distance of 50km per engineer per day 7

This means it would take 21 elapsed days (rounded up) to finish the project, meaning 21 return journeys in their cars for 8

each engineer. 9

Equating to 26250km travelled for all engineers combined (in a diesel car, 1.7 – 2.0 litre engine) 10 11 CO2 CH4 N2O Total Direct GHG CO2 CH4 N2O Total Direct GHG Total KMs travelled kg CO2 per vehicle km kg CO2e per vehicle km kg CO2e per vehicle km kg CO2e per vehicle km Total kg CO2 Total kg CO2e Total kg CO2e Total kg CO2e 26250 0.14518 0.00005 0.00166 0.14689 3,811 1 44 3,856 Source (Defra GHG Conversion factors spreadsheet, 2010) 12 13

Again, the Defra resources are a useful source to calculate from. 14

So for this section, the total emissions are 3,856 kg CO2e 15

16 17

Processes d) and e) Recruitment / Readiness / Training of Support, Engineering and Service Desk Teams and 18

Training / User Acceptance of Users 19

20

As this scenario is centralising the project from the 5 key customer locations, there are no significantly material 21

emissions, so the calculation can either be ignored, or subsumed within the Use phase (as a tiny proportion of the total). 22

Reason being is the training window is small (a week), thus the emissions for hosting the training (Heating, Lighting and 23

bespoke training staff commute to the 5 customer locations will be tiny overall. 24

In some circumstances, for example on global Desktop Managed Services, there may be requirements to fly people 25

around the world to recruit and train new members of staff (or to train users) which would give some material value to 26

calculating/measuring the impact. 27

28

Stage 4, Use Phase 29

30

Usage of End User Devices (by Use Profile) 31

32

The example estate is split thus, by use profile. The wattages are multiplied by the number of units, then the utilization 33

factor is applied. This gives a total wattage rate for all equipment. From there it is multiplied by the Working Days Per 34

Year and Hours Used Per Year, then divided by 1000 to give the yearly KiloWatt Hours. 35

36

Finally the Emission factor for the UK grid is applied, to give the number of Kilogrammes of CO2e per annum. 37

38

On global opportunities, there will be different Emissions factors of course dependent on the country. 39 40 41 42 43 44

(27)

Page 27 of 30

Equipment type Units Watts

Avg % utilisation Total Watts Hours usage / day Working days / year KWh p.a Fujitsu Esprimo E9900 2500 250 30.00% 187500 8 228 342000 Fujitsu Lifebook S781 2500 80 30.00% 60000 8 228 109440 HP Laserjet P3015 50 780 20.00% 7800 8 228 14227 247500 451440 Emissions factor (UK Grid power) 0.54522 Kg CO2e Emissions per annum 246,134 Notes :

Each desktop is used on an average utilisation of 30%, 8 hours a day, 228 working days a

year.

In this scenario the Laptop Users are consultants only working in office 50 days a year on average, the other days they are at customer sites (however, as there is power consumed at customer sites and therefore Emissions, the full 228 working days is included for measurement)

Assuming that when Laptop users are in the office they are using mains power and not

battery

1

This summary is quite simplistic, averaging out the utilization factor for each kit type at a top level, however, if there are 2

specific User Types or specific roles for kit, where the function means a different use profile, then separate lines can be 3

included. 4

For example, if there were a subset of desktops which were involved in generating complex mathematical equations, for 5

the most part 24 x 7, then a separate line can be included which accommodates a higher utilization, hours usage / day 6

and working days per year for these devices. 7

But they should be treated as an exception rather than the rule and only where the difference in emissions is significant 8

enough to justify a separate inventory entry. 9 10 11 Service Desk 12 13

The Service Desk calculation is very similar to the Usage by Equipment calculation. So a similar table to above can be 14

applied specific to the Service Desk if required. Alternatively, the equipment can be blended in as a line in the Use 15

phase. In this scenario/example, the Service Desk is on the customer site and the Desktops for the desk (25) are 16

subsumed within the figure for the Esprimo 9900’s. 17

If a Service Desk has a highly different Use Profile, for example their desktops are utilized at 50% and not 30%, then 18

this can be included as a separate section or line under the Use of Equipment phase. 19

Although there are no people related emissions for the Supported Employees served by the Desktop Managed Service 20

in relation to facilities power/lighting/heating, the Service Desk, as a dedicated constituent part of the Service should 21

account for both facilities power/lighting and any travel emissions. (This also counts for the local Deskside Engineering 22

teams) 23

24

Proxy Data on average CO2e emissions per office based employee are included in Appendix XX. As an alternative to 25

using an average, the energy bill from a physical location which houses the Support staff can be used to calculate the 26

emissions. Then, either an apportionment of heating/lighting is made for the floor space taken up by the Service Desk 27

(28)

Page 28 of 30

staff and dedicated service infrastructure, or by FTE (or seats) of total FTE’s (or seats) in the building. There is no fixed 1

rule on how this can be calculated, but it should be considered, explored and either included or excluded from total 2

emission calculations with appropriate summary. 3

4

Desk Side Services (Engineering) 5

6

As this example DMS contains mobile engineering support for support of the laptop users, there is a requirement to 7

calculate the engineering impact with regard to Emissions. 8

9

For demonstrative purposes as to how this impact could be calculated, using the example. 10

11

Of the 1 ticket raised on average per month per User, 90% are resolved by the Service Desk or Local Desktop 12

Engineering teams. 13

14

So the remaining 10% of tickets which require a mobile engineering visit will generate emissions. 15

16

For 5000 users, this means 500 visits per month. 17

Taking an average of 40km travel distance for each engineering visit, in a Diesel fueled car, up to 1.7L this comes to 18

20000km per month or 240000km per year. 19

This equates to 35,254kg CO2e per annum. (source is once again Defra) 20 21 CO2 CH4 N2O Total Direct GHG CO2 CH4 N2O Total Direct GHG Total KMs travelled kg CO2 per vehicle km kg CO2e per vehicle km kg CO2e per vehicle km kg CO2e per vehicle km Total kg CO2 Total kg CO2e Total kg CO2e Total kg CO2e 240000 0.14518 0.00005 0.00166 0.14689 34,843 12 398 35,254 22

Deskside Engineering teams will also need to have the emissions of their facilities included in the calculation (much like 23

the Service Desk) 24

25

Proxy Data on average CO2e emissions per office based employee are included in Appendix XX. As an alternative to 26

using an average, the energy bill from a physical location which houses the Support staff can be used to calculate the 27

emissions. Then, either an apportionment of heating/lighting is made for the floor space taken up by the Desk Side 28

Services staff and dedicated service infrastructure, or by FTE (or seats) of total FTE’s (or seats) in the building. There is 29

no fixed rule on how this can be calculated, but it should be considered, explored and either included or excluded from 30

total emission calculations with appropriate summary. 31

32 33

End User Infrastructure 34

35

This could include any infrastructure which supports the End Users, discounting the End User Devices which are 36

covered under their own individual section. 37

38

In this example, this would cover a number of servers, disk stores, backup devices and network equipment. Servers 39

would cover such functions as; 40

41

Mail, Print, Application, Service Management Toolset etc. 42

43

A similar table can be generated as per the End User Device Section. For example. 44

(29)

Page 29 of 30 1

Equipment type Units Watts

Avg % utilisation Total Watts Hours usage / day Working days /

year KWh p.a Allocation

Adjusted KWh p.a Servers 25 560 60.00% 8400 24 365.25 73634 90% 66271 Storage/ Backup Array 5 4000 25.00% 5000 24 365.25 43830 100% 43830 Switches 25 200 25.00% 1250 24 365.25 10958 100% 10958 Routers 25 220 25.00% 1375 24 365.25 12053 100% 12053 13400 117464 110101 Emissions factor (UK) (accomodating CO2e) 0.54522 Kg CO2e Emissions p.a 60,029 2 3

Allocation would play a part in this section potentially, especially if infrastructure is shared between different 4

organizations. In this example it is mostly ring fenced, but this organisation shares their Service Desk Toolset (and 5

server) with other organisations. Thus there is an adjustment on the allocation to 90%. 6

7

The Allocation section goes into greater detail as to methods of how this could be applied (e.g – through consumption of 8

resources, or financial for example). In this case, the Allocation method used is through usage, as in total number of 9

tickets logged between the organizations. And 90% of them come through the host organisation, hence the 90% 10 allocation. 11 12 13 14

Phase 5 – End of Life 15

16

For End of Life, there will be a reliance on some elements of the Infrastructure Chapters, specifically around disposal 17

and recycling. (Reference chapter) 18

19

However, the collection and transportation of the infrastructure should be considered. 20

21

In some circumstances, collection of legacy equipment takes place at the same time as the deployment of the new 22

infrastructure, so there will be an overlap of activity (and therefore Emissions) between Phase 3 Product Distribution and 23

Storage and Phase 5. 24

25

Examples of the Transportation of Equipment and the Movement of Engineers have been covered previously and the 26

principles can be re-used. 27

28

Collation of Results 29

The final stage is to collate and report the overall GHG emissions of the Service, through the guidelines laid out under 30

Reporting (section 10 and discussed fully in the top level Guidance Introduction Chapter). 31

32

(30)

Page 30 of 30

7. DOCUMENT CONTROL

1 2

VERSION CONTROL

VERSION DATE OWNER/CONTRIBUTOR CHANGE

0.1 22-07-2011 Andy Lewis, Mel Melis, Fujitsu First Formal Draft for comment by working group 0.2 28-10-2011 Andy Lewis, Mel Melis, Fujitsu First draft for Stakeholder Advisory Group

comment, inc revisions to reflect Steering Ctte comments

Desktop Managed Service