Функционал поручения. Статус

1.

Функционал Поручения
РУК, цифровые продукты
В.С. Ерохин
30.05.2022

2.

Функционал Поручения. Статус
Функционал поручения прорабатывается в рамках всего комплекса проектов ЦТ РУК.
Решение о контексте реализации (самостоятельный проект или в рамках одного из открытых) будет получено
после завершения проработке, выработки верхнеуровневой архитектуры (06.2022).Разработка будет
производиться в соответствии с изложенными требованиями и верхнеуровневой архитектурой.
Шаги:
• (В работе)Определение способа реализации «приземления поручений» - срок 21.06.2022, результат – арх
схема
• Решение о способе реализации принято 30.05.2022, на статусном совещании по РУК проектам) –
самостоятельная разработка на текущем стеке
• АРХ схема в работе
(проведена встреча с РП по ИТ, проведен опрос РП по ИТ оф-лайн)Встречи с РГ (РП по ИТ, Владельцы
продуктов) для уточнения требований конкретных проектов до 03.06.2022, результат - перечень требований
по проектам (протокол)
• (на 06.06.2022) Осуществляется в off-line режиме (рассылка, сбор замечаний, требований)
Доработка и согласование требований – срок 14.06.2022, результат – общий перечень требований по
проектам, сводный
Доработка по согласованию ролей в продуктах и ролей в приложении для исключения двойного ввода при
добавлении системы в Поручения -16.06.2022, результат – схема ролей
2

3.

Функционал Поручения. Цели
1. Обеспечение возможности контроля реагирования на
выявляемые отклонения показателей в системах РУК через
функционал «Поручения»
2. Обеспечение возможности анализа с точки зрения
приживаемости цифровых продуктов (посредством
количественного и качественного анализа поручений
3. Организация управления поручениями (контроль выполнения,
уведомлениями задействованных лиц, статус, сопутствующая
информация)
Цифровые продукты, обеспечивая базовый контроль параметров, не инициируют управляющие
воздействия, а только «отображают ситуацию». При использовании продукта именно
пользователь принимает решения о задачах, шагах, которые должны быть выполнены для
устранения «отклонений». Проконтролировать, что пользователь действительно что либо
предпринимает на основе результатов работы продукта, сложно. Именно для этого вносится
функционал Поручения.
3

4.

Функционал Поручения. Термины
1. Поручение – поставленная конкретному лицу задача со сроком исполнения в контексте того или иного
отклонения фактического значения показателя или предложения на изменение фактического значения
показателя.
2. Отклонение - несоответствие в цифровом виде фактического значения от планового (целевого,
нормативного) значения конкретного отслеживаемого показателя. Сопоставление значений и выявление
отклонения является функционалом системы, контролирующей показатель. Поручение на основе отклонения
должно инициироваться автоматически.
3. Предложение на изменение – инициатива ответственного лица (подающего предложение) на некоторые
изменения фактического значения (возможно, вместе с плановым). Примером можем служить инициатива по
улучшению показателей, даже если они находятся в допустимом диапазоне отклонений от планового
(целевого). Поручение на основе предложения на изменение инициируется вручную, с привязкой к
показателю
4. Драйвер - это одна из нескольких важных задач, которые устанавливаются старшими руководителями,
влияние на драйвер устанавливается в контексте инициации\создания цифрового продукта
5. Наряд – составленное на специальном бланке задание на безопасное проведение работы, определяющее ее
содержание, место, время начала и окончания, необходимые меры безопасности, состав бригады и лиц,
ответственных за безопасное выполнение работы. Наряды учитываются, хранятся.
4

5.

Функционал Поручения. Примеры
1. Проект 7517 (Куполообразование)
1. Поручение – Прогноз куполообразования. ш. Распадская/лава 3-6-37. снизить значение показателя «количество стоек с неисправными
гидрозатворами в смене» до не более 3 в смену (текущее значение 7, среднее за месяц 5, норматив 0) (Кому, Временные рамки)
2. Отклонение - Прогноз куполообразования. ш. Распадская/лава 3-6-37. текущее значение показателя «количество стоек с неисправными
гидрозатворами в смене» равно 7, норматив 0. (Кому, Временные рамки)
3. Предложение на изменение – Прогноз куполообразования. ш. Распадская/лава 3-6-37.Внести изменения по обслуживанию гидрозатворов
в сменах для обеспечения снижения показателя «количество стоек с неисправными гидрозатворами в смене» до 3 (норматив 0). Текущее
значение 7. (Кому, Временные рамки)
4. Драйвер - Увеличение ФРВ до XX% за счет снижения простоев по куполообразованию. (поручения могут быть привязаны к Драйверу ФРВ).
ш. Распадская/лава 3-6-37.
2. Проект 7509 (ЦШП)
1. Поручение – Цифровой штаб перемонтажей (ЦШП). ш. Ерунаковская\Перемонтаж 2-3-45/2-3-47. снизить значение показателя
«Прогнозная длительность монтажа гидростоек лавы» до не более 30, текущее значение 37, норматив 28 (Кому, Временные рамки)
2. Отклонение - Цифровой штаб перемонтажей (ЦШП). ш. Ерунаковская\Перемонтаж 2-3-45/2-3-47. текущее значение показателя
«Прогнозная длительность монтажа гидростоек лавы» равно 37, норматив 28, принять меры к возвращению к нормативам. (Кому, Временные
рамки)
3. Предложение на изменение – Цифровой штаб перемонтажей (ЦШП). ш. Ерунаковская\Перемонтаж 2-3-45/2-3-47. Изменить маршрут
перевозки, исключить задержки при перевозке секци для обеспечения снижения показателя «Прогнозная длительность монтажа гидростоек
лавы» до 30 (норматив 28). Текущее значение 37. (Кому, Временные рамки)
4. Драйвер - Снижение длительности перемонтажа на ХХ% за счет снижение времени перевозок секций. (поручения могут быть привязаны к
Драйверу ФРВ) ш. Ерунаковская\Перемонтаж 2-3-45/2-3-47.
5

6.

Функционал Поручения. Рассматриваемая архитектура
1. Подход с UI React базируется на
компонентах, которые подразумевают
реиспользование. Предлагается это и
задействовать
2. Модуль отправки может быть
реализован отдельно, а может
использоваться вызов к системе.
3. Задействовать очередь для развязки,
независимого логирования,
уведомлений, а так же в других
сервисах. Возможно, отправить
можно даже из систем, не
включенных явно в поручения.
4. Способ приземления (самостоятельная разработка)
6

7.

Функционал Поручения. Проекты, согл. требований (06.06.2022)
№ п/п
Проект
1
8572 —Внедрение «АСД карьер» разрез Коксовый (Карточка готова)
2
ПРП 9202 Цифровой контроль норм производственных процессов (7627 II этап)
3
8645 Ритмичность движения самосвалов. Разрез Распадский (Карточка готова)
Мероприятия
Наряды
РП по ИТ
Статус согласования требований
Комментарий
Нет
ВП , РП по ИТ не участвуют в
согласовании, не видят
потребность
Нет
Курносов
Да
4
Курносов
Казанцев
Да
8616 — Видеоаналитика порывов цепи лавного конвейера. (Карточка готова) (Пилот Кок-совая
Да
Нет
Безнин
Нет
5
6
9079 — Видеоаналитика порывов цепи лавного конвейера. (Карточка готова) Осинников-ская
8651 – 8657 Тираж 20 лент видеоаналитика КТ
7
8761,8764-8768 Бурение тиражи
Артем Сироткин
8
8674 — Мониторинг извлеченного метана при предварительной дегазации по типу буре-ния. (Е 8) (БТ –
Иван Масленников)
Безнин
9
10
11
8750 Подсказчик диспетчера по газовому фактору (MVP - Run) ш.Осинниковская
8977 Монитор отставания балки от забоя
8939 Автоматизация расчета циклов добычи/проходка
12
13
14
15
16
17
9051 Подсказчик по куполообразованию интеграция с электронными нарядами
ПРП 9109 Автоматизация сушильных отделений АОФ ЦТ
ПРП 9110 Автоматизация спиральных сепараторов КОФ ЦТ
ПРП ???? Видеоаналитика загруженности подрядных самосвалов
ПРП 9151 Видеоаналитика ККД (подрядчик B&D)
9100 Шахта GO ЮЖГРУ
18
19
ПРП 8780 Цифровой штаб перемонтажей. Развитие. Базовый проект (7509)
ПРП 8813 Машинное зрение определение источников газа
20 ПРП 7532. Видеоаналитика порывов конвейерных лент (1, 6, 8, 10) шахты (пилот ш Осин)
21
7998 Система контроля положения шнека MVP 30.09
22
8340 ЭКО ПРО
23
ПРП ЭКО ПРО ОФ
24
ПРП ЭКО ПРО Разрез
ИТОГО
Да
Безнин
Бендре
Согласовано
Нет
Нет
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Рожков
Кудрявцев
Кудрявцев
Нет
Нет
Нет
Проект АСУ ТП
Проект АСУ ТП
Бендре
Толочков
Бендре
Ахметшин
Да
Да
Да
Да
Да
Да
Предложение плотнее вовлечь
бизнес
Зюляев
Толочков
Речкин
Комаров
Безнин
Гурьянов
Гурьянов
Гурьянов
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
Нет
14
*Желтым выделены строки с необходимостью интеграции в Нарядах или Мероприятиях
7

8.

Функционал Поручения. Требования (в работе, отдельным списком)
1) Либо все пользоваться, либо придумывать ходы, как фиксировать исполнение
2) Нет значимых данных - не будет исполнения
3) Необходима поддержка для РП по ИТ при внедрении данного функционала .
4) Понять чью конкретно задачу мы решаем (если не контроль исп. Дисциплины., то не нужна). Если решаем – движение должно быть сверху вниз.
5) Жесткий подход. Мягкий не получиться.
6) Если не со стороны бизнеса – сами владельцы придут.
7) Как обеспечить приживаемость продукта Поручения.
8) Не привязываться к ролям?
9) Техническая история
10)Дизайн
11)Уточнение требований, моментов и др.
12)Делегирование (создается поручение, аналогичное вышестоящему, но от лица делегирующего – исполнителю). При делегиловании можно
ДОПОЛНИТЬ описание или НОВОЕ описание добавить
1) Автоматом не закрываем, должно быть подтверждение от делегирующего
13)Назначение «заместителя» (по поручнеию/продукту/месту)
14)Детализация поручения. (поручение порождает дочерние поручения)
15)Связанные поручения.
1) Может ли просматривать Вышестоящий (настройка)
2) Исполнитель уходит в отпуск – в системе выставляет на себя замещающего.???
16)Драйвер по умолчанию, привязка поручения к драйверу из списка.
17)РОЛЕВАЯ МОДЕЛЬ
8

9.

Функционал Поручения. Требования (в работе, отдельным списком)
ТОЛЬКО С ПРИВЯЗКОЙ ДРАЙВЕРОВ.
9

10.

Функционал Поручения. Предлагаемые изменения в системах
1. МИНИМУМ:
1. Системы должны вести список контролируемых показателей и их нормативов/плановых
значений для привязки в поручениях
2. Системы должны интегрировать встраиваемые компоненты UI Поручений в UI (только реакт)
3. Системы должны сделать доступной ссылку на UI поручений (вне react)
4. Системы должны получить и использовать единый идентификатор, по которому подключаются к
Поручениям (аналогию можно подглядеть в Матомо)
5. Системы (проекты) должны предоставить драйвера для ведения единой базы драйверов
6. (в проработке) Потребуется определить роли для поручений и ФИО
7. РАСШИРЕННЫЙ:
1. Взаимодействовать по API
2. Создан новый пользователь (сервисный) для автоматизированного формирования поручений (или
предоставлены права существующим
3. Определиться с периодичностью контроля показателя и отсылки поручения в систему Поручений
(автоматизированной отсылки (по отклонениям), определиться с толерансом показателя
10

11.

Функционал Поручения. Ключевые роли
1. Администратор – сотрудник РУК или РЦС, обеспечивающий:
1. Настройку системы Поручения
2. Настройку каналов уведомлений
3. Настройку необходимых НСИ системы
4. Добавление продуктов\сервисов\систем в функционал Поручения
2. Инициатор – пользователь\сервис, формирующий поручение (пользователь продукта\системы\сервиса или
Автомат, в рамках продукта\системы\сервиса)
1. Инициировать/создавать поручение
2. Редактировать описание поручения
3. Корректировать срок поручения
4. Изменять статус поручения
5. Менять атрибуты поручения (привязка к драйверу и др.)
6. Менять исполнителя поручения
3. Исполнитель – пользователь продукта\сервиса\системы, обеспечивающий исполнения Поручения.
1. Менять статус
2. Оставлять комментарий\запрос на доп. Информацию
3. Просматривать перечень поручений
4. Получать уведомления
5. Просмотр статистики по своим поручениям
11

12.

Функционал Поручения. Вопросы в проработке
1. Выбор ПО для приземления поручений, варианты:
1. 30.05.2022 Наряды – исключаем в связи со спецификой и минимизации смешения функций и
предназначения системы
2. 30.05.2022 Ремонты – исключаем в связи с спецификой и иными целями
3. Мероприятия ОТиПБ – подход и элементы интересны, рассмотреть подробнее
4. 30.05.2022 СЭД – исключаем, нет необходимости в официальном согласовании (может войти
частично после подтверждения требований
5. 30.05.2022 Confluence – возможно применения для «приземления», но для дополнительного
функционала требуется собственная БД, собственный бэк.(исключаем, сложности лицензирования,
пушкой по воробьям)
6. Самостоятельная разработка
В связи с перечисленным выбирается самостоятельная разработка, возможно заимствование решений
из «Мероприятий ОТ и ПБ».
2. Драйвера в проектах большей частью не ведутся и отсутствует возможность при автоматической отправки
поручения привязать к драйверу. Предлагается:
1. привязку Поручение-Драйвер влияния осуществлять в UI Поручения ответственному
(назначающему) в случае необходимости/
2. Вести НСИ драйверов в контексте Поручений в связке с продуктами 1-* (у продуктов могут быть
одни и те же драйвера, влияние можно оценивать комплексно при последующем анализе)
3. Первичную привязку в Нси можно использовать из Azure (требует проработки)
12

13.

Функционал Поручения. Дальнейшие шаги
(выполнено)Определение способа реализации «приземления поручений»
(выполнено)Встречи с РГ (РП по ИТ, Владельцы продуктов) для уточнения требований конкретных
проектов. Перечень проектов из списка стр 7 (отметка желтым на поручениях)
–Встречи офф-лайн, рассылка презентации, рассылка опросника и требований
Доработка и согласование требований
–На основании п.2
Доработка по согласованию ролей в продуктах и ролей в приложении для исключения двойного ввода
при добавлении системы в Поручения
Мобильные, адаптивны – рассмотреть потребность в мобильной версии приложения поручений (из
протокола 30.05.2022 - предусмотреть и мобильные и lazy approvals - что очень актуально бывает!
(Levon, проект 8340, подрядчик)
Согласование не в первых шагах.
13

14.

Схема развертывания
14

15.

Схема развертывания
15