Что такое верхнеуровневые задачи
Карта процессов верхнего уровня компании и матрица RACI c помощью drawio и google sheets
В крупных компаниях фиксируют верхнеуровневые процессы в картах процессов верхнего уровня. Наиболее наглядно это делается с помощью схем бизнес-процессов. На них же обозначают участников и владельцев процессов. Более сжатое представление дает матрица RACI. Встает вопрос, как автоматически строить матрацу по данным схемы процессов верхнего уровня.
Введение
Обычно отрисовку верхнеуровневых схем выполняют в нотации VAD (value added chain diagram).
Выжимку из КПВУ можно представить в виде половинчатой матрицы RACI, в которой заполняются только владелец бизнес-процесса и его участники:
Accountable (сокращение A) – подотчетный, утверждающий. Это видимо владелец процесса, а он должен быть одним (иначе будет по Райкину: «рукава и пуговицы»). Хотя часто в RACI под Accountable понимается что-то иное, судя по указанию нескольких «А» для одного процесса (задачи). Подробнее о Владельцах процессов (process owner) можно почитать тут: Process Roles — Who are the Process Owners? https://www.brcommunity.com/articles.php?id=b668
Responsible (сокращение R) – ответственный непосредственно за выполнение работы, исполнитель бизнес-процесса (executors)
Матрица RACI (матрица ответственности ролей в бизнес-процессах) предназначена для четкого распределения обязанностей и зон ответственности среди участников бизнес-процессов.
Странно. Так как ключевая роль у владельца процесса (A), то непонятно почему такую матрицу не назвали ARCI?
Задача
Нарисовать КПВУ и далее автоматически по ней построить матрицу RACI (половинчатую). Иметь возможность для анализа приведенных данных (поиск, фильтры, группировка), т.е. поместить названия процессов и роли (и связи между ними) в аналитическую табличку (Excel, google table и т.п.) или базу данных. Когда в компании полсотни подразделений и сотня верхнеуровневых процессов, то подобный инструмент становится очень актуальным.
Пожелания к инструментам: free & open source и наличие развертывания на корпоративном сервере.
1. Карта процессов верхнего уровня
Можно верхнеуровневые процессы рисовать в Visio и его BPM-развитиях, начиная с Бизнес-студии. Но желателен free & open source. Это позволит создать единый стандарт \ подход к подобным вещам. Связка Visio-Excel-VBA позволяет решить поставленную задачу, включая связку VAD с RACI, но она не перспективна.
Возьмем drawio, он же diagram.net. В примере показан первый уровень верхнеуровневых процессов. В нем, как правило, нет «цепочки добавленного качества (стоимости)», поэтому можно было бы заменить VAD-кораблики на прямоугольники. Посмотреть примеры процессов верхнего уровня можно вбив в поисковик фразу «процессы верхнего уровня», категория «картинки».
Карты верхнеуровневых процессов:
Ссылка на пример Карты верхнеуровневых процессов в drawio
При вводе данных по каждому процессу мы используем заполнители (placeholders), как показано на рисунке:
Формочка для заполнения заполнителей такая:
2. Обработка в Google Sheets
Пара возникших проблем.
Вначале пробовал парсить через функцию IMPORTXML(). Не вышло. Другие файлы парсит, но на этот выдает «Н/Д Не удалось обработать данные в формате XML». Даже для простых XPath-запросов типа «/«, «//«. Почему? Второй проблемой оказалось получить прямую ссылку с google drive. Для IMPORTXML нужна прямя ссылка, но разные: https://drive.google.com/uc?export=download&confirm=no_antivirus&id=[your_XML_file_id] не помогло. Поэтому использовал DropBox c заменой окончания исходной ссылки «? dl = 0» на «? dl = 1».
В итоге бросил упражнения с IMPORTXML.
Для разбора xml использовал незатейливый скрипт.
В xml данные placeholders хранятся так:
Пробегаемся по файлу, находим нужные имена placeholders и выводим их значения в промежуточную табличку (функции slice, indexOf):
Так как используются placeholders, то мы можем использовать в схеме любые графические примитивы: VAD-кораблики, прямоугольники, кружки.
Далее из вспомогательной таблички строим саму матрицу (полу-RACI):
Алгоритм такой: вручную расставляем в первой строке названия подразделений. Иначе ни как, хотя бы потому, что слева обычно указываются все front-подразделения, потом middle, далее back office и все обеспечивающие. Компу сложно рассказать про это.
Далее пробегаемся по вспомогательной табличке и сравниваем поля «Владелец» и «Исполнитель» с шапкой итоговой матрицы RACI (половинчатой). Если имеется равенство по Владельцу, то пишем «А» (Accountable), если по Исполнителю, то «R» (Responsible).
Кроме того, все данные у нас теперь в таблице и по ней можно проводить разнообразную аналитику: Сколько участников в конкретном процессе, иерархию подразделений по числу статусов «Владелец процесса» и «Исполнитель процесса».
Заключение
Перспектива
Если с Drawio интегрировать базу данных или хотя бы Excel (наподобие связки с Excel в Visio), то получится уже «половина» ARIS. Интеграция позволит двухстороннюю связь между схемой и объектом в БД. Например, достаточно синхронизировать вышерассмотренные заполнители (placeholders) с одноименными объектами в БД. Есть такие решения?
Технологии процессного управления
Три правила выделения процессов верхнего уровня
Технологии процессного управления
Три правила выделения процессов верхнего уровня
Сергей Ковалев — руководитель и ведущий консультант консалтинговой компании БИТЕК (Бизнес-инжиниринговые технологии). Имеет 20-летний опыт организационного проектирования и управления бизнес-процессами. Автор публикаций, семинаров и книг по стратегическому и процессному управлению и развитию.
Количество процессов верхнего уровня
Эмпирически, из практического опыта выведено оптимальное количество выделенных бизнес-процессов.
Правило 1. На верхнем уровне деятельность компании должна быть разбита на 15-20 бизнес-процессов верхнего уровня.
Практика показала, что разбиение компании на 15-20 процессов верхнего уровня является оптимальным с точки зрения контроля и интеграции процессов со стороны первого руководителя. В таком случае первый руководитель будет регулярно (как правило ежемесячно) получать 15-20 отчетов по выполнению ключевых показателей бизнес-процессов верхнего уровня. Также первому руководителю нужно будет активно учавствовать и принимать решения по оптимизации взаимодействий между 15-20 бизнес-процессами.
Если компанию разбить на большее количество бизнес-процессов верхнего уровня, то уровень контроля процессов со стороны первого руководителя будет излишне детальным, а интеграция процессов между собой потребует много времени. Такая детальная интеграция — не соответствует уровню первого руководителя, так как требует глубокого погружение на операционный уровень каждого бизнес-процесса.
Пример. В одной компании специалистами по описанию процессов было выделено 80 бизнес-процессов верхнего уровня. Это обосновывалось тем, что деятельность компании слишком сложная и требует множества бизнес-процессов. Когда специалистам сказали, что при таком подходе их генеральному директору придется ежемесячно рассматривать 80 отчетов о выполнении ключевых показателей по бизнес-процессам верхнего уровня, а также участвовать в выстраивании взаимодействий между этими 80 процессами, складывая их как мелкий пазл, то специалисты по описанию процессов задумались, но остались на своем решении. Однако, когда эта работа была доведена до генерального директора, он попросил специалистов по описанию процессов агрегировать многие процессы для того чтобы уровень контроля и интеграции с его стороны был оптимальным. В результате в этой компании на верхнем уровне стало 18 бизнес-процессов.
Практика показала, что при работе с процессами любая компания в итоге придет к 15-20 бизнес-процессам на верхнем уровне, которое, повторюсь, является оптимальным. Конечно есть небольшие компании, как например рассмотренная в части 5 компания «Видеомир», в которой было выделено 12 бизнес-процессов верхнего уровня. Также есть крупные компании, в которых приходится выделять много обеспечивающих бизнес-процессов, добавляя к типовому перечню такие обеспечивающие процессы как промышленная безопасность, экологическая безопасность, обеспечение электроэнергией и др. — в результате чего перечень процессов верхнего уровня может достигать количества 22-24 и даже выше. Но в среднем, как показывает практический опыт на верхнем уровне количество бизнес-процессов составляет значение 15-20.
Важность процессов верхнего уровня
На верхнем уровне все бизнес-процессы должны быть соразмерно важны для достижения стратегии компании. Не допускается на верхнем уровне рядом с важными и крупными процессами, размещать неважные и мелкие бизнес-процессы.
Правило 2. Бизнес-процессы верхнего уровня должны быть равнозначными с точки зрения важности для достижения стратегии компании.
Давайте рассмотрим, как влияет это правило на выделение бизнес-процессов верхнего уровня.
Пример. В торговой компании, занимающейся дистрибуцией лекарств (подробнее сотрите часть 5) в группе управленческих бизнес-процессов имеется процесс по управлению товарным запасом (рис. 20). Ранее на верхнем уровне этого процесса не было, так как он входил в состав бизнес-процесса закупки лекарств и был на втором уровне. Однако, с этим процессом связаны три ключевые проблемы и соответствующие им ключевые показатели.
Первый проблемный ключевой показатель — это величина товарного запаса, который достигал значения 6 месяцев продаж. То есть на складе товара лежало на 6 месяцев продаж и склад за год оборачивался всего лишь 2 раза. Таким образом оборачиваемость товарного запаса были слишком низкой, а его величина и соответственно затраты на складирование и поддержание товарного запаса были слишком высокими.
Вторым проблемным ключевым показателем по товарном запасу, являлся ассортиментный дефицит, который в определенный периоды времени достигал значения 20%. Когда клиенты направляли в компанию заказы на поставку лекарств, то оказывалось что по 20% ассортиментным позициям, товар на складе отсутствует. Соответственно компания теряла выручку, а удовлетворенность клиентов снижалась, и они переключались на других поставщиков лекарств. Основной причиной большого ассортиментного дефицита было то, что отсутствующий товар негде было размещать на складе, так как склад был забит большим количеством другого товара. То есть основная причина была связана с большим товарным запасом.
И третий проблемный ключевой показатель — это доля неликвидной продукции, которая также была высокой. Под неликвидной продукцией в компании считались лекарства со сроком годности менее 6 месяцев. Такие лекарства приходилось продавать с существенными скидками, то есть неликвидная продукция быстро обесценивалась и приводила к финансовым потерям. Причиной большого количества неликвидной продукции, как и большого товарного запаса были излишние закупки.
Когда руководители компании изучали опыт работы дистрибьютеров лекарств в других странах, то увидели, что там средняя величина товарного запаса составляет 2 месяца продаж. То есть при одном и том же объеме продаж товарным запас был в 3 раза меньше и требуемый размер склада тоже, соответственно затраты на складирование и поддержание товарного запаса также в 3 раза были меньше. Также было понятно, что все три проблемы товарного запаса взаимосвязаны и что ключевая причина трех проблем связана с излишними закупками и отсутствию должной работы по управлению товарным запасом.
Сначала в торговой компании ответственным за эти показатели являлся отдел закупок, так как процесс по управлению товарным запасом входил в состав процесса закупок. Но отдел закупки не смог обеспечить улучшение этих трех ключевых показателей по двум причинам:
• отдел закупок был сконцентрирован на других своих основных процессах — это поиск поставщиков, формирование заказов на поставку, их отслеживание и др.;
• поставщики лекарств большими скидками стимулировали отдел закупок закупать в прок.
В итоге руководством компании было принято решение о выведении процесса по управлению товарным запасом на верхний уровень и назначении другого ответственного за этот процесс (владельца процесса). Теперь процесс по управлению товарным запасом непосредственно контролировал генеральный директор, а выполнением этого процесса занималась новая служба управления товарным запасом. Эта служба формировала отчетность по товарному запасу, анализировала ее и предлагала инициативы по оптимизации товарного запаса. Генеральный директор рассматривал эти отчеты и инициативы, принимал решения, а также контролировал как это влияет на ключевые показатели по товарному запасу. В результате этой работы в течение года все три проблемы по товарному запасу были устранены, а соответствующие три ключевых показателя были значительно улучшены.
Согласно правилу равнозначности, наиболее важные и проблемные процессы целесообразно поднимать на более высокие уровни процессной модели компании. Полезно отметить, что в различных компаниях есть много похожих бизнес-процессов, но они могут находится на разных уровнях процессной модели по причине различной важности для стратегии компании, а также их различной степени проблемности.
Утверждение процессов верхнего уровня
При согласовании карты бизнес-процессов верхнего уровня с первым руководителем компании полезно видеть не только формальную процедуру, но и дополнительный инструмент контроля бизнес-процессов и возможность сделать модель процессов верхнего уровня наиболее оптимальной и эффективной для практической деятельности.
Правило 3. Перечень бизнес-процессов верхнего уровня должен быть согласован и утвержден первым руководителем компании.
Пример. В торговой компании занимающейся дистрибуцией лекарств изначально было предложено на верхнем уровне показать только один бизнес-процесс продаж, а на втором уроне сделать его детализацию на три бизнес-процесса продаж на трех различных рынках. При согласовании карты процессов с генеральным директором он указал на необходимость отображения на верхнем уровне всех трех бизнес-процессов продаж и соответствующей отчетности. В другой компании, первый руководитель посчитал необходимым агрегировать ряд бизнес-процессов на верхнем уровне, в результате построенные процессные модели стали более эффективно использоваться для управления деятельностью компании.
Рис. 20. Карта процессов верхнего уровня торговой компании
В примере производственной компании в отличие от торговой среди основных процессов появился бизнес-процесс доставки продукции потребителям (рис. 21). В торговой компании такой бизнес-процесс также есть, но он входит в состав процессов продаж. Причина в том, что в производственной компании продукция экспортируется и процесс доставки продукции потребителям является более важным и дорогим по стоимости, поэтому и размещен на верхнем уровне.
В группе обеспечивающих бизнес-процессов производственной компании в отличие от торговой также появились еще два бизнес-процесса: ремонт и модернизация оборудования, а также капитальный ремонт и строительство. В торговой компании есть складское оборудование и погрузчики, а также процессы по их ремонту и обслуживанию. Но объем этих ремонтных работ в торговой компании меньше, именно поэтому у нее процесс ремонта входит в состав процесса складирования и размещен на втором уровне процессной модели.
Рис. 21. Карта процессов верхнего уровня производственной компании.
Также в торговой компании есть работы по ремонту офисного здания, но вследствие их меньшего объема и стоимости они также размещены на втором уровне процессной модели и входят в состав обеспечивающего бизнес-процесса по административно-хозяйственному обеспечению деятельности. В производственной компании бизнес-процессы ремонта и модернизации оборудования, а также капитального ремонта и строительства по объему работ, стоимости и важности являются более значимыми и поэтому размещены на верхнем уровне процессной модели.
Среди бизнес-процессов управления в производственной компании есть бизнес-процесс по управлению проектами, которого нет на верхнем уровне в торговой компании. Это связано с тем что в производственной компании перечень реализуемых проектов развития значительно больше, а контроль их выполнения и управление портфелем проектом более значимы для стратегии компании. В торговой компании такой процесс входит в состав процесса стратегического управления.
Ответственные за бизнес-процессы или их владельцы
На карте процессов верхнего уровня производственной компании также показаны ответственные за бизнес-процессы или владельцы бизнес-процессов (рис. 21). Именно они отвечают перед первым руководителем за достижение ключевых показателей по своему процессу, а также за функционирование процессов в соответствии с требованиями, которые формулируются в организационно-распорядительных документах компании.
Альтернативным способом отображения распределения ответственности за бизнес-процессы верхнего уровня является матрица ответственности (рис. 22). В строках матрицы перечисляются бизнес-процессы верхнего уровня, в столбцах матрицы показываются руководители верхнего уровня, а на пересечении строк и столбцов показываются символы ответственности.
Рис. 22. Матрица распределения ответственности за процессы верхнего уровня производственной компании
Матрица распределения ответственности позволяет наглядно увидеть кто за что отвечает и показать равномерность распределения ответственности. Матрица позволяет наглядно показать бизнес-процессы, у которых нет ответственных, а также бизнес-процессы у которых несколько ответственных, что означает безответственность.
В результате матрица как наглядный формат описания распределения ответственности часто используется как на этапе доведения схемы распределения ответственности до должностных лиц компании, так и на этапе анализа и оптимизации деятельности компании.
В следующей части статьи мы расскажем о реинжиниринге и постоянном совершенствовании бизнес-процессов.
Как правильно оценивать сроки выполнения задач программистами. Часть 1
Авторизуйтесь
Как правильно оценивать сроки выполнения задач программистами. Часть 1
В первой части этой статьи я хочу коснуться общей информации об оценках сроков выполнения работ, рассмотреть, как оценка участвует в проектной деятельности и какое значение она имеет в итоговой реализации.
Зачем нужны оценки сроков выполнения проекта
Объективных прогнозов выполнения IT-проекта к определённой дате не существует. Если же прогноз сделан, что-то всё равно будет страдать: либо сроки сдачи, либо функционал, который будет урезан, либо программист, работающий сверхурочно из-за обязательств выполнить задачу в срок.
Раз прогнозы не бывают честными, зачем же их тогда делать? Так уж сложилось, что для успешного существования продукта управляющие им люди должны понимать, когда та или иная фича будет доступна пользователям. Этих знаний просто не может быть без оценок выполнения работы по внедрению этой фичи.
Оценки работы играют чуть ли не более важную роль, чем сама работа. Стоимость реализации напрямую зависит от оценки. Часто на этапе оценивания становится ясно, что игра не стоит свеч, шансы на успех невелики, а расходы слишком высокие. Но если проект всё-таки реализуем, то в игру вступает более сложная математика.
Выход на рынок первым бывает важнее, чем количество фич на старте. Часто после оценки изначального плана становится понятным, что его лучше видоизменить, упростить или сделать поэтапный выход на рынок.
Оценка выполнения напрямую влияет на стратегию развития продукта и на ранних этапах жизни стартапа играет решающую роль в успехе компании.
В здоровых взрослых компаниях оценку сроков работы дают сами исполнители на основе предоставленных им требований. Им могут помогать старшие коллеги, если у первых недостаточно опыта для этого. Бывают, конечно, и другие варианты, но мы не будем их касаться, т.к. их вариативность слишком высока и не представляет практического интереса.
Если программиста спросить про дату, к которой частная задача будет выполнена, то он может дать некоторую оценку. Но опытные менеджеры умножают эту цифру на 2 или даже 3, а мудрые менеджеры после этого добавляют ещё 30%. Во второй части статьи мы обсудим, почему такой подход работает и почему программистам не нужно становиться более пессимистичными.
Тема планирования очень обширная. Я не готов давать исчерпывающее описание всего процесса планирования. Я не буду строить модели, рисовать графики и диаграммы, постараюсь не использовать много страшных слов. Статья будет сведена к оценке со стороны исполнителя, моему опыту, наблюдениям и советам, полученным от более опытных коллег.
Как планирование отражается в проектном цикле
Озвучивание требований по фиче
В большинстве своём проекты имеют график релизов или запланированную дату, к которой функционал должен быть доступен пользователям. Обычно в компаниях есть люди, которые знают, в какую сторону развивать продукт. Продакт-менеджеры, СЕО, продюсер — как ни назови, роль в нашем контексте одна: у них есть видение рынка, понимание того, что сейчас наиболее важно. На основе этого они формируют бизнес-требования.
Подход к обсуждению и оформлению требований у каждого свой. Обсуждение может быть устной договоренностью, презентацией или текстовым документом с картинками (обычно предпочитают этот вариант). Мой любимый способ обсуждать требования — рассказывать о них, размахивая руками и рисуя маркером на доске. Но даже этот вариант лучше фиксировать не только фотографией доски, но и текстом.
Бывает такое, что директор компании подходит к программисту и просит что-то максимально быстро накодить и проверить его гипотезу на части пользователей на проде уже завтра. В этом случае никакого планирования и быть не может, поэтому оставим его за пределами нашей статьи.
Верхнеуровневая оценка реализации фичи
После того как идея сформирована разработчики должны сказать, реализуема ли задача, сколько может занять выполнение всех требований или каждого по отдельности. В простых случаях исполнителям сразу понятно, что делать. Задача может быть типичной для исполнителя или тривиальной в реализации.
В более сложных случаях исполнители могут дать высокоуровневую оценку вроде «Ну… денёк может быть уйдет», «Чёт ад прям» или «Если получится ‘А’, то hold my beer, иначе это долго». Такая оценка опирается на исторические данные или аналогии, с которыми сталкивался исполнитель. Обычно никто не ожидает, что эта оценка окажется точной.
Планирование сроков и состава фичи
Если предварительные оценки устраивают бизнес, то фичу начинают прорабатывать, искать особые случаи, писать User Story — вкладывают в фичу силы. Очень часто на этом этапе возникают изменения в требованиях, изначальный план становится верхушкой айсберга или видоизменяется до неузнаваемости.
Могут появиться требования к безопасности, устойчивости системы к нагрузкам, граф переходов состояний бизнес-сущности — да что угодно, что сразу было слишком сложным для описания (или об этом просто не подумали).
Уточнённая оценка
На основе уточнённых бизнес-требований программисты оценивают будущие изменения в коде, составляют план задач без детализации. Выделяется ответственный за фичу со стороны разработки, который решает технические вопросы, выбирает способ реализации, принимает архитектурные решения. Планируется способ реализации фичи, проверяют, уложатся ли изменения в текущую архитектуру, потребуется ли рефакторинг и можно ли обойтись без него.
Обычно даётся пара оценок — быстрая реализация (технический долг растёт) и с минимизацией энтропии ПО (технический долг не растёт или убывает). Проджект-менеджеры лучше программистов знают, что если постоянно выбирать быстрые реализации, то они скоро перестанут быть «быстрыми». Их оценки будут расти, обгоняя линейный график, и это может кончиться тем, что проще будет переписать приложение, чем пытаться закрыть технический долг и развивать существующее.
Поэтому выбор быстрой реализации является менее предпочтительным и требует веских аргументов в его необходимости. В итоге всё равно нужно будет навести порядок, а это дольше, чем не сорить сразу.
Финализация требований
На основе полученных уточнённых оценок проджект-менеджеры вместе с продакт-менеджерами выбирают дату релиза и, если она всех устраивает, запускают процесс. Если нет, то пробуют сильнее распараллеливать задачи, выделив большее количество программистов. Если их нет или распараллелить не получается, то либо отказываются от части требований, либо разделяют функциональность на два релиза.
После такого решения ответственный за фичу со стороны разработки может внести коррективы в оценку. Распилить функциональность — удовольствие не бесплатное. Хотя обычно сроки нивелируются за счёт принятия быстрых реализаций в коде, раз уж принимаются меры менеджерами, можно пойти им на встречу. Главное, чтобы это не превратилось в привычку.
После того как оценки получены и всех всё устраивает, происходит заморозка требований. Если возникают изменения, то они идут уже в следующий релиз, либо решаются в частном порядке.
Синхронизация с майлстоунами
При реализации проекта случается, что одна задача занимает больше, чем запланировано, а другая меньше. Чтобы не параноить, что из-за одной задачи сроки релиза поедут, создаются майлстоуны — ключевые точки, в которых планы должны соответствовать реальности. Проджект-менеджер, не вмешиваясь в процесс, может видеть со стороны, насколько сильно разработчики отстают от плана, оказать поддержку тем, кто застрял и вовремя увидеть надвигающуюся угрозу срокам готовности фичи.
Ретроспектива
После того как функционал протестировали и зарелизили хорошо бы свести планы с фактом, выделить экстремальные значения несоответствий, попытаться проанализировать причины, понять, могут ли они носить систематический характер или это случайность и уже в следующем проекте подобное не встретится. К этому процессу стоит относиться как к обучению. Руководству не следует устраивать охоту на ведьм, а программистам следует воспринимать вопросы о причинах несоответствий как точку профессионального роста.
Заключение
Мы рассмотрели вопрос необходимости планирования и оценки сроков реализации проектов, пробежались по типичному проектному циклу и увидели, какую роль играют сроки реализации. На этом первую часть и закончим.
Во второй части статьи будет рассказано о том, как программисты оценивают отдельно взятые задачи и как погрешность можно сделать приемлемой для промышленного применения.