Осторожно, кейс! Почему таск-трекер не помог управлять проектами.

Кажется, что люди, которые придумали таск-трекер, решили огромную проблему спутанного управления задачами и проектами любой компании. Но около половины клиентов, обратившихся к нам за системой проектного управления, использовали таск-трекеры неправильно. Не в том смысле, что выкладывали в Trello фотки котов или искали в Planfix вторую половину, а в том, что бизнес-процесс организовывали по наитию, без попытки сделать инструмент удобным для команды.

‍

Первым пунктом внедрения любого инструмента ОБЯЗАН быть аудит. И проработка бизнес-процессов. Это звучит, как формальность, но в любом проекте внедрения это 70% работы. Остальное – технические настройки и проверка системы в бою.

‍

Команда VISUALS обратилась к аналитикам ROCKET с одним единственным запросом: описать все бизнес-процессы компании, чтобы разобраться, как правильно организовать работу в платформе Asana. Как сделать системным управление вашими проектами? Покажем на примере кейса нашего клиента.

О проекте

‍

Компания VISUALS разрабатывает комплексные мультимедийные решения, создаёт интерактивные 3D-презентации, оформляет выставочные стенды, режиссирует зрелищные шоу, создает контент и организует онлайн-мероприятия, наполняет высокими технологиями музеи и внедряет инновации в обучение.

‍

Запрос: описание всех бизнес-процессов компании для дальнейшей оптимизации работы в Asana.

Срок работы над проектом: 20 рабочих дней. 

Менеджер проекта: Елена Андреенкова.

‍

Почему без описания процессов Asana не работала

‍

К моменту обращения в RocketSales компания VISUALS уже работала в Asana. Взаимодействие сотрудников в рамках направлений не было регламентировано.

‍

• Кто должен работать в Asana, а кому это не нужно? 
• В какой момент работа с клиентом переходит из CRM-системы в систему управления проектами? 
• Как отделить работу проектного менеджера от задач по производству?
• Почему задачи ставятся, но не выполняются? 
• Почему ставятся одни задачи, но выполняются совсем другие?  

‍

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

‍

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

‍

Как отделить гречку от риса и получить ту кашу, которую вы хотели? Разбираемся дальше.

Почему это сложно?

‍

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

‍

У аналитиков ROCKET, в силу опыта, работа заняла 20 рабочих дней и прошла в 5 этапов:

‍

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

‍

При описании бизнес-процессов используется три метода внесения информации:

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

‍

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

‍

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

‍

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

Чуть подробнее о последовательности описания бизнес-процессов

‍

Первая задача аналитика – изучить текущий процесс и найти то, что называется «узкое горлышко». Их (узких горлышек) обычно бывает много. Это та точка в бизнес-процессе, где проект резко теряет в эффективности. 

‍

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

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

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

На скриншоте – три этапа, на самом деле их больше 40. Такие таблицы позволяют четко видеть все операции в рамках бизнес-процессов, но не дают понимания о всех ролях специалистов, задействованных на этапе. 

‍

И тут наступает звездный час матрицы распределения ответственности по методике RACI. Сначала покажем. 

Теперь расскажем. 

‍

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

‍

Преимущества данного способа:

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

‍

А что дальше? 

‍

А дальше такой пятишаговой экзекуции подвергается каждый бизнес-процесс. 

У вас на руках оказывается реальная организационная структура команды и процесс, описанный на всех его уровнях. Аналогичная архитектура создается в платформе управления проектами и жизнь становится легкой и прекрасной. Но это, как говорил ведущий программы «Следствие вели», совсем другая история.