суббота, 11 марта 2017 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

воскресенье, 26 февраля 2017 г.

MINDSPACE - практический бихевиористский подход

Майндмэп

Итак, классическая пятифакторная схема коммуникации дополняется моделью MINDSPACE, которая определяет поведенческие реакции на коммуникацию.

Культурный контекст при этом задается моделью культурных измерений Хофстеде.
Можно, как вариант, воспользоваться Евробарометром, но только для европейцев.

При этом держим в уме, что воспринимаемая информация попадает вначале в Систему 1 (распределенные представления) и затем в Систему 2 (символьные представления), см. также пост про бибинарность и лидерство.

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

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

суббота, 25 февраля 2017 г.

Системное лидерство и бибинарность мышления

Еще одна задача, которую решает системный лидер, это сокращение разрыва между символьными представлениями описания предпринятия и бибинарными представлениями этого предпринятия в головах участников. Другими словами, архитектор и менеджер разработали регламент (символьное описание). Регламент является ведь даже не моделью желаемого поведения, а моделью модели, потому что потом, в самом предпринятии, менеджер на основании пункта регламента "магазин должен быть открыт за три дня" 1 февраля ставит задачу "Петрову открыть магазин на Новокаланчевской 8 до 5 февраля". И эта символьная модель в голове Петрова существует уже в виде целого сочетания символьных и распределенных представлений. Причем, чем дальше мы заходим с реформой системы образования, тем этих символьных представлений меньше и качество их хуже. Системный лидер отслеживает преобразование символьных моделей предпринятия в бибинарные представления и на основании этих преобразований восстанавливает модель психики, понимает, где происходит наибольшее искажение восприятия реальности, и понемногу его исправляет, указывая участнику команды на паттерны ошибочного восприятия и поведения.

Архитектура предприятия - с чего начать?

Начинают с модели жизненного цикла. Она состоит из двух частей:
1) Типовых контрольных точек, приходящих системной схемы предприятия (см. здесь) и структуры целевой системы (Михаил Софонов скоро выложит винрарное видео на эту тему, ждите)
2) Перечня практик жизненного цикла.

Пару слов и одна картинка на второй пункт. Если вы придете к людям, не знакомым с терминологией системного подхода, и начнете сыпать терминами, ничем хорошим это не кончится, коммуникации не случится. Перечень практик и связи между ними чаще всего называются "процессной моделью", а сам процесс разработки модели ЖЦ "регламентацией деятельности". Второй важный момент, который часто забывают и пропускают при разработке модели ЖЦ, заключается в том, что параллельно надо строить управленческую отчетность, пересматривать модели данных, искать новые ИТ-решения и улучшать бюджетирование и модели деятельности предприятия вообще. Это гораздо проще, чем построив процессную модель и даже пройдя с ней аудит на ИСО9001, пытаться надстроить бюджетирование и управленческую отчетность поверх уже закрепленных процессов.


четверг, 23 февраля 2017 г.

Адаптивный кейс-менеджмент (АКМ). Что это, зачем и почему?

Зачем использовать слово «кейс», оно уже надоело?
Да, действительно, слово кейс используется к месту и не к месту. См., например, график.


В русской административной традиции это просто «дело». Дело пациента, судебное дело. Дело приписывается конкретному физическому объекту. Обычно это человек в определенной роли – пациент, подзащитный, студент. Но дело может заводится и на ситуацию, тогда оно обычно называется инцидентом.

Почему тогда не говорить просто «делопроизводство» или «управление делами»?
Управлением делами называют также и организацию. Например, «управление делами президента». Чтобы избежать путаницы, лучше не использовать этот вариант. Почему не делопроизводство? Административные процессы сейчас автоматизированы, и когда вы говорите о практике, то подразумевается технология. В основе большинства делопроизводств лежит технология СЭД, систем электронного документооборота и отслеживания поручений. Это совсем-совсем не то же, что лежит в основе АКМ.
Поэтому, можно начать разговор и назвать АКМ «делопроизводством» или «управлением делами», никто не будет возражать, но через 15 минут выяснится, что все имели в виду разное. А можно те же 15 минут потратить на объяснение, что такое АКМ. Поэтому начнем!

Что такое АКМ?
Это практика, которая позволяет управлять работой с высокой неопределенностью.
Вначале разберемся с основными управленческими практиками. Их, условно, четыре:
  • Процессное управление
  • Управление проектами (гораздо правильнее говорить «управление проектами организации», organizational project management, OPM)
  • Управление делами
  • Управление кейсами, которое сейчас распалось на АКМ и т.н. production case management

Эти практики используются в двух областях – управление операционной деятельностью (business as usual, BAU, business run) и управление изменениями (business change).

Выглядит это так


Сравнение АКМ с управлением делами.

Популярен ли АКМ в мире?

Казалось бы, зачем вообще говорить о АКМ? А если так?


Ключевое отличие АКМ от управления проектами организации (OPM, P3M).
Управление проектами нацелено на эффективное прогнозирование. Цель задается, нужно оценить средства ее достижения и выполнить обещанное. Подразумевается, что достижение цели решает проблему.
АКМ нацелен на решение проблемы, цели (варианты решения) могут быть множественные в течение кейса.

Основное положение АКМ – отказ от постоянно уточняющейся оценки сроков и бюджета и распределение ответственности  между членами команды.

Чем плох АКМ? 
В областях, где власть клиента слаба, где нет давления сроков, бюджета, качества, АКМ будет неэффективен. Но будут ли такие области через 5-10 лет?
Есть еще PCM, production case management. Его ключевое отличие от АКМ в том, что нужны разработчики, которые будут дорабатывать рабочие процессы. То есть run time и change time разделены. В АКМ run time и change time не разделяются, если нужно что-то изменить, любой участник может это сделать. Разница кажется маленькой, но она кардинальна. Если вам нужно одно, а купили вы другое, то вы будете не удовлетворены.

Так зачем нужен АКМ? Лучше всего об этом говорит этот текст:

За точкой слома
Предисловие от меня. Недавно задумался, сколько пролетела-проплыла-проехала моя старшая дочь, ей еще пяти нет. 70 тысяч километров.
В начале 1930-х военные пилоты стали испытывать странный и зачастую смертельный феномен - отключение сознания. По мере роста скоростей и маневренностей самолетов, ускорения, действующие на пилотов, стали мешать пилотам оставаться в сознании, т.к. кровь отливала от головного мозга. Ситуация продолжалась до конца Второй Мировой войны, когда были изобретены костюмы, позволявшие пилотировать самолеты при перегрузках 9 джи.


Большую часть второй мировой пилоты маневрировали так, чтобы их сжимавшееся тело выталкивало кровь обратно в головной мозг. Не всем пилотам организм позволял делать такие штуки, так что, скажем аккуратно, пилоты были подвержены естественному отбору. Но даже те, кто выдерживал такие перегрузки, могли делать лишь немногим больше, чем удерживаться в сознании. Полетное задание и навыки пилотирования были вторичными по сравнению с теми критичными моментами, когда возможности машины превосходили их. Если коротко, скорость была их врагом. Она отвлекала их от того, что они умели делать - летать. Ирония заключалась в том, что скорость была их целью.
Мы все были на грани паники, когда поток задач и дел настолько превышает имеющиеся в наличии ресурсы и время, часы и дни настолько ускоряются, мы чувствуем себя настолько несоответствующими ситуации, а совместная работа набирает немыслимую интенсивность, что способность команды общаться и делать работу должна быть практически безупречной, вне зависимости от напряженности ситуации.
В этом нет ничего нового. Все предприятия оказываются в такой позиции. А если нет, значит, они просто плохо стараются.
И даже если мы можем справиться с такой ситуацией и вовремя все успеть, примерно как пилот во время особо крутого виража удерживается на грани потери сознания, попытки справиться с такой ситуацией из раза в раз, приводят к полному износу организации до полной остановки ее деятельности.
И, тем не менее, мы все в этой точке. Мы все должны делать больше с меньшими ресурсами, успевать в нереалистичные дедлайны, справляться с беспрецедентными уровнями неопределенности, и делать все это безупречно. И это стало новой нормой, никто не считает такое поведение выдающимся. Мы чувствуем себя постоянно истощенными из-за отсутствия инструментов, которые помогли бы справиться со сложностью и скоростью бизнес-машины, которую мы построили.
Тут нет никаких неожиданностей. Мы создали возможность нашим организациям двигаться настолько быстро, что эта возможность обнажила нашу неспособность сделать работу, и дела становятся все хуже!
Бесполезно философствовать на тему, как же мы все оказались в такой ситуации. Правда такова, что инструменты, которые мы создали подходят к управлению современным бизнесом примерно в той же мере, в какой пилот второй мировой экипирован для пилотирования современного истребителя.
Нам нужны больше, чем инструменты, нам нужен новый подход, чтобы справиться с работой, путешествующей со скоростью света по всему миру.
В этом суть адаптивного кейс-менеджмента (АКМ). Однако, я часто вижу в обсуждениях тезисы вроде "Почему вы называете это чем-то новым? Этой теме сто лет в обед. У нас полно инструментов для управления задачами, процессами, для координации и автоматизации".
Этим комментаторам я могу ответить только одно - называйте это как хотите, но не позволяйте вашей привязанности к прошлому заслонить обещание будущего.
АКМ затрагивает самые основы того, как мы смотрим на работу, как мы ее визуализируем, распределяем ее, перемещаем, отслеживаем, и в конце концов, объединяем в новую структуру коллективного труда.
Если вы говорите, что вам не нужна АКМ, то истинный смысл ваших слов таков - вам не была нужна АКМ. По мере чтения кейсов и статей из этой книги, вы поймете, что мы все ближе к тому времени, когда мы не будем понимать, как же мы без нее жили. Мы будем удивляться, как в мире традиционной, строгой командной структуры и автоматизации можно было удержать необходимую на рынке скорость действий. И более всего мы удивимся, как низко мы ценили и как мало понимали критичность автономного принятия решений в случае незапланированных событий и неопределенных рынков.
Как пишет Кит Свенсон в своей главе "Мир движется слишком быстро для централизованного контроля. Решения необходимо принимать в более автономных точках, включая обмен информацией и консультации в случае непредвиденных, незапланированных и неожиданных развитий событий".
Не отчаивайтесь, если все это кажется вам чрезмерной крайностью: на рынке уже есть целое поколение работников, для которых это вторая натура. Посмотрите на совместную работу детей, как они делятся своей жизнью с другими, на их разговоры в реальном времени 24 на 7. Между детьми уже нет разрывов в общении. Мы можем спорить о пользе такого непрекращающегося онлайн марафона, но сложно оспаривать о выгодах такого подхода при работе с неопределенностью будущего. Для них неопределенность - это возможность, и они скорее бегут к ней, чем убегают от нее. Может быть, имеет смысл понаблюдать за тем, как они работают, чтобы понять, как надо работать нам.
Мой совет вам прост: подумайте, что станет для вас возможным с АКМ, с возможностью жить и работать здесь и сейчас. Подумайте об очевидных выгодах от того, что все элементы вашей работы и ваши ресурсы будут объединяться на основе ваших представлений о том, как вы делаете вашу работу, а не на основе представлений программиста, который проектировал программный интерфейс десять лет назад для тысяч безликих пользователей по усредненным требованиям, в миллиардах раздробленных на мелкие кусочки таблицах ERP или КСУП. Подумайте о нарушенных из-за такого устройства ИТ систем коммуникациях, неудавшихся совещаниях и проваленных проектах и несработавших процессах. Вообразите взамен этого соединенный воедино мир вашей работы, где все ее части взаимодействуют без трения, последовательно и надежно протекая через всех исполнителей.
Сделайте это и вы поймете, что скорость больше не ваш враг, не точка слома, не стресс, который уносит вас все дальше от цели, но неизбежный аспект того, как мы будем работать и других вариантов нет. Единственный доступный путь для вас - уцепиться и использовать эту возможность, чтобы сфокусироваться на том, что вы делаете лучше других.
Не верите? Не надо беспокоиться, вести бизнес - это очень похоже на пилотирование самолетов, здесь действует естественный отбор.
Томас Коулопулус
Председатель Дельфи Груп


суббота, 18 февраля 2017 г.

Стандартные операционные процедуры (СОП)

По русски на эту тему мало что написано, чаще всего у нас SOP (standard operating procedures) воспринимаются как рабочие регламенты. Оригинально это короткие документы, умещающиеся на одном листе А4, и описывающие рабочий процесс. Зачастую организационную норму тоже называют СОП. Например, "Организатор собрания должен прислать повестку с указанием целей собрания и четкими ожиданиями от каждого участника не позднее, чем за 24 часа до начала собрания. В случае, если организатор этого не сделал, любой участник может отказаться от участия в собрании, заявив об этом".

Примером сборника СОП может служить Ядро.

Чем хороши СОП? Если вы правильно создали архитектуру процессов в моделлере (я буду ориентироваться на Archi), то каждый процесс обычно может быть описан 1-2 СОП. Это позволяет сделать три вещи:

1) Радикально упростить обучение новых сотрудников и переобучение текущих, если процесс изменился
2) Не пересогласовывать весь сквозной процесс при изменении небольшой части
3) Разделить требования к процессу (в особенности обусловленные комплаенсом и управлением качеством и рисками), которые фиксируются в моделлере с помощью расширения целеполагания, с интерфейсами, и дизайн процесса, который дается внутри СОП.

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

У нас есть две проблемы – нужно быстро стандартизовать процессы магазина, чтобы повысить качество управления на местах (1) и нужно закрыть компанию от юридических рисков, внедрив официальные регламенты под роспись управляющих (2).

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

Я предлагаю следующее решение – стандартные операционные процедуры (СОПы). Точнее даже их крайне урезанную версию.

Что такое СОП?
Это краткое описание требуемого поведения персонала. Пишется по одной из трех формул:
1) [Условие][Кто делает][Что делает][С чем делает][Ограничение]. 
Например, «В конце каждой рабочей смены[Условие]Кассир[Кто делает]Сдает[Что делает]Выручку[С чем делает]С точностью до рубля[Ограничение]», 
или «Когда находится в торговом зале[Условие]Продавец[Кто делает]Предлагает клиентам[Что делает]Товары промо-каталога[С чем делает]Если клиент не отказывается от помощи[Ограничение]»
2) [Условие][Действие или Ограничение][Значение].
Например, «При прохождении инвентаризации [Условие] Допускаются списания [Действие или Ограничение] Не более 20,000 рублей на магазин [Значение]
3) [Кто делает][Что делает][Значение].
Например, «Кулинар[Кто делает]Поддерживает количество готовых кур на витрине[Что делает]От 3 до 4[Значение]».

Принципы хорошего СОП:
1) Его можно проверить на соответствие
2) Его исполнение персоналом помогает успешно выполнить покупательскую миссию либо решить его проблему во время покупки
3) Выполнение может быть выражено численно
4) Определяет поведение персонала и не характеризует клиента
5) В формулировках не используются запреты и страдательный залог

Критерии качества СОП:
1) Обязательны к исполнению
2) Не описывают способ исполнения, описывается только поведение
3) Однозначно понимается всеми
4) Последователен и не противоречит другим СОП и регламентам
5) Полно описывает поведение
6) Описывает одиночное требование
7) Достижим и реализуем
8) Происхождение требования может быть отслежено к основному документу (регламенту, презентации, решению, политике)
9) Проверяемый

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

Варианты СОП:
https://www.template.net/business/word-templates/job-safety-analysis-template/
http://www.systems2win.com/LK/teams/TWI_JI.htm

четверг, 16 февраля 2017 г.

Системное лидерство - рабочие продукты


Управление ресурсами команды - технология, реализующая дисциплины системного лидерства:



Талант - это подальфа команды. Обратите внимание на стадию поддержания контакта после увольнения/расторжения контакта - это зона ответственности лидера.