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

Similar documents
Desktop Managed Service

GHG Protocol Product Life Cycle Accounting and Reporting Standard ICT Sector Guidance. Chapter 8: 8 Guide for assessing GHG emissions of Data Centers

Product Accounting & Reporting Standard ICT Sector Guidance Document

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

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

CARBON ASSESSMENT TICKETING DELIVERY SYSTEMS

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

Reporting criteria for selected key performance indicators in the 2014 Responsible Business Report

Prudential plc. Basis of Reporting: GHG emissions data and other environmental metrics.

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

Carbon Footprint Report 2013 Explanatory Document to Carbon Report

PROGRAMME OVERVIEW: G-CLOUD APPLICATIONS STORE FOR GOVERNMENT DATA CENTRE CONSOLIDATION

Service Desk. Description. Detailed Specifications

Capacity Plan. Template. Version X.x October 11, 2012

Green Power Accounting Workshop: Concept Note For discussion during Green Power Accounting Workshop in Mexico City, May 13th 2011

Harmonizing Global Metrics for Data Center Energy Efficiency. Global Taskforce Reaches Agreement Regarding Data Center Productivity.

Carbon Footprint Calculator for Royal Society of Arts

How To Make Money From Your Desktop Virtualisation

APPENDIX 8 TO SCHEDULE 3.3

Guide to Cloud Computing INFORMATION

THE GREEN DATA CENTER

Service Specification. ICT Support 2014/2015

ICT Indicators. The scope of the ICT function covers all aspects of infrastructure, systems, processes and disciplines required to support:

Asset Factory is a software service that allows you to manage the value, costs, risks and performance of your property, people and supply chain

APPENDIX 8 TO SCHEDULE 3.3

Why Choose Desktop as a Service (DaaS)? A TCO Study

Unified Communications. The Technologies, Features & Benefits

GUIDE TO ICT DESKTOP ENERGY MANAGEMENT. Public Sector ICT Special Working Group

Environmental sustainability BBC Environment Targets: Performance 2014/15

VISIT 2010 Fujitsu Forum Europe 0

Managing Cost and Complexity out of Desktop Management

MSP Service Matrix. Servers

APPENDIX 5 TO SCHEDULE 3.3

License management service

Environmental Benefits of Thin Computing A comparison of the environmental impacts of conventional desktop and thin computing

Green ICT Project. Project Management Plan. Project Manager: Samuel Fernandes. Date: March Version: 2.0

Premium Data Centre Europe Pricing, Business Model & Services

Energy Efficient Systems

Breckland Council. Printing Strategy

Service Level Agreement

Whitepaper. Tangible Benefits of Cloud Networking versus the alternative.

ICT budget and staffing trends in Healthcare

GMS NETWORK ADVANCED WIRELESS SERVICE PRODUCT SPECIFICATION

NOS for Network Support (903)

The benefits anticipated from the project can be summarised as follows:

Migrating to the Cloud. Developing the right Cloud strategy and minimising migration risk with Logicalis Cloud Services

2012 Bell Canada Energy Consumption and Greenhouse Gas Emissions Report

Key Solutions CO₂ assessment

Fujitsu Private Cloud Customer Service Description

Support & Field Services

Who moved my cloud? Part I: Introduction to Private, Public and Hybrid clouds and smooth migration

Karen Winter Service Manager Schools and Traded Services

Measuring Energy Efficiency in a Data Center

Request for Proposals (RFP) Managed Services, Help Desk and Engineering Support for Safer Foundation

Fact sheet. Conversion factors. Energy and carbon conversions 2011 update

ENVIRONMENTAL POLICY. The Forest of Marston Vale are rejuvenating the local area that has been scarred by decades of clay extraction and brick making.

Assistance of Cloud Computing For Green Computing

Sustainability and Environmental Review. Introduction

Remote Infrastructure Support Services & Managed IT Services

Fujitsu Cloud IaaS Trusted Public S5. shaping tomorrow with you

ARCHITECTURE SERVICES. G-CLOUD SERVICE DEFINITION.


Monitoring, Managing, Remediating

Software Asset Management (SAM) and ITIL Service Management - together driving efficiency

GUIDELINE. on SERVER CONSOLIDATION and VIRTUALISATION. National Computer Board, 7th Floor Stratton Court, La Poudriere Street, Port Louis

Leveraging the Private Cloud for Competitive Advantage

Information Services Strategy

ITIL Introducing service strategy

Lorraine Hudson Bristol City Council GREEN DIGITAL CITY

Remote Infrastructure Management Emergence of the Cloud-based Helpdesk

EMC PERSPECTIVE Managing Energy Efficiency in the Data Center

Low Carbon Data Centres without compromise

IT Onsite Service Contract Proposal. For. <<Customer>> Ltd

ALWAYS ON GLOBALSWITCH.COM

IT Cost Savings Audit. Information Technology Report. Prepared for XYZ Inc. November 2009

SERVICE SCHEDULE PUBLIC CLOUD SERVICES

ICT budget and staffing trends in the UK

Shades of Green. Shades of Green: Electric Cars Carbon Emissions Around the Globe. Shrink That Footprint. Lindsay Wilson.

Scientific Cloud Computing Environmental Aspects of Network Infrastructure Colin Pattinson, Professor in Mobile and Converging Technologies, School

The case for Application Delivery over Application Deployment

ICT Category Sub Category Description Architecture and Design

DIGITAL MARKETPLACE (G-CLOUD 7) OFFERING. Sopra Steria OneMobile SaaS Service. Introduction. Service Definition. Sopra Steria in the public sector

Summary of Green ICT Initiatives

Service Catalogue. 0984v1

Electricity North West Carbon Footprint Report

Annex 9: Technical proposal template. Table of contents

Life Cycle Assessment of a Solid Ink MFP Compared with a Color Laser MFP Total Lifetime Energy Investment and Global Warming Impact

Preparing for Mandatory Carbon reporting webinar questions

2012 Guidelines to Defra / DECC's GHG Conversion Factors for Company Reporting

ClimatE leaders GrEENHOUsE Gas inventory PrOtOCOl COrE module GUidaNCE

Category 15: Investments

ASIAN PACIFIC TELECOMMUNICATIONS PTY LTD STANDARD FORM OF AGREEMENT. Schedule 3 Support Services

VICTORIAN GOVERNMENT DEPARTMENT ENVIRONMENTAL MANAGEMENT SYSTEM MODEL MANUAL

Opex-based data centre services: Co-location, managed services and private cloud business support

Metrics for Data Centre Efficiency

>99.95% availability. Guaranteed. 1

2011 Business Carbon Footprint (BCF) Report Commentary & Methodology

EU Code of Conduct for Data Centre Efficiency

Australian Government ICT Trends Report

Defining a Standard Carbon Cost Model for Electronic Software Distribution. * Corresponding author: d.williams@student.reading.ac.

Transcription:

GHG Protocol Product Life Cycle Accounting and Reporting Standard ICT Sector Guidance Chapter : Guide for assessing GHG emissions of Desktop Managed Services DRAFT 0 March 0

Table of Contents Guide for assessing GHG emissions of Desktop Managed Services.... Introduction..... Chapter purpose..... How to use this chapter..... Rationale for providing sector guidance for DMS.... Establishing the scope of the product inventory.... Defining the functional unit.... Boundary setting..... Introduction..... Defining life-cycle stages & identifying attributable processes..... Developing a process map... 0.. Non-attributable processes..... Time boundary.... Allocation and apportionment.... Collecting data and assessing data quality..... Data collection approach..... Data collection requirements.... Calculating inventory results.... Calculating the GHG emissions... page

[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-reportingstandard-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.) has not changed from the previous version (v0. of January 0), except for changes to the paragraph numbers] page

0 0 0 0. Introduction.. Chapter purpose This chapter forms part of the ICT Sector Guidance to the Greenhouse Gas Protocol Product Life Cycle Accounting and Reporting Standard ( Product Standard ) and covers Desktop Managed Services (DMS). DMS comprise some or all of the following elements: Service desk. End user device. Deskside services. Service delivery management. End user infrastructure. A fuller description is available in Section. of this Chapter... How to use this chapter For ease of reference, the structure of this chapter follows as closely as possible that of the Product Standard. The main sections from the Product Standard most pertinent to providing guidance for DMS have been used, and are as follows: Establishing the scope of a product inventory. Boundary setting. Collecting data and assessing data quality. Allocation. Calculating inventory results. The following sections from the Product Standard are considered general to the guidance for all ICT services/applications and are therefore omitted from this chapter and are covered in the Introduction Chapter : Assessing uncertainty. Assurance. Reporting. Setting reduction targets and tracking changes over time. Appendices all... Rationale for providing sector guidance for DMS The Service Applications initially selected as requiring Sector Guidance on the Product Standard have been chosen largely on grounds of high customer demand and of broadness of coverage. DMS meet both criteria as they form a large portion of the ICT services delivered and required within business and, by their nature, are comprised of many underlying ICT services, e.g. desktop/laptop hardware, Local Area Networks (LANs), Wide Area Networks (WANs), datacentre hosted servers and other equipment, and ancillary services such as helpdesk and deskside support. Some of these underlying services are defined in the Introduction Chapter and the technical support chapters (e.g. the Hardware Chapter ). They are referenced in this chapter as appropriate to the context. page

. Establishing the scope of the product inventory The studied product for which the GHG assessment is performed relates to DMS, and covers the lifecycle of the whole service. The definition of DMS is aligned to the Gartner definition, which shows they can be broken down into some or all of the components shown in Figure. 0 0 Figure : The five stages of a product life cycle The Service Desk may provide / provides incident, problem, change and release management and a single point of contact for all it issues. The service desk may also provide remote assistance to users, and can manage and maintain any User self service provision allowing users to fix common IT issues (such as password lockouts) without the need to log a call. The End User Device service covers / may cover the provision and management of the desktop device, including desktops, laptops, thin client terminals and mobile devices through the full lifecycle (Material acquisition and pre-processing to end of life). During the device lifetime, the latest configuration management tools can be used to ensure a common standard across the IT estate and ensure the device is kept up to date with the latest security enhancements. This element may also include advanced third and fourth line (remote) support for desktop issues. End user devices encompasses the likes of laptops, desktops and services which are not covered in other segments such as desk side services or service desk (for example : software builds, third and fourth line support) Desk Side Services ensure that users have the right level of support, wherever they may be. Where Remote Assistance by the Service Desk (where provided) is not enough desk side support teams can visit the end user to help resolving any software issues, providing hardware fixes or replacements or providing support for any planned upgrades, changes or moves as required. The End User Infrastructure service can include the hosting (if required), management and ongoing optimisation of the infrastructure that supports the desktop service. this could include directory, email, file & print, mail relay, security and internet proxy services. The service can encompass elements expected from a comprehensive infrastructure management service including operating system and application updates, service backup and restore, availability management, capacity management, performance management, http://www.gartner.com/id=0 page

0 0 0 0 software and hardware support. This component can also include management and support for the desktop printer infrastructure. Service Delivery Management can include service level management, service reporting and strategies for continuous improvement providing a single point of authority and management interaction dedicated to ensuring quality of service.. Defining the functional unit The functional unit of DMS is the provision of a defined amount of desktop services to a number of supported users for a specified time period. This relates to how DMS are usually priced and sold by vendors. Thus the functional unit needs to define: The scope of the service provided. The number of users supported. The time period of the service. The scope of service should reference the elements of the DMS, as defined in Section.: Service desk. Deskside services. Service delivery management. End user devices (including make/model and usage profiles). End user infrastructure. There is the potential for apportionment where these elements are shared (e.g. End user infrastructure), and this is covered in the Section. Allocation and apportionment. The time period of the functional unit may be expressed as the life of the contract or per year (or both measures may be used). Typically the definition of the functional unit for DMS will be based on variables for example: The Magnitude: The number of users supported. For each user or user group a list of supported devices. Expected tickets per user (requests and incidents). The Duration: The length of service. And whether there is a refresh planned either prior to, or during the service. With usage profile within this (usually office hours). The Quality: The service levels which apply for the service. The type of engineering support (e.g. on site,mobile). The response/fix times for the support service (e.g. service desk,engineering). The geography of the service must also be considered and whether the service is delivered over several countries/geographies. However, this is covered under calculation where the (consistent) energy output is varied by the emission factor for each country. The calculation should take into account all of these variables. The magnitude, quality and duration parameters are all based on the technical performance characteristics and service life of the studied product. page

0 0 0 0 Examples of two types of DMS are provided below which demonstrate the breadth of possibility in terms of a DMS service (product). Many permutations of DMS are possible, two examples of which are below: Functional Unit, Example : Five year contract.,000 Users in total, split as follows: a.,00 Users office based (Each with a Desktop). b.,00 Users mobile (Each with a Laptop). Average of ticket per user per month (split 0. / 0. requests/incidents). Five office locations (all UK) 00 users in each. Local Desktop Engineering teams at each office. Mobile Desktop Engineering teams supporting mobile laptop users. Dedicated service desk (housed in one of the UK locations) x service. Local IT infrastructure. Standard Service-Level Agreements (SLA) (see below on explanations on how service levels can impact the environmental aspects of a DMS). Usage profile/hours of support cover (office hours 0:00 :00 Monday to Friday). Functional Unit, Example : Five year contract 0,000 Users in total, split as follows: a. UK: i.,000 users office based (each with a desktop). ii.,000 users mobile (each with a laptop). b. France: i.,000 users office based (each with a desktop). ii.,000 users mobile (each with a laptop). c. Germany: i.,000 users office based (each with a desktop). d. USA: i.,000 users office based (each with a desktop). ii.,000 users mobile (each with a laptop). Locations: office location : UK, France, Germany. office locations USA (00 users in each). Average of ticket per user per month (split 0. / 0. requests/incidents). Local Desktop Engineering team in each office location. Mobile Desktop Engineering teams supporting mobile laptop users in each supported country. Dedicated off site multi-lingual Service Desk (UK based) x. Dedicated off site infrastructure (two hubs, USA and Europe (UK)). Standard SLA, with enhanced SLA for 0% of the workforce considered VIPs (evenly split between the user groups). Usage profile (office hours, Monday to Friday 0:00 :00) (for each country). Examples of how calculations can be derived from example scenarios are worked through as part of Section. Calculating the GHG emissions. This framework can therefore be used as the basis for building any bespoke derivative DMS (Product), by changing the variables or adding to the examples provided. page

0 0 Service Level Agreements and Use Profiles Service Level Agreements (SLA) can impact the environmental aspects of DMS. Tight SLA with high penalties for failure will usually drive higher costs, bigger delivery teams and potentially more resource hungry infrastructure to support the SLA. All of this will contribute to greater GHG emissions. Examples of SLA impacts on GHG emissions: Service Desk Call answering SLA. If for example, the SLA is tough to achieve (e.g. % in 0 seconds), it will drive a bigger headcount on the desk and therefore greater emissions. If the Time to Close service level is tight, (e.g. hour to replace a laptop), then again this will almost certainly require a bigger team to deliver the service and a much bigger spares stock to supplement the immediate availability of replacement laptops. Again, this would increase GHG emissions. For Use Profiles a standard office hours type service, say 0:00 :00 Monday Friday will usually have a much lower emissions profile than a x service, where additional staff will be required in the support space, potentially on numerous shift patterns. This would, in most circumstances, increase the emissions.. Boundary setting.. Introduction For the purposes of setting boundaries, the component elements and deliverables of DMS must be defined. Physical products are an integral part of the service (in simplistic terms, an estate of printers, desktop PCs, laptops and/or thin client devices) together with the support, infrastructure and service delivery management functions. In that regard, DMS can be broken down into some or all of the following components: Service desk. Deskside services. Service delivery management. End user device. End user infrastructure... Defining life-cycle stages & identifying attributable processes The life cycle stages for DMS are shown in Figure below: page

0 0 Figure : The five stages of a product life cycle* *Source: Product Standard Material acquisition and pre-processing and production stages The first two stages, material acquisition & pre-processing and production are directly related to the physical ICT equipment used in providing the service (PCs, laptops etc). The assessment of these is described in the Introduction Chapter and in the Hardware Chapter. Product distribution and storage stage The third stage covers the delivery, installation and deployment of the DMS equipment and services. The definition of this stage (from the Product Standard, Section..) is as follows: The product distribution and storage stage starts when the finished studied product leaves the gate of the production facility and ends when the consumer takes possession of the product. The elements for this stage would typically include: Transportation of supported products from production facility to distribution centres. Transportation of supported devices from distribution centres to customer locations. Setting up a programme/project rollout team. Transportation of supported products to individual user location(s). Physical installation of products (for users and support teams). User acceptance of products. Training of users. Recruitment / Readiness of Desktop and Service Desk Teams. page

0 0 0 0 Use stage The use stage would typically include: Engineering visit assumptions emissions related to staff movements, with the most significant impact from car use. Tickets (incidents and requests) per user (based on stable estate, e.g. 0. to ticket per user per month). Emissions due to medium use of desktop/laptop equipment in a time period, for example 0 hours a day, Monday to Friday (The use profile). Impact of service desk, for example one service desk seat per 00 users supported (also based on tickets per user). Impact on supporting infrastructure and associated emissions/timings. Clarity around scalability on size and geographies (for different emission factors). Any impact of hardware refresh (for instance if the life/length of service is not intrinsically linked to the life of the equipment supported). End of life stage Section.. of the Product Standard indicates that: The end-of-life stage begins when the used product is discarded by the consumer and ends when the product is returned to nature or allocated to another product s life cycle. Depending on the circumstances specific to the DMS and local legislation on decommissioning of services and collection and disposal of relevant ICT equipment, the following will need to be considered: Collection of equipment. Recycling of equipment. Disposal of equipment. These are covered under the Hardware Chapter (including shared infrastructure equipment and service desk equipment where appropriate). The decommissioning / standing down of support teams at service end may not necessarily be considered a major factor to generation of emissions but screening should be employed to ascertain materiality... Developing a process map The example process map showing the five key life cycle stages for DMS is given in Figure. Material acquisition & pre-processing and production stages As previously described in this section, these stages are assessed in accordance with the Hardware chapter. Product distribution and storage stage This stage covers the program and project element of deploying DMS prior to go live. This could involve a number of processes, and a typical flow is depicted in Figure. The first process of this stage covers the transportation of the manufactured hardware from the production location to a distribution location. At this point (and the processes may well take concurrently or with overlaps as opposed to the sequential flow below), there could be further emissions, related to both transport and training, recruitment of project and service teams as well as user training and engagement. For example, if there are thousands of users over several countries, the emissions from the transport of equipment and the travel impact of project / engineering teams will need to be identified and could well be significant. page 0

Stage Stage Stage Stage Stage Material Acquisition & Pre Processing Production Product Distribution & Storage Use End of Life Taken From Hardware Chapter Taken From Hardware Chapter Delivery of Products (End User Devices / Infrastructure) to Distribution Centres Setting Up of a Programme / Project Rollout Team Transportation of Supported (physical) products from Distribution Centre to Customer Location Recruitment / Readiness / Training of Support, Engineering and Service Desk Teams Training / User Acceptance of Users Usage of End User Devices (by Use Profile) Service Desk Desk Side Services (Engineering) Collection and drop off of equipment (including transportation impact) Re-use / Recycling of equipment (including any transportation impact) Finished hardware / software products leaving the production gate and arriving at distribution centre Transportation of Supported (physical) Products to Individual User Location(s) Physical Rollout (Installation) of physical products (for Users and Support Teams) SERVICE LIVE End User Infrastructure Service Delivery Management Disposal of equipment (including any transportation impact) 0 0 Figure : Example process map showing the five key life cycle stages for DMS Use stage In example DMS such as those in Section. Defining the functional unit, the use stage is almost always where the biggest emissions will be made. The constituent parts (equipment, service desk, engineering and infrastructure) are the biggest and most significant contributors. The Service Delivery Management element may well not be significant and could be excluded as a contributor (for example if the Service Delivery Management function consists of a small management team). Screening is recommended to ascertain significance. End of life stage The final stage specifically relates to equipment, in that the decommissioning of teams will not be a significant consideration (but screening should be applied to check significance). Therefore, the hardware related steps cover collection, re-use/recycling and disposal along with their associated transportation emissions. Where there is an early refresh of equipment (compared to the expected life of the equipment) a proportionate credit may apply for embodied emissions if say equipment has a five year life expectancy, but is refreshed after three years, with the incumbent equipment being recycled into a different process. With regard to recycling (e.g. of components, metals or plastics) again there may be a credit to consider, however the credit with be almost negligible considering it is a small percentage of the recycling stage, which in itself constitutes only a tiny percentage of the overall (infrastructure) product lifecycle. Manufacturers product carbon footprint calculations may be a good source of information for this purpose, but even these may not be accurate or measured in the same way compared to peer manufacturers calculations. page

0 In reality, for any DMS service of any size, there would be, in the lifetime of the service, different parts of the estate being refreshed at different times and therefore there may be several lifecycles (and therefore Process Maps) active at different stages at any given time. For example, Servers may have a five year life, compared to a three year life for Desktops and Laptops... Non-attributable processes The following are considered as non-attributable processes for the assessment of DMS: For embodied emissions for engineers cars/transport, only the in use emissions of their vehicles will count. Lighting/heating for users of the DMS. Lighting/heating for support staff who are part of the DMS will be counted. Support staff non-business related travel (e.g. commuting)... Time boundary The time boundary for the assessment of DMS will typically be the length of the DMS service contract (e.g. five years), which is equivalent to the length of the use stage. The length of the end of life stage will relate to the disposal, recycling or re-use of the equipment in the scope of the DMS. 0 0 0. Allocation and apportionment [Note on terminology: The term allocation is used in the Product Standard to refer to two different situations: ) Allocation of emissions between two or more co-products produced by the same process (A co-product is where one co-product can only be produced when the other co-product(s) is also produced. For example, a soya bean processing plant produces both soy meal and soy oil). ) Allocation of emissions between independent products which share the same process or service. (For example, multiple products being transported in the same vehicle) The first type of allocation is not common for ICT products, but the second type is very common. In this draft document, the term apportionment is used for the second type of allocation to distinguish between the two. This use of terminology may be revised in future versions of this draft. It would be useful to have comments on what use of terminology is more useful.] Allocation relates to processes that produce co-products, and in DMS this is typically not relevant. However, the apportionment of emissions (where more than one product/service shares a common process) is relevant. ICT services today increasingly use shared infrastructure and shared support arrangements (e.g. service desk, remote support). The advent of cloud computing and desktop virtualization has accelerated this trend. Sharing can happen in various ways (e.g. between different services used by the same customer, or between the same type of service used by different customers) and this makes it highly likely that some apportionment will be required when assessing the GHG emissions of all but the most simple services. DMS are normally complex and wide in scope, with a number of common processes and shared infrastructure for which apportionment will be required. The most appropriate apportionment methods for DMS involve pro-rating of usage of the shared component. Table lists frequently encountered shared components of DMS and provides guidance on apportionment methods: page

Table Recommended apportionment methods for shared components Shared component Recommended apportionment method(s) LAN WAN Servers (e.g. email, directory, database, application) End user devices (e.g. desktop, laptop) Office-based support staff (service desk and desktop engineer) infrastructure Deskside services (e.g. break fix, IMACs) 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) Refer to Introduction and Networks chapters. Apportionment based on % of traffic or bandwidth. 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). 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). 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). 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). 0. Collecting data and assessing data quality.. Data collection approach Directly measured and activity data The Product Standard defines two typical methods by which data can be gathered: Directly measuring or modelling the emissions released from a process. Collecting activity data and an emission factor for a process and multiplying the activity data by the emission factor. The first method is not directly applicable to the calculation of GHG emissions for DMS (or any other ICT service), as all relevant data is activity data (predominantly electricity consumed, but also fuel used in service operations). page

0 0 0 0 Process and financial activity data The Product Standard further defines two types of activity data: Process activity data: Physical measurements from a process that results in GHG emissions or removals (e.g. energy consumed, distance travelled, or hours of operation). Financial activity data: Monetary measures of a process that results in GHG emissions. Data gathered in the DMS context is expected to be largely process activity data. General guidance on sources for emission factors is covered in the Introduction Chapter. The wide variation in electricity emission factors across the world is likely to have a major impact on the calculation of the GHG emissions of DMS supplied to a multi-national organisation compared with services based in a single country. Also, with the increasing take up of cloud-based services even previously single-country based organisations may find that the emission factors used for their on-premises equipment may differ widely from those used for the cloud-hosted services (as the datacentres may be in another country and/or powered by a different electricity mix from the grid average (e.g. high use of renewables)). Primary and secondary data Primary data are process data from specific processes within the product lifecycle. Examples relevant to DMS include: Kilowatt-hours (kwh) of electricity consumed by equipment used in the service. Litres of fuel used by service engineers while travelling to customer sites. Secondary data are process data not from specific processes within the product lifecycle. Examples relevant to DMS include: Kilowatt-hours of electricity consumed by equipment of the same general type used in the service, based on rule-of-thumb industry knowledge. Litres of fuel used by service engineers while travelling to customer sites based on data obtained from supporting similar services. The Product Standard stipulates that Primary data are required to be collected for all attributable processes under the financial control or operational control (as defined by the GHG Protocol Corporate Standard) of the company undertaking the product inventory. Primary data is clearly likely to be more accurate than secondary data and is always preferred. However, primary data cannot always be obtained, or may not be cost-effective to collect, and therefore secondary data can be used to fill the data gap... Data collection requirements Table identifies the data normally required to be collected for the GHG assessment of DMS, guidance on obtaining it, and notes relating to the data types and quality outlined above (see process map in Section. Boundary setting, for a definition of the processes entailed in each stage): Table Data requirements for the GHG assessment of DMS Data Sources Notes Emissions in Stages & (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 page

carbon ) for operational equipment (i.e. that is running the live service) including equipment used to run the service Emissions in stage (service set-up ) Emissions in stage - live equipment devices, servers), applying suitable apportionment factors for shared equipment. A range of sources, for example: Embodied carbon of equipment used in development and testing - as for stages and. In-use electricity consumption of equipment used in development and testing - as for stage. 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). The electricity consumption of all live equipment (with apportionment factor applied for shared equipment see Section.). 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). 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 0% 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 inuse (stage ) 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 live equipment below. A mix of primary and secondary data. The emissions contribution of this stage is likely to be small relative to that of stages, &, and may not turn out to be materially significant (less that % 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. 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 page

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 in Infrastructure Data Centers chapter. GHG emission factors Emissions in stage - WAN usage 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., then 0% 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. GHG emission factors need to be applied to the power consumption figures calculated for stage. 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. 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). page

0 Emissions in stage service support staff Emissions in stage engineering Emissions in stage (End of Life) The electricity consumption of all equipment used to support the service, (e.g. service desk and desktop engineers) ( embodied carbon covered under Stage & ). Data sources as for Emissions in stage - 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) 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. See guidance defined in Hardware Chapter. Contribution will depend upon a number of factors, such as geographical spread of the DMS and how centralised/ decentralised the architecture is. Primary data where measurable (e.g. supplier premises). If not, then proxy (secondary) data should be used. Primary data (using Defra fuel conversion factors). TBA. The following elements are excluded from the DMS GHG emissions calculation: Power consumed by non-ict usage, by users in offices and in homeworker or mobile users homes (e.g. heating, lighting). Emissions from manufacturing/usage of consumables (e.g. printer paper, printer ink). Emissions from the manufacture of engineering support vehicles. Travel of staff working on the service to their normal place of work (i.e. commuting). Emissions related to the construction of buildings which support the service.. Calculating inventory results In the context of DMS, the inventory items for calculation are listed in the Data Management Plan which in turn references the processes listed in the process map. Material acquisition & pre-processing and production calculations See guidance in the Introduction Chapter and the Hardware Chapter for these two stages. Product distribution and storage stage calculations Setting up of a programme / project rollout team. Transportation of supported (physical) products from distribution centre to customer location. 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. page

0 0 0 Training / user acceptance of users. Use stage calculations Use of equipment. Service desk. Infrastructure. Engineering. Service delivery management. End of life stage calculations Collection and drop off of equipment (including transportation impact). Re-Use / Recycling. Disposal. The Product Standard proposes the following calculation formulae for indirect emissions: GHG Impact (kg CO e) = Activity Data (Unit) x Emission Factor (kg GHG/Unit) x GWP (kg CO e/kg GHG) When direct emissions data has been collected, an emission factor is not required and therefore the basic calculation equation is: GHG Impact (kg CO e) = Direct Emissions Data (kg GHG) x GWP (kg CO e/kg GHG) In the context of DMS, the activity data could, for example, be in Kilowatt-hours (when considering energy use of hardware) or kilometres travelled, when considering driving distance of engineers. Please note: As the Global Warming Potential (GWP) is based on 00 years and the GWP for CO is, then this does not need to be multiplied further to get the CO e kg total. So the next section has accounted for this.. Calculating the GHG emissions This section provides an example calculation for a DMS and is based on the scope of Example from Section. (Defining the functional unit). Example Five year contract.,000 users in total, split as follows: a.,00 users office based (each with a desktop). b.,00 users mobile (each with a laptop). Average of ticket per user per month (split 0. / 0. requests/incidents). Five office locations (all UK) 00 users in each. Local desktop engineering teams at each office. Mobile desktop engineering teams supporting mobile laptop users. Dedicated service desk (housed in one of the UK locations) x service. Local IT infrastructure. Standard SLA. Usage profile (office hours, Monday to Friday). page

0 0 0 0 Material acquisition & pre-processing and production (and partial product distribution and storage) stages For the hardware related to this service, the calculation of the GHG emissions follows the guidance in the Introduction Chapter and Hardware Chapter so it is not demonstrated here. In this example we are assuming the following hardware:,00 Fujitsu Esprimo 00 desktops.,00 Fujitsu Lifebook S laptops. 00 Hewlett Packard P0 printers. Fujitsu TX00 servers. storage / backup arrays. switches. routers. As well as this, there is also the consideration for hot swap spares, in this example, we are assuming (from an embodied perspective) that there are an additional 0 desktops, 0 laptops and printers. The calculation for these stages will be assessed from the Hardware Chapter. If, for example, the total emissions were calculated as 0,000 kg CO e, then as the example was for a five year contract (the time boundary and the service contract term are in this case assumed to be the same as the expected life of the equipment), the figure can be amortized over the service contract term, therefore 0,000 kg CO e per annum. Product distribution and storage stage Process a) Setting up of a project / program project rollout team Setting up of a project or program team relates to recruiting, training and arming a team with relevant knowledge and tools (for example project managers, engineers and admin people) so they are ready to implement the rollout. In this example, the emissions relating to this are negligible and therefore ignored. In some circumstances, for example on global DMS contracts, there may be requirements to fly people around the world to recruit and train new members of staff, which would give some material value to calculating/measuring the impact. For this example it is assumed that the service provider will pull from a pool of already existing project people who are already trained, meaning there is little value in measuring or calculating the CO e impact. Process b) Transportation of supported (physical) products from distribution centre to customer location In this example, the equipment is already in UK distribution centres, but transport needs to be arranged to get to customer locations. Criteria applied to the example scenario are as follows: Distributed from one location. Regional locations for delivery (). Number of delivery vehicles required (0). Average journey (km) (00km). Type of vehicle articulated t-t. Loading % (UK average). Fuel is diesel. A calculation of the emissions for this example is shown in Table below: page

Table : Example of emissions from transportation of supported (physical) products from distribution centre to a customer location Total km travelled Direct GHG emissions per vehicle km* (kg CO e per vehicle km) Total direct GHG emissions (kg CO e) CO CH N O CO CH CH CO CH 0 0 0 0000 0. 0.000 0.00 0.,, *Source: Defra GHG Conversion factors spreadsheet, 00. The above calculation is taken from a Defra s spreadsheet which is freely available on their website. There are multiple options for transport, with different vehicle sizes and loadings. The unit of calculation in this case is kilometres, although litres of fuel consumed is also a method to calculate the emissions. It splits the emissions into the different GHGs and provides an answer in CO e. So for this section, the total emissions are, kg CO e. Process c) Transportation of supported (physical) products to individual user location(s) In some circumstances, there may be staging locations (for example a regional head office) within the customer environment and a further step is required to deliver kit to the individual locations. In this example, the kit has been delivered direct to the five office locations, so mobile users will have to attend their nearest office to collect their laptop. Therefore the emissions for this example are zero. Process d) Physical rollout (installation) of physical products (for users and support teams) In some scenarios this could potentially involve significant travel time in visiting a large number of sites or users. In this example, the users will be congregated at the five key locations during rollout. Assuming there are : rollout engineers. Rolling out on average 0 pieces of equipment per working day per engineer. With an average travelled distance of 0km per engineer per day. This means it would take elapsed days (rounded up) to finish the project, meaning return journeys in their cars for each engineer. This equates to,0km travelled for all engineers combined (in a diesel car,..0 litre engine). A calculation of the emissions for this example is shown in Table below: Table : Example of emissions from transportation for physical rollout of physical products Total km travelled Direct GHG emissions per vehicle km* (kg CO e per vehicle km) Total direct GHG emissions (kg CO e) CO CH N O CO CH CH CO CH 0 0. 0.0000 0.00 0.,, *Source: Defra GHG Conversion factors spreadsheet, 00. Again, the Defra resources are a useful source to use for calculations. So for this section, the total emissions are, kg CO e. page 0

0 0 0 Processes d) and e) Recruitment/readiness/training of support, engineering and service desk teams and training/user acceptance of users As this scenario is centralising the project from the five key customer locations, there are no significantly material emissions, so the calculation can either be ignored, or subsumed within the use stage (as a tiny proportion of the total). The reason for this is that the training window is small (a week), thus the emissions for hosting the training (heating, lighting and bespoke training staff commute to the five customer locations) will be tiny overall. In some circumstances, for example on global DMS, there may be requirements to fly people around the world to recruit and train new members of staff (or to train users) which would give some material value to calculating/measuring the impact. Use stage Usage of end user devices (by use profile) The example estate is split thus, by use profile. For each type of equipment, the power consumption per unit is multiplied by the number of units, and then the utilization factor is applied. This gives a total power consumption for all equipment in watts. This is then multiplied by the number of working days per annum and the usage per day in hours used per year, then divided by,000 to give the yearly energy consumption in kilowatt-hours. Finally the emission factor for the UK grid electricity is applied, to give the number of kilograms of CO e per annum. On global opportunities, there will, of course, be different emission factors dependent on the country. A calculation of the emissions for this example is shown in Table below: Table : Example of emissions from usage of end user devices Equipment type Fujitsu Esprimo E00 Fujitsu Lifebook S HP Laserjet P0 Number of units Power per unit (W) Average % utilisation Total power (W) Usage per day (Hrs) () Working days per annum () Total energy per annum (kwh),00 0 0%,00,000,00 0 0% 0,000 0,0 0 0 0%,00, Total,00,0 Electricity emission factor (UK grid power) () Emissions per annum Notes: = 0. kg CO e/kwh =, kg CO e () Each desktop is used on an average utilisation of 0%, hours a day, working days a year () Source: Defra GHG Conversion factors spreadsheet, 00 This summary is quite simplistic, averaging out the utilization factor for each equipment type at a top level. However, if there are specific user types or specific roles for equipment, where the function means a different use profile, then separate lines can be included. For example, if there were a subset of desktops which were involved in generating complex mathematical equations, for the most part hours per day, seven days per week, then a separate line can be included page

0 0 0 which accommodates a higher utilization, hours usage per day and working days per year for these devices. But they should be treated as an exception rather than the rule and only where the difference in emissions is significant enough to justify a separate inventory entry. Service Desk The service desk calculation is very similar to the usage by equipment calculation. So a similar table to above can be applied specific to the service desk if required. Alternatively, the equipment can be blended in as a line in the use stage. In this scenario/example, the service desk is on the customer site and the desktops for the desk () are subsumed within the figure for the Esprimo 00 s. If a service desk has a highly different use profile, for example their desktops are utilized at 0% and not 0%, this can be included as a separate section or line under the Use of Equipment process. Although there are no people related emissions for the Supported Employees served by the DMS in relation to facilities power/lighting/heating, the Service Desk, as a dedicated constituent part of the Service should account for both facilities power/lighting and any travel emissions. (This also counts for the local Deskside Engineering teams) Proxy Data on average CO e emissions per office based employee are included in Appendix XX. The preferred alternative to using an average is to use the energy bill from a physical location which houses the support staff. Then, either an apportionment of heating/lighting is made for the percentage of total floor space taken up by the service desk staff and dedicated service infrastructure, or by Full Time Equivalent (FTE) (or seats) of total FTE (or seats) in the building. There is no fixed rule on how this can be calculated, but it should be considered, explored and either included or excluded from total emission calculations with appropriate summary. Desk Side Services (Engineering) As this example, the DMS contain mobile engineering support for laptop users, and there is a requirement to calculate the engineering impact with regard to emissions. For demonstrative purposes as to how this impact could be calculated, using the example. Of the one ticket raised on average per month per user, 0% are resolved by the service desk or local desktop engineering teams. so the remaining 0% of tickets which require a mobile engineering visit will generate additional emissions. For,000 users, this means 00 visits per month. Taking an average of 0 km travel distance for each engineering visit, in a diesel fueled car, up to. l this comes to 0,000 km per month or 0,000 km per year. This equates to,kg CO e per annum as shown in Table below: Table : Example of emissions from transportation for mobile engineering support Total km travelled Direct GHG emissions per vehicle km* (kg CO e per vehicle km) Total direct GHG emissions (kg CO e) CO CH N O Total CO CH N O Total 0,000 0. 0.0000 0.00 0.,, *Source: Defra GHG Conversion factors spreadsheet, 00 Deskside engineering teams will also need to have the emissions of their facilities included in the calculation (much like the service desk). page

0 0 0 Proxy data on average CO e emissions per office based employee are included in Appendix XX. The preferred alternative to using an average is to use the energy bill from a physical location which houses the support staff. Then, either an apportionment of heating/lighting is made for the percentage of total floor space taken up by the Service Desk staff and dedicated service infrastructure, or by Full Time Equivalent (FTE) (or seats) of total FTE (or seats) in the building. There is no fixed rule on how this can be calculated, but it should be considered, explored and either included or excluded from total emission calculations with appropriate summary. End User Infrastructure This could include any infrastructure which supports the end users, discounting the end user devices which are covered under their own individual section. In this example, this would cover a number of servers, disk stores, backup devices and network equipment. Servers would cover such functions as mail, print, application, service management toolset etc. A similar table can be generated as for the End User Devices (Table above). An example is shown in Table below: Table : Example of emissions from usage of end user infrastructure Equipment type No. of Units Power per unit (W) Total power (W) Usage per day (Hrs) Working days per year Total energy per annum (kwh) Avge % utilisation Apportionment Adjusted energy per annum (kwh) Servers 0 0%,00., 0%, Storage/ Backup Array,000 %,000.,0 00%,0 Switches 00 %,0. 0, 00% 0, Routers 0 %,.,0 00%,0 TOTAL,0 0,, Electricity emission factor (UK grid power)* Emissions per annum *Source: Defra GHG Conversion factors spreadsheet, 00 = 0. kg CO e/kwh =, kg CO e Apportionment may need to be considered in this section, especially if infrastructure is shared between different organizations. In this example it is mostly ring fenced, but this organisation shares their service desk toolset (and server) with other organisations. Thus there is an adjustment using an apportionment factor of 0%. Section. (Allocation and apportionment) goes into greater detail as to methods of how this could be applied (e.g. through consumption of resources, or financial). In this case, the apportionment method is based on usage, (i.e. total number of tickets logged between the organizations). Since 0% of tickets come through the host organization, a 0%apportionment factor is used. End of Life Stage For End of Life, there will be a reliance on the Hardware Chapter. However, the collection and transportation of the infrastructure should be considered. In some circumstances, collection of legacy equipment takes place at the same time as the deployment of the new infrastructure, so there will be an overlap of activity (and therefore emissions) between products. page