IPC standard

[Audio] Table of contents 1 Introduction ........................................................................................................................ 3 2 Service Definition............................................................................................................... 4 3 Service Life Cycle .............................................................................................................. 5 3.1 Design ........................................................................................................................ 5 3.2 Deployment ............................................................................................................... 6 3.3 Run ............................................................................................................................ 8 3.3.1 Specify the Service ................................................................................................ 9 3.3.2 Performance of the Service ................................................................................... 9 3.3.3 Service Maintenance and Data Security ............................................................... 9 3.3.4 Follow up on Service Incidents ............................................................................. 9 3.3.5 Adjusting a Service .............................................................................................. 10 3.3.6 Funding a Service ............................................................................................... 11 3.4 Retire ....................................................................................................................... 11 4 Annex ............................................................................................................................... 12 IPC Service Management Handbook V13 2 Choose classification www.ipc.be ©2024.

[Audio] 1 Introduction Why is an IPC service management handbook important? IPC is a cooperative that exists to meet the needs of its members (primarily) and its non-members (who are mostly postal operators). IPC meets those needs by providing services mainly to members and, if it is for the members' benefit, also to non-members, both called participants of a service. IPC provides a portfolio of services to its participants. High level service quality is important, since well performed service contributes to the success of IPC and its members. Thus, IPC's services need to be provided in a professional manner and adjusted over time to always meet the members' requirements and remain secure as much as it is economically reasonable. Service participants should remain involved in the service responsibility. The participation and the usage of a service should strive for and achieve target level. The following definitions are applied in this document: Participants: Postal operator (member as well as non-member posts) or non-posts participating in the service. Users: Staff using and/or benefiting from the service. That would largely be the staff of the participants as well as from IPC. User Groups: Organised subset of the representatives of the participants of a service to specifically supervise the development of a service. In many cases this may only be an IPC member representative, due to the cooperative nature of IPC. Each user group is constituted on respective Terms of Reference (ToR). Service Owner: A member of staff at IPC, who is responsible for a specific service. The service owner manages the service throughout the cycle, predominantly in the run phase. The service owner is responsible for securing the funding, actively managing the costs of a service, and serving as the main contact for the participants. The service owner also provides important information regarding the development of the service, ensures targeted usage and participation, facilitates the changes with the participants, secures the data security and data privacy and organises the service of that service. The service owner is responsible for the acceptance of the service by the participants. Thus, service owners stay in close contact with the participants on a regular basis. The yearly service survey identifies potential issues. Service Business Needs Statement (SBNS): Explanation, in principle generated before developing a service, why participants would need a service and how they would benefit from it. Service Management Plan (SMP): Structured description of a service, updated on yearly bases and for internal use to oversee the development of a service. In the following document, IPC's services will be defined, and the service life cycle will be introduced. In the annex, important service-related documents are described, Appendix 1: SBNS, Appendix 2: Operations Level Agreement, Appendix 3: Terms of Reference, Appendix 4: SMP, required at different phases of the service life cycle. IPC Service Management Handbook V13 3 Choose classification www.ipc.be ©2024.

[Audio] 2 Service Definition What is an IPC service? A service is a means of generating value to the members by facilitating outcomes members want to achieve, while sharing ownership of the related price and risks. A service may accompany a tangible product (for example: the provision of performance dashboards) or it may have no tangible component (the facilitation of best practise sharing among members). Either way, a service meets a definable service participant need (or needs) – which means that if the output of a service and its value can be defined, and so can its inputs. In most cases, input and output can be measured to verify delivery. An IPC service combines the input, resources and procedure as well as output in a way that can be delivered repetitively in the same manner and along the same standards. Delivering a service consumes resources (e. g., staff, contractors, hardware, licences, 3rd parties). Therefore, all standing IPC services have a price. The price is a function of the estimated costs for the year to come, resulting from the service definition and standard (which determines the resources needed) and will change if either definition and/or standard changes. Ideally, all costs which can be allocated to a service, with an acceptable amount of effort, should be shared among the participants in a fair way, such as how often the service will be used and the subscription per participant. The methodology in which the price for a service is split among the participants would need to be agreed among participants in advance. The benefit of IPC providing services consists of generating value by resource pooling and synergies. These services should lead to new or better features, lower costs, more revenue, or higher reliability of logistics activity of the participating entities. Any investment into an IPC service or infrastructure should be better than any member doing it alone. Some services may offer a network effect, meaning that the benefit increases exponentially by the number of participants, because the benefit correlates with the number of links between the participants. The benefits generated by a service may vary between participants and should always be clear to the service owners and service participants and may change over time. A secondary benefit is shared infrastructure across services to increase synergies for the members. Any synergy between services may make cost allocation more difficult. The risks which come with the provision of a service needs to be managed by IPC. If the risks are substantial, IPC needs to inform the Board about the liability linked to the risks and ask for approval to perform the service, since the cooperation has no buffer to cover for liabilities. Meaning liabilities need to be carried by the members. A service, in which only IPC members will participate in, is called a Collectively Agreed Service. The costs are shared among the members. There are two criteria applied to determine Collectively Agreed Services: In members' interest to maximise the "network" and "pooling" benefits of having a range of Collectively Agreed services, subject to practical constraints (e. g. the geographical reach of a service). Preventing an individual member from "free riding" (i. e., benefitting from a Collectively Agreed service without actively participating in, or paying for, that.

[Audio] would be possibly invited to participate if it would be of benefit of the members. The costs are shared among the participants only. Developing services on the request of the members geared to all of them or a subset of them, on occasion including non-members. 3 Service Life Cycle How does IPC create, maintain and end a service? Unlike a project, which has a start and end defined right from the beginning, a service follows a well-defined lifecycle. IPC services (Both IT and non-IT services) follow a life cycle that ensures they are designed, deployed, run, and eventually retired effectively. The specific activities and focus areas can differ, especially given the technical nature of IT services versus the broader range of non-IT services. IPC has both and they are often combined. This simplified four-phase model provides a clear, high-level view of how a service is conceived, implemented, managed, and eventually retired, applicable to both IT and non-IT services. All four phases of an IPC service life cycle are described below. The first two phases would in most cases be supported by the IPC Project Management logic. For all phases, but specifically for the third phase, Continuous Improvement may be applied. 3.1 Design Objective: To conceptualise and create a comprehensive blueprint for the service, ensuring it meets the needs and expectations of participants and users while being feasible and sustainable and would fit within IPC's strategy. Key Activities: Needs Assessment: Understanding the requirements of the business, members, and potential participants of the future service. Service Design: Defining the service's structure, features, and functionalities, including any necessary processes, resources, and technologies. High level Risk Assessment: Identifying potential high level business risks while having that service and developing high level mitigation strategies. Quality Assurance Planning: Establishing criteria to ensure the service will meet predefined standards. In detail: The first step is to define the scope of the service which needs to be provided. The service scope could result from a completed project in which many elements of the scope have been previously defined and possibly a solution has been developed. However, the exercise of clearly defining the service scope – in terms of the service to be delivered – should always be done as a separate exercise carried out at the latest on completion of the project and certainly prior to the beginning of the service. IPC Service Management Handbook V13 5 Choose classification www.ipc.be ©2024.

[Audio] The scope must be defined in terms of: The participant need(s) that are to be satisfied and the value that will result. The resources and processes necessary to provide the value with a clear reference to service ownership, accountability, roles and/or responsibilities in the form of a Responsible, Accountable, Consulted, Informed (RACI) Matrix. The output is defined in the Operational Level Agreements (the exception may be a oneoff service but even these services tend to rely – at least in part – on the application of more than one standard process). The Key Performance Indicator(s) (KPIs) that will be used to measure the service delivery performance (quality, availability, participant satisfaction etc.) according to the specification within the scope. The estimated cost for the year will be charged to the participants of the service with a clear statement of what is included in the costs, and what is not – in terms of contribution and rebilling. Non-Members will get a markup on the estimated costs as a price. That markup is normally due to the additional taxes IPC must pay for non-member revenues. What is not part of the service and the boundaries of the service offering. o The validity period of the service: the date from which the service is/will be provided and its validity period (which could be "until further notice"). o The periodic review of the service with the participant(s) – the review period and the IPC Service Manager responsible for the regular review. Given the cooperative nature of IPC, the definition of scope is likely to involve close consultation with the potential participants for which the service is being designed. Participants that are not IPC members are not usually consulted in this process. It is of upmost importance that this consultation is carried-out thoroughly, which shall include the level of demand of the specific service and that is no doubt about expected the outputs and values of the service. This should apply equally to IPC's Collectively Agreed services (in which all members participate) and Selected Services (in which a sub-set of members and possibly non-members participate). The consultation period is vital within the design phase of the service but also required later, in the running of a service, to adjust to the needs of the participants in a dynamic environment. At this point the completion of a written and agreed Service Business Needs Statement (SBNS, Appendix 1) of what the service will deliver, and what constitutes successful performance will help to avoid potential disputes later. The key element of service set-up is the formation of expectations among users. Participants and the service manager must have a clear understanding of exactly what is to be delivered, and for how much. It is thus easy for participants (and IPC) to judge success, and for IPC to be clear that future variations to the service will impact on cost: either more, or less. The agreed SBNS should then be submitted to the IPC Directors' meeting for review. Collectively Agreed services are ultimately agreed by the IPC Board as they may affect IPC budget guidelines as set by the Board. 3.2 Deployment Objective: To bring the service from the {design.

[Audio] Key Activities: Implementation Planning: Developing a step-by-step plan to deploy the service, including timelines, resource allocation, and contingency plans. Infrastructure Setup: Establishing the necessary infrastructure, systems, and tools to support the service. Testing and Validation: Conducting tests to ensure the service operates as intended, identifying and resolving any issues before full-scale deployment. Training: Providing training to IPC staff and non-IPC users to ensure they can effectively use and support the service. Go-Live: Officially launching the service, making it available to the intended audience. Service agreement: An Operation Level Agreement (OLA) needs to be signed with the participants. An IPC Service has defined and agreed outputs that must be measured (by using key performance indicators) to verify service delivery performance ideally defined in the operational level agreements (OLA, somehow equal to SLA without liability). In detail: The first elements like Implementation Planning, Infrastructure Setup, Testing and Validation, Training and Go-Live are largely covered by the IPC project methodology. What is specific for an IPC service is the service agreement which is not covered by the Project methodology. An independent commercial company would normally have a commercial contract with a participant setting out the legal terms on which a service is supplied, the charges applicable to the defined service, and other charges that apply to any service variations. Part of the contract may be an Operational Level Agreement (OLA - annexed or as a separate document) stating the service delivery performance to be achieved against various KPIs. This is different at IPC. IPC has always tried to avoid the creation of formal contracts (including penalties and/or liabilities) between a member and IPC to avoid unnecessary legal fees, penalties, liabilities and lengthy negotiations (members will always try to impose their "standard" terms, possibly to the detriment of other members). The principle that IPC follows is to offer services to IPC members, providing maximum benefits with minimal cost and effort. Due to the legal structure, IPC cannot join Service Level Agreements with participants. This is because SLAs requires legal expertise for all parties, including IPC. The IPC legal expenses would be paid by the members, which at the same time would be paying their own lawyers to discuss/negotiate with IPC's lawyers. In the context of cost consciousness, this situation should be avoided. In addition, any SLA penalties payable to any member would have to be paid by the members since IPC works with zero profit and zero loss. IPC should also not assume responsibility for liabilities because all members as shareholders could potentially become liable to one participating post using the service. Rather the approach has been – and should continue to be – the creation of agreed Terms of Reference (ToR) documents that lays out the agreement between IPC and the participants of the specific service. The structure of the ToR is illustrated in the Appendix 3. IPC often handles data from participants within their services. IPC will then act as a data processor. The oversight of the data owner respectively of the data controller is with the participants. Since at IPC has many services the oversight for all services is organised in.

[Audio] Data Protection Oversight Committee (DPOC). The oversight shall be covered by the Terms of Reference. Such ToR are not commercial contracts, but rather set out agreed outputs, targets and operating methods and procedures. It is essential that the documents are referred to as "Operating Guide", "Handbook", "Annual Operating Plan", "Terms of Reference" or some such, and not "Contract" or "Service Level Agreement", to avoid the rigidities and complexities of members introducing legal advice. Equally important in an IPC context is an agreement about the principles of how the price of the defined service will be charged to the participants. For example, this may be based on a cost allocation determined by member shareholdings or member traffic volumes, or a combination of these. If participants do not use the service at the same frequency, it is preferable to charge per cost driver– which entails making a forecast of use overall to ensure that revenue covers costs. Specifically at the start of a service, usage could be uncertain, then a split key along member shares or equivalent may be more appropriate. In most cases, it should be sufficient that such documents are discussed, aligned and approved in the service user group. The outcome should be documented through the meeting minutes. If the service has no user group, then a brief consultation with a representative sample of users will be sufficient. The same approach has been taken with larger non-members although for most of the smaller non-members there is often no documentation of the service to be provided. This approach will now begin to change – in part driven by the demands of Data Protection and the risks/liabilities that EU legislation now imposes upon IPC and thus members. In the future. non-members may be required to enter commercial contracts to participate in services. 3.3 Run Objective: To ensure the ongoing delivery, performance, and continuous improvement of the service, while meeting user expectations and operations level agreements (OLAs). Ensuring the uptake of the service by as many members as possible and increased usage. This might also require changes to the scope of the service. It includes the management of the user group supervision this service. Key Activities: Monitoring and Performance Management: Continuously monitoring the service's performance, availability, and reliability. Incident and Problem Management: Handling any issues that arise, minimising service disruptions, and identifying root causes to prevent recurrence. Change Management: Managing updates, upgrades, or modifications to the service to adapt to changing needs or technology. Service Desk Support and Communication: Providing assistance to users, gathering feedback, and maintaining open lines of communication. Optimisation and Improvement: Regularly reviewing the service and implementing improvements based on performance data and user feedback. IPC Service Management Handbook V13 8 Choose classification www.ipc.be ©2024.

[Audio] In detail: IPC services often require IT systems (which may serve more than one IPC service) for their proper functioning. IT maintenance windows may occur, which – depending on the business criticality of the IPC system for the user – are tolerable for the participating members and non-members. 3.3.1 Specify the Service Every IPC service needs a Service Management Plan (SMP) which contains at least the elements described in Appendix 4. Parts of it might be generated out of the SBNS. Many more parts need to be specified newly. The approval of the SMP from the IPC Directors' is required. Therefore, the service owner will submit for any new service a SMP to the IPC Directors' meeting for approval and, when approved, register the service in the Service Catalogue and make sure that it is included in Jira. All SMPs should be updated by the service owners in January for the current year's perspective. 3.3.2 Performance of the Service The dashboard will be presented to the respective director on a bi-monthly basis for review. It contains the following information: The service manager will provide the participants of the respective service monthly. The service manager will provide the usage, as defined in the SMP, monthly or at least every quarter. For specific services like INTERCONNECT, this is required monthly. The service manager must provide the information about service performance for each KPI defined in the SMP. The PMO team, based on the input from IPC Service Owners, will prepare a Service Performance Dashboard. 3.3.3 Service Maintenance and Data Security For IT maintenance and Data security, the ongoing costs should be considered. If no more detailed information is available, the following costs should be applied from the creation of the service or the change of a service: IT Maintenance cost: 15 % of the service investment costs Data Security cost: 5 % of the service investment costs These costs add up to 20% for IT maintenance and Data security in total per year. Continual service improvement (CSI) is required to identify and execute opportunities to make IT processes and services better, and to objectively measure the effects of these efforts over time. 3.3.4 Follow up on Service Incidents Quarterly ticket reviews on incident and service request tickets shall be performed between the business owner, the technical product manager and the Service Desk to ensure the service continues to be optimised based on the incident and service request. IPC Service Management Handbook V13 9 Choose classification www.ipc.be ©2024.

[Audio] During the fourth quarter of the current year, the IPC Technology department will provide the planned maintenance windows of the service for the forthcoming year. The service owner then needs to communicate and align the planned maintenance windows with the service participants or user group by the end of the current year. The participant representatives are responsible for the proper communication of the maintenance windows within their respective organisations. 3.3.5 Adjusting a Service Change is often necessary to adjust to the dynamics of the needs of our members, as well as the dynamics of the markets. Therefore, it is key to rethink the service offering and to enhance or reinvent the service. This should happen in consultation with the participants. The source of changes to a service (and thus to the SMP) will be varied (for example, IPC itself, user oversight committees, service and change requests submitted through IT service desks) and will depend upon the magnitude of the change proposed and the nature of the service provided. A service request is generally something that can be encompassed within the service definition without any significant change in the resources required or the output of the service. A change request is a formal request for the implementation of a significant change to add a new service, change an existing service (i. e., a change in the service definition, output or resources) or to remove a service from production. It needs to be approved by the Business Owner and the level of detail depends on the size and likely impact of the requested change. Every service and change request must be documented (e. g., Jira ticket). A change request must be initially assessed in terms of: Does the request fall within or outside the service definition? If outside, but linked to the existing service, there will probably be a monetary consequence for the participant. Is the change request sufficiently large or complex to justify an implementation project? If yes, there will be resource and priority consequences. If the change request impacts IT applications or any other IPC service, then for approval and planning follow the IPC Change Request Policy. Are resources available to implement it? Is the cost of delivering the change request covered by the funding of this service or will the costs be charged back to all participating members, if they agree to it, or only the member(s) requesting it? The action to be taken and likely timescale for every change request (unless immediately resolved) must be promptly fed back to the user that raised the request. If the change is outside the SMP and is to be implemented, the SMP must be updated to reflect the new outputs, activities, processes, KPIs and service charges. Changes of this magnitude must be agreed and signed-off by the participants. Many changes (particularly those originated by IPC) can be predicted. These will be listed in the pipeline document in the SMP. It will be presented bi-monthly to IPC Directors for review. IPC Service Management Handbook V13 10 Choose classification www.ipc.be ©2024.

[Audio] 3.3.6 Funding a Service Services are fully budgeted on a yearly basis by the business owner. The responsibility is with the service owner at IPC to secure the funding for the respective service in a reliable way. This information will be provided in the Business Plan input sheets, e. g., if after some years the technology is outdated and not supported any more by the provider, the service owner, with the support of IT, needs to explain the situation to the participants and secure the funding for the renewal, since IPC does, if not decided differently, not provision for the renewal of systems. The same applies for data security or data privacy risks. If those risks need to be mitigated, it is the responsibility of the service owner to convey the message to the participants and secure funding. The service owner and IT representatives at IPC for a service are jointly responsible for an effective costing of a service. Services should also not increase the complexity of the IPC service and infrastructure landscape more than necessary. Complexity reduction should always be the aim of IPC staff. The IT representatives are responsible of managing the run and maintenance costs on the lowest level possible. 3.4 Retire Objective: To safely and efficiently phase out the service when it is no longer needed or is being replaced by a new service, ensuring minimal disruption to users. Key Activities: Decommissioning Planning: Developing a plan for retiring the service, including timelines and communication strategies. Data Migration or Archiving: Transferring, securing, or archiving data associated with the service as needed. Communication: Informing participants and users about the retirement process, including timelines and any necessary actions on their part. Service Shutdown: Gradually or fully shutting down the service, ensuring that all dependencies are managed, and any remaining resources are released or reallocated. Post-Retirement Review: Conducting a final review to document lessons learned, close out any outstanding issues, and formally conclude the service's lifecycle. In detail: Although a service could theoretically continue forever, common sense suggests that it will eventually be substituted by something better, transferred to another organisation like the UPU or that demand for the service will disappear. The way in which a service is withdrawn can have a profound effect upon the perception of participants – and even upon potential participants. The way in which a service should be withdrawn is to: Trial (with explanations) the closure well in advance of the formal notification period. Respect the formal notice period and give written notice. Agree with participants when they will cease to use the service (which may be in advance of the formal termination date). Try to accommodate participants that wish to continue for a limited period after the formal closure date – on condition that those participants bear any costs. IPC Service Management Handbook V13 11 Choose classification www.ipc.be ©2024.

[Audio] Establish a cut-off date beyond which change requests (other than those that can be immediately resolved) will not be accepted. Establish any monies owing by, or to, participants and settle these amounts within one month of the formal closure date. Ensure that IPC resources devoted to the service are re-assigned (when possible) to other IPC activities. Define the period of running the service with no support (if applicable), allowing the participant(s) a grace period to replace this service with an alternative. Remaining assets may need to be handed over to future owner. 4 Annex Appendix 1: Service Business Needs Statement Why would participants need this service and how would the members benefit from that service? In principle, this would be described in the Service Business Needs Statement (SBNS). The SBNS is an internal document, created by the service owner at the start of a potential service and it must not be longer than two pages and would need approval be the IPC management. The content is likely to be helpful also in the dialog with members and/or potential participants. The SBNS should follow the structure below: Background: Describe the context (including the link to the IPC strategy), reasons for, and origin of the service(s) being specified in this Business Needs Statement. State whether the solution is a follow-up for a service or service group, a replacement for an existing service, or a new, self-contained service. Needs: A simple description that encapsulates the key participant business needs. Benefit: How will the service cover the needs of the participants. Summarize the benefits. For example: o network benefit for participants o response to users' and participant needs o efficiency Participants: Is the service aimed at IPC members and/or non-members? In either case, which ones? Have the target participants agreed the service in principle, or have they already agreed to finance part or all the service? Are the users the same as the participants (i. e., the paying parties)? Usage: Usage is how many service delivery instances are used by the participating posts. A service is not functioning well, if it is not used according to the expectations stated in the SBNS and SMP. Thus, the need to define usage as it applies to every service, specifically since there is not a single definition that would correctly apply to all services. There is a mixture of both quantitative and qualitative measurements that can apply, depending upon the service being considered. Further, there may be a need to change the type of usage for a specific service, depending upon where it stands as to the maturation of its use. Quantitative measures should be used wherever possible; given that qualitative measures are subject to too much opinion and variability. Quantitative measurement of usage will IPC Service Management Handbook V13 12 Choose classification www.ipc.be ©2024.

[Audio] range from simply the number of participants using a service to more detailed measurements that measure the extent to which a service is being used. Maturation of a service also plays a role in the selection of a usage measure. In the first stage of development there may only be a need to have a qualitative measure that ensures the service has been properly implemented and made available to participants. As maturation progresses for a service it may be possible to utilise more specific operational data. It should be always broken down by participant. Process: Summarise the process to provide the service or the significant functions that it performs or enables users to perform. This section should clearly define the inputs and outputs of the service. If applicable, define the IPC systems and/or reports that will be used to provide the service. Resources: An initial estimate of the resources required for the process necessary to perform the service, e. g., "X" FTEs per year (divided into IPC employees and contractors) at a cost of "Y"; non-staff costs per year. State any assumptions e. g., estimate based upon "Z" users. Provide an estimate of infrastructure requirements and costs required for the service (if applicable) based on data volume estimates. Performance: Describe possible Key Performance Indicators (KPIs, maximum three) which would measure service delivery performance (and thus relate to service features and participant benefit). Specify how the service performance will be measured. Cost split: A qualitative outline on how the costs could be split among the participants and the status of the agreement with the participants (who, when and what). Appendix 2: Operations Level Agreement Operations Level Agreement (OLA) Performance targets, and output level to be achieved (to be described in the OLAs), taking account of maintenance windows. Appendix 3: Terms of Reference Part of the deployment of a service is having a joint understanding of the service delivery between IPC and the participants of that service. At IPC it's called Terms of Reference (ToR). The ToR is created by the service owner, reviewed and approved by the CFO, and aligned together with the user group. The ToR is adjusted, whenever a change appears. It is stored under I:\IPC Services\Terms of Reference. The ToR contains the following elements: Scope: Scope of the service. Framework: Operating method and rules. Roles: Roles of each participant and IPC. Maintenance: Maintenance windows (to be described in the OLAs), and the procedure for updating these. KPI: Reference to the OLA. Change request: Process for managing changes; if the change request impacts IT applications, IPC policy for change request management should be followed. Cost distribution: Charging structure. Participant admission: Procedure for admitting new participants. IPC Service Management Handbook V13 13 Choose classification www.ipc.be ©2024.

[Audio] Notice: Notice periods if all or some participants, or IPC, wish to withdraw from the service and way in which costs will be redistributed to remaining participants. User Group: Members of the user oversight committees of that specific service and review cycle. Appendix 4: Service Management Plan How is the service specified, and the specification regularly reviewed? The Service Management Plan (SMP) is an IPC internal document, created by the service owner, latest when the service has been deployed, for the current year and updated on the yearly basis at the beginning of the year. It is first signed off by the responsible director and afterwards by the management. The Service Management Plan (SMP) contains at least the elements described below: Date: The date when the SMP is approved by IPC members / Participants / Participant user group and comes into effect. IPC Responsible Manager (Day-today): State the position title(s) that will be responsible for "business-as-usual" delivery (in all aspects, including revenue) of the service and, if different, its development. IPC Responsible Manager (Development, if different): If the service is being developed, i. e., there is a running project, please include the name of the IPC Manager responsible for the development. IPC Service Support Person: IPC person providing this service for the participants. Please include the name of the key person for single point of contact. Benefit creation: The key qualitative and quantitative benefits will be summarised for the to the point communication with the participants and potential participants. Detailed benefits and values generated by the service should be reflected in the SBNS. Participant Contact Person(s): Single Point of Contact per Participant for this service. Brief description of service: A couple of sentences on the service offered helps in setting the context. Scope: As documented during the service set-up (as outlined in section 3 of the Service Management Handbook). Participants: List the participants (including any distinction between those that are charged for the service and those which obtain the service for free. For the latter, note why the service is not charged). Participant admission: Describe the procedure for admitting new participants to the service. Service window: Specify the times, time zones, and days of the week when the service is provided and detail the support relevant to the service. For example: o Telephone support: 07:00 to 19:00 on (Belgian) working days. o Calls received out of these hours will be forwarded to a mobile phone and best efforts will be made to answer / action the call, however there will be a backup answer phone service. o Email support: 7am to 7pm on (Belgian) working days. Emails received outside of these hours will be collected, however no action can be guaranteed until the next working day. IPC Service Management Handbook V13 14 Choose classification www.ipc.be ©2024.

[Audio] o Onsite assistance guaranteed within 72 hours during business week. o Maintenance windows to be included on specified dates / cycles. Service Desk: Description of all processes to be supported by the Service Desk (SD). o Description of Service Requests supported by the service desk (user management mandatory). o Description of Service health checks to be performed by the SD. o Incidence / Response plan for the service. List of activities: It is vital to list every activity that is required to deliver the service. There should be no ambiguity, and the list should be consistent with scope. Usage: What is the definition of usage per participant, displayed at least quarterly or monthly? Capacity: How many service delivery instances are envisaged, and in what period (per hour, day, month etc.)? Are there any peaks/troughs? Processes: Map the processes (including the service request and change management process) involved in delivering the service. Dependencies: List other services (including the relevant parts of IPC's IT systems) and suppliers that support this service, and how these relate to the processes that deliver the service. Training: What, if any, training is required for IPC staff/Participant users, and how frequently for operating the service? Resources: List the FTEs and non-staff resources (meetings, travel, legal fees, training, software license costs, server costs etc.) required to keep the service up and running. Convert the resource cost into the service budget and business plan forecast. Roles: Any service will have various roles, (e. g., analysts, coordinators, team leads, managers, users, members and non-members and administrative support). Map the activities listed to the roles, indicating the accountabilities and responsibilities. KPIs: List the indicators that will be used to set targets and measure the service delivery performance against target. Describe clearly the source of the information that generates each KPI and the frequency with which the KPI is produced. These are to be included within the Service dashboard. Targets: Describe the target participants and the target usage of the service for the current year. Compliance: List the IPC policies or external standards (e. g., ISO) to which the service delivery should conform and make sure that these are reflected in the service processes. Roadmap: A document which lists changes and activities that are planned (i. e., not aspirations), the source of these proposals, and tentative dates for introduction. Risks: Identify any risks that may affect service delivery and how these risks will be mitigated. Notice period: Define the notice period if participant(s) decide to withdraw from the use of this service or IPC decides to stop the service. Define the notice communication process to participants, users, user groups. Charges: Describe on what basis the price of the service are shared among participants and at what frequency prices are invoiced to participants. Oversight: List the participant user bodies (if any) that oversee the delivery of the service, and write-down the Terms of Reference of that body. Also list any IPC internal committees concerned with delivery of the.

[Audio] Participating member responsibilities: specify the responsibilities of the participants(s) in support of the provision of this service: i. e., reasonable availability of participant representative(s) when resolving a service-related incident or a request, provision of information or data when requested, provision of access to participant(s) systems if required. Personal data: List the items of personal data (if any) which the service requires for its operation and the organisations to which this data is to be transferred. Confirm that the said organisations have either signed the IPC Personal Data Protection Agreement or will be able "click and accept" it before access via an IT application is permitted. Dispute escalation: If the oversight committee cannot reach agreement, describe to whom (or to what body) any disputes within the oversight committee (or between the oversight committee and IPC) will be escalated. Communication plan: There may be several levels of communications — manager level, administrative level, with suppliers and others. List them all and note any repeated meetings – e. g., quarterly meetings with the service user group. Also write a "headlines from hell" communications plan – if the worst happens (the service is interrupted for short or long periods) what is the plan for communicating with users and how should they be reassured? Operating Guides, Standards and agreements between participants: Note where performance targets are documented (e. g., for INTERCONNECT they are found in the INTERCONNECT Operations Framework Agreement, which is an agreement between participating posts, and in the minutes of meetings of the INTERCONNECT Operations Steering Committee and its sub-groups), the role that IPC plays in documenting the performance targets, standards etc., and the date of the last update. Data: Data usage aligned with Data Governance Board regarding data sharing and processing agreements, IPC Service Management Handbook V13 16 Choose classification www.ipc.be ©2024.