Выбираем систему для управления процессами в больших командах: часть 2
Блог Kaiten ·
Во второй части гайда проверяем возможности системы для сложных процессов и делимся комментариями экспертов
В первой части мы разобрали , как выбрать систему управления работой для команды: какие задачи она должна закрывать и какие возможности проверить перед внедрением. Но когда один инструмент используют несколько подразделений, этого уже недостаточно: приходится учитывать, как команды работают вместе, какие правила должны быть общими и где нужна гибкость для отдельных процессов.
Поэтому во второй части мы сосредоточились на критериях выбора системы для работы на уровне всей компании. При подготовке материала мы опирались на опыт команды Kaiten, изучили возможности других решений и пообщались с экспертами, которые помогли разобрать требования к системам с разных сторон.
Команды поддержки, разработки, закупок и редакции обычно приходят в общую систему уже со своими правилами работы. У каждой свои этапы, поля, доски и привычный порядок действий, который до этого мог нормально работать годами.
Проблемы начинаются, когда все это пытаются собрать в одном продукте. Если его настройки недостаточно гибкие, одной команде придется упростить этапы, другой — отказаться от нужных полей, а третьей — оставить часть работы в старом сервисе. 
Поэтому при выборе стоит проверить, получится ли перенести в систему реальные процессы команд без такой переделки.
Анна Юрченко, ITSM-эксперт и автор Telegram-канала «ITSM4U: Управление без иллюзий» , работала с системами управления задачами и в небольших компаниях, и в крупных организациях с множеством подразделений. При выборе продукта она предлагает учитывать эту разницу в масштабе:
Теперь перейдем к конкретным критериям выбора.
Проверять гибкость лучше на процессах, которые действительно отличаются друг от друга. Анна Юрченко приводит два знакомых примера из редакционной и продуктовой работы:
Чтобы командам не приходилось подстраивать свои процессы под общую схему, проверьте, какие настройки можно задавать отдельно для каждого пространства и доски. В частности, проверьте, можно ли:
На этот критерий обращает внимание Динара Камолова, методолог процессного управления и автор Telegram-канала Process Mgmt :
При выборе проверьте, можно ли назначить одному сотруднику разные роли в отдельных процессах и связать с ними нужные права.
При этом одного разделения по ролям может быть мало , если внутри роли сотрудникам доступны действия, которые компания хочет ограничить. Илья Горбаров, CEO digital-агентства Атвинта и автор канала «Горбаров о…» , вспоминает, что такая деталь однажды стала для его команды причиной отказаться от продукта:
Так что дополнительно стоит проверить права на конкретные действия с карточкой: кто может закрывать и удалять задачи, менять ответственного, сроки или другие важные данные.
Если компания регулярно запускает проекты с одинаковой структурой, проверьте, можно ли сохранить уже настроенный проект как собственный шаблон. В него могут входить этапы, поля, стандартные задачи и автоматизации.
Отдельно уточните, какие элементы сохраняются в шаблоне. Чем больше настроек приходится вручную добавлять после создания проекта, тем меньше времени такой шаблон экономит при подключении новой команды или запуске похожей работы
Сначала посчитайте, сколько рабочих пространств, проектов, досок и активных задач понадобится после подключения всех команд. Затем сравните эти значения с ограничениями тарифа , который рассматриваете.
Уточните:
Например, если 15 командам потребуется по три доски, выбранный тариф должен позволять создать не меньше 45. Если лимит ниже, выясните, доступно ли нужное количество досок на другом тарифе. Иначе придется объединять на одной доске команды или процессы, которые изначально планировали разделить.
Допустим, при выходе нового сотрудника к процессу подключаются несколько подразделений. IT потребуется подготовить учетную запись и технику, административной команде — пропуск и рабочее место, а HR — проконтролировать, чтобы все было готово к дате выхода.
Каждому отделу может понадобиться своя задача с отдельными сроками, ответственными и этапами. Все эти задачи относятся к одному процессу, поэтому между ними важно сохранить связь.
Связанные карточки позволяют сохранить общий контекст, но по ним еще непонятно, когда одна команда закончила свою часть работы и следующая может продолжать процесс. Динара Камолова предлагает отдельно проверить этот момент:
Для такой проверки посмотрите, можно ли закрепить обязательные поля , чек-листы, критерии качества, контрольные точки или SLA.
Сначала выясните, поддерживает ли система связи между отдельными задачами. Если такая функция есть, каждая команда сможет работать со своей карточкой, а сотрудники будут видеть, какие задачи относятся к одному процессу, и переходить между ними.
Отдельно уточните:
В нашем примере это понадобится, чтобы связать задачу HR с задачами IT и административной команды.
Если такой функции нет, сотрудникам придется вручную добавлять в карточки ссылки друг на друга. Как итог, на поиск связанных задач и сверку их статусов будет уходить больше времени.
В процессе с несколькими подразделениями одной команде могут понадобиться данные из задачи другой. Например, при выходе нового сотрудника на работу HR может потребоваться передать IT-команде информацию для подготовки учетной записи и техники.
Чтобы понять, насколько система подходит для такой передачи данных, стоит проверить:
Последний пункт особенно важен, когда несколько подразделений опираются на одни и те же данные. Если значения в связанных задачах расходятся, сотрудники могут планировать работу по разным срокам или другой устаревшей информации.
Автоматизацию стоит проверять на действиях, которые сотрудники регулярно повторяют вручную. Например, после передачи задачи на проверку сотрудник каждый раз назначает проверяющего, ставит срок и отправляет уведомление. Такая цепочка уже дает конкретное требование к продукту: после смены статуса нужно иметь возможность автоматически выполнить эти действия.
Для сравнения систем возьмите несколько подобных цепочек из реальной работы и проверьте, получится ли собрать их целиком.
В процессе работы правила могут меняться: команде потребуется добавить новое условие, скорректировать маршрут или заменить одно из действий. Поэтому при выборе проверьте, можно ли вносить такие изменения самостоятельно через настройки продукта.
На это же обращает внимание Динара Камолова:
Если для изменения каждого правила потребуется помощь разработчика, это стоит учитывать еще при выборе системы.
Разберите правило на событие и действие, а при необходимости добавьте условия:
Проверьте, есть ли в конструкторе события и действия, которые нужны именно для ваших процессов. Отдельно посмотрите, какие поля можно использовать в условиях: например, сумму, подразделение, тип задачи или собственные поля компании.
Для более сложных правил важно сочетать несколько условий и задавать разные действия в зависимости от результата проверки. Допустим, задачу со статусом «Готово к проверке» и высоким приоритетом нужно назначить руководителю группы, а с обычным приоритетом — дежурному специалисту. Проверьте, можно ли собрать такую логику в одном правиле.
После одного события может потребоваться выполнить сразу несколько действий. Например, после согласования заявки нужно изменить ее статус, создать задачу на закупку и уведомить инициатора.
Проверьте, можно ли добавить все эти действия в одно правило и задать порядок их выполнения. Если цепочку приходится разбивать на несколько правил, при изменении процесса придется отдельно менять каждое из них.
Отдельно уточните, как обрабатываются правила, которые одновременно меняют одно и то же поле. Например, после одного события два правила могут назначить карточке разных ответственных. В таком случае важно заранее понимать, какое значение останется в карточке.
ИИ-агент может стать еще одним способом работать с задачами без постоянного перехода в интерфейс системы. Илья Горбаров уже использует такой подход в Атвинте: через агента он может запросить задачи на день, посмотреть загрузку разработчиков или разобрать то, что пришло на согласование.
Если компании нужен такой формат, проверьте не только наличие подключения для ИИ-агентов, но и какие данные и действия можно открыть каждому из них.
Не все действия привязаны к изменению карточки. Компании может понадобиться создавать задачу первого числа каждого месяца, за три дня до срока отправлять напоминание или раз в неделю выполнять одно и то же действие для подходящих задач.
Проверьте, можно ли настроить запуск:
Для правил, которые зависят от срока задачи, отдельно проверьте, пересчитывается ли время запуска после изменения дедлайна. Если дедлайн изменился, напоминание за три дня до него тоже должно рассчитываться от новой даты.
Сначала выясните, что именно учитывает лимит выбранного тарифа. В одном продукте ограничение может зависеть от количества активных правил, в другом — от числа запусков или выполненных действий. Только после этого можно посчитать, хватит ли доступного объема для ваших процессов.
Например, если тариф считает каждое автоматическое действие, а через систему проходит 3 000 задач в месяц и для каждой выполняются четыре действия, потребуется около 12 000 выполнений. Сравнивать с лимитом нужно именно это число.
Уточните также:
Если правило не дало ожидаемый результат, администратору нужно понять, где выполнение остановилось и какие действия успели выполниться. Для этого проверьте, сохраняется ли история запусков и какие данные в ней доступны.
Для каждого запуска пригодится информация о том:
Еще проверьте, можно ли повторить неудачный запуск после исправления причины. Если такой возможности нет, администратору может потребоваться вручную выполнить действия, которые правило не завершило.
Когда в системе работают несколько команд, руководителю нужны ответы на конкретные вопросы: где растут просрочки, как меняются сроки работы, какие направления требуют внимания. Перед выбором выпишите несколько таких вопросов и проверяйте отчеты в продукте именно на них. Так будет проще отделить нужные возможности от графиков, которыми никто не будет пользоваться.
Начните с охвата отчета. Если команды работают в разных проектах, досках или пространствах, проверьте, можно ли свести их данные в одном месте. Иначе руководителю придется открывать несколько отчетов и вручную сопоставлять результаты.
Андрей Малахов, управляющий партнер в PMLogix и автор Telegram-канала о проектном управлении , работал со сводной отчетностью в крупной публичной сети. В такой отчет у них входили данные сразу по нескольким параметрам проектов:
При сравнении продуктов посмотрите:
Проверьте эти возможности вместе. Отчет по всем проектам мало поможет, если из него нельзя выделить конкретную команду или сгруппировать данные в том разрезе, который нужен руководителю.
Текущие показатели показывают, что происходит сейчас. Для сравнения периодов нужна история изменений: иначе после смены статуса или срока часть информации о прошлой работе исчезнет.
На практике сравнивать могут не только календарные периоды. Андрей Малахов приводит еще один вариант:
Проверьте, какие данные можно использовать в отчетах за прошлые периоды:
Отдельно уточните, от какого момента считается каждый показатель. Например, длительность задачи можно отсчитывать от ее создания или от перехода в работу. На одном и том же наборе задач эти способы дадут разные результаты, поэтому их стоит сверить с тем, как компания считает сроки сейчас.
Проверьте, можно ли из сводной цифры или графика перейти к задачам, которые в него вошли. Если в отчете 25 просроченных задач, руководителю нужен список именно этих карточек, чтобы не искать их вручную в разных проектах.
Уже в этом списке можно посмотреть детали, которых нет в общей цифре: какие проекты и этапы встречаются чаще, кто отвечает за задержавшиеся задачи и насколько давно прошел срок. После этого руководитель может открыть нужную карточку и разобрать конкретную ситуацию.
Готовых отчетов может быть недостаточно, если руководителю нужно смотреть на работу компании по своим показателям. Например, стандартный отчет показывает количество задач и сроки, но не позволяет собрать в одном месте показатели, которые руководитель проверяет регулярно.
Одной общей сводки в крупной компании может не хватить. Например, Андрей Малахов приводит несколько разрезов, которые использовали для разных управленческих задач:
Проверьте, можно ли:
Последние два пункта важны для отчетов, которые руководитель открывает регулярно. Если период приходится каждый раз менять вручную, а данные обновлять повторной сборкой отчета, часть работы с аналитикой останется ручной.
Заявки могут быть частью работы как внутренних служб, так и клиентской поддержки. Сотрудник может попросить открыть доступ к программе у IT-команды, оплатить счет у бухгалтерии или заказать технику у отдела закупок. Внешний клиент, в свою очередь, может обратиться в поддержку с вопросом по продукту или сообщить о проблеме.
Во всех этих случаях один человек обращается за результатом, а работу по заявке выполняет другая команда. Такой формат стоит отдельно учитывать при выборе системы. Разберем критерии, по которым можно сравнить продукты для работы с заявками.
Определите, откуда в систему должны поступать заявки. Например:
Когда над заявкой работают несколько специалистов, им может понадобиться обсудить ее между собой. Проверьте, можно ли оставить внутренний комментарий, который увидят сотрудники, но не заявитель.
Также после поступления заявки можно отдельно проверить инструменты, которые используются уже во время работы специалиста с обращением. Илья Горбаров среди таких возможностей выделяет подключение ИИ-агента:
Сначала проверьте, какие поля можно добавить в форму. Для разных заявок могут понадобиться:
Также проверьте, можно ли сделать нужные поля обязательными и сохраняется ли каждый ответ в отдельном поле заявки. Тогда еще до отправки можно потребовать данные, без которых специалист не сможет начать работу, а после отправки они останутся в карточке в понятной структуре.
Сравните правила распределения в компании с возможностями продукта. Проверьте:
Если нужного правила нет, часть заявок придется просматривать и назначать вручную.
Когда в системе много заявок, каждой команде нужен свой рабочий список. Например, IT-поддержка может отдельно вывести новые заявки без исполнителя, а финансовый отдел — обращения на согласование оплаты. Такой список в разных продуктах может называться очередью, представлением или сохраненным фильтром.
При выборе проверьте, насколько гибко можно настраивать списки. Важно учитывать:
SLA задает сроки обработки заявок. Например, для критичного обращения компания может установить 30 минут на первый ответ и четыре рабочих часа на решение. При выборе системы важно проверить, какие сроки она позволяет отслеживать и по каким правилам их рассчитывает.
Проверьте:
Даже в двух частях невозможно разобрать все функции, которые могут встретиться в системах управления работой. Некоторые продукты выходят далеко за пределы задач и проектов: в них можно вести продажи и клиентскую базу, работать с документами, учитывать отдельные финансовые данные или переносить рабочее общение в корпоративные чаты.
Мы не стали подробно уходить в каждое из этих направлений, иначе материал превратился бы в разбор сразу нескольких классов систем. Отдельные функции лучше проверять уже под конкретные задачи компании. Например, про рабочее общение у нас есть отдельный материал о выборе корпоративного мессенджера , а про работу с клиентами — обзор CRM для отдела продаж и разбор того, как устроены CRM-системы и как их выбирать.
В третьей части вернемся к критериям выбора и разберем уже то, что стоит проверить непосредственно перед внедрением: как решение будет связано с другими сервисами компании, насколько сложно перенести в него данные, какие требования возникают к безопасности и во сколько обойдется переход. Отдельно рассмотрим, как провести пилот до того, как подключать всю компанию.