Выбираем систему для управления процессами в больших командах: часть 2

Запутанные процессы?

Покажем, как навести порядок с помощью Кайтен — за 30 минут.

Записаться на демо

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

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

Если нужно объединить работу разных команд в одной системе

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

Проблемы начинаются, когда все это пытаются собрать в одном продукте. Если его настройки недостаточно гибкие, одной команде придется упростить этапы, другой — отказаться от нужных полей, а третьей — оставить часть работы в старом сервисе. 

Поэтому при выборе стоит проверить, получится ли перенести в систему реальные процессы команд без такой переделки.

Анна Юрченко, ITSM-эксперт и автор Telegram-канала «ITSM4U: Управление без иллюзий», работала с системами управления задачами и в небольших компаниях, и в крупных организациях с множеством подразделений. При выборе продукта она предлагает учитывать эту разницу в масштабе:

Теперь перейдем к конкретным критериям выбора.

Можно ли настроить рабочее пространство под процесс команды

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

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

• создавать свои этапы и при необходимости разделить их на более подробные стадии;
• добавить свои поля в карточки и сделать часть из них обязательными;
• собрать в рабочем пространстве только те доски, которые нужны команде;
• перенести или подключить уже настроенную доску к другому пространству без ее пересоздания, если структура команд изменится.

Можно ли задавать разные роли и права

На этот критерий обращает внимание Динара Камолова, методолог процессного управления и автор Telegram-канала Process Mgmt:

При выборе проверьте, можно ли назначить одному сотруднику разные роли в отдельных процессах и связать с ними нужные права.

При этом одного разделения по ролям может быть мало, если внутри роли сотрудникам доступны действия, которые компания хочет ограничить. Илья Горбаров, CEO digital-агентства Атвинта и автор канала «Горбаров о…», вспоминает, что такая деталь однажды стала для его команды причиной отказаться от продукта:

Так что дополнительно стоит проверить права на конкретные действия с карточкой: кто может закрывать и удалять задачи, менять ответственного, сроки или другие важные данные.

Можно ли быстро запускать однотипные проекты

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

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

Проверьте лимиты на пространства, проекты и задачи

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

Уточните:

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

Например, если 15 командам потребуется по три доски, выбранный тариф должен позволять создать не меньше 45. Если лимит ниже, выясните, доступно ли нужное количество досок на другом тарифе. Иначе придется объединять на одной доске команды или процессы, которые изначально планировали разделить.

Если один процесс проходит через несколько подразделений

Допустим, при выходе нового сотрудника к процессу подключаются несколько подразделений. IT потребуется подготовить учетную запись и технику, административной команде — пропуск и рабочее место, а HR — проконтролировать, чтобы все было готово к дате выхода.

Каждому отделу может понадобиться своя задача с отдельными сроками, ответственными и этапами. Все эти задачи относятся к одному процессу, поэтому между ними важно сохранить связь.

Можно ли закрепить условия передачи работы

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

Для такой проверки посмотрите, можно ли закрепить обязательные поля, чек-листы, критерии качества, контрольные точки или SLA.

Можно ли связывать задачи разных подразделений

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

Отдельно уточните:

• работают ли связи между задачами из разных пространств или досок;
• можно ли связать одну задачу сразу с несколькими другими;
• отображается ли связь в обеих карточках, чтобы сотрудники могли переходить между ними.

В нашем примере это понадобится, чтобы связать задачу HR с задачами IT и административной команды.

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

Проверьте, какие данные можно передавать между связанными задачами

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

Чтобы понять, насколько система подходит для такой передачи данных, стоит проверить:

• можно ли автоматически передавать значения полей между связанными задачами;
• можно ли выбирать конкретные поля. При выходе сотрудника разным подразделениям нужны разные данные: IT-команде — дата выхода и формат работы, административной — дата выхода и офис. Если передавать всем одинаковый набор полей, в связанных задачах появится информация, которая не нужна конкретной команде;
• видно ли в карточке актуальный статус связанной задачи или для этого нужно переходить на доску другой команды;
• синхронизируются ли значения после изменений. Например, если HR перенесет дату выхода, обновится ли она и в задаче IT-команды или там останется прежнее значение.

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

Если хотите автоматизировать повторяющиеся действия

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

Для сравнения систем возьмите несколько подобных цепочек из реальной работы и проверьте, получится ли собрать их целиком.

Насколько просто менять автоматизации

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

На это же обращает внимание Динара Камолова:

Если для изменения каждого правила потребуется помощь разработчика, это стоит учитывать еще при выборе системы.

Можно ли собрать нужное правило

Разберите правило на событие и действие, а при необходимости добавьте условия:

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

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

Для более сложных правил важно сочетать несколько условий и задавать разные действия в зависимости от результата проверки. Допустим, задачу со статусом «Готово к проверке» и высоким приоритетом нужно назначить руководителю группы, а с обычным приоритетом — дежурному специалисту. Проверьте, можно ли собрать такую логику в одном правиле.

Сколько действий можно добавить в одно правило

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

Проверьте, можно ли добавить все эти действия в одно правило и задать порядок их выполнения. Если цепочку приходится разбивать на несколько правил, при изменении процесса придется отдельно менять каждое из них.

Отдельно уточните, как обрабатываются правила, которые одновременно меняют одно и то же поле. Например, после одного события два правила могут назначить карточке разных ответственных. В таком случае важно заранее понимать, какое значение останется в карточке.

Если планируете работать через ИИ-агентов, проверьте доступ к системе

ИИ-агент может стать еще одним способом работать с задачами без постоянного перехода в интерфейс системы. Илья Горбаров уже использует такой подход в Атвинте: через агента он может запросить задачи на день, посмотреть загрузку разработчиков или разобрать то, что пришло на согласование.

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

Можно ли запускать автоматизации по времени

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

Проверьте, можно ли настроить запуск:

• в конкретную дату и время;
• через заданный промежуток после события;
• за определенное время до срока задачи;
• по повторяющемуся расписанию.

Для правил, которые зависят от срока задачи, отдельно проверьте, пересчитывается ли время запуска после изменения дедлайна. Если дедлайн изменился, напоминание за три дня до него тоже должно рассчитываться от новой даты.

Хватит ли лимитов на ваш объем автоматизаций

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

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

Уточните также:

• на каком уровне действует лимит: для всей компании, отдельного пространства или проекта;
• за какой период считается использование и когда лимит обновляется;
• можно ли увеличить доступный объем на выбранном или другом тарифе;
• будут ли новые запуски выполняться после исчерпания лимита.

Можно ли разобраться в ошибке автоматизации

Если правило не дало ожидаемый результат, администратору нужно понять, где выполнение остановилось и какие действия успели выполниться. Для этого проверьте, сохраняется ли история запусков и какие данные в ней доступны.

Для каждого запуска пригодится информация о том:

• какое правило выполнялось;
• для какой задачи;
• какие условия прошли проверку;
• какие действия выполнялись до ошибки;
• на каком шаге выполнение остановилось;
• какая причина ошибки указана в журнале.

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

Если руководителю нужны отчеты по нескольким командам

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

Можно ли собрать данные разных команд в одном отчете

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

Андрей Малахов, управляющий партнер в PMLogix и автор Telegram-канала о проектном управлении, работал со сводной отчетностью в крупной публичной сети. В такой отчет у них входили данные сразу по нескольким параметрам проектов:

При сравнении продуктов посмотрите:

• какие данные можно объединить — из нескольких проектов, досок, пространств или команд;
• как работает фильтрация — можно ли оставить только нужную команду, проект, статус, приоритет или период;
• как можно группировать данные — например, сравнить просрочки по командам или сроки по типам работ.

Проверьте эти возможности вместе. Отчет по всем проектам мало поможет, если из него нельзя выделить конкретную команду или сгруппировать данные в том разрезе, который нужен руководителю.

Сохраняет ли система историю для анализа прошлых периодов

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

На практике сравнивать могут не только календарные периоды. Андрей Малахов приводит еще один вариант:

Проверьте, какие данные можно использовать в отчетах за прошлые периоды:

• даты начала и завершения работы;
• переходы между этапами и статусами;
• время на каждом этапе;
• историю изменения сроков.

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

Можно ли открыть конкретные задачи из отчета

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

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

Можно ли собрать отчеты под свои задачи

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

Одной общей сводки в крупной компании может не хватить. Например, Андрей Малахов приводит несколько разрезов, которые использовали для разных управленческих задач:

Проверьте, можно ли:

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

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

Если в системе будут обрабатывать заявки

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

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

Через какие каналы можно получать заявки и какие инструменты есть для работы с обращениями

Определите, откуда в систему должны поступать заявки. Например:

• электронная почта;
• веб-форма или портал для заявителей;
• мессенджер или рабочий чат.

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

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

Какие данные можно собирать через форму

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

• текстовые поля;
• списки с вариантами ответа;
• даты;
• числа;
• файлы.

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

По каким правилам можно распределять заявки

Сравните правила распределения в компании с возможностями продукта. Проверьте:

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

Если нужного правила нет, часть заявок придется просматривать и назначать вручную.

Можно ли настроить очереди под работу команды

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

При выборе проверьте, насколько гибко можно настраивать списки. Важно учитывать:

• какие поля заявки можно использовать для отбора: тип обращения, статус, приоритет, исполнителя, срок и другие параметры;
• можно ли сочетать несколько условий, например вывести только заявки высокого приоритета без исполнителя;
• можно ли менять порядок заявок внутри списка: сначала показывать просроченные, самые срочные или самые старые обращения.

Если нужен SLA, проверьте, как считаются сроки

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

Проверьте:

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

Что дальше

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

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

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