Трекер Notal System: рассылка уведомлений (часть 2)

Интерфейс редактирования наборов критериев

Каждый набор критериев должен иметь уникальный номер (присваивается автоматически), для удобства каждый набор снабжаем именем. Наборы критериев должны быть видны в виде таблицы. Для редактирования наборов критериев должны быть кнопки:

• Создать новый
• Копировать (создать новый копированием)
• Редактировать
• Удалить

Редактирование набора критериев выполняется в отдельном окне.

Эту таблицу наборов критериев в конфигураторе разместить в бизнес-процессе отдельным пунктом (по аналогии с ролями).

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

Интерфейс редактирования одного набора критериев (специальное окно) должен включать в себя две части:

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

Отправка уведомлений по почте и через SMS - общие принципы

Это надстройка для системы, рассылать будем (или не будем) все те извещения, которые есть для пользователя в системе. Никакой дополнительной фильтрации не предусмотрено.

Пользователь сам устанавливает, будет ли он получать уведомления на почту и/или через SMS. Это потребует дополнения информации о пользователе следующими полями:

• Адрес электронной почты
• Мобильный телефон
• Флаг "Получать уведомления на почту"
• Флаг "Получать уведомления через SMS
• Префикс почтовых сообщений (см. ниже)

Все это надо разместить в интерфейсе пользователя с правом редактирования (по аналонии со сменой пароля).

Отправка уведомлений по почте

Письмо делается на основе внутреннего уведомления системы и содержит его текст полностью. Необходимые дополнения:

• Текст письма должен содержать ссылку на открытие задачи
• Заголовок письма начинается с префикса (см. след пункт) и содержит аббревиатуру бизнес-процесса и номер задачи
• Префикс письма нужен для возможности настройки пользователем сортировки входящих писем его почтового ящика. Поэтому пользователь может сам задать префикс для уведомлений. Если пользователем префикс не задан, используем "Notal System: ".
• Отправитель - ? Входящая почта все равно приниматься не будет - лучше чтобы не было возможности ее отправить.

Отправка уведомлений через SMS

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

В настоящий момент не реализуем и считаем, что вопрос требует додумывания.

Трекер Notal System: рассылка уведомлений (часть 1)

Постановка проблемы

Пользователям полезно оперативно получать информацию о происходящем с задачей, особенно если эта задача не у них на исполнении. К примеру:

• автору или владельцу задачи полезно узнать, что его задача отрицательно завершена
• исполнителю полезно узнать, что задача передана другому
• возможным исполнителям полезно узнать, что в накопителе (ждущем состоянии) появилась новая задача

Все это решается механизмом внутренних уведомлений системы с возможностью отправлять эти уведомления вовне по e-mail или через SMS.

События, которые могут являться основанием для уведомления

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

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

Содержание уведомлений и их хранение

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

Уведомления должны быть организованы как таблица базы данных, которая отображается разными способами: в пользовательском интерфейсе Notal System, как исходные данные для отправки почты или SMS. Для последних стоит завести соответствующие поля таблицы, в которых отмечать, что соответствующее сообщение отправлено.

Редактирование уведомлений не предусмотрено. Чистка истории уведомлений "ранее выбранной даты" может быть реализована в интерфейсе конфигуратора для пользователя с полными правами администратора.

Создание уведомлений: критерии отбора событий

Как сказано выше, уведомления имеют в основе появление комментария к задаче. Поскольку не каждый комментарий стоит того, чтобы делать из него уведомление, то необходим набор критериев, удовлетворив которым коммент породит уведомление. По аналогии со спам-фильтрами надо иметь возможность задать несколько наборов критериев для уведомлений. Каждый такой набор может иметь свой список адресатов.

Набор критериев создается для конкретного бизнес-процесса.

Комментарий должен соответствовать всем критериям набора, чтобы породить уведомление.

Первый критерий - тип комментария. Мы имеем комментарии трех типов:

• Движение
• Служебный
• Пользовательский

Выбираем один или несколько типов комментария.

Второй критерий - состояние. Мы можем указать конкретное состояние или определенный тип состояния:

• Активное
• Ждущее
• Финальное (без разделения)
• Финальное положительное
• Финальное отрицательное
• Любое состояние
• (Конкретное состояние)

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

Третий критерий - теги задачи. Мы можем указать перечень тегов и способ их обработки "и"/"или". Если теги не выбраны, то критерий считается удовлетворенным.

К каждому комментарию применяются все имеющиеся наборы критериев - даже если удовлетворяет одному, то у другого набора могут быть другие адресаты.

Адресаты уведомлений

В каждом наборе критериев должен быть указан адресат или механизм создания адресатов. Имеем три варианта:

• Конкретный адресат
• По ролям
• По выделенным пользователям задачи

Вариант конкретного адресата наиболее прост и должен быть реализован в интерфейсе пользователя, при этом адресатом является он сам. Т.е. это для того, чтобы пользователь мог сам настроить себе рассылку уведомлений.

Второй вариант - указание адресатов по ролям. Указываем одну или несколько ролей, пользователи с которыми должны получать уведомления.

Третий вариант - указание выделенных пользователей задачи. К выделенным пользователям задачи относятся:

• Автор
• Владелец
• Основной исполнитель
• Текущий исполнитель
• Исполнитель до совершения движения - имеет смысл, если задача при движении меняет исполнителя.

Можно выбрать несколько пунктов или не выбирать ни одного.

Второй и третий вариант могут присутствовать одновременно. Эти варианты адресатов доступны при создании рассылки в интерфейсе конфигуратора. Права на создание/редактирование рассылки есть у администратора бизнес-процесса.

Автору действия не отправляется уведомление, даже если он удовлетворяет критерию адресатов рассылки. Это логично - он сделал действие, его незачем уведомлять о нем.

Адресат уведомления должен иметь право просмотра задачи. То есть по предыдущим критериям определяется набор пользователей, кому отправить уведомления, и этот набор прогоняется через фильтр прав на просмотр задачи - если пользователь не имеет права смотреть задачу, то ему и незачем получать уведомления о ней.

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

Заблокированные пользователи не могут получать уведомления - уведомления для них просто не должны создаваться.

Интерфейс просмотра уведомлений

На панели пользователя зарезервирована ссылка на уведомления - просматривать их будем на специальной странице, где они выводятся в обратной хронологической последовательности. Количество показываемых уведомлений и навигация просмотра - как удобнее реализовать. Желательно наличие фильтров уведомлений по следующим критериям:

• Бизнес-процесс
• Тип комментария
• Тип состояния

Уведомление должно являться ссылкой на открытие соответствующей задачи в новом окне (по аналогии с реестром задач).

Интерфейс редактирования наборов критериев

Для удобства каждый набор снабжаем именем, нумеруем все наборы по порядку. Наборы критериев должны быть видны в бизнес-процессе в виде таблицы (в интерфейсе конфигуратора ясно, где расположить в интерфейсе пользователя?).

(продолжение следует)

Open Office Basic - функция Shell

Клиентская часть трекера Notal System встроена в Open Office и потому писалась на опенофисофском бэйсике. С ним какая проблема - пишут на нем мало, так что найти решение каких-либо проблем в сети не получается. Вот решил выкладывать сюда записки - больше себе для памяти.

Функция Shell и перенаправление вывода в файл

Плюсом OO-реализации этой функции является то, что в отличие от VBA она имеет синхронный режим, т.е. следующая команда будет отрабатываться только после завершения Shell (полезно, если используешь ее для вызова внешней программы для кодировки большого файла - время работы предсказать трудно и измеряться оно может секундами). Но есть засада: если надо вызвать внешнюю программу и перенаправить вывод в файл, то файл-то создается, но нулевой длины. Комбинация с Environ не помогает.

РЕШЕНИЕ: написать bat-файл с нужной командной строкой с перенаправлением вывода и уже его вызывать через Shell.

PS. Для таких записок завожу отдельный тег "OO Basic"

Notal System - наш трекер

Давно не писал сюда, возобновляю. За прошедший почти год трекер получил имя Notal System, получил свой сайт notalsystem.ru и свою wiki, где раполагается документация. На основе Notal System на нашем заводе автоматизированы три бизнес-процесса, один из них - маркетинговая подготовка производства (о ней как-нибудь напишу подробнее). Сейчас этот трекер внедряется в двух сторонних организациях - в общем, нормальная жизнь продукта. Какие плюсы:

• наглядное представление бизнес-процесса в виде диаграммы состояний - это понятно даже коммерсантам
• веб-интерфейс
• интеграция с офисными программами - Ms Office и Open Office
• наличие API, что позволяет интегрировать с любыми программами, способными отправлять и принимать веб-запросы (у нас на заводе интегрировано с 1С)
• удобно использовать для управления инцидентами - можно реализовать ITIL, к примеру

Некоторые недостатки (временные, разумеется):

• пока не сделано управление временем - у задачи нет срока исполнения. Это не мешает текущему управлению в том смысле, что можно посмотреть, сколько задача находится у исполнителя, не превышен ли норматив; а вот планировать на будущее пока неудобно
• во встроенном электронном архиве документы хранятся с историей версий, но пока не реализованы состояния документа - черновик/утвержден/отменен и т.п.

В общем, есть куда развиваться. Да, если вам интересно попробовать поработать с Notal System, то пишите мне на notal@nm.ru - сделаем вам свою базу, срок пробного использования два месяца.

Управление временем в трекере

1. Постановка проблемы

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

2. Что есть исполнение планового срока?

Пусть задаче назначен срок. Как понять, исполнен он или нет? Какое событие, происходящее с задачей, должно фиксировать момент фактического наступления запланированного события? Прежде всего считаем, что:

• у задачи планируется только одна контрольная точка на ее маршруте.
  
• попадание задачи в любое финальное состояние является наступлением запланированного события, если оно не наступило раньше (не отмечено в задаче как наступившее).

Но одних финальных состояний недостаточно для отслеживания сроков задачи. К примеру, в трекере модельной оснастки наступлением срока будет считаться еще и переход в состояние "Поставить на контроль в 1С", поскольку реально задача будет завершена только после акта разметки, т.е. когда по этой оснастке будет выпущена отливка. Но планируем мы только время изготовления, так что как факт наступления срока добавляем следующую возможность:

• первое попадание задачи в одно из выделенных состояний.

В задаче заводим реквизит факт наступления срока типа "дата", туда записываем эту дату. Кроме того, пишем служебный коммент, в котором отмечаем это событие.

Назначение события как факта исполнения делаем не для задачи, а для диаграммы. Т.е. мы не можем установить, что задача 1 считается исполненной при попадании в состояние 7, а задача 2 - при попадании в состояние 5; нет, правило устанавливается на уровне диаграммы: задача считается исполненной при попадании в любое из состояний 5, 6, 8. Реализовать это можно установкой флажка в состоянии.

3. Виды сроков

Срок типа "конкретная дата" не очень удобен - для отдаленных планов это слишком большая конкретика, удобнее планировать "в ноябре", "в 3 квартале" и т.п. Фактически задаче мы назначаем интервал времени. Поскольку задачи понимаются как нечто достаточно элементарное, то для крупных временных интервалов можно считать, что задача должна начаться и завершиться в этом периоде (требуется еще продумать этот момент).
Мы рассматриваем следующие календарные сроки:

• Дата
  
• Неделя (№ недели в году + год)
  
• Месяц (+ год)
  
• 1-4 неделя месяца (экзотика, но у нас используется в планировании производства)
  
• 1-3 декада месяца (у нас не используется и пока не делаем)

Кроме календарных сроков, т.е. имеющих жесткие привязки к календарю (дату начала и дату конца), удобно планировать по условным этапам или итерациям. Эти периоды не обязательно имеют даты начала/конца, но мы считаем, что они имеют определенную длительность - к примеру, по две недели. Тогда мы можем спланировать проект и оценить его трудоемкость и сроки в условных периодах, не зная еще даты запуска проекта (начальной даты первого периода). Этап/итерация это специальный объект со следующими свойствами:

• этапы рассматриваются сразу рядами: А1, А2 ... Аn. Относительно этапов в ряду считаем, что они идут один за другим и не пересекаются. Нам потребуется несколько рядов этапов для того, чтобы иметь возможность планировать независимые проекты.
  
• каждый этап имеет дату начала и дату конца (привязка к календарю), но они могут быть и на начальном этапе планирования будут пустыми. То есть мы создаем ряд этапов, раскидываем задачи проекта по этапам и потом устанавливаем конкретные даты этапам, причем не обязательно всем - можно только начальным, а более поздние пока без календарной привязки.
  
• для ряда этапов устанавливаем единую плановую длительность этапа - две недели, месяц - как выберем.

4. Назначение сроков задаче

Задаче могут быть назначены несколько сроков из разных рядов: к примеру, месяц Март и 12-я неделя года, этап А3 и этап В8. Из каждого ряда может быть назначен только один срок (что естественно, поскольку периоды в ряду не пересекаются). При назначении срока проверяем, не вступает ли он в конфликт с уже назначенными сроками: так при назначении срока "12-я неделя" мы должны проверить, что она пересекается со сроком "Март".
При назначении этапов А3 и В8 если у них указаны даты начала и конца, то проверяем, если не указаны - можем назначать.
По сути сроком задачи будет пересечение всех назначенных ей сроков, т.е. для задачи можно вычислить дату начала и дату конца. Эти даты не редактируются вручную, а пересчитываются при назначении срока задаче (в том числе при отцеплении задачи от ранее назначенного срока: был Март, сменили на Апрель или вообще убрали привязку к месяцу).
Дата начала не несет особого смысла - мы можем начать задачу и раньше, можем и позже. Важной является лишь дата конца и именно по ней мы будем определять, уложилось ли фактическое выполнение (см. п. 2) или нет.

5. Назначение срока этапу

Сроки этапов подчиняются следующим правилам:

• Этапы в ряду не пересекаются и идут по возрастанию
  
• При назначении дат начала и конца этапа необходимо учитывать уже назначенные сроки задач, входящих в эти этапы

Второе правило рассмотрим подробнее. При назначении дат начала и конца этапу они должны быть такими, чтобы ни у одной из входящих в этап задачи не возникло несовместимых сроков. Для этого по всем срокам всех задач этого этапа считаем C1 = max(ДатаНачала_k) и C2 = min(ДатаКонца_k). Условиями совместимости дат этапа с уже назначенными сроками будут:

ДатаНачалаЭтапа < C2
ДатаКонцаЭтапа > C1

6. Специальные операции с рядами этапов

Ограничения предыдущего пункта все равно не позволяют однозначно вычислить даты этапов, а кроме того не проверяется совместимость соседних этапов. Для этого добавляем еще граничные условия от соседних этапов - этапы должны быть последовательны и не пересекаться. У нас есть три варианта расчета:

• Расчет от более ранних этапов к более поздним - расчет от старта проекта
  
• Расчет от более поздних этапов к ранним - успеть к сроку
  
• Пересчет единичного этапа, предшествующий и следующий этапы считаем фиксированными

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

7. Взаимозависимость задач

Кроме описанных выше сроков полезно уметь учитывать взаимозависимость задач. К примеру, задача 56 требует того, что описано в задаче 48. Это не значит, что для начала задачи 56 требуется, чтобы была завершена задача 48 - часто достаточно выполнения только части ее. Поэтому рассматриваем эту зависимость как "начало-конец": задача 56 не может завершиться без того, чтобы началась задача 48. на языке сроков это означает следующее: в любом ряду этапов или календарных сроков (месяцев, недель), которые назначены обеим задачам, этап задачи 48 не может быть позже этапа задачи 56. Здесь мы неявно считаем, что задачи достаточно невелики и полностью укладываются в рассматриваемые этапы. Если рассматриваемые этапы достаточно велики (хотя бы неделя), то это вполне корректное предположение.
Соответственно, необходимо сделать следующие механизмы:

• Указание задаче списка предшествующих задач
  
• Построение дерева зависимых и зависящих задач
  
• Проверка корректности сроков зависимых задач относительно ряда календарных сроков или ряда этапов - т.е. проверяем, правильно ли раскиданы задачи по месяцам или по этапам

Управление правами в трекере

1 Общие положения
Управление правами осуществляется на основании ролей. В роли прописаны права на действия. Каждое право либо дано, либо нет.
Стоит сделать вектор (массив) объектов прав (то, на что устанавливаем права) и по этому образцу задавать права у ролей.
Права считаются независимыми друг от друга (т.е. при установке права не проверяется, есть или нет какие-то другие права).
Каждый пользователь может иметь несколько ролей. Права пользователя определяются объединением прав ролей, т.е. операцией .or. над векторами прав.
Каждое действие совершается, если у пользователя есть права хоть по одному основанию (особенности при движении, чтобы результат не вызвал противоречия с другими правами).

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

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты
Часть действий (критически важные) сопровождаются служебными комментариями со стандартным текстом.

2.1 Создание инцидента
Да/нет

2.2 Просмотр инцидента

я — Исполнитель: всегда да!

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.3 Передача инцидента

я — Исполнитель: всегда да!

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.4 Комментирование

я — Исполнитель: всегда да!

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.5 Редактирование текста инцидента

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты
Существенная особенность: редактирование текста инцидента не-Исполнителем возможно только в неактивном состоянии.

2.6 Изменение приоритета инцидента

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.7 Редактирование тегов инцидента
Назначение/удаление тегов у инцидента. Считаем теги, так же как и приоритет, не критичными для сохранения истории, поэтому не разделяем операции назначения и удаления тегов.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.8 Выбор рамочной задачи
Действие представляет собой ситуацию {номер рамочной задачи пуст} => {номер рамочной задачи непуст}.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.9 Очистка рамочной задачи
Действие представляет собой ситуацию {номер рамочной задачи непуст} => {номер рамочной задачи пуст}.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.10 Изменение рамочной задачи
Действие представляет собой ситуацию {номер рамочной задачи непуст} => {номер рамочной задачи непуст и не совпадает с начальным}.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.11 Прицепление файла
Действие представляет собой добавление нового файла из ЭА.

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

2.12 Отцепление файла

я — Исполнитель

я — Автор

я — Основной исполнитель

я — Владелец

все инциденты

3 Состояние
Важное отличие прав на состояние от прав на инциденты состоит в том, что права на инциденты устанавливаются как по их свойствам, так и индивидуально.

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

все состояния

активные

ждущие

финальные

<по каждому состоянию индивидуально>

3.2 Быть исполнителем в состоянии
Показывает то, что данный исполнитель может быть исполнителем для инцидентов в данном состоянии.

активные

<по каждому состоянию индивидуально>

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

4.1 Переход без доп.условий

все переходы

<по каждому переходу отдельно>

4.2 Переход в ситуации «я — Исполнитель»
Действие представляет собой ситуацию {задача в состоянии А, исполнитель Иванов} => {задача в состоянии Б (возможно Б=А), исполнитель Иванов}, т.е. некий переход вообще может быть недоступен, но доступен для пользователя, если он является текущим Исполнителем инцидента. При таком движении исполнитель не изменяется. Если данного пользователя нет в списке возможных исполнителей конечного состояния перехода, то такой переход не должен быть доступен вне зависимости от этого права.

все переходы

<по каждому переходу отдельно>

4.3 Переход в ситуации «я — Владелец»
Это возможность Владельцу дать права на движения его инцидентов.

все переходы

<по каждому переходу отдельно>

5 Прочие права
Прочие права должны описывать доступ к следующим объектам:

Реестр инцидентов

Отчеты (когда они будут написаны)

Создание/изменение текста тегов

...и т.д.
Доступ к файлам управляется на уровне прав электронного архива.
Все это будет описано в отдельном документе.

Цели и структура корпоративной 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, что я видел в сети, это не настроено)

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

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

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