Service Level Management. Configuring the SLM of Xpert.NET

Transcription

1 Service Level Management Configuring the SLM of Xpert.NET

2 Table of Contents 1 Introduction Purpose of the Document Addressees of the Document Remarks on the Content of this Document Overview Structure and Mode of Operation of the SLM Contract Service Priority Escalation Times Coverage SLA Assignment Outside of the SLM CMDB Ticket Management Configuring the SLM Creating and Managing Contracts Creating New Contracts Copying Existing Contracts Managing Contracts File Attachments Service Level Agreements in Other Modules Ticket Schemas Ticket Mail2Ticket Account Services and Service Transactions CI Schema CI Early Warning System General Creating New Rules Details Rules Configuration Example Table of Contents 2

3 6 Statistics and Change Management Statistics Change Control Table of Contents 3

4 1 Introduction 1.1 Purpose of the Document Xpert.NET is a very dynamic help desk solution that can be configured in various directions. Daily routine and experience have shown that users get acquainted with the most important modules and configurations quickly. Nevertheless, some questions regarding the functionalities of the Xpert.NET modules often remain. Thus, the individual modules cannot be used to their full potential. This document is supposed to help you with the proper configuration of the Service Level Management (SLM). For this purpose, the configuration and use will be described step by step, just like the overall integration into the Xpert.NET system. 1.2 Addressees of the Document This document only addresses administrators of Xpert.NET. 1.3 Remarks on the Content of this Document This document describes all the functions of the Service Level Management module and its extensions. Nevertheless, the range of the module may vary due to configuration, licensing, and version. If you miss certain functions listed in this document in your Xpert.NET installation, please contact our support directly. 1.4 Overview Via the Service Level Management (SLM), real external or internal service agreements can be recreated on your Xpert.NET system. The Service Level Management is responsible for the standardization and surveillance of the IT services. Here, the customer s requirements are turned into service offers by the IT organization, the services are planned and agreed upon in contract. The process also ensures the continuous surveillance of the agreed on Service Levels as well as the Service Reporting. The underpinning contracts with service providers as well as Operational Service Agreements ensuring internal services are subject to the SML as well. This is one of the central Service Level Management processes, with an extensive relevance for customer satisfaction and the professional supervision of the IT organization. The SLM module provides contracts, services, coverage, priorities, escalation times, and contract times for configuration and set-up of the escalations. Introduction 4

5 2 Structure and Mode of Operation of the SLM The Service Level Management can be designed as a simple system of rules or as a complex set of rules, which can influence each other as well. In order make the configuration of the SLM module clearer, the individual objects and their modes of operation will be explained in this chapter. Figure 2.1: Structure of the objects in the Service Level Management 2.1 Contract A contract in the Service Level Management can be equated with a real contract, which has been concluded with a service provider (internal or external). Thus, for every real existing contract, a respective contract can be reproduced and managed in Xpert.NET. There is an option to record miscellaneous data for every single contract. Some of this data is optional and not directly relevant for the application or the end user. However, the service times, the beginning, and the end of the contract as well as its validity within the service times are essential and must be specified. 2.2 Service A contract within the Service Level Management can consist of any number of services. These services can differ completely from each other and will be generally recorded in the real contracts in the same way. For example, there are different services defined within a contract for the desktop computers of a support department compared to the servers, on which the customer or other external data is stored. 2.3 Priority Within every service, an arbitrary amount of priorities can be created. Priorities define the gravity of the occurring problem. When defining the priorities, one should keep in mind that they often can be regarded very subjectively. Structure and Mode of Operation of the SLM 5

6 Example An employee is not able print on his workstation s printer any more. Subjectively, this would be a big problem for him and he would set its priority to High. If he, however, has the additional option to use another network printer, the actual priority would have to be regarded as much lower. 2.4 Escalation Times For every defined priority, an arbitrary amount of escalation times can be defined. These times specify, up to which point in time a certain reaction to an occurred problem is expected. Actions in the context of workflows, which will be executed whenever the requirement is not met until the lapse of time, can be linked to these escalation times (e.g. an sent automatically to the supervisor or a ticket s reassignment can be configured here). Example For example, the Reaction time is defined as the escalation time. It specifies, how much time is allowed to elapse, until a reaction to a ticket has to occur (e.g. a ticket has to be accepted by the first level support within four hours of its creation). The first option to solve this problem is to grant the user the right to define the priority of a ticket immediately on ticket creation within the Ticket Wizard himself. This would, however, lead to a subjective prioritization. In order to automatically assign services and priorities of the SLM instead and thus avoid the subjective perception of priorities by the user, the SLM can be configured to define via coverages, which services and priorities will be applied in certain ticket/user/configuration item constellations automatically. 2.5 Coverage The coverage specifies, which service and priority contained within is to be used as soon as a ticket is created. This coverage can refer to different sections within a ticket. This can be seen in the following example: The coverage of the service is only set for the ticket schema Incident. Structure and Mode of Operation of the SLM 6

7 Figure 2.2: Coverage of the service The coverage for the service Standard Support is set on the ticket schema Incident and on the entry Configuration Problem in the ticket field that allows for categorizing the incident. Figure 2.3: Coverage of the priority Critical Structure and Mode of Operation of the SLM 7

8 When a ticket is created with this schema, the following will happen: If the category Configuration Problem is selected in the ticket, the service Standard Support will be set automatically. If another category is used in the ticket (which does not have a separate coverage), another service will be used. Affected User/Affected Group The coverage can be defined on certain users or user groups. For example, there is a user group working on a very important project at the moment. Consequently, this user group can be defined as coverage and as soon as user from this group creates a ticket, the defined priority will be used. Figure 2.4: A coverage on a group Ticket/Ticket Field The ticket field coverage has been already illustrated briefly in the previous example. There is an option to define a coverage referring to normal ticket fields here as well. Figure 2.5: A coverage on certain ticket field content For this purpose, the mode of searching for the specified text within a ticket field can be defined. In the figure above, the search parameter Contains has been selected for a ticket field; e.g. no matter where the specified word can be found in the field, this coverage will be used. If ticket fields are pre-filled via a list, it possible to use values defined in the list instead of individual, freely-definable words. If the Service Portfolio is activated, process schemas, services, and service transactions can additionally be defined for a coverage here. CI/CI Schema Here, a configuration item (CI) can be used as a coverage area. A CI schema can be selected with or without the additional delimitation of a CI type. When the ticket is created and linked to a CI of the selected type or schema (during creation), the coverage will be applied. Structure and Mode of Operation of the SLM 8

9 Figure 2.6: A coverage on a CI type and a CI schema A certain CI can be used for the coverage as well. Then, the coverage will only be used, if exactly this selected CI has been linked to the ticket (during creation). 2.6 SLA Assignment Outside of the SLM In Xpert.NET, an SLA can be assigned outside of the Service Level Management as well. For this purpose, nearly all objects have a tab referring to the SLM. The available assignment options are different for every object. For example, only a priority can be assigned in a ticket schema. In a CI, on the other hand, it suffices to define a service, the assignment to a priority is not obligatory. It depends on how limited the selection of the SLA is supposed to be during ticket creation. The assignments performed outside of the SLM will, however, still be visible in the SLM and can be managed there CMDB CI In a configuration item, an assignment to a service or a priority can be performed on the SLA tab. The priority is optional here. However, a contract has to be set for an expense additionally; for a priority, a contract as well as an expense is required. Figure 2.7: SLA configuration in an individual configuration item As soon as a ticket is created, which is then linked to this CI (during creation), the service and/or priority specified here will be used for the ticket. Structure and Mode of Operation of the SLM 9

10 CI Schema The assignment of a service or a priority can be also performed on a CI schema in the CMDB configuration. It is not necessary to specify it down to the priority level here as well; the assignment of a service will suffice. When a ticket is created, which is linked to a CI of the respective CI schema, the SLA configured here will be used. Thus, it is possible to link all the CIs of a schema to an SLA, so that not every single CI has to be edited individually Ticket Management In the configuration dialogue of a ticket schema, a tab named SLM Priorities can be found as well. The name already hints at the fact that here - in contrast to other objects a specific priority has to be defined. The definition of a service does not suffice. Whenever a ticket is created that cannot be assigned with a service and a priority definitively, a fallback mechanism will be applied. For this, the last ten tickets matching the priorities in question will be consulted. The coverage used most frequently for these ten tickets will then be used for the new ticket as well. Thus, the creation of tickets without a priority due to a lack of distinct assignment will be avoided. Structure and Mode of Operation of the SLM 10

11 3 Configuring the SLM The Service Level Management can be accessed via Settings -> Service Level Management -> Service Level Management. The various Service Level Agreements, coverage ranges, services, priorities, and escalation times can be managed here. Figure 3.1: The configuration page of the SLM 3.1 Creating and Managing Contracts The SLM overview displays all contracts already created and provides the option to create new contracts via the New Contract button top right. Via the Actions menu on the left, already existing contracts can be copied and deleted. A double click on an existing contract allows for editing it subsequently Creating New Contracts For creating a new contract, a New contract button can be found. A click on this button opens a new dialogue window, in which the first information on the contract can be entered. Until the first saving, only the Settingstab will be visible and usable here Copying Existing Contracts In order to copy an existing contract, it has to be highlighted on the contract list. The menu item Copy in the Actions menu has to be selected subsequently. Now, a new dialogue will open, in which the new contract s name can be entered. Hint Coverages and file attachments will not be copied when copying a contract and have to be recreated manually! Managing Contracts In order to display the contained information of an existing contract and change it if necessary, a double click on a contract on the SLM overview opens the properties dialog of each contract. In the following sections, the individual configuration pages and parameters will be described. Configuring the SLM 11

12 Preferences This tab allows for entering and managing general information on the contract. As long as the contract has not been created yet, this is the only tab that can be filled in. Figure 3.2: The settings tab of a new contract The following information and options can be configured here: Name: The name for the contract for identifying it distinctly. If multiple languages have been activated, the localization buttons are displayed. Service times: Defines operation or contract times for the contract. Often used times are already included by default. If the service times mentioned in the contract are not available here, new service times can be created via the Edit button on the right. The service times configuration and management will be explained in the following section. Start: Defines the date, on which the contract comes into effect. End: If the contract is temporary, it is possible to define the contract end via the date and time feature. For this purpose, there is a Specific date? checkbox. If it is enabled, the date and time can be defined via date selection field and the drop-down list for times just like for the beginning of contracts. If the option is deactivated, the contract is to run indefinitely. Cancellation period: In case of a contract with an indefinite validity period, there is a cancellation period which must be adhered to in most cases. It can be deposited here; however, the value entered here is purely descriptive and has no further tasks. Validity period of the contract: The validity period of the contract defines the periods of time, in which this contract will be applied to certain items automatically. Pre-set time values are available here. If these deviate from the times agreed on in the real contract, they can be edited via the Edit button on the right. If all of the information has been entered correctly, a click on the Save button creates the contract. The remaining tabs will now be available. Service Times Service times are used for defining operation and contract times and for reproducing a contract s validity coverage. For this purpose, an arbitrary amount of service times can Configuring the SLM 12

13 be defined, which then will be used for computing the individual escalation times. These service times can be saved in contracts as well as in individual services. The service times do not only define the general operation times, but they also include special leave days. Such days (e.g. fixed and moveable holidays) override the contract times. They can be entered as specific days in a year (day, month, and year) or as annual days (day and month). An example for such a contract time consisting of general service times and specific special leave days could look as follows: Day of the week Start End Start End Monday 08:00 12:00 13:00 17:30 Tuesday 08:00 12:00 13:00 17:30 Wednesday 08:00 12:00 13:00 17:30 Thursday 08:00 12:00 13:00 17:30 Friday 08:00 12:00 13:00 17:30 Saturday Sunday Special leave days Start End Start End Day of the week January 1st January 2nd May 1st Good Friday Easter Monday Ascension Day Whit Monday August 1st December 24th 08:00 12:00 13:00 16:00 Monday - Friday December 25th December 26th December 31st 08:00 12:00 13:00 16:00 Monday - Friday Hint In the automatic SLA assignment for new tickets, only services and priorities with a start date before the ticket creation date and an end date either in the future or undefined will be taken into account. Contracts with an expired validity period will be generally not taken into account. Creating and Managing Service Times Everywhere a service time or validity period can be selected, service times can be managed or newly created as well. All All All All All All All All All All Configuring the SLM 13

14 Right next to the drop-down box, the Show service times button is displayed. In the dialog it opens, the already existing service times can be displayed and new ones created. Figure 3.3: A click on the Show service times button opens the dialog for managing service times Figure 3.4: Service times can be managed here individually In this dialog, new service times can be created as well as existing ones edited. Service time: This drop-down box allows for selecting already existing service times. The buttons right next to it have the following functions (from left to right): Edit service time: Via this button, the currently selected service time s name can be edited subsequently. New service time: With this, a new service time can be created. Show list: This button shows a summary of all already configured work times and all created special leave days of the currently selected service time. Delete service time: Via this button, individually created service times can be deleted. However, this is not possible for the already existing and pre-set service times! Time zone: Here, the matching time zone for the current service times is configured. Below, working time blocks can be configured via the two tabs Weekdays and Special days. Configuring the SLM 14

15 Weekdays Week days (Monday to Sunday) can be provided with individual work time blocks (from-to-settings) or the settings of the preset week days can be applied. Under Week day, the designated day can be set in order to define the start and end time of the new block via New work time block. Figure 3.5: Creating a work time block Figure 3.6: Alternatively, settings can also be taken over from pre-configured days Special days The configuration of special days is different than the configuration of usual week days. As soon as the tab Special days has been opened, the desired special day list can be selected. After the list has been selected, the section below will display the service times using this list. The three Configuring the SLM 15

16 buttons next to the list provide the options to either create a new list, edit the current list, or delete this list. Figure 3.7: Editing the work times for a special day When editing the current list, the above dialog is displayed. Under Working times, either existing special days can be edited or new special days can be created. If a new special day is created, the work times can adopted from existing entries. Otherwise, proceed as follows: Click on the New special day button. Subsequently, a new dialog will open, in which the desired date can be entered. The date specification is to be entered in the DD.MM format for annually recurring special days or in the DD.MM.YYYY format including a year for special days occurring only once, irrespective of the selected language in Xpert.NET. After the creation of the special day, either settings from other, already existing special days can be applied or individual work time blocks can be defined. Configuring the SLM 16

17 Details On this tab, various details like Provider, Customer, Description, and Comments can be specified for the contract. These values are purely descriptive attributes for the contract and do not have any further impact on it. Figure 3.8: Various descriptive details on contracts can be entered here Services On this tab, the various contract services including their service times, coverages, and priorities are defined. By clicking on New service top right, new services can be created. For this purpose, a new dialog will open, in which the information and settings for the respective service can be entered. Alternatively, this configuration dialog can be accessed via a double click on an existing service. Settings In the service preferences, the following options can be modified: Figure 3.9: Configuration in the settings of an expense Name: Specifies the name of the service. If multiple languages have been activated, the localization buttons are displayed. Configuring the SLM 17

18 Service times: Defines the time periods the ticket with the current service can escalate in. The configuration is similar to the service times of a contract. Service validity time: Defines the time periods a ticket has to be created in for this specific service to be applicable. This configuration is performed analogously to the configuration of the service validity time of the contract. After a click on the Save button, the remaining tabs of the dialog will be available. A service cannot be used until at least one priority has been created for it. Details On this tab, various information like Description, Customer responsibilities, Provider responsibilities, Services, and Comments on the service can be entered. This information only consists of descriptive attributes on the service and has no further impact on it. In doing so, service descriptions can be created, edited, and deleted via the three buttons next to the service selection box. Coverage Coverages are necessary for the automatic assignment of the right SLA service to a newly created ticket. After a click on New Assignment or a double click on an existing coverage in the table, a dialog will appear, in which all of the elements of a coverage line can be edited. At least one array has to be filled in (Affected user/group, Ticket/Ticket field, or CI/CI schema). Affected user/group: In this field, either the user s login name or the group s name can be entered. If the respective name is found, the user or group will be displayed with the complete name in the field. Alternatively, the user browser can be used via the magnifying glass icon, in order to search for the correct user or group. Ticket/Ticket field: Depending on the coverage type selected here, different fields will be displayed. The following coverage types are available here: Ticket/Process schema: A ticket/process schema can be selected as well as a field and the required field content. In addition, it is possible to select a matching operator for certain field contents (e.g. text field) and thus define whether the ticket s field content is to be equal or unequal to the specified value, for example. Service: This option is only available, if the Service Portfolio has been activated. A service can be selected from the Service Portfolio. Every ticket created via a service transaction that can be found below the service selected here fulfills the condition. Service transaction: This option is only available, if the Service Portfolio has been activated. A service transaction can be selected from the Portfolio. Every ticket created via this service transaction fulfills the condition. CI/CI schema: In these fields, either a configuration item or a configuration schema (CI schema) and a matching configuration schema type (CI type) can be selected. Configuring the SLM 18

19 Configuration item: Here, a configuration item (CI) can be selected from the CMDB. If a ticket is linked to it, the condition is fulfilled. CI schema/ci type: Here, existing CI schemas and the corresponding types can be selected. If a CI linked to a ticket belongs to schema and type, the condition is fulfilled. Please note It is possible to define a configuration item as well as schema and type. If both criteria are set, it is important that this results in a usable assignment and the settings are not mutually exclusive (configuration item A belongs to schema B, however, configuration schema C has been selected). In doing so, an arbitrary amount of coverage areas can be defined. The individual coverage areas may overlap as well. If no coverage area is defined, all priorities defined within the service will still be available for the automatic assignment to tickets albeit with a lover rank. If, however, at least one coverage area has been defined and no coverage is compatible with the new ticket, none of a service s priorities can be assigned to the ticket automatically. There are several assignment criteria: All criteria that are combined within a coverage are linked via an AND relation. A ticket has to meet all criteria in order to make the coverage area relevant for this ticket. If multiple coverages with various criteria are defined, they are linked via an OR relation. When using the assignment criterion User/group in a coverage, an SLA service with the main group of the user included in the coverage area will be taken into account preferentially. If a ticket field, in which a user-defined date is to be entered, is defined as a criterion and this ticket field changes subsequently, the calculation of the completion and escalation times will be triggered once more. Example for an AND Relation In one line of the coverage range, Supporter has been specified as the affected group and Scope = Lotus Notes as a ticket field. This coverage area will only be relevant for a ticket, if the affected user of the ticket is a member of the group Supporter and at the same time the ticket field Scope has the content Lotus Notes. Configuring the SLM 19

20 Example for an OR Relation The individual lines of the coverage range table are linked to each other via an OR relation. For the service to be assigned to the ticket, the defined coverage area of at least one line has to match the ticket. In the first line of the coverage range, only the group Supporter has been specified as an affected group, in the second line, only the ticket field Scope = Lotus Notes has been specified. This coverage range will be relevant for a ticket, if the affected user of the ticket is a member of the group Supporter or the ticket field Scope has the content Lotus Notes or both applies. Priorities On the Priorities tab of the service of a contract or a Service Level Agreement (SLA), the priorities can be found in a drop-down list. Below, all already existing escalation times of the selected priority are displayed. Figure 3.10: The drop-down box allows for selecting the priorities. The buttons next to it are used for editing, recreating, and deleting existing priorities Priorities within a service are used for discerning the relative importance of a ticket based on its urgency and impacts. A priority defines the maximum necessary time requirement for the actions to be executed, which is represented using various escalation times. Escalation Times The escalation times, which are displayed for each configured priority in the list below the priorities selection, represent the core of the SLA. They define the times after ticket creation, until which certain statuses have to be reached. For this purpose, any number of escalation times can be defined for every priority. Please note A priority is only configured sensibly and usable, if at least one escalation time has been defined for it. Escalations are used for observing the working times agreed upon with the customer in a Service Level Agreement. For instance, they can determine the time period, in which a member of support has to accept a ticket (reaction time) and then solve it (solving time). These times can be computed absolutely as well as relatively, based on the service times. Configuring the SLM 20

21 The configuration dialog for an escalation is opened when a new escalation time is created or via a double click on an existing escalation time. Figure 3.11: An example escalation time The following criteria for an escalation time are to be defined: Name: The specific name of the escalation time. The localization buttons are displayed, if multiple languages have been activated on the system. Symbol: A symbol to facilitate the identification of the escalation time can be defined here. Escalation symbols can be displayed in the ticket or activities list later on. Reference date: There are a total of four options available as a reference date: Ticket creation: The escalation time is calculated based on the time of ticket creation. Ticket start: The escalation time is calculated based on the start of work defined in the ticket. It is mandatory to coordinate this option with the workflows. If the SLA calculation starts before the start of work has been entered (manually or automatically), it is not possible to calculate a reference date. Ticket completion: The escalation time is calculated based on the completion date defined in the ticket. This option has to be coordinated with the workflows as well. User-defined: As soon as this checkbox is activated, a user-defined expression can be entered here, which reads out the reference date, e.g. from an attached CI or a ticket field. Configuring the SLM 21

22 Figure 3.12: It is necessary to set the content for the fields Start date and Completion date in the ticket first Offset: The offset defines a period of time that is set off against the reference date in order to define the escalation date. The predefined offset options here are Manual input (manual input of a timespan in HH:MM:SS format; example: 03:30:00) and Work duration (estimated effort that can be specified in a ticket under Expenses). Finally, it is necessary to define whether the offset is to be added to the reference date (= forward) or subtracted from it (= backward). Please note If the offset is subtracted from the reference date, the escalation progress bar underneath the ticket view cannot be used. Show as total running time: Defines the timer that can be displayed as a total escalation timer (escalation progress bar). Service times: Defines the service times the calculation of the escalation times is to be based on. Via the checkbox right next to it, this can be automatically be read out from a CI attached to a ticket, which matches a certain CI schema and type. Required ticket status: Defines the ticket status to be reached by the ticket for it not to escalate with the current escalation time. Escalation workflow: If the necessary ticket status has not been reached and a ticket escalates, it is moved to the escalation workflow specified here. Apply changes to existing tickets: If this checkbox is activated, all changes made to the escalation time will be applied to all existing tickets that are affected by this escalation time automatically. File Attachments Here, an arbitrary amount of file attachments for the service can be uploaded, e.g. in order to describe it more clearly or to provide additional material for it File Attachments On this tab, file attachments to the contract (e.g. the contract s text in wording or in multiple languages) can be uploaded. After all the information relevant for the contract has been entered, the contract can be updated via a click on the Save button. The contract is now ready and can be used. Configuring the SLM 22

23 4 Service Level Agreements in Other Modules In addition to the automatic assignment of contracts via the coverages, they can, of course, be added to ticket schemas, individual tickets, Mail2Ticket accounts, service transactions, CMDB schemas, and individual CIs manually as well. 4.1 Ticket Schemas A contract can be assigned to a ticket schema via Settings -> Ticket Management -> Ticket Schemas. If a ticket schema is opened here, a list of preferred SLM priorities can be assembled from different contracts and services on the SLM Priorities tab. These will be taken into account for every ticket created via this schema. This list will be used whenever no automatic selection can be made by the system. Further information on this topic can be found in the Ticket Management documentation. 4.2 Ticket In individual tickets, escalation times and priorities can be modified afterwards as well. For this purpose, the ticket actions Edit escalation time and Edit escalation priority are required, which can be configured in the respective ticket schema. Further information on this topic can be found in the Ticket Management documentation. 4.3 Mail2Ticket Account SLM priorities can be defined in Mail2Ticket accounts as well. These priorities will be used whenever the assignment of a priority for a Mail2Ticket ticket via the coverage areas has no clear result. Detailed information on the configuration can be found in the Messaging and Collaboration documentation. 4.4 Services and Service Transactions Both the services and the service transactions provide a tab for Service Level Packages, where Service Level Agreements can be specified. Those can be used, if no consistent contracts can be saved for the individual process schemas. 4.5 CI Schema CI schemas can contain particular SLA priorities as well. Their configuration can be found under Settings -> Configuration Management (CMDB) -> CMDB Schemas. If an SLA service or a priority is specified here, it will be taken into account for new tickets, whenever the respective CI is linked to the ticket. Further information on the detailed configuration can be found in the CMDB documentation. 4.6 CI Individual SLA priorities can also be defined in individual configuration items (CIs). The user wanting to create or change the priorities is required to have the right View on the SLA Service Level Agreements in Other Modules 23

24 tab within the respective CI. Further information on this topic can be found in the User Management and CMDB documentations. Service Level Agreements in Other Modules 24

25 5 Early Warning System Via the early warning system, rules can be created that allow for sending notifications to certain users automatically in order to inform them about a tendency within the ticket creation, for example. On the one hand, it is possible to create early warning rules monitoring the ticket creation in the background and triggering an early warning workflow as soon as a certain number of tickets on a particular topic has been created. On the other hand, early warning rules can also be created as templates individual users can subscribe to and personalize in order receive prompt notification s. However, other workflow plug-ins can be also used in early warning workflows, which can only be addressed via the early warning system. Detailed information on this topic can be found in the Workflow Management documentation. 5.1 General The early warning system allows for detecting early on that many tickets on a specified topic have been created within a certain time period, for example. Thus, countermeasures in order to ensure compliance with the Service Level Agreements can be taken early on as well. Warning rules configured in the early warning system can be subscribed to by users in their user settings, provided that they have been configured as a template, and then can be customized individually. Whenever the conditions of an early warning rule are fulfilled, a particular early warning workflow is triggered, which sends an to every subscriber or a predefined person, for example. The management of the early warning system can be found under Settings -> Service Level Management -> Early Warning System. Figure 5.1: Overview of already created early warning rules Early Warning System 25

26 5.2 Creating New Rules The New rule button for creating new rules can be found top right. The following dialog allows for defining the details for the new early warning rule as well as the conditions that have to be met Details General information on the warning rule can be defined on the Details tab. The dialog here is divided into the two arrays Basic specification and Time frame. Basic Specifications Various general specifications for the early warning rule can be made here. Title: Defines the name of the new rule. If multiple languages are available, an individual name can be entered for every language. Active: As soon as the rule has been configured completely and is needed, this checkbox can be enabled. The early warning rule will then be applied by the system. Template: If this option has been activated, the early warning is available as a template. Users can subscribe to it and customize it individually, as soon as they are assigned with the access rights for this rule in the User Management. Further information on this can be found in the User Management documentation. Further affected user: This checkbox defines whether users are added to the respective tickets as further affected users as soon as they subscribe to the rule. Workflow: An already created early warning workflow has to be specified here. Early warning workflows require special early warning workflow plug-ins. Additional information can be found in the Workflow Designer documentation. The early warning workflow should contain either the plug-in Send message or Send early warning message, via which an can be sent using a specific message template (message schema). Figure 5.2: The simplest early warning workflow possible Ticket schema: The ticket schema the early warning rule is to be valid for is specified here. Time Frame In the Time frame array, the frequency (the number of tickets) and the time period, in which the tickets need to be created for the rule to apply, have to be defined. Frequency: The number of tickets is specified here. Available options are: Equals, Greater than/equals, and Greater than. The ticket quantity has to be entered in the next field. Duration: The time period the tickets have to be created in has to be entered here. Early Warning System 26

27 5.2.2 Rules On the Rules tab, additional rules are set, which have to be fulfilled for the early warning rule to be seen as fulfilled and a message to be sent. For this purpose, ticket fields have to be selected as well as a logical operator and a required field value for the ticket field. Only ticket fields of the previously selected ticket schema will be displayed here. If an early warning rule is supposed to be valid for multiple ticket schemas, the configured rule can be simply copied and customized for the respective other ticket schemas subsequently. Equal: The value in the ticket field has to match the entered one completely for the rule to be fulfilled. Identical: Multiple tickets, which fulfil the rule in all other respects, are compared to see whether they all have the same, identical value in this field. Starts with: The value of the ticket field has to begin with the specified value. After the early warning rule has been completed, activated, and subscribed to by users, it will be triggered automatically as soon as the entered values have been reached. For example, if a specified amount of tickets on one topic has been received, an will be sent automatically to all users having subscribed to the early warning rule. 5.3 Configuration Example The following section will exemplify the creation of a simple early warning rule as template. A message will be sent automatically as soon as one ticket per hour has been created for a customer. Here, every user that has subscribed to the rule can select individually, for which customer a ticket has to be created for the rule to apply and a notification to be sent. Preparation The following items have to be already available and/or configured in order to be able to create an early warning rule: A ticket schema the early warning rule can be applied to. A message template of the type Early warning system (see Messaging and Collaboration documentation). Early Warning System 27

28 Figure 5.3: A template of the type Early warning system is necessary A messaging schema of the type Early warning system, in which the message template is integrated. It is advisable to have selected Subscriber as a recipient (see also Messaging and Collaboration documentation). Figure 5.4: Additionally, a corresponding messaging schema of the same type is required A workflow of the type Early warning workflow containing a plug-in, which can send a message via the messaging schema (see Workflow Management documentation). Early Warning System 28

29 Figure 5.5: Example for a very simple early warning workflow Configuring the Early Warning Rule A new early warning rule can now be created via the early warning stage. Users are supposed to be able to use the rule as a template later on. Thus, the option Template is enabled. As the rule is not completed yet, it remains disabled for the moment. Figure 5.6: The newly configured early warning rule Next, a simple rule is configured, in which only one ticket field containing the client s name is to be evaluated. As the rule is intended as template, the field value is not specified and thus can be filled in by each user individually. Early Warning System 29

30 Figure 5.7: The early warning rule can be customized later on, if the field value has not been specified After the rule has been completed, it can, after a click on Save, be marked as active and then saved once more. In the next step, the permission for using the early warning rule has to be set (see User Management documentation). Figure 5.8: Setting the required permission Now, the rule can be used by every user of the groups that have been granted the permission for the use of the early warning rule. Via the user settings, the early warning rule can be now subscribed to. Figure 5.9: In the user settings, the rule can be subscribed to... Early Warning System 30

31 As soon as the subscription is saved, the template can be customized by every user individually. Figure 5.10:...and customized individually Early Warning System 31

32 6 Statistics and Change Management 6.1 Statistics By Maik Wisatzke Date Doc-ID DOK Version Status Approved Replaces version Release date Valid from Immediately Valid until Cancellation Document name Service Level Management _EN 6.2 Change Control Version Date Executed by Comments Maik Wisatzke Created Maik Wisatzke Adjustments for version 3.4/miscellaneous revisions Marco Mehl/Maik Wisatzke Advice for copying of SLA-Contracts added. Advice for configuring service times added Maik Wisatzke Linguistic revision, new figures for escalation times, adjustments for version Maik Wisatzke Complete linguistic revision, Adjustments for the service portfolio Maik Wisatzke Revision of the early warning system Maik Wisatzke New design adapted, new figures Alexander Schmidt Updates for 2015 Statistics and Change Management 32

33 Copyright c 2015 isonet ag, Engineering und Beratung, Zürich This document is intellectual property of isonet AG and protected by copyright. It must not be saved, copied, duplicated, or passed on photo mechanically, digitally, or through any other means. Nor must it be used for the execution of projects. The companies directly addressed in this project have the right to use this document for their purposes exclusively within the scope of this offer.