Цели и структура корпоративной wiki

Иметь корпоративную wiki сейчас модно. Хочется разобраться, что полезного стоит за этой модой. То есть выявить возможные цели, средства и спроектировать структуру базы знаний - именно сюда относят wiki-системы.

1. Цели, они же проблемы

Что является проблемами при работе со знаниями? Знания и умения - это то, что в головах работников. Отсюда первый риск:

• Риск утраты знаний при увольнении сотрудника. Для детализации необходимо определить список ключевых областей знания, возможность описания этих знаний (и форму этого описания), выявить ключевых носителей этого знания и умеют ли они писать связные тексты.

Это наиболее обсуждаемый в литературе риск, но не уверен, что он является наиболее опасным - есть такая вещь, как корпоративная культура, и она же является механизмом передачи знаний (хотя далеко не всегда эффективным).
Собственно, рассмотренный риск является едва ли не единственным собственно риском - когда убытки связаны с неким малопредсказуемым событием. Неотчужденность знаний связана и с другими затратами, которые проявляются постоянно. Вот некоторые из них:

• Затраты времени на интеграцию новых сотрудников. При приеме нового сотрудника тратится время двоих: и новичка, и обучающего его более опытного сотрудника. Если же есть база знаний (описания бизнес-процессов и т.п.), то можно сократить по крайней мере затраты времени опытного сотрудника - ему меньше придется рассказывать.
  
• Риск дисбаланса бизнес-процессов при их изменении. Как правило, серьезные бизнес-процессы затрагивают несколько подразделений компании, поэтому если одно подразделение решит оптимизировать этот бизнес-процесс у себя, то оно может существенно усложнить работу других подразделений. Часто требуемые изменения в действиях смежных подразделений невелики - проблема только в том, чтобы вовремя их известить об изменении (по уму - согласовать изменение бизнес-процесса с ними). Описание бизнес-процесса в базе знаний решает часть этой проблемы: теперь руководитель подразделения может хотя бы увидеть, с кем стоит согласовать изменение бизнес-процесса (связи могут быть весьма неочевидными).
  
• Затраты времени на поиск информации об особенностях редко используемых бизнес-процедур. Обычный вопрос: "как работает этот документ?". Вопрос важен как для пользователя, так и для IT-службы, отвечающий за поддержку и доработку учетной или ERP-системы. Нужна документация, которая описывает то, что называется "учетной политикой" - некие экономические (или процедурные) предположения, принятые как описание среды. То, что не ясно из алгоритма, из самого кода программы. Это скорее ответ на вопрос "почему это так сделано". Это что касается вопросов программиста. У пользователя вопросы проще - как это работает, какие кнопки нажимать? Документация или контекстный help решают эту проблему как для пользователя, так и для программиста, причем это одна и та же документация. Критически важный вопрос - своевременность и простота обновления документации.
  
• Затраты времени на поиск информации на поиск ответа на нечетко сформулированный вопрос. К примеру: "каким отчетом я могу посмотреть такую информацию?", "как можно сделать то-то?" и т.п. Принципиальной тут является открытость списка вопросов и нечеткость их формулировок. Решением является поиск по тексту базы знаний - при достаточном ее объеме что-либо полезное выловится.

В статьях на тему менеджмента знаний встречается еще несколько целей базы знаний:

• Поиск эксперта по проблеме среди сотрудников. Обычно используется в программистских фирмах - кто из сотрудников работал с такой-то библиотекой и т.п.
  
• Быстрый поиск ответов на типовые вопросы клиентов. Особенно важно для сервисных служб. Такой функционал удобно интегрировать в CRM-систему.

Не думаю, что последние два пункта актуальны для нашего завода.

Определившись с целями создания базы знаний осталось определиться с тремя вещами:

• Виды информации в базе знаний
  
• Структура информации - рубрикация, категории, поиск и т.п.
  
• Выбор конкретного программного решения

Рассмотрим их по порядку.

2. Виды информации в базе знаний

В дальнейшем изложении я рассматриваю актуальные для нашего завода виды информации.

2.1. Неспециальная или общая информация

Информация, которая может быть потенциально интересна любому сотруднику предприятия:

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

Скорее всего, этот список будет пополняться.

2.2. Специальная информация

Информация, имеющая свой круг пользователей (остальным просто не нужна):

• Описание бизнес-процессов (см. п.1). Бизнес-процессы должны описываться единообразно, т.е. в одной-двух нотациях, чтобы быть сопоставимыми.
  Отдельный и весьма интересный вопрос, должны ли эти описания являться нормативными документами. Противоречие здесь в следующем: само понятие знания предполагает отражение того, как есть на самом деле и именно в этом ценность; нормативный же документ описывает должное и не всегда это должное достижимо, удобно или практично. Система менеджмента качества обязывает согласование всех изменений со всеми заинтересованными лицами, что не очень вяжется с понятием "знания". Это явно проблема, которую надо додумать.
  
• Учетная политика. Здесь имеется в виду не столько бухгалтерская учетная политика, сколько предположения о внешней среде и обычных предположениях деятельности. К примеру: "все контрагенты делятся на две группы, для первой применяем одну модель планирования, для остальных - другую", "двуместный монтаж оснастки предполагает, что обе отливки одинаковы; теми редкими случаями, когда это не так, пренебрегаем и обрабатываем их вручную". Такие предположения можно выявить при анализе алгоритмов работы инфосистемы (если соответствующий процесс автоматизирован), но гораздо полезнее иметь их явное описание.
  
• Описание инфосистемы, вернее всех входящих в нее компонентов. В частности, у нас есть описание нашей конфигурации 1С на нескольких уровнях, нижним из которых является описание элементарного объекта, его назначения и способов использования:
  
  • Справочник
    
  • Документ
    
  • Отчет
  
  Эти описания нижнего уровня встроены как контекстный help в диалоговые окна этих объектов.
  Также с имеется описание других систем автоматизации бизнес-процессов - мы используем трекер с набором диаграмм состояний для различных бизнес-процессов и процедур.
  
• Методическая информация - если мы используем формализованные описания бизнес-процессов, то надо научить пользователей базы знаний понимать эти записи. То есть требуется описать используемые нотации записи и т.п.
  
• Очень специфическая информация - в нашем случае это описание архитектуры инфосистемы и алгоритмов, т.е. информация только для программистов (очень небольшого отдела на заводе). Возможно, металлурги и конструкторы тоже имеют подобные специфические для них знания, которые стоило бы внести в базу знаний - посмотрим позже, по практике использования.
  
• Теоретическая информация - всевозможные статьи, опубликованные сотрудниками завода. Эти знания не вполне адекватны для корпоративной базы знаний (они не обязательно имеют отношение к работе предприятия), но это сама по себе ценная информация, которая может оказаться полезной.

Последняя категория информации выделяется по критерию авторства: только здесь имеет смысл автор материала. Этот вид информации годится для поиска экспертов среди сотрудников (см. п.1).

3. Структура информации в базе знаний

Имеется в виду структура организации информации. Электронный вид хранения информации позволяет структурировать информацию одновременно многими способами. Первый из них - по разделам. Вот, к примеру, как выглядит наш раздел информации по 1С (выдержки):

Производственное планирование

Общее устройство производственного планирования

Нормативная производственная информация
Техусловия
Нормы материалов на производство продукции и техпроцесс
Нормы вспомогательных материалов

Баланс деталей и учет НЗП
Баланс времени
Основные производственные виды деятельности

Стальное литье
Цветное литье
Электрошлаковое литье
Механическая обработка
Участок ИДЛ

Потребность в материалах

Отчеты норма/факт

Планы производства

Создание планов производства
Понедельное перепланирование
Сменные задания
Отчеты план/факт

Управление качеством продукции

Техусловия
Сертификаты
Управление требованиями к проверке качества опытных отливок

Бухгалтерский учет

Учет затрат

Прямые затраты и общепроизводственные расходы
Коммерческие расходы
Управленческие расходы

Учет НДС

Общий учет НДС
Экспортный НДС

Учет ТМЦ
Учет оплаты труда

Оплата труда как затраты
Учет оплаты труда в механическом производстве
Учет оплаты труда по заказам на производство

Учет реализации

Структура 90-х счетов
Документы реализации по видам деятельности

Управленческий учет

На более низких уровнях расположены описания конкретных справочников, документов и отчетов.
Разделение статей по категориям решает одну важную проблему - набор шаблонов статей. Сходные сущности должны быть описаны единообразно. У нас имеются шаблоны статей для описания справочников, документов и отчетов 1с, сейчас разрабатываются шаблоны описаний бизнес-процессов и т.д.

Параллельно с вышеприведенной классификацией каждая статья снабжена списком категорий, в которых отражается раздел, бизнес-процесс, тип статьи (к примеру, "1С-документ") и т.д. Набор категорий в настоящее время разрабатывается.

Имеется также наборы рекомендованных статей по подразделениям завода. Они предназначены для обучения новых сотрудников или при автоматизации очередного бизнес-процесса - что прочесть сотрудникам, чтобы быстро войти в курс дела. Такие рекомендательные списки удобно держать отдельно, а не в виде категорий - в них стоит включать наиболее важные материалы, а остальное при нужде сотрудники найдут сами.

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

В некоторых wiki-движках встречается механизм случайная статья, который открывает случайную статью из базы знаний. Хороший механизм для тех баз, в которых лежит в основном теоретическая информация и персонал мотивирован на чтение. Для нашего заводе этот механизм необязательная игрушка.

4. Конкретное программное решение

Прежде всего было решено, что это должен быть wiki-движок. Потому что:

• Работает в любом браузере
  
• Легко писать и править статьи
  
• Хранятся все версии статьи
  
• Легко развернуть на имеющихся серверах
  
• Свободное (бесплатное) ПО
  
• Народ работал с википедией и легко освоит построенную на таком же движке базу знаний

Каждая статья имеет свой адрес, что позволило легко реализовать контекстный help в 1С и остальных системах автоматизации.
Наиболее популярным движком является media-wiki, но мы выбрали doku-wiki, больше случайно, чем осознанно. Плюсы doku-wiki:

• Все данные хранит в текстовых файлах, не требует базы данных
  
• Очень просто освоить и начать использовать
  
• Стандартный набор стилей позволяет распечатывать статьи без элементов управления и навигации (к слову, во многих media-wiki, что я видел в сети, это не настроено)

Вместе с тем есть и минусы:

• Достаточно бедная работа с картинками, невозможно вести историю версий картинки
  
• Нет встроеннного механизма категорий, требуется устанавливать плагин
  
• Встроенный поиск не учитывает русскую морфологию, требуется устанавливать плагин

В общем, решение вполне приемлемое.
Процесс внедрения и оценка результатов находятся за рамками этой статьи (хотя бы потому, что все в самом разгаре).