Автоматизация

Короткий ответ

Сделка и смарт-процесс — инструменты для разных задач.

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

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

Когда сделка логична

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

Когда смарт-процесс полезен

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

Пример

Одна коммерческая возможность может привести к нескольким контрактам или этапам исполнения.

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

Ошибка архитектуры

Создавать новый смарт-процесс под каждую категорию:

• гарантия;
• письмо;
• расчёт;
• документ;
• отдельную роль.

Такие объекты часто лучше остаются задачами, полями, делами или документами.

Вывод

Выбор СРМ-сущности начинается с вопроса «что живёт независимо?», а не с перечня доступных функций Битрикс24.

Практический следующий шаг

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

Короткий ответ

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

Слишком широкие права создают риск случайных изменений. Слишком узкие — заставляют сотрудников обходить СРМ через переписку и личные файлы.

Что определить до настройки

Для каждой роли:

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

Пример ролей

Тендерный специалист

Работает с закупкой, документами, сроками, статусами.

Технический эксперт

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

Юрист

Видит договорный и правовой контекст.

Руководитель

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

Исполнение

Получает доступ после передачи к своему контуру.

Ролевая модель Битрикс24

СРМ позволяет назначать роли с разными правами для сотрудников и подразделений.

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

Вывод

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

Практический следующий шаг

Составьте матрицу «роль → что видит → что изменяет → что утверждает» и только потом переносите её в права СРМ.

Короткий ответ

Автоматически созданная плохая задача остаётся плохой задачей — только создаётся быстрее и чаще.

Реальный пример из практики:

«Посмотреть гарантию».

Исполнитель действительно может её посмотреть и закрыть задачу.

Что должно быть в шаблоне

• действие;
• объект;
• критерий;
• срок;
• ожидаемый артефакт;
• ссылка на исходные данные;
• ответственный.

Пример

Вместо:

Проверить документы.

Лучше:

Сверить комплект участника с перечнем обязательных документов закупки. До 15:00. Результат: чек-лист со статусом по каждому требованию и отдельный список недостающих документов.

Что может автоматизировать Битрикс24

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

Но смысл задачи остаётся ответственностью проектировщика процесса.

Как принимать результат

Если задача критична, закрытие должно означать достижение конкретного результата, а не просто нажатие «Завершить».

Иногда это можно проверить:

• обязательным полем;
• файлом;
• заполненным чек-листом;
• комментариями по структуре.

Вывод

Автоматизация задач начинается с хорошего шаблона результата. Иначе система масштабирует размытые поручения.

Практический следующий шаг

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

Короткий ответ

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

Битрикс24 позволяет задавать обязательность полей для отдельных стадий в сделках и смарт-процессах.

Пример логики

«К анализу»

Нужны:

• ссылка на закупку;
• заказчик;
• предмет.

«участие согласовано»

Нужны:

• решение;
• владелец;
• ключевое основание.

«К подаче»

Нужны:

• готовность расчёта;
• статус проверки документов;
• срок.

«Победа»

Нужны:

• итоговая цена;
• протокол;
• данные по договору.

Почему нельзя сделать обязательным всё

Если сотрудник при создании новой карточки должен заполнить 40 полей, часть данных будет:

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

Качество данных падает.

Что должно быть обязательным

Только данные, отсутствие которых:

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

Вывод

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

Практический следующий шаг

Выберите по 1–3 критических данных для каждой стадии. Не превращайте контроль этапа в форму из десятков обязательных полей.

Короткий ответ

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

Из реальной практики: процесс вида

агрегатор → несколько таблиц → ручная чистка → шаблон импорта → Битрикс24 → портал клиента

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

Что нужно определить

Источник истины

Какая система владеет каждым полем.

Триггер

Когда данные должны передаваться.

Маппинг

Как одно поле источника соответствует полю назначения.

Дедупликация

Как система понимает, что закупка уже была передана.

Ошибка

Что происходит при неполных данных или недоступности второй системы.

Повтор

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

Когда интеграция не нужна

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

Главный риск

Интеграция ускоряет и правильные данные, и ошибочные.

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

Вывод

Ценность интеграции — не отсутствие таблиц само по себе, а сокращение повторного ввода, задержки и риска потери информации.

Практический следующий шаг

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

Короткий ответ

Руководителю нужен не максимальный объём данных, а быстрое понимание, где процесс требует внимания.

Битрикс24 предлагает Конструктор бизнес-аналитики для создания аналитических отчётов на основе данных портала.

Что полезно видеть

Воронка

Сколько процедур:

• найдено;
• квалифицировано;
• согласовано;
• подано;
• допущено;
• завершено.

Возраст

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

Дедлайны

Какие критические задачи просрочены или приближаются к сроку.

Качество

Причины:

• Отказ от участия;
• отклонений;
• Проиграно;
• Решение не принято.

Передача

Сколько побед ещё не принято исполнением.

Экономика

Только если данные действительно ведутся качественно:

• сумма;
• себестоимость;
• маржинальность;
• отклонение факта.

Важное правило

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

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

Не пытаться управлять всем ежедневно

Часть показателей нужна каждый день, часть — раз в неделю или месяц.

Вывод

Аналитическая панель должна превращать данные СРМ в очередь управленческих решений, а не в экран, который открывают только перед совещанием.

Практический следующий шаг

Сначала определите управленческие вопросы, затем стройте отчёт. Дашборд без действия по отклонению — просто красивая статистика.

Короткий ответ

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

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

Битрикс24 позволяет проверять работу роботов в карточке СРМ, но для сложных интеграционных сценариев нужен более широкий операционный контроль.

Минимальная наблюдаемость

Для критического потока должны быть понятны:

Запуск

Какое событие инициировало действие.

Результат

Что должно появиться после успеха.

Ошибка

Где фиксируется сбой.

Ответственный

Кто получает сигнал.

Повтор

Можно ли запустить действие ещё раз без дублей.

Восстановление

С какого шага продолжить процесс.

Почему это важно

Автоматизация может «тихо» не выполнить действие.

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

Без журнала возникает спор:

«Наверное, робот не сработал».

Это не диагностируемая система.

Практический принцип

Чем критичнее операция для срока, денег или договора, тем меньше она должна зависеть от невидимого фонового действия.

Вывод

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

Практический следующий шаг

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

Короткий ответ

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

Тендерный процесс содержит переносы, отмены, неполные данные, повторы и человеческие ошибки.

Какие сценарии тестировать

Обычный

Данные полные, сроки стандартные, все роли доступны.

Перенос срока

Заказчик изменил дату.

Отмена закупки

Нужно остановить зависимые задачи и уведомления.

Неполные данные

Обязательное поле отсутствует.

Повтор

Один и тот же вебхук/событие пришло дважды.

Ошибка внешней системы

Получатель недоступен.

Смена ответственного

Сотрудник отсутствует или сделка передана.

Уже выполненное действие

Робот не должен создать второй договор или дублирующую задачу.

Регрессия

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

Например, исправление логики переноса срока может случайно нарушить расчёт внутренних дедлайнов.

Набор примеров сбоев

Полезно сохранять реальные сбои как тестовые примеры.

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

Вывод

Автоматизация готова не тогда, когда работает на демо, а когда предсказуемо ведёт себя на отклонениях от идеального сценария.

Практический следующий шаг

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

Короткий ответ

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

Чек-лист

Процесс

• стадии согласованы;
• владельцы определены;
• исключения известны.

Данные

• источник истины определён;
• поля не дублируются;
• критические данные структурированы.

Задачи

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

Права

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

Интеграции

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

Контроль

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

Тестирование

• проверены обычные и ошибочные сценарии;
• есть набор регрессионных проверок.

Поддержка

• понятно, кто меняет настройку после изменения процесса.

Красные флаги

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

Вывод

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

Практический следующий шаг

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