General Settings
Companies and employees
Demonstrational companies are added to the system to illustrate the service exchange process.
The provider company is called Providing Company. This company belongs to the Service Provider class. The company's employees are granted access to processing the tickets and editing the Knowledge Base.
The Providing Company employees and their roles in the system
Employee | Role | Group |
---|---|---|
Maria Kirillova | itsm_event_reader, cmdb_read, ITSM_agent, service_level_manager | ITSM Agents, SLM Managers |
Dmitriy Nikolaev | itsm_event_reader, cmdb_read, ITSM_agent, service_level_manager | ITSM Agents, SLM Managers |
Igor Sergeev | itsm_event_reader, cmdb_read, ITSM_agent, incident_manager | Incident Managers |
Ivan Petrov | itsm_event_reader, cmdb_read, ITSM_agent, request_manager | Request Managers |
Sergey Ivanov | itsm_event_reader, cmdb_read, ITSM_agent, problem_manager | Problem Managers |
The company that supplies IT services is called IT Service. This company belongs to the Service Provider class. The company's employees are granted access to processing the tickets.
The IT Service employees and their roles in the system
Employee | Role | Group |
---|---|---|
Ilya Markov | itsm_event_reader, cmdb_read, ITSM_agent, incident_manager | Incident Managers |
Natalia Alexeeva | itsm_event_reader, cmdb_read, ITSM_agent, problem_manager | ITSM Agents, Problem Managers |
Alexey Filippov | itsm_event_reader, cmdb_read, ITSM_agent, request_manager | Request Managers |
Mark Maximov | itsm_event_reader, cmdb_read, ITSM_agent, service_level_manager | ITSM Agents, SLM Managers |
The consumer company is called Consumer Company. The class of this company is Consumer. The employees of this company have no roles in the system: they are regular service portal users.
The Consumer Company employees:
- Oleg Dmitriev – CEO
- Olga Andreeva – Project Manager
The following employees have been created without reference to companies:
Employee | Role | Group |
---|---|---|
Kirill Gerasimov | impersonator, admin, security_admin, knowledge_admin, itsm_event_reader, cmdb_read, ITSM_agent | Admins, Knowledge Admins, ITSM Agents |
Dmitriy Glavnyj | without roles, referred to in the contacts of the Cloud service agreement |
User groups are added to the system to categorize employees according to their job title.
Group | Roles |
---|---|
SLM Managers | service_level_manager |
ITSM Agents | ITSM_agent |
Request Managers | request_manager |
Problem Managers | problem_manager |
Incident Managers | incident_manager |
Knowledge Admins | knowledge_agent |
Admins | impersonator, security_admin, admin |
Contacts are added for connection between the provider and service consumer records. Services, in turn, are associated with agreements and contracts:
Contact type | Contact name |
---|---|
Company | Consumer Company |
Division | Production unit |
Employee | Dmitriy Nikolaev |
Employee | Oleg Dmitriev |
Employee | Olga Andreeva |
Employee | Ivan Petrov |
Employee | Ilya Markov |
Employee | Nataliya Alekseeva |
Employee | Alexey Filippov |
Employee | Mark Maksimov |
Employee | Dmitrij Glavnyj |
Configuration items and CMDB classes
The demonstration data includes configuration items and CMBD classes. Configuration items are IT service components and classes are logical groups of CIs based on similar parameters. Some of the CIs are created on the form (such demonstrational CIs are included in classes), and others are created automatically from the services.
Demonstrational CMDB classes structure
Parent class | Class |
---|---|
Accessories | Power supplies |
Processor | |
HDD | |
Automated workstation | Personal computer |
System unit | |
Laptop | |
Printing equipment | Plotter |
Printer | |
Network equipment | Wi-Fi access point |
Router | |
Server equipment | Multilevel matrix switcher |
Storage System | |
Server |
Request subject generation rules
Subject generation rules are configured for the service requests created from the demonstrational services. The usage type is set to Override for all rules, which means complete subject generation according to the rule.
Service request model | Template | Example |
---|---|---|
Access to Network Resources | ${subject} ${rem_attr.request_type} | Access to Network Resources Give access to technical devices |
Software Installation or Upgrade | ${subject} ${rem_attr.request_type} | Software Installation or Upgrade Update software |
Virtual Office | ${subject} ${rem_attr.description} | Virtual Office Set up Outlook |
IT Infrastructure Setup | ${subject} ${rem_attr.description} | IT Infrastructure Setup Set up servers |
Ordering or Replacement of Equipment | ${subject} ${rem_attr.request_type} | Ordering or Replacement of Equipment Order additional equipment |
IT Consulting | ${subject} ${rem_attr.desired_consultation_date} | IT Consulting 2024-07-11 07:16:30 |
Agreements and contracts
Agreements complement the service and define the consumer of the service and the conditions for receiving it. In the demo data, each service has its own agreement. These agreements are used in the SLA calculation settings.
- Workplace
- Ordering or Replacement of Equipment
- Access to Network Resources
- IT Consulting
- IT Infrastructure Setup
- Virtual Office
- Software Installation or Upgrade
- Cloud Service
The records in the Contract table contain information about signed agreements, such as the service provider, vendor, and consumer.
Contract name | Description | Responsible |
---|---|---|
Providing a workplace | The contract between IT service and the Production unit of the Providing Company. | Nataliya Alexeeva |
Providing a cloud service | The contract between the Providing and Consumer companies. | Ivan Petrov |
Indicators
The indicators for each service are added to the system. The indications can be created from these indicators to assure compliance with the SLA. It allows for the evaluation of the service quality. The indicators are created for the tables Requests (itsm_request) and Incidents (itsm_incident).
The commitment type is set to Resolution time for all indicators. The duration varies depending on the ticket type: it equals one day for all typical requests and varies depending on the Impact level of the incidents. This period is calculated based on the schedule selected for the indicator.
The working conditions of the typical requests processing and incidents resolution indicators:
- Start Conditions: Impact is the value specified for the indicator.
- Pause Conditions: State is Postponed or State is Information Needed.
- Complete Conditions: State is Completed.