ИТ-процессы редко укладываются в один шаг. Диагностика ведёт к выполнению, выполнение - к проверке, и каждый этап имеет смысл только после результата предыдущего. В стандартном GLPI каждая из этих задач появляется из ручного ввода специалиста, что делает стандартизацию невозможной, как только растёт объём. Модуль SubTask Flow связывает эти этапы в цепочку: когда специалист регистрирует решение задачи в ленте, следующая создаётся автоматически в соответствии с этим ответом.
Почему ручное создание следующей задачи не масштабируется
Многие процессы обработки предсказуемы: проанализировать, выполнить, проверить, сообщить. GLPI предлагает шаблоны задач (TaskTemplates) для стандартизации содержимого каждого шага, но он не знает, что один шаг должен порождать следующий. Результат известен: специалист открывает нужный шаблон, копирует ответственного и срок и создаёт следующую задачу вручную. В среде с десятками специалистов это порождает три хронические проблемы: забытые этапы, расхождения данных между аналогичными заявками и полное отсутствие отслеживаемости того, «почему эта задача существует». Когда аудит спрашивает, была ли проведена проверка, ответ зависит от личной дисциплины каждого специалиста, а не от спроектированного процесса.
Как SubTask Flow связывает задачи по решению
Модуль создаёт иерархические связи между TaskTemplates. Родительский шаблон указывает на один или несколько дочерних, и каждый дочерний может быть обусловлен конкретным решением. Когда специалист регистрирует решение в ленте родительской задачи (или, если у шаблона нет условия, отмечает задачу как «Выполнено»), модуль выполняет три шага:
- Определяет дочерние шаблоны, привязанные к этому решению;
- Создаёт дочерние TicketTasks в ленте той же заявки;
- Копирует содержимое, категорию, длительность и ответственного (специалиста и группу), заданные в дочернем шаблоне.
Конфигурация живёт в шаблоне, а не в заявке. Вы настраиваете процесс один раз, и он начинает действовать для всех заявок, использующих этот шаблон, без вмешательства в бизнес-правила или внешние автоматизации. В этом разница между тем, чтобы задокументировать процесс, и тем, чтобы система его выполняла.
Пошаговая настройка
- Стандартизируйте список решений в настройках модуля (например: «hardware», «software», «нет дефекта»). Относитесь к нему как к закрытому словарю, а не к свободному тексту.
- Откройте родительский TaskTemplate и привяжите дочерние шаблоны на вкладке цепочки.
- Для каждого дочернего шаблона укажите, какое решение его запускает. Условный дочерний шаблон требует, чтобы у родительского шаблона было состояние по умолчанию «Информация».
- Убедитесь, что у каждого дочернего шаблона заполнены ответственная группа или специалист и длительность - именно это поле причиняет больше всего проблем впоследствии.
- Протестируйте на тестовой заявке, прежде чем выпускать в продуктив: создайте тестовую родительскую задачу для каждого возможного решения, зарегистрируйте решение в ленте и убедитесь, что появляется нужная дочерняя задача с правильными данными.
Обнаружение циклов
Цепочка без защиты становится ловушкой. Шаблон A, порождающий B, который порождает C, который снова возвращается к A, пересоздавал бы одни и те же задачи на каждом круге, и процесс никогда бы не завершился. При сохранении новой связи модуль выполняет поиск в глубину (DFS) по графу шаблонов. Если находится цикл, он показывает предупреждение с путём петли, но связь остаётся сохранённой: удалить её - задача того, кто настраивает. Блокируется только связь шаблона с самим собой. Поэтому стоит соблюдать дисциплину любой автоматизации: короткие и понятные цепочки облегчают диагностику, когда что-то идёт не так, как ожидалось.
Отслеживаемость: вкладка журнала
Автоматизация без журнала - чёрный ящик. SubTask Flow ведёт историю выполнений с заявкой, родительской задачей, созданной дочерней задачей, тем, кто запустил, тем, кто завершил, и временными метками. При аудите это отвечает на самый частый вопрос - «эта подзадача создана кем-то или процессом, и из какой задачи?» - не полагаясь на чью-либо память. Это также первое место, куда смотреть, когда клиент сообщает, что «этап пропал»: журнал показывает, сработал ли триггер и из какой задачи.
Диагностика: аудит процесса через SQL
Тихая автоматизация требует активного мониторинга. Запрос ниже выводит ещё открытые подзадачи, созданные без назначенного ответственного, - классический симптом неполного дочернего шаблона. Выполняйте его на реплике для чтения или в окно низкой нагрузки:
-- Subtarefas em aberto (state=1) sem tecnico nem grupo responsavel.
-- Sinaliza TaskTemplate filho sem users_id_tech/groups_id_tech preenchido.
SELECT t.id AS chamado,
tt.id AS task_id,
tmpl.name AS modelo,
tt.state,
tt.users_id_tech,
tt.groups_id_tech,
tt.date_creation
FROM glpi_tickettasks tt
JOIN glpi_tickets t ON t.id = tt.tickets_id
LEFT JOIN glpi_tasktemplates tmpl ON tmpl.id = tt.tasktemplates_id
WHERE tt.state = 1
AND tt.users_id_tech = 0
AND tt.groups_id_tech = 0
AND t.is_deleted = 0
ORDER BY tt.date_creation DESC
LIMIT 200;В GLPI state = 1 - это «К выполнению», а state = 2 - «Выполнено». Если этот список растёт каждую неделю, проблема не в модуле: это дочерний шаблон, опубликованный без ответственного, который порождает задачи, невидимые ни в чьей очереди.
Когда использовать (и когда нет)
| Подход | Когда использовать | Ограничение |
|---|---|---|
| Отдельная задача (вручную) | Разовые процессы, малый объём, без повторения | Не стандартизирует и не отслеживает |
| Встроенный шаблон задачи | Повторяющийся шаг с фиксированным содержимым | Не связывает со следующим шагом |
| SubTask Flow | Условная последовательность задач внутри одной заявки, запускаемая решением | Область действия - заявка; не создаёт новых заявок |
| Проект GLPI | Поставка с вехами, несколькими заявками, диаграммой Ганта и сроками | Высокие накладные расходы для короткого процесса |
| Бизнес-правила | Маршрутизация и назначение при создании заявки | Не управляет шагами после создания |
Самая частая ошибка на практике
При сопровождении сред с большим количеством специалистов чаще всего встречается проблема не техническая, а моделирования. Кто-то настраивает дочерний шаблон на срабатывание по решению «Hardware», а вариант, который специалист реально выбирает на экране, - «hardware» строчными буквами или «HW» в среде, унаследовавшей словарь от другого инструмента. Триггер не совпадает, подзадача не создаётся, никто не получает ошибки, и этап выполнения просто исчезает из процесса, не оставляя видимого следа. Исправление, которое мы стандартизировали: относиться к строкам решений как к контролируемому словарю, все строчными буквами, задокументированными в единой таблице соответствий, и пересматривать дочерние шаблоны каждый раз, когда кто-то добавляет новое решение. Вторая повторяющаяся ошибка - дочерний шаблон без ответственного: задача рождается бесхозной, теряется посреди ленты и всплывает снова, только когда SLA уже нарушен. Поэтому SQL-запрос выше входит в чек-лист сопровождения, а не в разовый аудит.
NexTool внедряет и сопровождает среды GLPI с автоматизациями вроде SubTask Flow, спроектированными под реальную работу каждого клиента. Свяжитесь с нашей командой, чтобы описать и автоматизировать процесс задач вашей команды.
Проверено командой NexTool Solutions.
