Как выбрать систему управления работой. Часть 3: интеграции, безопасность и цены
Блог Kaiten ·
Финал гайда — о том, что важно выяснить до подписания договора. В конце — бесплатный чек-лист на 200+ критериев
Это третья часть большого гайда по выбору системы управления работой. В первых двух частях мы разбирали саму работу в системе: сначала на уровне отдельных команд, затем на уровне всей компании. Теперь завершаем выбор и переходим к тому, что нужно проверить уже перед внедрением.
Если пропустили предыдущие материалы:
Также в конце этой статьи — бесплатный чек-лист на 200+ критериев!
При переходе на новую систему компания может оставить CRM, бухгалтерскую программу, репозиторий кода и другие привычные сервисы. Тогда при выборе проверьте, как с ними будет работать новый продукт: какие данные можно передавать, после каких событий начинается обмен и синхронизируются ли последующие изменения.
Допустим, после создания заказа в учетной системе команде нужна отдельная задача на его выполнение. В нее должны попасть номер заказа и срок, а после завершения задачи итоговый статус нужно передать обратно в учетную систему.
Проверьте этот процесс целиком:
Отдельно проверьте, как работает синхронизация после первого обмена. Если срок заказа изменили уже после создания задачи, новая дата должна попасть и в связанную карточку. Когда одно и то же поле можно менять в обеих системах, выясните, откуда будет браться актуальное значение. Без такого правила в учетной системе и рабочей карточке могут остаться разные сроки.
Готовая интеграция может не передавать нужные данные или не поддерживать часть действий. Тогда пригодится API: через него можно, например, получать данные из карточек, создавать новые карточки и менять их поля.
Как будет устроен такой обмен, зависит от инфраструктуры компании. Если в ней есть интеграционная шина — общий слой, через который корпоративные системы обмениваются данными, — для подключения новой системы обычно хватает готовых технических коннекторов.
Если обмен должен учитывать бизнес-логику, то есть правила конкретного процесса, под него все равно придется писать отдельный адаптер. Поэтому еще до выбора выясните, кто его разработает, кто будет его сопровождать и во что это обойдется.
От возможностей API зависит, сколько работы потребует такой адаптер. Что в нем проверить:
Возможности API — только одна сторона интеграции. Татьяна Сальникова, старший системный аналитик и автор Telegram-канала «Системный сервант» , советует оценить и вторую:
«Надо проверить, насколько API новой системы совместим с системами компании, с которыми придется интегрироваться: например, знают ли команды этих систем предлагаемые технологии интеграции».
Также Татьяна предлагает выяснить, может ли поставщик доработать или настроить 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 критериев из всех трех частей.
Это сравнительная таблица: сначала впишите в нее требования своей компании, а затем пройдите те же строки по каждой системе — так различия между продуктами окажутся рядом.