Как выбрать систему управления работой. Часть 3: интеграции, безопасность и цены

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

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

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

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

Если пропустили предыдущие материалы:

• Часть 1. Как выбрать систему управления работой: задачи, проекты и документация
• Часть 2. Выбираем систему для управления процессами в больших командах

Также в конце этой статьи — бесплатный чек-лист на 200+ критериев!

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

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

Проверьте, закрывает ли готовая интеграция нужный обмен

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

Проверьте этот процесс целиком:

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

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

Если готовой интеграции не хватает, проверьте API

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

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

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

От возможностей API зависит, сколько работы потребует такой адаптер. Что в нем проверить:

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

Возможности API — только одна сторона интеграции. Татьяна Сальникова, старший системный аналитик и автор Telegram-канала «Системный сервант», советует оценить и вторую:

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

Проверьте, что можно передавать через вебхуки

Часть запросов к API можно заменить вебхуками. Вебхук — это автоматическое сообщение, которое уходит в другой сервис сразу после нужного события. Например, компания ведет обращения клиентов в сервисе поддержки, а задачи по ним — в системе управления работой. Когда статус задачи меняется на «Готово», с помощью вебхука можно отправить в сервис поддержки ID задачи и новый статус, и там автоматически обновится связанное обращение.

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

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

Для этого компании нужна точка входа, через которую внешние запросы попадают во внутреннюю сеть. Как ее устроить, зависит от инфраструктуры и правил безопасности: например, ее размещают в DMZ — защищенной зоне на границе сети — и дополнительно защищают межсетевым экраном или фильтром веб-запросов (WAF).

Для вебхуков проверьте:

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

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

Проверьте требования к безопасности

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

Уточните, где хранятся данные

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

Алексей Лукацкий, бизнес-консультант по информационной безопасности в Positive Technologies и автор Telegram-канала «Пост Лукацкого», советует разобраться в этом вопросе подробнее:

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

Алексей Лукацкий добавляет к этой проверке еще один вопрос:

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

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

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

Перед выбором проверьте:

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

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

Проверьте вход через корпоративные учетные записи

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

Отдельно проверьте двухфакторную аутентификацию: можно ли потребовать второй способ подтверждения входа для всех сотрудников.

Проверьте журнал аудита

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

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

Для каждого события посмотрите, можно ли определить пользователя, время, IP-адрес и объект, которого коснулось действие. Если важно разбирать правки настроек или данных, проверьте также, видно ли предыдущее значение. Иначе по журналу будет понятно, что изменение произошло, но не его детали.

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

Можно ли вернуть случайно удаленные данные

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

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

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

Посмотрите, чем поставщик подтверждает безопасность

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

Процессы информационной безопасности. Если поставщик ссылается на ГОСТ Р ИСО/МЭК 27001-2021, откройте сертификат и найдите область сертификации. В ней указано, какую деятельность компании проверяли. Для оценки сервиса важно, чтобы проверка охватывала разработку, сопровождение или эксплуатацию именно выбранного продукта.

Соответствие конкретного продукта требованиям безопасности. Если компании разрешено использовать только ПО с сертификатом ФСТЭК, проверьте продукт в государственном реестре сертифицированных средств защиты информации.

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

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

Алексей Лукацкий советует не ограничиваться документами и поговорить с поставщиком напрямую:

Если предстоит переход из другого продукта

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

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

Проверьте, что сохранится после импорта

Что проверить после пробного импорта:

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

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

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

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

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

Проверьте, какие данные можно выгрузить и в каком виде

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

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

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

В выгрузке важно сохранить связи между данными. Например, у комментария нужен идентификатор задачи, к которой он относится, а у связанных задач — идентификаторы друг друга.

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

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

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

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

Проверьте:

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

Особенно внимательно проверьте первый пункт. Алексей Грищенков называет ошибки в подсчете пользователей типовыми:

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

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

Еще Алексей Грищенков советует обратить внимание на регулярные платежи:

Проверьте систему в реальной работе

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

Напоследок — 200+ критериев в одной таблице

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

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