Управление знаниями является одной из ключевых составляющих организации процессов управления в ИТ.
Как известно, любая деятельность компании строится на «трех китах» — люди, процессы и технологии. Из этих «трех китов» лишь процессы и технологии являются собственностью компании, и их постоянство можно гарантировать.
Кадры решают все. Квалифицированные кадры — это успех бизнеса, качество работы подразделений и в итоге — качество результата.
Но при этом бизнес-процессы могут попасть в ловушку собственных кадров.

Профессиональные сотрудники — ключ к успеху, но когда огромная корпорация становится зависимой от отдельных инженеров, это не добавляет ей стабильности в работе. Инженер может уволиться, уйти к конкурентам или по каким-либо другим причинам прекратить выполнять свои обязанности. При этом возникает угроза нарушения бизнес-процессов компании.
Первичная защита от подобной ситуации — это прозрачность описания бизнес-процессов, поддержание данного описания в актуальном состоянии и регулярный аудит состояния процессов (см. статьи в Windows IT Pro/RE № 3, 5 за 2007 г.). Такие меры снижают вероятность сбоя налаженных процессов.
Тем не менее решение только этого вопроса не дает нам гарантий стабильности работы. Второй способ — внедрять в компании единый процесс управления знаниями, который будет охватывать уникальные для компании знания и гарантировать, что они не пропадут при любых кадровых перестановках.
Целью процесса управления знаниями, Knowledge Management, является хранение и поддержание в актуальном состоянии статей, описывающих специфику работы определенной ИТ-инфраструктуры, специалистов, использования технологий, поправки к документации, практические советы по исправлению ошибок и т. п.
Для успешной реализации процесса управления знаниями необходимо определить для компании следующие понятия:
1. Владелец процесса управления знаниями. Следует определить человека, который более других в компании заинтересован в существовании базы знаний, в ее актуальности и качественном использовании. Скорее всего, это будет CIO или руководитель ИТ-инфраструктуры, хотя может быть и другой ИТ-руководитель. Основная забота владельца процесса — финансирование запуска и поддержки процесса и определение метрик, ключевых показателей производительности (Key Performance Indicators, KPI) процесса и их целевые значения, т.е. то, что необходимо получить в качестве результата работы процесса.
2. Менеджер процесса управления знаниями. Необходим также сотрудник, который занимается непосредственно организацией процесса и подотчетен владельцу процесса по получению регулярных значений установленных метрик. Обычно это рядовой менеджер одного из подразделений ИТ-эксплуатации либо менеджер процесса управления инцидентами или процесса управления проблемами.
3. Формат и место размещения статей базы знаний.
4. Регламент доступа к статьям и правила создания и корректировки.
Теперь приведу несколько советов по организации процесса управления знаниями из практического опыта внедрения подобных систем.
Во-первых, вся корпоративная база знаний должна быть расположена в едином информационном пространстве и поддаваться единой системе поиска. Разрозненные файлы Word и Excel, архивы почты, заметки на бумаге — это если и можно назвать «базой знаний», то качественного управления знаниями мы на этом не построим.
Во-вторых, необходимо четко определить перечень полей одной записи. В качестве отправной точки предлагаются следующие поля.
Название статьи — заголовок статьи, раскрывающий тему.
Текст статьи. Подробное описание статьи. Необходимо иметь возможность добавлять файлы, вставлять графики и изображения для наглядности материала. Полезной также будет возможность писать текст статьи в формате Rich Text или html, что повысит наглядность материала.
Категория — категория знаний, к которой относится данная статья. Обычно категории удобно делать древовидными. Перечень категорий определяется менеджером процесса и на первых этапах внедрения может включать не более 10 наименований. Гораздо лучше добавлять наименования по мере необходимости, чем иметь разделы, в которых так и не появится ни одной статьи.
Статус статьи. Текущий статус, для которого могут быть определены следующие значения: «новая статья», «требует проверки», «актуально», «устарела», «архивная». Данный перечень не является окончательным и может быть скорректирован по мере необходимости и с учетом индивидуальной специфики компании.
Автор статьи — сотрудник, написавший статью в ее первичном виде.
Автор последней модификации — сотрудник, последний раз корректировавший статью. Следует отметить, что ответственность за точность данных в статье ложится именно на автора последней модификации, а не на первоначального автора.
Список согласования/визирования — перечень лиц (один или больше), которые проверяют корректность статьи, общую правильность изложения, корректность использования языка и т.п. Только после прохождения всех этих проверок можно объявлять статью «актуальной». Теоретически можно обойтись и без этого, но на практике без подобных проверок в базе знаний начинается неразбериха буквально через 2-3 месяца (после первых 50-100 статей).
Рейтинг статьи. Данный индикатор должен показывать популярность статьи, ее корректность, наглядность и частоту использования. Для создания такого рейтинга необходимо при автоматизации данного процесса сделать так, чтобы пользователь, прочитав статью и воспользовавшись полученным знанием, мог пометить ее флажком «Мне это помогло».
Рейтинг статей является достаточно важным параметром в управлении знаниями и выполняет еще одну важную функцию — формирует перечень статей для первичного обучения сотрудников службы поддержки Service Desk.
Как известно, во многих дежурных службах существует проблема текучести кадров. На фоне общего кадрового голода в ИТ-департаментах руководители подразделений рассматривают службу поддержки Service Desk как кузницу кадров и не преминут утащить из нее самых квалифицированных и перспективных сотрудников.
В результате перед руководителем Service Desk встает задача подготовки кадров, и система рейтинга статей базы знаний ему очень поможет. Обычная картина: на Service Desk приходит новый сотрудник, перед ним кладется стопка документации на текущие системы со словами «Разбирайся, мы это эксплуатируем». Обучение может занять недели, причем это будет голая теория, которая зачастую отличается от того, как система работает на самом деле. Вместо этого сотрудник может прочитать «топ 20» статей из базы знаний (которые написаны, как правило, более понятным языком, с большим количеством контекстных комментариев, чем официальная документация по программному продукту), и как результат через день-два мы уже получим инженера, который худо-бедно, но сможет уже решать проблемы. Результат налицо.
В отношении работы Service Desk хотелось бы напомнить организаторам процесса управления знаниями, что основной механизм работы базы знаний заключается в том, что знания передаются от более старшей линии поддержки к младшим. В этом случае основная цель статей в базе знаний — передать знания в простой и понятной форме на первые линии поддержки с целью снижения средней стоимости устранения инцидентов и обработки заявок пользователей. Для доказательства эффективности данного метода можно применить следующий простой механизм, который работает даже при отсутствии в ИТ процесса управления финансами (Financial Management).
Для каждого сотрудника заводится некий параметр Billing Rate, который показывает ориентировочную стоимость времени данного сотрудника для компании. Это может быть условная величина, не обязательно выраженная в денежном эквиваленте. После этого в каждый инцидент или заявку вводится поле «Стоимость», основанное на времени решения инцидента, и Billing Rate сотрудника. В итоге при активном использовании базы знаний и ее действительной актуальности и наглядности можно проследить, что за несколько месяцев средняя стоимость инцидента заметно сократится. Снижение данного показателя хотя бы на 20-30% (на ранних стадиях развития процесса — отличный показатель) свидетельствует о том, что база данных работает и выполняет свои функции.
Для успешного развития процесса управления знаниями можно напомнить еще о некоторых принципах:
1. Проводите PR процесса. Подпишите всех пользователей базы знаний на новости о появлении свежих статей и обновлении имеющихся.
2. Проводите онлайн-тренинги (webinar) по наиболее сложным статьям для персонала, кому это необходимо (обычно это сотрудники Service Desk).
3. Выкладывайте в общий доступ основные метрики процесса: количество статей, рейтинги, наиболее активных пользователей.
4. Поощряйте авторов и корректировщиков статей, чтобы база знаний регулярно пополнялась свежей и актуальной информацией без административного принуждения сотрудников. На практике случались ситуации, когда сотрудники просто выполняли норму «по 10 статей от каждого», заполняя базу знаний ненужной информацией.
5. Следите за актуальностью имеющихся данных. Все устаревшие статьи должны переводиться в архив. Без этого вера сотрудников в эффективность базы знаний сойдет на нет через несколько месяцев с начала работы.
Хотя процесс управления знаниями не вошел во вторую версию библиотеки ITIL, третья версия уже содержит достаточно подробное описание элементов этого процесса (книга Service Transition, раздел 4.7).
По вопросам практической организации данного процесса, проведения тренингов и консалтинга можно обращаться к автору статьи.
Руслан Акмеев (rakmeev@microsoft.com , ruslan@akmeev.ru ) — консультант по организации ИТ-процессов, Microsoft Consulting Services, Russia