Осторожно, кейс! Почему с таск-трекером каши не сваришь

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

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

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

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

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

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

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

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

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

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

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

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

У профессиональных команд по внедрению проектного управления такая работа проходит за 20 рабочих дней и в 5 этапов:

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

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

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

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

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

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

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

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

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

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

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

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