Knowledge Management в ITIL: жизненный цикл статьи и метрики reuse

Почему 90% баз знаний мёртвые

Типичная история. IT-отдел внедряет helpdesk, в нём есть модуль «База знаний». Кто-то один (обычно техлид) заливает туда 30 инструкций по сетевому оборудованию, потому что «нужно же что-то для старта». Через полгода в БЗ — те же 30 статей, операторы туда не заходят, пользователи о ней не знают.

Причины:

• Никто не владеет. Без явного владельца статьи устаревают. «Это писал Сергей два года назад, я не знаю актуальна ли инструкция».
• Статьи пишут «впрок». Без связи с реальными вопросами пользователей. Получается академический трактат, который никто не ищет.
• Поиск не работает. Если в БЗ нельзя найти ответ за 10 секунд — её нет. Полнотекстовый поиск + теги + структура каталога — обязательны.
• Нет петли обновления. Решили заявку — и забыли. А ведь решение могло стать новой статьёй или дополнить старую.

Жизненный цикл статьи

Каждая статья проходит фазы. В ITIL/KCS их обычно пять:

1. Drafted — написана, не опубликована. Видна только автору. Этап быстрый: 5–10 минут, набросок прямо из закрытой заявки.
2. In review — опубликована в ограниченном круге (например, видна только операторам). На этом этапе её используют для проверки практикой, накапливают комментарии.
3. Published — публикуется широко, в т.ч. на портале для пользователей (если применимо).
4. Periodic review — раз в 3–6 месяцев владелец перепроверяет актуальность. Если что-то изменилось — правит. Если статья перестала использоваться — рассматривает retire.
5. Retired — снята с публикации. Сохраняется в архиве (для аудита), но не показывается в поиске. Альтернатива удалению, потому что на retired-статьи могут ссылаться старые тикеты.

Без явного жизненного цикла статьи живут «вечно» и неотличимы друг от друга по свежести — а это убийца доверия к БЗ.

KCS — Knowledge-Centered Service

KCS — это методология, разработанная Consortium for Service Innovation. Главная идея: знания создаются в процессе решения заявок, а не в специально выделенное время.

Четыре принципа KCS:

1. Создавай контент в момент работы. Оператор решил заявку → 2 минуты на запись решения в БЗ → закрытие тикета. Если выделять отдельное время «потом», статья не будет написана никогда.
2. Развивай контент в момент использования. Открыл статью, увидел опечатку или устаревший шаг → исправил прямо там же. Низкий порог редактирования.
3. Награждай за коллаборацию, не за объём. Метрика «кто больше статей написал» не работает. Работает: «кто чаще обновляет существующие», «чьи статьи чаще переиспользуются».
4. Прозрачность. Каждый оператор видит свою активность по KM. Это не KPI «должен сделать X статей», это видимость своего вклада.

KCS считается best practice для масштабных сервис-десков (от 30 операторов). На малых командах KCS-полноценный overkill, но принципы — особенно «писать в процессе» — работают везде.

Метрики Knowledge Management

Главные метрики, которые показывают, живёт ли БЗ:

• Reuse rate — сколько раз каждая статья была привязана к заявке / показана в поиске / решила запрос на портале. Цель: ≥ 70% статей используются хотя бы раз в квартал. Те, что не используются — кандидаты на retire или переписывание.
• Article freshness — средний возраст последнего обновления. Если медиана > 18 месяцев — БЗ устарела. Цель: меньше 9 месяцев.
• Self-service success rate — сколько пользователей нашли решение через БЗ и НЕ создали заявку. Связано с shift-left метриками.
• Time-to-publish — сколько проходит от первого появления проблемы до публикации статьи. Цель: первое решение → черновик в течение 1 дня, проверенная статья — в течение недели.

В TIQQET метрики KM считаются автоматически в админ-разделе «Аналитика → База знаний». Reuse rate подсвечивает статьи, которые не использовались > 3 месяцев — это сигнал «проверь и обнови или retire».

Теги vs иерархия: как организовать каталог

Классический спор: строить БЗ как дерево категорий или как плоский набор статей с тегами. Истина — комбинация:

• Дерево категорий отвечает на вопрос «где это лежит». Полезно для навигации: пользователь зашёл, увидел структуру, кликнул в «Доступ к сети → VPN».
• Теги отвечают на вопрос «что ещё связано». Одна статья про «настройку 2FA в VPN» может быть в категории «Безопасность», но иметь теги [vpn, 2fa, byod, ssh-keys] — и попадаться при поиске по любому из них.

Анти-паттерн — глубокая вложенность («Сеть → VPN → Windows → Корпоративный VPN → Pulse Secure → 2FA-аутентификация»). Никто не дойдёт до пятого уровня. Максимум 2 уровня вложенности; всё остальное — теги.