Systemation Standard Software Support Services – TIBCO EBX
This Standard Software Support Service Agreement is intended to stipulate the agreements between End User and Systemation AES BV, hereinafter referred to as “Supplier”, with respect to the services provided by Supplier in the context of the application support services for the EBX MDM platform. In addition to the description of the services, the SLA includes key performance indicators and standards for the scope and quality of the services delivered. Per indicator, the corresponding standard is included.
The included service level standards are minimum standards in application support to which Supplier must comply.
These Standaard Software Support Services include:
- Providing improved versions (updates);
- Providing new versions (upgrades);
- Providing of Patches;
- Providing support via a professional helpdeck fort the TIBCO EBX Platform.
The Standard Software Support Services do not include:
- Services of any kind in relation to the generated application (s). An additional Service Level Agreement (SLA) must be concluded for this
The Standard Software Support Services Agreement commences on the Effective Date of the End User License Agreement (‘EULA’) between End User and Supplier. Unlesss Parties agree otherwise, the Standard Software Support Services Agreement ends on the end date of the EULA.
Changes to this Standard Software Support Services Agreement can be proposed and discussed by the contract managers of the Supplier and the Customer. Proposed changes must be recorded in writing and signed for approval by the contract owners of the Supplier and the Customer. Changes to this Standard Software Support Services Agreement will be recorded on the change sheet included at the beginning of this document.
The change sheet will in any case contain the following information: Change date, new version, who entered the change, (sub) paragraph in which the change took place and the change (s) concerned. This change sheet is initialed by both parties, after which the change has become part of these Standard Software Support Services.
This Standard Software Support Services Agreement will in any case be evaluated by the contract managers of the Supplier and the Customer every year, at the latest one month before the anniversary of the Effective Date of the EULA and adjusted where the Customer deems it desirable and / or necessary.
If a change in the objects and/or the service levels, to which this Standard Support Services Agreement relates to, has a major impact on the scope and/or complexity of the Standard Support Services, the Parties may mutually agree to adjust the agreement. When the desired adjustments have an impact on the size and/or complexity an additional Service Level Agreement (SLA) will be coposed. Additional costs will be charged for this SLA.
In the context of this Support Services Supplier hosts a professional service desk. The Supplier service desk is responsible for the following activities:
- During office hours (08:30-17:00), support desk staff will monitor the registration of incidents;
- 3rd line* support for incidents within agreed service windows (09.00 tot 17.00 uur) on Dutch officedays in relation to the TIBCO EBX platform
- The scope of this Standard Support Agreement is limited to the TIBCO EBX platform only;
- In case it is deems necessary to include support from End User or third parties, the response times/resolving time will not be part of the calculation of various Standard Services parameters.
- End User will, as far as possible, assist in the resolution of malfunctions and the implementation of work-around solutions, provided that continuity and performance is ensured. Supplier stays responsible for solving issues.
- All disturbances outside the scope of this agreement are explicitly not part of the agreed service levels.
- Out of scope activities will only be charged to End User, after prior approval by End User on scope, cost and time, validated by a Purchase Order.
The End User is responsible for fort he following first line maintenance and support activities:
- Front-office for general user questions
The End User is responsible for the following second-line maintenance and support activities:
- Technical application management
- Functional application management
- Performing patch management and upgrades on operating systems, databases and the Standard software;
- Monitoring and maintaining the infrastructure, such as the network, databases and operating systems and the standard software;
- Optimize the interaction with the Supplier with regard to expert questions and other forms of third-line support (“Single Point of Contact” between the Customer and the Supplier);
If deemed necessary, one of the Parties may schedule a meeting on an ad hoc basis. Supplier creates minutes of this meeting and maintains an action register of the Support Services meetings and these will be submitted for approval by all Parties involved.
For the purpose of effective and efficient support, the following prerequisites need to be met:
- Incidents are normally signaled in the production platform. The malfunctions and incidents are solved in the development environment and promoted to the Test environment. End User will, after testing, deploy the solution on the Acceptance and the Production environment. If the cause is not immediately found, Supplier will make efforts to reproduce this in the development environment in close cooperation with End Cusomer’s MDM application manager.
- De procedure Incident Management will be followed (please find below);
- For questions about incidents, refer to the incident number provided profided by Supplier
- Supplier does not make any changes outside the agreed service windows without prior notice of End User;
- When Supplier has to make changes, the Supplier issues a quotation based on estimation to the best of its ability. This proposal when executed will be invoiced time and material based.
- The schedule for the guaranteed minimum available Supplier capacity for the End User in this period is based on regular Dutch office days and office hours from 09:00 to 17:00. For public holidays officially recognized in the Netherlands, additional agreements must be made to meet End User’s need.
- Incidents are reported using Supplier’s ticket system. If there is a (possible) Prio 1 disturbance, End User’s representative will also report this by telephone. When a (possible) Prio 1 disruption is detected by Supplier, Customer’s contact person will be informed.
For both the service desk and application support, the services are delivered by Supplier within a so-called time frame. For the different services, this time frame is defined as follows:
|Service window||Monday: from 09.00 to 17.00
Tuesday: from 09.00 to 17.00
Wednesday: from 09.00 to 17.00
Thirsday: from 09.00 to 17.00
Friday: from 09.00 to 17.00
|Servicedesk||· Reporting incidents and questions can be done 24 hours a day from a helpdesk ticketsystem directly into Supplier’s ticket system.
· A Priority 1 incident has to be reported by the MDM application manager by telephone +31 (0)88 3031122 during office hours.
|Additional opening hours|
|Availability outside the indicated timeframes has to be requested by End User with a notice period of preferably 8 (eight) workdays, but at least 5 workdays. An additional charge for this service will be agreed upon separately.|
The purpose of the incident management is to resolve disruptions in End Customer’s business processes. End Customer should experience as little disruptions as possible and should resume normal operations.
- Fix the incident by correcting the issue, defining and implementing a work-around or making an appointment to implement a change;
- A resolution of a Priority 1 or Priority 2 incident can exist in creating a workaround. If so the incident will be downgraded to a Priority 3 incident;
- Create a change request in the change management process
- Create a problem report if multiple incidents are registered with the same cause;
- Alignment and communication with parties responsible for managing relevant ICT infrastructure components and application areas that are not covered by this Standard Software Support Services Agreement.
The notifier of an incident determines the urgency and impact of the incident. This leads to an Priority-level. When the impact and urgency are low there will be a lower priority logged, but when both the urgency and impact are high, then the priority is also high.
In the table below there is a definition of the Priority-level (Urgent, High, Medium and Low).
|The following are Priority Definitions that should be used to determine business critical, high, medium or low priority of issues|
|1 Urgent||Definition: The loss of a critical business service or function for the organization and no workaround is available.
· Business and Financial Exposure – Application failure creates critical business operations and major financial impact
· Work Outage – The application failure causes the client to be unable to work or perform some significant portion of their job.
· Number of Users Affected – Application Failure affects majority of the users
|2 High||Definition: The partial or limited loss of a critical business service or function.
· Business and Financial Exposure – Application creates serious impact to business operations and major financial impact
· Work Outage – The application failure causes the client to be unable to work or perform small portion of their job at some locations
· Number of Users Affected – Application failure affects some of the users
|3 Medium||Definition: Degradation or potential loss of a business service or function, but service continues (with or without a workaround).
· Business and Financial Exposure – Application failure causes minimum business and financial exposure
· Work Outage – The application failure causes the client to be unable to work or perform minor portion of their job and able to complete most of their jobs
· Number of Users Affected – Application failure affects only a few (one or two) users
|4 Low||Definition: Incidents impacting individual end-user or small groups, an inconvenience to the business
§ Business and Financial Exposure – Application failure causes no business and no financial exposure
§ Work Outage – No loss of service
§ Number of Clients Affected – Application failure affects only a few (one or two) users
Per Priority there are different response times and resolution times. In this table there is a distinction between Response-time and solving time (resolution delivered).
|Priority Levels||Response Time||Solving Time (workours/workdays)|
|1 Urgent||< 1 hour||< 8 hours|
|2 High||< 4 hours||< 16 hours|
|3 Medium||< 2 days||< 5 days|
|4 Low||< 5 days||n/a|
Hours means business hours (working days from 8.30 till 17.00 hrs). For Critical Issues (P1) Systemation will continue working on a solution or workaround, after business hours.
|Percentage of incidents resolved within Response Time||80% *|
|Percentage of P1 incidents resolved within Solving Time||80% *|
* Measured over the past three months within the agreed service window
Escalation is applicable when:
- Agreements, service levels and/or quality of services delivered by Supplier to End User are violated by Supplier;
- Severe disruptions occur in the service offering or when for a longer period deviations exist or have a high likelihood to occur on the main KPI’s;
- Incidents are not resolved within the resolution times, regardless priorities set.