Холон розничной торговой сети

Напоминаю системную схему холона.

Внимание, вопрос.

Главный стратег предприятия Петя разрабатывает план развития компании (возможно, с изменением формата торговли на онлайн или дополнительные клиентские сервисы) на 2017-2020 годы. В процессе подготовки он сходил на тренинг по системному мышлению Школы системного менеджмента и по результатам устроил рабочее совещание, на котором правление, бизнес-аналитик и главный стратег пытались определить целевую систему проекта развития. В результате рабочего совещания голоса участников разделились поровну между 4-мя вариантами:

А) ЦС - это ассортимент и сервисы магазинов сети

Б) ЦС - это купленные клиентом продукты в магазине сети

В) ЦС - это приготовленная клиентом еда из продуктов, купленных в магазине сети

Г) ЦС - это сытый довольный клиент

При этом высказывалось множество аргументов за и против.



А) Против. Что же тогда является использующей системой? Кто использует ассортимент? Частью чего является ассортимент? Какую функцию выполняет ассортимент? За. Ассортимент - это то, что приносит пользу клиентам и то, что на самом деле отличает один магазин от другого. Ассортимент определенно отвечает потребностям и к нему можно предъявить требования. У ассортимента есть эмерджентность от составляющих частей, кто же не знает поговорки "пиво без водки - деньги на ветер". Ассортимент мы можем менять. Есть подсистемы - товарные категории, группы.

Б) Против. Изменить покупку нельзя. Можно только как-то убеждать клиента сделать покупку, влиять на него. Сырое мясо в составе клиента как использующей системы бесполезно, его нужно готовить. Архитектуры покупки нет, по крайней мере ее нельзя задать. За. Покупка явно является часть клиента (использующей системы), в особенности после того, как он ее съест. Она эмерджментна, т.к. прибавляет интеллект клиента (сытый голодного не разумеет). Потребности и требования сформулировать к покупке можно. Есть подсистемы - отдельные продукты. Покупка выполняет функцию. За покупку платят! Покупка пересекает границу предприятия для поставки.

В) Против. Можно только влиять, напрямую ничего не сделать. Архитектуру готового блюда задать нельзя, а как? Платят все-таки не за готовую еду, разве что при покупке кулинарии, платят за продукты. За. Готовая еда является частью использующей системы - клиента, она приносит пользу, у нее есть функция. Готовая еда эмерджментна - есть питательный и эстетический аспект. Она удовлетворяет потребности и к ней можно предъявить требования.

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

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

1) Поднять протоколы встречи, выбрать вариант генерального директора (вариант Б), и утвердить его в качестве финального на очной встрече с ГД.

2) Поднять маркетинговые исследования и выяснить, что 80% клиентов воспринимают магазины формата как "расширение холодильника" и покупательская миссия у них "дозакупка свежих скоропортящихся продуктов и алкоголя перед праздниками и выходными", а значит дискуссию надо продолжать, т.к. ни целевую ни обеспечивающую системы команда правильно не определила.

3) Бросить страдать ерундой и вернуться к проверенным методам управления, пока не уволили за смелые эксперименты.

На выходных напишу про конкретику, а пока немного метафизики про rationale системного мышления

Условно есть два типа инженерных менеджеров - Дилберт и pointy-haired boss. Дилберт по крайней мере интуитивно понимает про байесовскую статистику, и часто сомневается. PHB уверен всегда.
Но когда у Дилберта появляется системное мышление, он становится Догбертом, и начинает решать любые проблемы и уверен в своих действиях, т.к. держит в голове весь холон и ЖЦ ЦС. И окружающие, знающие типичного Дилберта, немного фигеют от такой трансформации, и делятся на два лагеря. Лагерь первый, условный "Obey ^Leena Dilbert", лагерь второй "WTF, his talking crazy". Завтра будем учиться составлять холон в http://www.mindlyapp.com/

P.S. Обычное использование проектного менеджмента

Quick wins - doing it right

Что такое быстрое улучшение (quick win)?

 

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

 

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

 

Требования к быстрым улучшениям:

1. Не требует капитальных затрат, требует минимум операционных затрат
2. Вам должна быть понятна причина проблемы и ее решение должно быть очевидным
3. Узкий и понятный фронт работ, обычно внутри отдела
4. Все руководители согласятся с предложением
5. Изменение можно реализовать за 30-60 дней

 

Примеры быстрых улучшений:

Логистика

Что сделано	Результат
Адресное хранение готовых заказов на линиях у ворот	Сокращение времени поиска заказов, тем самым уменьшение времени загрузки ТС на 56% (с 1,2 ч. до 0,58 ч.) Сокращение затрат на персонал ХХХ руб. в месяц.
Увеличение наполняемости паллет путем объединения прайсов "Сухого ассортимента" и "Соки, воды"; "Фреш" и "Яйцо".	Увеличили утилизацию транспорта, что приведет к сокращению транспортных затрат на ХХХ руб. в месяц
Закупили паллетайзеры	Сокращение затрат на Расходные материалы для склада на ХХХ руб. в месяц, что составляет  67 % экономии.

Как найти идеи для быстрых улучшений?

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

Что с ними делать дальше?

1. Оцените эффект. Он должен быть быстрый и положительный.
2. Выберите, какие улучшения вы реализуете. Чем больше будет исходный набор, тем лучше выбор.
3. Благодарите людей за любые предложения. Если вы отказываетесь от предложения, объясните, почему.
4. Определите, как будет измеряться эффект. Какой отчет, какие KPI. Отчет и KPI необходимо выбирать из уже существующих в систем бизнес-аналитики и отчетности.

Чек-лист для поиска областей быстрых улучшений:

1. Убрать ненужные шаги рабочего процесса. Если это не нужно клиенту, то зачем мы это делаем?
2. Изменить неэффективные процедуры
3. Изменить формы документов (заказы, наряды, заявки и т.п.). Особенно бумажные.
4. Уменьшить или ликвидировать запасы материалов и запчастей «на всякий случай»
5. Улучшить коммуникации между участниками рабочего процесса. Поищите, какие места наиболее проблемные, откуда приходит наибольшее количество жалоб?
6. Получить скидки или добиться снижения цен от поставщиков
7. Эффективно использовать Outlook и Excel (найдите внутреннего эксперта)
8. Эффективно использовать отчеты в BI (приглашайте айтишников)
9. Обучать персонал лучшим практикам работы, в особенности между филиалами
10. Встраивать в рабочий процесс «защиту от дурака»

В программах развития бизнеса быстрые улучшения - это первые пакеты работ, которые необходимо запланировать и сделать. Бланк для планирования:

https://drive.google.com/open?id=0BzE5YSuAvD3IQ2RDZHBkcm9sNnc

KPI и панели мониторинга, запись с конференции Адванты

https://youtu.be/-fHuwJ87_Ls
https://drive.google.com/open?id=0BzE5YSuAvD3ISFlsTTdsb2NoQWpOQ2RVN3hVOC1iQzhnTFJz




https://youtu.be/AIOdYJqsYU8 (это первое выступление на эту же тему, но с другого угла)


https://drive.google.com/open?id=0BzE5YSuAvD3IWjF0TURYWU9uQnM (первый слайд про системную инженерию неправильный, но исправлять лень)

Зачем проектным менеджерам системный менеджмент (чтобы делать ИСР с покрытием не 92, а 99%)

Несколько месяцев назад столкнулся с ситуацией, когда одна девушка доросла с обычного бухгалтера до главного, ее переманил конкурент, но отдел кадров не смог ее трудоустроить, т.к. у нее не было не то что диплома, но даже аттестата об окончании средней школы и результатов ЕГЭ. Арифметические действия она делала исключительно с помощью калькулятора и в принципе не понимала, что такое дроби. Ей было 28 на тот момент и три попытки сдать ЕГЭ окончились ничем. Человек прошел кучу аудиторских и камеральных проверок практически без замечаний. Казалось бы, забавная история, но в этой ситуации находится большинство операционных менеджеров, руководителей проектов включая. Эта самая "ориентированность на результат" и отсутствие понимания того, как работает вся система в целом, опора на "многолетний опыт в проектах различного размера и разных индустриях", разработка проектной документации с использованием "экспертной оценки и исторических данных". И полная неспособность понять главную причину неизменности моего любимого слайда ПиЭмАй "Пульс профессии 2011-2012-2013-2014 и далее", что основной причиной проблем в проектах по прежнему является неточные требования и оценка объемов работ. Одураченные случайностью, как и было сказано. Все РП используют индукцию при построении планов, и это спокойно уживается у них в голове с определением "проект - это уникальное бла-бла-бла". Уникальное, конечно, но мы возьмем все старые данные и подходы, применим здравый смысл (с) и двинемся дальше. Это, на мой взгляд, приводит к ситуации, в которой РП, в особенности в рисковых проектах, становится грушей для битья.

Я сам много раз шел в проект без понимания того, как конкретно этот план принесет заявленные в бизнес-кейсе эффекты, и даже как конкретно мы этот план исполним, я имею в виду часть интеграции планов по областям. Картинка до этого была такой - есть баналитик, который ищет проблему и предлагает обоснованное решение, а РП это такой парень, который за фиксированный прайс и срок это решение реализует. И эта модель жива и наиболее распространена в Штатах, например. Один мой знакомый, проходя собеседование в американской компании, сказал, что хочет позицию ПиЭма, на что СЕО его удивленно спросил: "Так это же те, которые таблички в Экселе рисуют и отчеты пишут, что тут интересного? Наверное, продакт менеджером?"

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

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

1. Системный подход в головах у участников команды. Все единообразно понимают холон и могут свободно по нему двигаться вверх и вниз.

2. Знания, информация и данные находятся в экзокортексе и они актуальны. Вы не можете дергать команду для пояснения деталей холона во время своих рассуждений.

 

Я давно обещал Анатолию Левенчуку, что когда будет четкое понимание и однозначная обратная связь от окружения по поводу полезности курса системного менеджмента, я напишу отзыв о тренинге, и этот момент настал. Итак, для чего нужен системный менеджмент руководителю проекта?

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

2. Для формирования плана проекта, который реально позволит контролировать ключевые аспекты и узкие места в работах проекта, а не слепо доверять заверениям исполнителей о том, что все под контролем. Доверие возникает только из понимания ситуации в ее динамике и theory of mind исполнителя. Во втором СМ не поможет, но в первом вполне даст удовлетворительный ответ. Одним из примеров может быть список KPI для всех команд проекта, который будет подстроен под конкретный проект, а не слепо взят из базы или из опыта, и который позволит отследить цепочку получения результата.

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

 

Конкретный пример использования СМ. Две недели назад я сменил место работы, город, перешел с DIY в FMCG. И одна из первых задач у меня была, помимо того, что надо снять квартиру и вообще обустроить жизнь в Москве, за три недели разработать и запустить программу развития. Я успел три раза разработать и уточнить стратегию, провел пять десятков встреч, разработал черновик бизнес-архитектуры as is и начал рисовать to be, доделаю к концу года. За две недели я понял ключевые проблемы и продуктивно участвую в производственных совещаниях и фасилитирую дискуссии. Я понимаю ключевых стейкхолдеров и отслеживаю их интересы, я разобрался в ключевых ИТ сервисах, поддерживающих бизнес-процессы. Вы когда-нибудь стояли рядом с коммутационным шкафом? Такое щелк-щелк каждую секунду, иногда по нескольку раз. Вот и у меня так же - стейкхолдер-интерес, система, требование, работа, команда, технология, метод описания, описание. И сразу архитектура в голове дорисовывается в Архимейте, надо только сесть и быстро все записать.

Вход в новый проект - это сложно для всех, тут и опыт важен, и навыки взаимодействия и конечно, это все имеет значение. Но, только СМ дает ТЕХНОЛОГИЮ, т.е. повторяемость и воспроизводимость этого входа в проект. Специалист, владеющий технологией, однозначно бьет даже крутого ремесленника, хотя Левши всегда были в России в почете. Порядок бьет класс, системный менеджмент бьет "25 лет опыта и более 60 выполненных проектов". Я выбираю быть на выигравшей стороне, свой выбор вы делаете сами.

Про непрошенные советы и рефрейминг

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

 

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

 

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

Дочитал "Одураченные случайностью". Пара мыслей, возникших после прочтения.

 Эмоциональный интеллект более значим, чем логический интеллект, потому что эмоции включаются раньше логики (Системы 1 и 2 Канемана и Тверски). Т.е., если у вас не будет эмоциональной компетентности, вам просто некогда будет предъявить интеллектуальную.

 

При объяснении Системы 1 и 2 аудитории не надо говорить, что так работает мозг любой обезьяны, сидящих здесь и носящих одежду в т.ч. Скажите, что по данным научных исследователей от 94,0 до 96,5% людей ведут себя именно так. За счет ошибки атрибуции аудитория будет думать, что это не про них, они-то рациональны, но вас послушает и записи сделает. Всем приятно чувствовать себя умнее других, сыграйте на этом.

 

Появился еще один аргумент в пользу микропринципов и микропрактик. Чем больше инструмент и чем для более сложной последовательности событий он рассчитан, например "Методология оценки комплексных инвестиционных проектов", тем реже он будет использоваться (меньше частота). В результате, значимая статистика для понимания его эффективности накопится позже, если накопится вообще. Ведь по проектным менеджерам, сделавшим 2-3 проекта, непонятна их квалификация. То ли повезло ему и все окончилось хорошо, хотя поведение РП было неправильным, то ли даже несмотря на правильно сделанные вещи, проект был неудачен почему-то еще и тут вопрос почему.

 

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

 

В силу этого же подхода шаблоны проектов надо разбивать на шаблоны кейсов контрольных точек, привет Алферову с его РИМ-3. И ситуационная инженерия методов для проектного менеджмента будет с одной стороны заходить со стороны Эссенс, в части проектирования ЖЦ проекта, а с другой стороны набором КТ, приходящим в виде ключевых требований стейкхолдеров (нужны справочники учета интересов и соответствующих выполнению этих интересов КТ), индивидуальных для каждого проекта, которые надо в этом проект пройти. Оценки при этом собираются a priori из справочников либо экспертным путем, загоняются в модель МКЦ*, затем на основании данных по фактическому исполнению и экспертным догадкам байесовская сетка дает прогноз по завершению задач, пересчитывая сетевую модель и профиль риска проекта.

 

Ключевой вопрос здесь в том, как строить сетевую модель в проекте эджайл, это явно нечеловеческая задача. На старте проекта можно задать мягкую логику связей КТ по модели ЖЦ, в особенности если модель ЖЦ предусматривает гейты/"пересмотры выделения ресурсов". Надо думать дальше.

 

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

 

При этом подходе из четырех подходов выживает только Axelos и P2M, натянуть эту модель на подход PMI сложновато, так он и останется метатекстом-онтологией. Теперь надо засесть за изучение P2M, спасибо Михаилу Софонову за текст стандарта, который в нынешние копирастические времена в этих ваших Интернетах не найти.

 

*И тут есть идея, что МКП с использованием метода Монте-Карло для получения статмодели разброса расписания и бюджета, см. пост про Palisade @Risk и Oracle Crystal Ball, и МКЦ есть одно и то же.