GHG Protocol Product Life Cycle Accounting and Reporting Standard ICT Sector Guidance. Chapter 3:

24 

Loading....

Loading....

Loading....

Loading....

Loading....

Full text

(1)

GHG Protocol Product Life Cycle Accounting

and Reporting Standard

ICT Sector Guidance

Chapter 3:

3

Guide for assessing GHG emissions of

Desktop Managed Services

DRAFT

10 March 2012

(2)

page 2

Table of Contents

3 Guide for assessing GHG emissions of Desktop Managed Services ... 1

3.1 Introduction ... 4

3.1.1 Chapter purpose ... 4

3.1.2 How to use this chapter ... 4

3.1.3 Rationale for providing sector guidance for DMS ... 4

3.2 Establishing the scope of the product inventory ... 5

3.3 Defining the functional unit ... 6

3.4 Boundary setting ... 8

3.4.1 Introduction ... 8

3.4.2 Defining life-cycle stages & identifying attributable processes ... 8

3.4.3 Developing a process map ... 10

3.4.4 Non-attributable processes ... 12

3.4.5 Time boundary... 12

3.5 Allocation and apportionment ... 12

3.6 Collecting data and assessing data quality ... 13

3.6.1 Data collection approach ... 13

3.6.2 Data collection requirements ... 14

3.7 Calculating inventory results ... 17

(3)

page 3

[This is a chapter of the GHG Protocol Product Standard ICT Sector Guidance.

It is being issued as a draft for public comment, through the GHG Protocol ICT Stakeholder Advisory Group.

This is a DRAFT chapter and is still subject to further review and changes. All chapters have been drafted separately by Technical Working Group members, and then reviewed by the TWG and the Steering Committee; however they have not yet been fully reviewed and edited by the convening secretariat. In particular, consolidation and rationalisation with other chapters of the ICT Sector Guidance is still to be reviewed and completed. Use of terminology and methodology also still needs to be reviewed for conformance with the Product Standard.

The ICT Sector Guidance consists of the following chapters: Introduction; Telecommunications Network Services; Desktop Managed Services; Transport Substitution; Cloud and Data Center Services. Plus technical support chapters covering: Hardware; Software; Data Centers. The Introduction Chapter includes general principles applicable to the GHG assessment of ICT products and a summary of common methods to be used, which all the chapters can refer to. Further details of the ICT Sector Guidance initiative are available at the GHG Protocol website:

http://www.ghgprotocol.org/feature/ghg-protocol-product-life-cycle-accounting-and-reporting-standard-ict-sector-guidance

Sections (such as this) in italics and square brackets are for explanation of the draft and will be removed for the final version of the document.]

[Note: this version of the DMS chapter (v0.8) has not changed from the previous version (v0.7 of 29 January 2012), except for changes to the paragraph numbers]

(4)

page 4

1

3.1

Introduction

2 3.1.1 Chapter purpose 3

This chapter forms part of the ICT Sector Guidance to the Greenhouse Gas Protocol Product Life Cycle 4

Accounting and Reporting Standard („Product Standard‟) and covers Desktop Managed Services (DMS). 5

DMS comprise some or all of the following elements: 6

Service desk. 7

End user device. 8

Deskside services. 9

Service delivery management. 10

End user infrastructure. 11

12

A fuller description is available in Section 3.3 of this Chapter. 13

3.1.2 How to use this chapter 14

For ease of reference, the structure of this chapter follows as closely as possible that of the Product 15

Standard. 16

The main sections from the Product Standard most pertinent to providing guidance for DMS have been 17

used, and are as follows: 18

Establishing the scope of a product inventory. 19

Boundary setting. 20

Collecting data and assessing data quality. 21

Allocation. 22

Calculating inventory results. 23

24

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

services/applications and are therefore omitted from this chapter and are covered in the “Introduction 26 Chapter”: 27 Assessing uncertainty. 28 Assurance. 29 Reporting. 30

Setting reduction targets and tracking changes over time. 31

Appendices – all. 32

3.1.3 Rationale for providing sector guidance for DMS 33

The „Service Applications‟ initially selected as requiring „Sector Guidance‟ on the Product Standard have been 34

chosen largely on grounds of high customer demand and of broadness of coverage. DMS meet both criteria 35

as they form a large portion of the ICT services delivered and required within business and, by their nature, 36

are comprised of many underlying ICT services, e.g. desktop/laptop hardware, Local Area Networks (LANs), 37

Wide Area Networks (WANs), datacentre hosted servers and other equipment, and ancillary services such as 38

helpdesk and deskside support. 39

Some of these underlying services are defined in the “Introduction Chapter” and the technical support 40

chapters (e.g. the “Hardware Chapter”). They are referenced in this chapter as appropriate to the context. 41

(5)

page 5

3.2

Establishing the scope of the product inventory

1

The studied product for which the GHG assessment is performed relates to DMS, and covers the lifecycle of 2

the whole service. The definition of DMS is aligned to the Gartner1 definition, which shows they can be

3

broken down into some or all of the components shown in Figure 1. 4

5

6

Figure 1: The five stages of a product life cycle

7 8

The Service Desk may provide / provides incident, problem, change and release management and a single 9

point of contact for all it issues. The service desk may also provide remote assistance to users, and can 10

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

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

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

including desktops, laptops, thin client terminals and mobile devices through the full lifecycle (Material 14

acquisition and pre-processing to end of life). During the device lifetime, the latest configuration 15

management tools can be used to ensure a common standard across the IT estate and ensure the device is 16

kept up to date with the latest security enhancements. This element may also include advanced third and 17

fourth line (remote) support for desktop issues. End user devices encompasses the likes of laptops, desktops 18

and services which are not covered in other segments such as desk side services or service desk (for 19

example : software builds, third and fourth line support) 20

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

Remote Assistance by the Service Desk (where provided) is not enough desk side support teams can visit 22

the end user to help resolving any software issues, providing hardware fixes or replacements or providing 23

support for any planned upgrades, changes or moves as required. 24

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

optimisation of the infrastructure that supports the desktop service. this could include directory, email, file & 26

print, mail relay, security and internet proxy services. The service can encompass elements expected from a 27

comprehensive infrastructure management service including operating system and application updates, 28

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

(6)

page 6

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

printer infrastructure. 2

Service DeliveryManagement caninclude service level management, service reporting and strategies for 3

continuous improvement – providing a single point of authority and management interaction dedicated to 4

ensuring quality of service. 5

3.3

Defining the functional unit

6

The functional unit of DMS is the provision of a defined amount of desktop services to a number of 7

supported users for a specified time period. This relates to how DMS are usually priced and sold by vendors. 8

Thus the functional unit needs to define: 9

The scope of the service provided. 10

The number of users supported. 11

The time period of the service. 12

13

The scope of service should reference the elements of the DMS, as defined in Section 3.2: 14

Service desk. 15

Deskside services. 16

Service delivery management. 17

End user devices (including make/model and usage profiles). 18

End user infrastructure. 19

20

There is the potential for apportionment where these elements are shared (e.g. End user infrastructure), 21

and this is covered in the Section 3.5 Allocation and apportionment. 22

The time period of the functional unit may be expressed as the life of the contract or per year (or both 23

measures may be used). 24

Typically the definition of the functional unit for DMS will be based on variables – for example: 25

The Magnitude: The number of users supported. 26

For each user or user group a list of supported devices. 27

Expected tickets per user (requests and incidents). 28

29

The Duration: The length of service. 30

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

With usage profile within this (usually office hours). 32

33

The Quality: The service levels which apply for the service. 34

The type of engineering support (e.g. on site,mobile). 35

The response/fix times for the support service (e.g. service desk,engineering). 36

37

The geography of the service must also be considered and whether the service is delivered over several 38

countries/geographies. However, this is covered under calculation where the (consistent) energy output is 39

varied by the emission factor for each country. 40

The calculation should take into account all of these variables. 41

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

and service life of the studied product. 43

(7)

page 7

Examples of two types of DMS are provided below which demonstrate the breadth of possibility in terms of a 1

DMS service (product). Many permutations of DMS are possible, two examples of which are below: 2

Functional Unit, Example 1:

3

Five year contract. 4

5,000 Users in total, split as follows: 5

a. 2,500 Users office based (Each with a Desktop). 6

b. 2,500 Users mobile (Each with a Laptop). 7

Average of 1 ticket per user per month (split 0.25 / 0.75 requests/incidents). 8

Five office locations (all UK) – 500 users in each. 9

Local Desktop Engineering teams at each office. 10

Mobile Desktop Engineering teams supporting mobile laptop users. 11

Dedicated service desk (housed in one of the 5 UK locations) – 24 x 7 service. 12

Local IT infrastructure. 13

Standard Service-Level Agreements (SLA) (see below on explanations on how service levels can 14

impact the environmental aspects of a DMS). 15

Usage profile/hours of support cover (office hours – 08:00 – 18:00 Monday to Friday). 16

Functional Unit, Example 2:

17

Five year contract 18

10,000 Users in total, split as follows: 19

a. UK: 20

i. 1,000 users office based (each with a desktop). 21

ii. 1,000 users mobile (each with a laptop). 22

b. France: 23

i. 2,000 users office based (each with a desktop). 24

ii. 2,000 users mobile (each with a laptop). 25

c. Germany: 26

i. 1,000 users office based (each with a desktop). 27

d. USA: 28

i. 2,000 users office based (each with a desktop). 29

ii. 1,000 users mobile (each with a laptop). 30

Locations: 1 office location : UK, France, Germany. 4 office locations USA (500 users in each). 31

Average of 1 ticket per user per month (split 0.25 / 0.75 requests/incidents). 32

Local Desktop Engineering team in each office location. 33

Mobile Desktop Engineering teams supporting mobile laptop users in each supported country. 34

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

Dedicated off site infrastructure (two hubs, USA and Europe (UK)). 36

Standard SLA, with enhanced SLA for 20% of the workforce considered “VIPs” (evenly split between 37

the user groups). 38

Usage profile (office hours, Monday to Friday 08:00 – 18:00) (for each country). 39

40

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

3.8 Calculating the GHG emissions. This framework can therefore be used as the basis for building any 42

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

(8)

page 8

Service Level Agreements and Use Profiles

1

Service Level Agreements (SLA) can impact the environmental aspects of DMS. 2

Tight SLA with high penalties for failure will usually drive higher costs, bigger delivery teams and potentially 3

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

Examples of SLA impacts on GHG emissions:

5

Service Desk – Call answering SLA. If for example, the SLA is tough to achieve (e.g. 99% in 10 6

seconds), it will drive a bigger headcount on the desk and therefore greater emissions. 7

If the “Time to Close” service level is tight, (e.g. 1 hour to replace a laptop), then again this will 8

almost certainly require a bigger team to deliver the service and a much bigger spares stock to 9

supplement the immediate availability of replacement laptops. 10

11

Again, this would increase GHG emissions. For Use Profiles a standard “office hours” type service, say 12

08:00 – 18:00 Monday – Friday will usually have a much lower emissions profile than a 24 x 7 13

service, where additional staff will be required in the support space, potentially on numerous shift 14

patterns. This would, in most circumstances, increase the emissions. 15

3.4

Boundary setting

16

3.4.1 Introduction 17

For the purposes of setting boundaries, the component elements and deliverables of DMS must be defined. 18

Physical products are an integral part of the service (in simplistic terms, an estate of printers, desktop PCs, 19

laptops and/or thin client devices) together with the support, infrastructure and service delivery 20

management functions. 21

In that regard, DMS can be broken down into some or all of the following components: 22

Service desk. 23

Deskside services. 24

Service delivery management. 25

End user device. 26

End user infrastructure. 27

3.4.2 Defining life-cycle stages & identifying attributable processes 28

The life cycle stages for DMS are shown in Figure 2 below:

(9)

page 9

1

Figure 2: The five stages of a product life cycle*

2

*Source: Product Standard 3

Material acquisition and pre-processing and production stages

4

The first two stages, „material acquisition & pre-processing‟ and „production‟ are directly related to the 5

physical ICT equipment used in providing the service (PCs, laptops etc). The assessment of these is 6

described in the “Introduction Chapter” and in the “Hardware Chapter”. 7

Product distribution and storage stage

8

The third stage covers the delivery, installation and deployment of the DMS equipment and services. The 9

definition of this stage (from the Product Standard, Section 7.3.1) is as follows: 10

“The product distribution and storage stage starts when the finished studied product leaves the 11

gate of the production facility and ends when the consumer takes possession of the product”. 12

The elements for this stage would typically include: 13

Transportation of supported products from production facility to distribution centres. 14

Transportation of supported devices from distribution centres to customer locations. 15

Setting up a programme/project rollout team. 16

Transportation of supported products to individual user location(s). 17

Physical installation of products (for users and support teams). 18

User acceptance of products. 19

Training of users. 20

Recruitment / Readiness of Desktop and Service Desk Teams. 21

(10)

page 10

Use stage

1

The use stage would typically include: 2

Engineering visit assumptions – emissions related to staff movements, with the most significant 3

impact from car use. 4

Tickets (incidents and requests) per user (based on stable estate, e.g. 0.5 to 1 ticket per user per 5

month). 6

Emissions due to medium use of desktop/laptop equipment in a time period, for example 10 hours a 7

day, Monday to Friday (The use profile). 8

Impact of service desk, for example one service desk seat per 200 users supported (also based on 9

tickets per user). 10

Impact on supporting infrastructure and associated emissions/timings. 11

Clarity around scalability on size and geographies (for different emission factors). 12

Any impact of hardware refresh (for instance if the life/length of service is not intrinsically linked to 13

the life of the equipment supported). 14

End of life stage

15

Section 7.3.1 of the Product Standard indicates that: 16

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

the product is returned to nature or allocated to another product‟s life cycle‟. 18

Depending on the circumstances specific to the DMS and local legislation on decommissioning of services 19

and collection and disposal of relevant ICT equipment, the following will need to be considered: 20 Collection of equipment. 21 Recycling of equipment. 22 Disposal of equipment. 23

These are covered under the “Hardware Chapter” (including shared infrastructure equipment and service 24

desk equipment where appropriate). 25

The decommissioning / standing down of support teams at service end may not necessarily be considered a 26

major factor to generation of emissions but screening should be employed to ascertain materiality. 27

3.4.3 Developing a process map 28

The example process map showing the five key life cycle stages for DMS is given in Figure 3. 29

Material acquisition & pre-processing and production stages

30

As previously described in this section, these stages are assessed in accordance with the Hardware chapter. 31

Product distribution and storage stage

32

This stage covers the program and project element of deploying DMS prior to go live. This could involve a 33

number of processes, and a typical flow is depicted in Figure 3. The first process of this stage covers the 34

transportation of the manufactured hardware from the production location to a distribution location. At this 35

point (and the processes may well take concurrently or with overlaps as opposed to the sequential flow 36

below), there could be further emissions, related to both transport and training, recruitment of project and 37

service teams as well as user training and engagement. For example, if there are thousands of users over 38

several countries, the emissions from the transport of equipment and the travel impact of project / 39

engineering teams will need to be identified and could well be significant. 40

(11)

page 11

Material

Acquisition & Pre Processing

Use Product Distribution & Storage

Production End of Life

Taken From Hardware Chapter Taken From Hardware Chapter D e liv e ry o f P ro d u c ts ( E n d U s e r D e v ic e s / I n fr a s tr u c tu re ) to D is tr ib u ti o n C e n tr e s Transportation of Supported (physical) products from Distribution Centre to Customer Location Setting Up of a Programme / Project Rollout Team Transportation of Supported (physical) Products to Individual User Location(s) Physical Rollout (Installation) of physical products

(for Users and Support Teams) Recruitment / Readiness / Training of Support, Engineering and Service Desk Teams Training / User Acceptance of Users SERVICE LIVE

Stage Stage Stage

Finished hardware /

software products leaving

the production gate and arriving

at distribution centre

Usage of End User Devices (by

Use Profile) Service Desk End User Infrastructure Desk Side Services (Engineering) Stage Collection and drop off of equipment (including transportation impact) Re-use / Recycling of equipment (including any transportation impact) Disposal of equipment (including any transportation impact) Stage Service Delivery Management 1

Figure 3: Example process map showing the five key life cycle stages for DMS

2

Use stage

3

In example DMS such as those in Section 3.3 Defining the functional unit, the use stage is almost always 4

where the biggest emissions will be made. The constituent parts (equipment, service desk, engineering and 5

infrastructure) are the biggest and most significant contributors. The Service Delivery Management element 6

may well not be significant and could be excluded as a contributor (for example if the Service Delivery 7

Management function consists of a small management team). Screening is recommended to ascertain 8

significance. 9

End of life stage

10

The final stage specifically relates to equipment, in that the decommissioning of teams will not be a 11

significant consideration (but screening should be applied to check significance). Therefore, the hardware 12

related steps cover collection, re-use/recycling and disposal along with their associated transportation 13

emissions. 14

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

proportionate credit may apply for embodied emissions if say equipment has a five year life expectancy, but 16

is refreshed after three years, with the incumbent equipment being recycled into a different process. 17

With regard to recycling (e.g. of components, metals or plastics) again there may be a credit to consider, 18

however the credit with be almost negligible considering it is a small percentage of the recycling stage, 19

which in itself constitutes only a tiny percentage of the overall (infrastructure) product lifecycle. 20

Manufacturers‟ product carbon footprint calculations may be a good source of information for this purpose, 21

but even these may not be accurate or measured in the same way compared to peer manufacturers 22

calculations. 23

(12)

page 12

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

the estate being refreshed at different times and therefore there may be several lifecycles (and therefore 2

Process Maps) active at different stages at any given time. 3

For example, Servers may have a five year life, compared to a three year life for Desktops and Laptops. 4

3.4.4 Non-attributable processes 5

The following are considered as non-attributable processes for the assessment of DMS: 6

For embodied emissions for engineers‟ cars/transport, only the “in use” emissions of their vehicles 7

will count. 8

Lighting/heating for users of the DMS. Lighting/heating for support staff who are part of the DMS 9

will be counted. 10

Support staff non-business related travel (e.g. commuting). 11

3.4.5 Time boundary 12

The time boundary for the assessment of DMS will typically be the length of the DMS service contract (e.g. 13

five years), which is equivalent to the length of the use stage. The length of the end of life stage will relate 14

to the disposal, recycling or re-use of the equipment in the scope of the DMS. 15

3.5

Allocation and apportionment

16

[Note on terminology: 17

The term “allocation” is used in the Product Standard to refer to two different situations: 18

1) Allocation of emissions between two or more co-products produced by the same process 19

(A co-product is where one co-product can only be produced when the other co-product(s) is 20

also produced. For example, a soya bean processing plant produces both soy meal and soy 21

oil). 22

2) Allocation of emissions between independent products which share the same process or 23

service. (For example, multiple products being transported in the same vehicle) 24

The first type of allocation is not common for ICT products, but the second type is very common. 25

In this draft document, the term „apportionment‟ is used for the second type of allocation to 26

distinguish between the two. This use of terminology may be revised in future versions of this 27

draft. It would be useful to have comments on what use of terminology is more useful.] 28

Allocation relates to processes that produce co-products, and in DMS this is typically not relevant. However, 29

the apportionment of emissions (where more than one product/service shares a common process) is 30

relevant. 31

ICT services today increasingly use shared infrastructure and shared support arrangements (e.g. service 32

desk, remote support). The advent of cloud computing and desktop virtualization has accelerated this trend. 33

Sharing can happen in various ways (e.g. between different services used by the same customer, or 34

between the same type of service used by different customers) and this makes it highly likely that some 35

apportionment will be required when assessing the GHG emissions of all but the most simple services. DMS 36

are normally complex and wide in scope, with a number of common processes and shared infrastructure for 37

which apportionment will be required. 38

The most appropriate apportionment methods for DMS involve pro-rating of usage of the shared 39

component. Table 1 lists frequently encountered shared components of DMS and provides guidance on 40

apportionment methods: 41

(13)

page 13

Table 1 Recommended apportionment methods for shared components

1

Shared component

Recommended apportionment method(s)

LAN In-use power consumption of active equipment (e.g.

switch): Either % of data volume passing through or % processing time.

Embodied carbon 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 Refer to Introduction and Networks chapters.

Apportionment based on % of traffic or bandwidth. Servers (e.g. email,

directory, database, application)

In-use power consumption: % of processing time. Embodied carbon: As for in-use (be sure to factor in use of the equipment for other purposes pre- and post- use in DMS).

End user devices (e.g. desktop, laptop)

In-use power consumption: % of processing time. Embodied carbon: As for in-use (be sure to factor in use of the equipment for other purposes pre- and post- use in DMS).

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.

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

Deskside services (e.g. break–fix, IMACs)

Carbon emissions during travel: Where a call-out is clearly related solely to the DMS instance (e.g. to replace a broken desktop where that desktop is only used for the DMS, then no apportionment is required).

All other circumstances: Apportionment may be based on distance travelled (for example).

3.6

Collecting data and assessing data quality

2

3.6.1 Data collection approach 3

Directly measured and activity data

4

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

Directly measuring or modelling the emissions released from a process. 6

Collecting activity data and an emission factor for a process and multiplying the activity data by the 7

emission factor. 8

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

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

service operations). 11

(14)

page 14

Process and financial activity data

1

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

Process activity data: Physical measurements from a process that results in GHG emissions or 3

removals (e.g. energy consumed, distance travelled, or hours of operation). 4

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

6

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

General guidance on sources for emission factors is covered in the “Introduction Chapter”. The wide 8

variation in electricity emission factors across the world is likely to have a major impact on the calculation of 9

the GHG emissions of DMS supplied to a multi-national organisation compared with services based in a 10

single country. Also, with the increasing take up of cloud-based services even previously single-country 11

based organisations may find that the emission factors used for their on-premises equipment may differ 12

widely from those used for the cloud-hosted services (as the datacentres may be in another country and/or 13

powered by a different electricity mix from the „grid average‟ (e.g. high use of renewables)). 14

Primary and secondary data

15

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

include: 17

Kilowatt-hours (kWh) of electricity consumed by equipment used in the service. 18

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

20

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

to DMS include: 22

Kilowatt-hours of electricity consumed by equipment of the same general type used in the service, 23

based on rule-of-thumb industry knowledge. 24

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

from supporting similar services. 26

27

The Product Standard stipulates that „Primary data are required to be collected for all attributable processes 28

under the financial control or operational control (as defined by the GHG Protocol Corporate Standard) of 29

the company undertaking the product inventory‟. 30

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

primary data cannot always be obtained, or may not be cost-effective to collect, and therefore secondary 32

data can be used to fill the data gap. 33

3.6.2 Data collection requirements 34

Table 2 identifies the data normally required to be collected for the GHG assessment of DMS, guidance on

35

obtaining it, and notes relating to the data types and quality outlined above (see process map in Section 3.4

36

Boundary setting, for a definition of the processes entailed in each stage):

37 38 39 40

Table 2 Data requirements for the GHG assessment of DMS 41

Data Sources Notes

Emissions in Stages 1 & 2 (aka „embodied

See guidance in the “Introduction Chapter” and “Hardware Chapter” for all the relevant equipment types (e.g. client

The data is likely to be a mix of primary and secondary data, depending on whether LCAs have been carried out for

(15)

page 15

carbon‟) for

operational equipment (i.e. that is running the „live‟ service) including equipment used to run the service

devices, servers), applying suitable apportionment factors for shared equipment.

the equipment. The emissions contributions for these stages are normally amortised over the lifetime of the service (e.g. a five year lifetime would mean 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, or GHG emission 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, for example: „Embodied carbon‟ of equipment used in development and testing - as for stages 1 and 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 (including transport to any intervening distribution centres).

Fuel used in transport of staff to carry out „set-up‟ activities (e.g. equipment installation, user training).

A 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 (less that 1% of total) and is potentially omittable. This will depends upon a number of factors, for example:

Degree of variation from „standard‟ service (i.e. higher development and 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 overhead).

Distance from equipment manufacturing plants to user locations and datacenters. Emissions in

stage 4 - live equipment

The electricity consumption of all live equipment (with apportionment factor applied for shared equipment – see Section 3.5).

Ideally, the actual consumption 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).

A mix of primary and secondary data. Should include power consumed by mobile 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 datacenter element also see guidance

(16)

page 16

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. Power Usage Effectiveness (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.

in „Infrastructure – Data Centers‟ chapter.

GHG emission factors

GHG emission 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 DMS with users and ICT infrastructure components located in more than one country, appropriate emission factors will need to be applied. See “Introduction Chapter” for further discussion of this.

Emissions in stage 4 - WAN usage

See guidance defined in the ”Telecomms Network Services Chapter”.

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

(17)

page 17

Contribution will depend upon a number of 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 apportionment 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 (secondary) data 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 (End of Life)

See guidance defined in “Hardware Chapter”.

TBA.

1

The following elements are excluded from the DMS GHG emissions calculation:

2

Power consumed by non-ICT usage, by users in offices and in homeworker or mobile users‟ homes 3

(e.g. heating, lighting). 4

Emissions from manufacturing/usage of consumables (e.g. printer paper, printer ink). 5

Emissions from the manufacture of engineering support vehicles. 6

Travel of staff working on the service to their normal place of work (i.e. commuting). 7

Emissions related to the construction of buildings which support the service. 8

3.7

Calculating inventory results

9

In the context of DMS, the inventory items for calculation are listed in the Data Management Plan which in 10

turn references the processes listed in the process map. 11

Material acquisition & pre-processing and production calculations

12

See guidance in the “Introduction Chapter” and the “Hardware Chapter” for these two stages. 13

Product distribution and storage stage calculations

14

Setting up of a programme / project rollout team. 15

Transportation of supported (physical) products from distribution centre to customer location. 16

Transportation of supported (physical) products to individual user location(s). 17

Physical rollout (installation) of physical products (for users and support teams). 18

Recruitment / readiness / training of support, engineering and service desk teams. 19

(18)

page 18

Training / user acceptance of users.

1

Use stage calculations

2 Use of equipment. 3 Service desk. 4 Infrastructure. 5 Engineering. 6

Service delivery management. 7

End of life stage calculations

8

Collection and drop off of equipment (including transportation impact). 9 Re-Use / Recycling. 10 Disposal. 11 12

The Product Standard proposes the following calculation formulae for indirect emissions: 13

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

14

GHG) 15

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

calculation equation is: 17

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

18

In the context of DMS, the activity data could, for example, be in Kilowatt-hours (when considering energy 19

use of hardware) or kilometres travelled, when considering driving distance of engineers. 20

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

21

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

22

this. 23

3.8

Calculating the GHG emissions

24

This section provides an example calculation for a DMS and is based on the scope of Example 1 from 25

Section 3.3 (Defining the functional unit). 26

Example 1

27

Five year contract. 28

5,000 users in total, split as follows: 29

a. 2,500 users office based (each with a desktop). 30

b. 2,500 users mobile (each with a laptop). 31

Average of 1 ticket per user per month (split 0.25 / 0.75 requests/incidents). 32

Five office locations (all UK) – 500 users in each. 33

Local desktop engineering teams at each office. 34

Mobile desktop engineering teams supporting mobile laptop users. 35

Dedicated service desk (housed in one of the 5 UK locations) – 24 x 7 service. 36

Local IT infrastructure. 37

Standard SLA. 38

Usage profile (office hours, Monday to Friday). 39

(19)

page 19

Material acquisition & pre-processing and production (and partial product distribution and

1

storage) stages

2

For the hardware related to this service, the calculation of the GHG emissions follows the guidance in the 3

“Introduction Chapter” and “Hardware Chapter” so it is not demonstrated here. 4

In this example we are assuming the following hardware: 5

2,500 Fujitsu Esprimo 9900 desktops. 6

2,500 Fujitsu Lifebook S781 laptops. 7

100 Hewlett Packard P3015 printers. 8

25 Fujitsu TX300 servers. 9

5 storage / backup arrays. 10 25 switches. 11 25 routers. 12 13

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

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

The calculation for these stages will be assessed from the “Hardware Chapter”. If, for example, the total 16

emissions were calculated as 450,000 kg CO2e, then as the example was for a five year contract (the time

17

boundary and the service contract term are in this case assumed to be the same as the expected life of the 18

equipment), the figure can be amortized over the service contract term, therefore 90,000 kg CO2e per

19

annum. 20

Product distribution and storage stage

21

Process a) Setting up of a project / program project rollout team 22

Setting up of a project or program team relates to recruiting, training and arming a team with relevant 23

knowledge and tools (for example project managers, engineers and admin people) so they are ready to 24

implement the rollout. In this example, the emissions relating to this are negligible and therefore ignored. In 25

some circumstances, for example on global DMS contracts, there may be requirements to fly people around 26

the world to recruit and train new members of staff, which would give some material value to 27

calculating/measuring the impact. For this example it is assumed that the service provider will pull from a 28

pool of already existing project people who are already trained, meaning there is little value in measuring or 29

calculating the CO2e impact.

30

Process b) Transportation of supported (physical) products from distribution centre to customer location 31

In this example, the equipment is already in UK distribution centres, but transport needs to be arranged to 32

get to customer locations. 33

Criteria applied to the example scenario are as follows: 34

Distributed from one location. 35

Regional locations for delivery (5). 36

Number of delivery vehicles required (50). 37

Average journey (km) (200km). 38

Type of vehicle articulated 3t-33t. 39

Loading 45% (UK average). 40

Fuel is diesel. 41

42

A calculation of the emissions for this example is shown in Table 3 below: 43

(20)

page 20

Table 3: Example of emissions from transportation of supported (physical) products from 1

distribution centre to a customer location 2

Total km travelled

Direct GHG emissions per vehicle

km* (kg CO2e per vehicle km)

Total direct GHG emissions

(kg CO2e)

CO2 CH4 N2O CO2 CH4 CH4 CO2 CH4

10000 0.84788 0.00095 0.00881 0.85763 8,479 9 88 8,576

3

*Source: Defra GHG Conversion factors spreadsheet, 2010.

4 5

The above calculation is taken from a Defra‟s spreadsheet which is freely available on their website. There 6

are multiple options for transport, with different vehicle sizes and loadings. The unit of calculation in this 7

case is kilometres, although litres of fuel consumed is also a method to calculate the emissions. 8

It splits the emissions into the different GHGs and provides an answer in CO2e. So for this section, the total

9

emissions are 8,576 kg CO2e.

10

Process c) Transportation of supported (physical) products to individual user location(s) 11

In some circumstances, there may be staging locations (for example a regional head office) within the 12

customer environment and a further step is required to deliver kit to the individual locations. In this 13

example, the kit has been delivered direct to the five office locations, so mobile users will have to attend 14

their nearest office to collect their laptop. Therefore the emissions for this example are zero. 15

Process d) Physical rollout (installation) of physical products (for users and support teams) 16

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

users. In this example, the users will be congregated at the five key locations during rollout. 18

Assuming there are : 19

25 rollout engineers. 20

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

With an average travelled distance of 50km per engineer per day. 22

23

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

their cars for each engineer. This equates to 26,250km travelled for all engineers combined (in a diesel car, 25

1.7 – 2.0 litre engine). A calculation of the emissions for this example is shown in Table 4 below: 26 27 28 29 30 31 32 33

Table 4: Example of emissions from transportation for physical rollout of physical products 34

Total km travelled

Direct GHG emissions per vehicle

km* (kg CO2e per vehicle km)

Total direct GHG emissions

(kg CO2e)

CO2 CH4 N2O CO2 CH4 CH4 CO2 CH4

26250 0.14518 0.00005 0.00166 0.14689 3,811 1 44 3,856

35

*Source: Defra GHG Conversion factors spreadsheet, 2010.

36 37

Again, the Defra resources are a useful source to use for calculations. So for this section, the total emissions 38

are 3,856 kg CO2e.

(21)

page 21

Processes d) and e) Recruitment/readiness/training of support, engineering and service desk teams and 1

training/user acceptance of users 2

As this scenario is centralising the project from the five key customer locations, there are no significantly 3

material emissions, so the calculation can either be ignored, or subsumed within the use stage (as a tiny 4

proportion of the total). The reason for this is that the training window is small (a week), thus the emissions 5

for hosting the training (heating, lighting and bespoke training staff commute to the five customer locations) 6

will be tiny overall. 7

In some circumstances, for example on global DMS, there may be requirements to fly people around the 8

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

calculating/measuring the impact. 10

Use stage

11

Usage of end user devices (by use profile)

12

The example estate is split thus, by use profile. For each type of equipment, the power consumption per 13

unit is multiplied by the number of units, and then the utilization factor is applied. This gives a total power 14

consumption for all equipment in watts. This is then multiplied by the „number of working days per annum‟ 15

and the „usage per day‟ in hours used per year, then divided by 1,000 to give the yearly energy consumption 16

in kilowatt-hours. 17

Finally the emission factor for the UK grid electricity is applied, to give the number of kilograms of CO2e per

18

annum. On global opportunities, there will, of course, be different emission factors dependent on the 19

country. A calculation of the emissions for this example is shown in Table 5 below: 20

Table 5: Example of emissions from usage of end user devices 21

Equipment

type Number of units

Power per unit (W) Average % utilisation Total power (W) Usage per day (Hrs)(1) Working days per annum(1) Total energy per annum (kWh) Fujitsu Esprimo E9900 2,500 250 30% 187,500 8 228 342,000 Fujitsu Lifebook S781 2,500 80 30% 60,000 8 228 109,440 HP Laserjet P3015 50 780 20% 7,800 8 228 14,227 Total 247,500 451,440 22

Electricity emission factor (UK grid power)(2) = 0.54522 kg CO 2e/kWh

23

Emissions per annum = 246,134 kg CO2e

24 25 Notes: 26 27 (1)

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

28 (2)

Source: Defra GHG Conversion factors spreadsheet, 2010

29 30

This summary is quite simplistic, averaging out the utilization factor for each equipment type at a top level. 31

However, if there are specific user types or specific roles for equipment, where the function means a 32

different use profile, then separate lines can be included. 33

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

equations, for the most part 24 hours per day, seven days per week, then a separate line can be included 35

(22)

page 22

which accommodates a higher utilization, hours usage per day and working days per year for these devices. 1

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

is significant enough to justify a separate inventory entry. 3

Service Desk

4

The service desk calculation is very similar to the usage by equipment calculation. So a similar table to 5

above can be applied specific to the service desk if required. Alternatively, the equipment can be blended in 6

as a line in the use stage. In this scenario/example, the service desk is on the customer site and the 7

desktops for the desk (25) are subsumed within the figure for the Esprimo 9900‟s. 8

If a service desk has a highly different use profile, for example their desktops are utilized at 50% and not 9

30%, this can be included as a separate section or line under the Use of Equipment process. 10

Although there are no people related emissions for the Supported Employees served by the DMS in relation 11

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

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

Engineering teams) 14

Proxy Data on average CO2e emissions per office based employee are included in Appendix XX. The

15

preferred alternative to using an average is to use the energy bill from a physical location which houses the 16

support staff. Then, either an apportionment of heating/lighting is made for the percentage of total floor 17

space taken up by the service desk staff and dedicated service infrastructure, or by Full Time Equivalent 18

(FTE) (or seats) of total FTE (or seats) in the building. There is no fixed rule on how this can be calculated, 19

but it should be considered, explored and either included or excluded from total emission calculations with 20

appropriate summary. 21

Desk Side Services (Engineering)

22

As this example, the DMS contain mobile engineering support for laptop users, and there is a requirement to 23

calculate the engineering impact with regard to emissions. 24

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

Of the one ticket raised on average per month per user, 90% are resolved by the service desk or 26

local desktop engineering teams. so the remaining 10% of tickets which require a mobile 27

engineering visit will generate additional emissions. 28

For 5,000 users, this means 500 visits per month. 29

Taking an average of 40 km travel distance for each engineering visit, in a diesel fueled car, up to 30

1.7 l this comes to 20,000 km per month or 240,000 km per year. 31

32

This equates to 35,254kg CO2e per annum as shown in Table 6 below:

33

Table 6: Example of emissions from transportation for mobile engineering support 34

Total km travelled

Direct GHG emissions per vehicle

km* (kg CO2e per vehicle km)

Total direct GHG emissions

(kg CO2e)

CO2 CH4 N2O Total CO2 CH4 N2O Total

240,000 0.14518 0.00005 0.00166 0.14689 34,843 12 398 35,254 35

*Source: Defra GHG Conversion factors spreadsheet, 2010

36 37

Deskside engineering teams will also need to have the emissions of their facilities included in the 38

calculation (much like the service desk). 39

(23)

page 23

Proxy data on average CO2e emissions per office based employee are included in Appendix XX. The

1

preferred alternative to using an average is to use the energy bill from a physical location which 2

houses the support staff. Then, either an apportionment of heating/lighting is made for the percentage 3

of total floor space taken up by the Service Desk staff and dedicated service infrastructure, or by Full 4

Time Equivalent (FTE) (or seats) of total FTE (or seats) in the building. There is no fixed rule on how 5

this can be calculated, but it should be considered, explored and either included or excluded from total 6

emission calculations with appropriate summary. 7

End User Infrastructure

8

This could include any infrastructure which supports the end users, discounting the end user devices which 9

are covered under their own individual section. 10

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

Servers would cover such functions as mail, print, application, service management toolset etc. 12

A similar table can be generated as for the End User Devices (Table 5 above). An example is shown in 13

Table 7 below: 14

Table 7: Example of emissions from usage of end user infrastructure 15 Equip- ment type No. of Units Power per unit (W) Avge % utili-sation Total power (W) Usage per day (Hrs) Working days per year Total energy per annum (kWh) Apport-ionment Adjusted energy per annum (kWh) Servers 25 560 60% 8,400 24 365.25 73,634 90% 66,271 Storage/ Backup Array 5 4,000 25% 5,000 24 365.25 43,830 100% 43,830 Switches 25 200 25% 1,250 24 365.25 10,958 100% 10,958 Routers 25 220 25% 1,375 24 365.25 12,053 100% 12,053 TOTAL 16,025 140,475 133,112 16

Electricity emission factor (UK grid power)* = 0.54522 kg CO2e/kWh

17

Emissions per annum = 72,575kg CO2e

18 19

*Source: Defra GHG Conversion factors spreadsheet, 2010

20

Apportionment may need to be considered in this section, especially if infrastructure is shared between 21

different organizations. In this example it is mostly ring fenced, but this organisation shares their service 22

desk toolset (and server) with other organisations. Thus there is an adjustment using an apportionment 23

factor of 90%. 24

Section 3.5 (Allocation and apportionment) goes into greater detail as to methods of how this could be 25

applied (e.g. through consumption of resources, or financial). In this case, the apportionment method is 26

based on usage, (i.e. total number of tickets logged between the organizations). Since 90% of tickets come 27

through the host organization, a 90%apportionment factor is used. 28

End of Life Stage

29

For End of Life, there will be a reliance on the “Hardware Chapter”. 30

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

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

the new infrastructure, so there will be an overlap of activity (and therefore emissions) between products. 33

(24)

page 24

Distribution and Storage Stages and End of Life Stages

1

Examples of the transportation of equipment and the movement of engineers have been covered previously 2

and the principles can be applied here. 3

Collation of Results

4

The final stage is to collate and report the overall GHG emissions of the Service, (refer to the “Introduction 5

Chapter”). 6

7 8

Figure

Updating...

Related subjects :