Содержание:
1. Описание процесса TO BE от Заказчика
2. Описание реализованного кейса
5. Регистрация событий в системе
Система мониторинга и диспетчеризации (СдиМ).
ESM — ESM (Enterprise Service Management) — это подход к управлению услугами предприятия, основанный на принципах ITSM, в нашем случае система 1С: ИТИЛИУМ.
Служба Service Desk — Единая точка контакта между поставщиком услуг и пользователями. Типичная служба Service Desk управляет инцидентами, запросами на обслуживание, а также взаимодействует с пользователями.
SLA — Соглашение об уровне услуг (Service Level Agreement, SLA) — письменное соглашение между поставщиком услуг и заказчиком, в котором задокументированы услуги и согласованы условия предоставления услуг и уровни оказываемого сервиса. SLA описывает Услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон: поставщика услуг и заказчика.
Управление инцидентами — это процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель управления инцидентами — скорейшее восстановление услуги для пользователей.
Каталог услуг — это перечень услуг, предоставляемых Обслуживающей Организацией Клиенту (заказчику услуг). Описание услуги содержит детальное описание результата, условий и уровней ее предоставления, форм предоставляемой отчетности и другую необходимую информацию на понятном заказчику языке.
Обращение — документ, предназначенный для регистрации инцидентов, запросов на обслуживание и запросов на изменение.
Инцидент — любое событие, которое не является частью стандартной эксплуатации и которое приводит, или может привести, к прерыванию предоставления услуги или к снижению ее качества.
Проблема — причина одного или нескольких инцидентов (Массовый инцидент).
Событие — изменение состояния, которое имеет значение для управления услугой. События обычно требуют от персонала Service Desk выполнить определенные действия и часто приводят к регистрации инцидентов.
Наряд — документ, предназначенный для фиксации трудозатрат и иных ресурсов, потраченных на устранение инцидента, либо на выполнение какой-либо не связанной с инцидентом задачи.
Номенклатура — перечень материальных ценностей, сгруппированных по характерному для них признаку и соответствующим образом зашифрованных с указанием единицы измерения.
Показатель — обобщенная характеристика уровня услуги, выраженная в численной форме и определяемая совокупностью метрик.
Метрика — числовое значение, определяющее величину той или иной характеристики уровня услуги.
Организация — юридическое лицо, выполняющее функции поставщика услуг. В системе Итилиум под организацией может пониматься как независимая организация, оказывающая услуги, так и подразделение, являющееся частью бизнеса.
Клиент — юридическое лицо или подразделение, пользующееся услугами организации, заказчик услуг.
Пользователь — лицо, участвующее в функционировании системы или использующее результаты ее функционирования (в терминологии системы —Пользователь информационной базы (ИБ)); потребитель услуг, являющийся контактным лицом того или иного клиента (в терминологии системы —Пользователь (Потребитель услуг)).
Сотрудник — работник поставщика услуг.
1. Описание процесса TO BE от Заказчика
(Записано, как предоставлено Заказчиком).
1. Информация от исполнительного оборудования, датчиков и механизмов формируется в контроллерах или терминалах.
2. С помощью стационарных или мобильных модулей связи (модемы, маршрутизаторы) данная информация сводится в системы диспетчеризации и мониторинга (СДиМ), установленных на локальных ПК (инстансах), либо на облачных платформах c доступом через браузер. Количество подключаемых контроллеров на один «инстанс» ограниченное.
3. Доступ к данным в СДиМ для автоматизированного рабочего места в ситуационном центре (СЦ), организован через интернет-канал с помощью программ удаленного доступа для «инстансов» или с помощью входа в личный кабинет облачного сервиса.
Специалисты СЦ круглосуточной смены в онлайн режиме осуществляют визуальный мониторинг за состоянием оборудования и механизмов. После чего в ручном режиме регистрируют их в бумажных и электронных журналах, и доводят информацию до ответственных лиц, организуя устранение неполадок.
На этом этапе необходимо добавить функционал прямой передачи потоков данных из СДиМ в ESM для формирования базы для анализа обстоятельств возникновения инцидента и вывода на экран специалисту СЦ оповещения (предложки) от виртуального помощника (на базе ИИ).
Функционал прямого визуального мониторинга специалистом СЦ круглосуточной смены в онлайн режиме за состоянием оборудования и механизмов непосредственно в СДиМ, остается как дополнительная возможность проверки и подтверждения гипотезы наличия инцидента или сбоя в работе оборудования, которую сформировал виртуальный помощник в ESM.
События и инциденты специалист СЦ регистрирует уже не в бумажных и электронных журналах, а непосредственно в ESM системе, либо исходя из оповещения виртуального помощника. Либо из собственного визуального анализа.
После регистрации события ESM система, исходя из выбранной подгруппы и типа инцидента, включает стандартизированный сценарий, его отработки с рекомендациями по его устранению, а также с перенастроенной функцией автоматического оповещения ответственных лиц. Все имеющиеся в системе сценарии отработки событий должны иметь SLA по типам и времени их эскалации.
4. В ручном режиме специалисты СЦ экспортируют из СДиМ информацию, носящую ежесуточный характер в формате исходных электронных таблиц .xls и без корректуры и объединения в общие своды размещают их в каталог экспортирования, а система (ESM???) автоматически загружает их из данного каталога в свои базы данных для формирования ежесуточных отчетов (п.5). Либо система из подключенных напрямую потоков данных самостоятельно формирует базы данных для ежесуточных отчетов.
5. На основе загруженных исходных данных, описанных в п.4, а также зарегистрированных данных о возникших инцидентах, система формирует единую базу исторических данных. После чего в автоматическом режиме формирует ежесуточные отчеты трех типов: производственный, логистический и итоговый по заданным фильтрам, параметрам и периодам, которые автоматически отправляются ответственным лицам и руководителям служб.
6. Руководители служб принимают оперативные управленческие решения, учитывая данные, отраженные в этих отчетах (доступ к системе напрямую для просмотра отчетов, либо выгрузка отчетов в формате .xls и рассылка почтой рассматриваются исходя из количества и стоимости пользовательских лицензий).
7. Все дашборды и сценарии отработки событий в ESM-системе должны быть написаны с использованием Low code/Now code технологии, чтобы главные специалисты СЦ могли иметь возможность без специализированных знаний программирования вносить корректировки в действующие сценарии и дашборды, а также создавать новые сценарии и дашборды.
Из сформированной в ESM системе базы исторических данных руководитель СЦ и главные/ведущие специалисты по запросам от руководителей служб или руководства предприятия автоматически подготавливают аналитические отчеты с инфографикой и срезами за более длительные периоды (месяц, квартал, год и т.п.), которые предоставляются либо электронной почтой, либо в виде презентаций, либо путем их создания в виде дашбордов в BI системе с интерактивным доступом заинтересованных лиц.
8. Сформированная в ESM системе база исторических данных будет интегрироваться либо с имеющейся, либо с вновь внедряемой BI системой, что позволит Руководству компании, а также другим подразделениям и службам строить свои модели более широкого анализа и более точного поиска первопричин и прогнозирования.
(Записано, как предоставлено).
Нештатная ситуация
2. Описание реализованного кейса
Ограничения реализации.
Ограничения реализации:
Не реализована интеграция с внешними системами;
Не реализованы автоматическое формирование и рассылка отчетов;
Не реализована функция виртуального помощника ИИ;
В реализованном кейсе намеренно введено ограничение по типу производственного оборудования;
В рамках кейса не моделируется управление Активами и конфигурационными единицами (т. к. заказчик не ведет и не планирует вести такой учет).
3. Бизнес описание данных
2. В составе ООО «Рога и копыта» 10 территориально-обособленных подразделений.
3. Каждое из Обособленных подразделений эксплуатирует некоторое количество зданий (производственных корпусов), расположенных на разных площадках.
В корпусах размещены цеха с разным направлением деятельности: Подращивание или Откорм птицы.
В цехах работает оборудование обеспечения жизнедеятельности Птицы, также в цехах размещены датчики контролирующие: Влажность; Освещенность; Температуру; Состав воздуха; Регулярность подачи воды; Регулярность подачи Корма.
4. События мониторинга систем фиксируются во внешней системе, а отклонения от нормы дополнительно регистрируются в Итилиум сотрудником Ситуационного центра.
5. По данным анализа, зафиксированных отклонений (наблюдаемой динамики), сотрудник ситуационного центра принимает решение об отправке Инженеров на устранение неполадки.
6. Дополнительно, Сотрудник ситуационного центра оповещает ответственных лиц об Инциденте.
7. Инженер, по мере исправления ситуации, извещает сотрудника Ситуационного центра о своих действиях и/ или о дополнительных действия, которые необходимо сделать для устранения неполадки.
8. В процессе диалога, Сотрудник ситуационного центра принимает решение о необходимости направления дополнительных ресурсов на устранения причин Инцидента.
9. После устранения причин инцидента, Сотрудником ситуационного цента производится контроль изменения ситуации, по данным мониторинга. При наблюдении положительной динамики Инцидент закрывается.
10. По факту анализа Инцидента, в Базу знаний Итилиум, может быть добавлено описание решения и/ или иная полезная для принятия решения информация.
11. Для помощи в оценке ситуации могут использоваться тематические чек-листы.
4. Основные настройки системы
1. Создана тестовая Организация - ООО «Ситуационный центр».
Ситуационный центр
2. Зарегистрирован Клиент ООО «Рога и Копыта» и его территориально обособленные подразделения.
Клиенты
3. Созданы группы физических лиц, сотрудников. Собственно, Физические лица и Сотрудники для Организации Ситуационный центр.
Физические лица
Сотрудники
3. Создан каталог Услуг:
Контроль систем жизнеобеспечения птицы
Состав услуги
Уровни оказания услуги
Уровень услуг зависит от времени поступления обращения
Понедельник
Четверг
Настройка Уведомлений на услугу.
Форма настройки оповещения
4. В систему добавлено несколько обобщенных конфигурационных единиц, привязанных к территориальным подразделениям Клиента.
База данных управления конфигурациями
5. Рабочее место - фактически описывает место нахождение оборудования в территориально-обособленном подразделении.
6. Между клиентом и Организацией заключено Соглашение об уровне сервиса по направлениям услуг.
Соглашение об уровне услуг
7. Т.к. тестовый пример формировался на демонстрационной базе, при работе с документами использовались преднастроенные правила обработки инцидентов (Воркфлоу).
По умолчанию.
Графическая схема
Для Инцидента.
Графическая схема
5. Регистрация событий в системе
1. Регистрация событий в системе начинается с переноса данных из систем мониторинга.
Это можно сделать, например, используя объект системы «Событие».
Потенциально, создание событий может быть автоматизировано (получение информации по Апи протоколу, или загрузка выгруженных данных из систем). Объем вносимых данных определяется требуемым уровнем детализации для принятия решения Сотрудником ситуационного центра в Итилиум.
В настоящем примере, в Итилиум вносятся только факты отклонений.
Событие
Дополнительные поля – добавлены в пользовательском режиме, без использования конфигуратора и привлечения программиста.
Количество дополнительных полей не ограничено.
В Системе можно настраивать шаблоны заполнения документов.
Список документов также можно настраивать по усмотрению пользователя.
Отчеты, в частности реестр событий, реализованы на СКД, что, в свою очередь, так же предоставляет пользователю широкие возможности настроек. Пользовательские настройки сохраняются. Ими можно делиться, выгружать в файл.
Реестр событий
2. Далее, сотрудник Ситуационного центра, наблюдая за событиями, принимает решение о Регистрации Инцидента (и/ или Проблемы) и направлении Инженеров для устранения причин зарегистрированных отклонений (Создание Наряда).
Для автоматического заполнения наряда, в системе можно настроить правило обработки, например:
Наряд Уровень воды
Наряд Уровень воды
Результат ввода на основании события.
Наряд
Наряду, определяется Исполнитель и/или Группа исполнителей, Приоритет.
3. В зависимости от настроек уведомлений, при назначении наряда оповещение будет отправлено Ответственным лицам.
4. При необходимости, может быть настроена цепочка взаимозависимых нарядов исполняемых последовательно.
Событие
5. Для фиксации ситуации, События могут быть объедены ПРОБЛЕМОЙ или Инцидентом.
Событие
Проблема
6. По мере исполнения нарядов, в них фиксируется время исполнения и результат.
7. Каждому из документов могут быть определены метрики, для фиксации показатели уровня оказываемого сервиса.
Метрики
8. В Системе ведется база знаний/ список готовых решений.
База знаний
9. Отчетность.
SPA Report
Так же в системе можно настроить автоматическое формирование отчетов по расписанию и отправку их заинтересованным лицам.
Реестр событий
Специалист компании ООО "Кодерлайн"
Лилия Климкович