пятница, 31 марта 2017 г.

Системное лидерство - материалы рев.03

Презентация с первого ознакомительного семинара.

По замечаниям участников семинара фрагмент доработанной системной схемы предприятия:

Хамп-диаграмму тоже надо дорабатывать, пока тезисно практики выглядят так:

1) Активное слушание по учебнику "Умение слушать" Бернарда Феррари
2) Инфостиль по учебнику "Пиши, сокращай" Максима Ильяхова, Людмилы Сарычевой. Как вариант гарвардская школа делового письма, см. Минто.
3) Визуальное мышление по учебнику "Практика визуального мышления" Дэна Роэма
Замечу, что в этот раз специально разделяю навыки восприятия и передачи информации.
4) Модели психики. "Триггеры" Маршал Голдсмит, Марк Рейтер. "Думай медленно, решай быстро" Даниел Канеман, Амос Тверски. "Гибкое сознание" Кэрол Дуэк, на английском материалы здесь. "Укрощение амигдалы" Джон Ардан.
5) Бихевиоризм. "Все начальники делают это" Брюс Тулган.

воскресенье, 12 марта 2017 г.

Регламенты - что вы делаете неправильно

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

Обычно в той или иной вариации организация использует 3-4 уровневую структуру документов:

  1. Уровень общих описаний. Политики, положения, сквозные процессы уровня организации.
  2. Уровень регламентов. Достаточно детальное описание последовательности действий при выполнении работ, распределение ответственности.
  3. Рабочие инструкции. Детальные описания последовательности работ и распределение ответственности.
Уровни 1 и 2 могут быть разбиты на 2 подуровня.

В чем подвох? Для простоты буду приводить примеры конкретных бизнес-процессов розничной организации.

Ловушка 1. Целевая система или обеспечивающая?
Сравните "Регламент обслуживания покупателей в кассовой зоне" и "Регламент закупки и технического обслуживания оборудования кассового узла". Видя слово регламент в названии, разработчик документа часто использует одну и ту же форму. Где ошибка?

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

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

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

Ловушка 2. Интерфейсы и интерфейсные модели.

Инструкция по приемке товара на склад. Коротенькая, пара страниц максимум. Кто что делает, что проверяет. Это процесс-интерфейсный модель, если поставить трекер или оформлять приемки по файлам папочек, будет кейс-интерфейсный модуль. Здесь важны стабильность, надежность, воспроизводимость и низкая стоимость операций. Часто в документе пропускают порядок постоянного улучшения процесса. А зачастую нет и самого описания интерфейса, только "кладовщик принял ТТН, принес ТОРГ-12 начальнику склада, подписал и т.п.". Нужно описать между какими подсистемами интерфейс, описание интерфейса, режимы работы. См.? например, Бакмана.

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

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

Силы зла побеждают. У них даже картинки смешнее.