Где публиковать регламенты?

Это сообщение – копия рапорта site@lessi:trako/3

Надо создавать базу знаний по управлению и там публиковать должностные инструкции.
НПЖ не подходит т.к. не поддерживает следующую функциональность (акшн) вики (ещё не проверял):

• BackLinks — ссылки на данный документ – работает
• OrphanedPages — список документов, на которые нет ссылок,
• WantedPages — список документов, на которые есть ссылки, но которые ещё не созданы,
• Search — различные поиски.

Кроме того в вики можно подписаться на отдельную страницу, в НПЖ (если я правильно понял) – только стать наблюдателем в РГ

В своё время я отказался от WackoWiki в пользу НПЖ
Использовать другую вики мне бы не хотелось – сотрудникам надо осваиваться с другими правилами разметки и интерфейсами

По результатам работы в комментариях к этому сообщению был создан документ management@lessi:БазаЗнанийПоУправлению

 

Комментарии к этому сообщению:

Системы управления

Есть три системы управления:

• функциональная,
• проектная,
• программная.

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

1. Отбор (выбор) цели для реализации происходит через обзор рапортов с определённым статусом с учётом приоритетов (стратегии) компании.
2. Уточнение цели происходит через комментарии к рапорту.
3. Достижение цели происходит через создание рабочей группы и выделение ей ресурсов.
4. Рабочая группа координирует свою деятельность с помощью списков задач и встреч.
5. Мотивация и публичный контроль за работой РГ может быть реализована через возможность для заинтересованных лиц стать наблюдателем в РГ.

Функциональный
Можно делать так же через РГ типа комитет. Совет директоров это пример комитета, осуществляющего функциональное управление.
Но в функциональном управлении главное не группа, а документ. Т.е. функциональное управление осуществляется через создание и поддержание в актуальном состоянии базы регламентирующих документов.

 

#797 @ 23:17 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

База регламентирующих документов

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

#798 @ 23:26 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Порядок разработки и утверждения документа

Порядок разработки и утверждения документа должен соответствовать логике процесса.
Например для Совета директоров

1. должен быть баг-трекер, где накапливаются вопросы.
2. в ходе (закрытого) обсуждения (в виде комментариев) вырисовываются варианты решения – предложения на Совет.
3. в ходе Совета обсуждается уже не вопрос, а варианты решения
4. в ходе Совета происходит голосование или вопрос отправляется на дальнейший поиск путей решения

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

#799 @ 23:29 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Процесс работы с регламентирующим документом

Этапы работы с документом:

1. Подготовка
2. Согласование
3. Утверждение
4. Публикация
5. Актуализация

Всё это желательно делать в единой базе с соответствующими механизмами разграничения прав доступа и оповещениями.

#801 @ 23:33 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Разные процессы для разных типов документов

Менеджеры управляют тремя вещами:

• Политиками,
• Процедурами,
• Показателями.

Возможно это три разных типа документов, которые имеют разный процесс прохождения документа.

#808 @ 09:59 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Показатели отображаются в отчетах. Для работы с показателями лучше подходят 1С, Парус, SharePoint. Значит процесс прохождения этих документов лучше описывать там. Максимум, на что может претендовать база знаний по управлению – иметь возможность вставить отчёт в тело страницы в виде:

• таблицы,
• картинки (график),
• html

Это требуется для:

• единого места публикации,
• единого адресного пространства (сохранение целостности ссылок при обновлении отчёта)
• единой системы разграничения прав доступа
• организации обсуждения
• упрощения системы оповещений

#809 @ 10:07 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Процедуры отображаются в диаграммах. Реже – с помощью специальных языков (Каллиграф). Хуже всего – средствами обычного языка.
Для работы с процедурами лучше подходят ARIS, BPwin, Инталев: бизнес-навигатор. Процесс прохождения этих документов можно описывать и тут, но готовить их прийдется там.
База знаний по управлению для такого рода документов должна:

• иметь возможность вставить отчёт в тело страницы в виде изображения (диаграммы),
• иметь возможность вставить отчёт в тело страницы в виде html-кода
• поддерживать традиционный цикл работы с документом
• в идеале – иметь возможность столь гибкого разграничения прав доступа, что бы привлекать внештатных специалистов для работы над отдельными документами.

#810 @ 10:16 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Редакторский цикл

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

1. Инициация
2. Назначение
3. Подготовка
4. Согласование
5. Утверждение
6. Публикация
7. Актуализация
8. Оповещение

#802 @ 23:46 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

До Подготовки

До первого шага должно быть нечто, что инициирует (запускает) весь процесс подготовки документа.
Разработка определенного документа может быть целью проекта (например ks2006@lessi или regulman@lessi). Тогда механизмом запуска послужил рапорт и стратегия.
Разработка (скорее актуализация) отдельного документа может быть спровоцирована жалобой, как элементом программного управления.
Подготовка документ может может быть инициирована руководителем. С точки зрения программного управления – это та же жалоба в баг-трекере.
Наконец потребность в документе может возникнуть исходя из потребностей самой системы. Система функционального управления это есть связанный набор непротиворечивых документов. И если между документами не хватает связи, или есть противоречие – эту ситуацию можно исправить создав новый или отредактировав старый документ. (особенно это часто это будет происходить при обновлении одного из связанных документов – начнется цепочка изменений)

#803 @ 23:47 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

права доступа

#804 @ 23:48 06.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

оповещения
доведение до исполнителей

 

#805 @ 09:06 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Разберём критически

>Надо создавать базу знаний по управлению
Именно базу знаний, а не базу данных. Организация, как и человек, пытаются понять себя. Но это лишь знания.
Попытка навязать на этом уровне правила – обречена. Можно лишь понять себя и те правила которые уже работают. Далее эти правила надо зафиксировать на бумаге. От этого эти правила не станут работать лучше. Это лишь даст возможность вовремя отказаться от этих правил.

>и там публиковать должностные инструкции.
ДИ это лишь часть системы управления. Даже если брать в расчет только организационное управление, то сначала идет Дерево функций, потом – Организационная диаграмма, и лишь потом – ДИ. ДИ – это пересечение между Деревом функций и Организационной диаграммой.

 

#806 @ 09:17 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

База знаний

База знаний может создаваться двумя путями:

• формальный (ARIS, Инталев бизнес-навигатор)
• описательный (Вики)

Формальный метод хорош тем, что уже есть некая методология, которой надо следовать. Это гарантирует меньше ошибок и более надёжный результат.

Недостаток формального метода – время отдачи. Для запуска формального метода нужны:

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

Результат формальный метод даст, только при достаточном наполнении базы.

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

• Гипертекстовых блоках страниц, полученных путем экспорта из формализованных систем,
• Вики для накопления информации.

 

#807 @ 09:30 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Архитектура системы

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

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

 

#811 @ 11:41 07.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

Окончательный выбор в пользу WackoWiki

Меня не устраивает НПЖ, т.к. я пока не смог получить:

• • OrphanedPages? — список документов, на которые нет ссылок,
  • WantedPages? — список документов, на которые есть ссылки, но которые ещё не созданы,

Обе эти функции удобны при создании базы знаний.

Кроме того в вики можно подписаться на отдельную страницу, в НПЖ – только стать наблюдателем в РГ. Это важный аргумент, который меня заставляет отказаться от НПЖ.

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

 

#874 @ 16:08 13.11.2007

Комментирует Эдуард Курганский — eduardk@lessi

>Мне нет смысла использовать какую-либо другую Вики, т.к. всё что мне хотелось бы иметь в корпоративной базе знаний поддерживается в WackoWiki

Есть и другие точки зрения в комментариях к management@lessi:БазаЗнанийПоУправлению