AI-Support: Цикл жизни статьи

   KPI инженера: не закрыл тикет без ссылки на статью (или создания черновика).

1. Управленческая задача: Стимулирование создания знаний и повышение эффективности.
Установление KPI (Key Performance Indicator — ключевой показатель эффективности) для инженера поддержки — "не закрыл тикет без ссылки на статью (или создания черновика)" — это мощный управленческий инструмент для превращения каждого решенного инцидента в актив компании. Цель — мотивировать технических специалистов документировать решения типовых проблем, тем самым обогащая базу знаний (Drupal Wiki) и снижая нагрузку на всю службу поддержки в будущем. Без такого KPI ценные знания остаются "в голове" инженеров, что приводит к повторному решению одних и тех же проблем, увеличению MTTR и зависимость от конкретных специалистов.

2. Суть KPI и его обоснование.

• Проблема: Инженеры часто решают проблему, но не документируют решение, так как это занимает дополнительное время и не является их прямой "боевой" задачей. В результате, когда та же проблема возникает снова, другой (или даже тот же) инженер тратит время на её повторное решение.
• Решение: Включаем в KPI требование: при закрытии тикета инженер должен привязать к нему ссылку на статью в Wiki, которая описывает решение этой проблемы.
  • Если такой статьи нет, инженер обязан создать её черновик. Это гарантирует, что каждая новая или нетиповая проблема будет задокументирована.
  • Черновик затем может быть доработан техническим писателем или руководителем L2.
• Механизм мотивации: Этот KPI влияет на премию, бонус или карьерный рост инженера. Невыполнение KPI ведет к снижению оценки его работы.

3. Инструментальная реализация через Vtiger, OpenProject и n8n.

• Vtiger: Модуль "HelpDesk" может быть настроен так, чтобы поле "Ссылка на статью Wiki" было обязательным при переводе тикета в статус "Решено" или "Закрыто". Vtiger может проверять, что ссылка действительно ведет на существующую статью в Drupal.
• OpenProject: Инженеры работают в OpenProject. При закрытии Work Package (рабочего пакета), они должны указывать ссылку на статью Wiki. OpenProject может иметь кастомное поле "Wiki Link" с валидацией.
• n8n (контроллер):
  1. n8n "слушает" (polling) OpenProject или Vtiger на предмет закрытия тикетов/задач.
  2. Проверяет, заполнено ли поле "Ссылка на статью Wiki".
  3. Если поле не заполнено, n8n:
     • Возвращает тикет/задачу в статус "В работе" с комментарием "Требуется ссылка на Wiki".
     • Отправляет уведомление инженеру и его руководителю.
     • (Опционально) Фиксирует нарушение KPI для последующей аналитики.
  4. Если ссылка есть, n8n проверяет её валидность (например, доступность URL) и привязывает её к тикету.

4. Поддержка процесса.

• Обучение: Инженеры должны быть обучены, как правильно создавать статьи и использовать шаблоны.
• Время на документирование: Выделяйте время в рабочем графике инженера на документирование, это часть его работы, а не дополнительная нагрузка.
• Технический писатель: Наличие специалиста, который дорабатывает черновики инженеров, критично для качества базы знаний.

5. Управленческие выгоды.

• Постоянное пополнение базы знаний: Каждое решение обогащает общий пул знаний.
• Снижение MTTR: Инженеры и клиенты быстрее находят решения.
• Увеличение Self-service: Клиенты чаще решают проблемы самостоятельно.
• Обучение новых сотрудников: База знаний становится мощным обучающим инструментом.
• Снижение зависимости от "звездных" сотрудников: Знания становятся корпоративным активом.
• Улучшение AI: AI-агенты получают больше актуальных и структурированных данных для своей работы (RAG).
• Оптимизация ФОТ: Снижение затрат на повторное решение типовых проблем.

   Ревизия актуальности (TTL статей).

1. Управленческая задача: Поддержание достоверности базы знаний и избежание дезинформации.
Ревизия актуальности (Revision of Relevance), или внедрение TTL (Time To Live — время жизни) для статей базы знаний (Drupal Wiki), — это критически важный управленческий процесс для обеспечения достоверности и актуальности информации, доступной клиентам и сотрудникам. Без регулярной проверки, статьи быстро устаревают: меняются версии ПО, адреса серверов, регламенты, и пользователи начинают опираться на неверные данные. Это приводит к ошибкам, увеличению MTTR, недовольству клиентов и подрыву доверия к службе поддержки. Цель — создать механизм, который гарантирует своевременное обновление или архивирование устаревших статей.

2. Суть TTL для статей.

• Время жизни: Каждой статье присваивается атрибут "Дата следующей ревизии" или "Срок актуальности" (например, 6 месяцев, 1 год, бессрочно).
• Категории статей: Разные категории статей могут иметь разный TTL.
  • Быстро меняющиеся (короткий TTL): Инструкции по настройке нового ПО, временные решения проблем (3-6 месяцев).
  • Умеренно меняющиеся (средний TTL): Общие FAQ, регламенты работы (1 год).
  • Стабильные (длинный TTL): Описание базовых услуг, контактные данные (2-3 года или бессрочно, но с ручной проверкой раз в N лет).

3. Механизм реализации через Drupal и n8n.

• Drupal:
  1. Кастомное поле: Для каждого типа материала (статьи) в Drupal создается кастомное поле "Дата следующей ревизии" (Next Review Date).
  2. Ответственный: Также можно добавить поле "Ответственный за ревизию" (Reviewer).
  3. Автоматическое проставление: При создании или обновлении статьи, это поле автоматически заполняется (например, текущая дата + 1 год).
• n8n (контроллер):
  1. Планировщик (Scheduler): n8n настраивается на ежедневную или еженедельную проверку статей в Drupal через API.
  2. Фильтрация: n8n отбирает все статьи, у которых "Дата следующей ревизии" наступила или просрочена.
  3. Действия: Для просроченных статей n8n может:
     • Создать задачу в OpenProject: "Ревизия статьи [Название статьи] (ID: [Article ID])" и назначить её "Ответственному за ревизию" или руководителю L2.
     • Отправить уведомление: Направить Email/Telegram-уведомление ответственному лицу с напоминанием о необходимости проверки.
     • Изменить статус статьи (опционально): В Drupal можно создать статус "Требует ревизии", и n8n будет переводить статью в него, пока она не будет проверена.
     • Снять с публикации (опционально): Крайняя мера для очень критичных статей, чтобы предотвратить использование устаревшей информации.

4. Процесс ревизии.
Ответственный за ревизию (Team Lead, L2-инженер, технический писатель):

1. Получает задачу из OpenProject.
2. Перечитывает статью, проверяет актуальность информации.
3. Вносит необходимые правки или подтверждает актуальность.
4. Обновляет поле "Дата следующей ревизии" в Drupal.
5. Закрывает задачу в OpenProject.

5. Управленческие выгоды.

• Достоверность информации: Гарантия, что клиенты и сотрудники используют актуальные данные.
• Снижение ошибок: Предотвращение проблем, вызванных устаревшими инструкциями.
• Повышение качества Self-service: Уверенность в том, что ответы из Wiki всегда верны.
• Эффективное использование AI: AI-агенты (RAG-система) всегда работают с актуальной базой знаний.
• Системность: Упорядоченный процесс управления знаниями.
• Снижение рисков: Юридическая защита, если некорректная информация могла повлечь убытки.