Примеры автоматизации
Уровень Продвинутый
ГОЛОСОВАНИЕ С НЕЯВНЫМ ПРАВОМ ВЕТО — КАК СОХРАНИТЬ «ЗАСТОЛЬНЫЙ» ПРИНЦИП В ЦИФРЕ
«Сначала все, потом президент» — почему этот сценарий не подходит живому бизнесу
Откройте любую инструкцию по настройке голосования в Битрикс24. Сценарий везде одинаков:
- Первый этап — голосуют все, кроме руководителя.
- Если большинство «За», запускается второй этап — финальное решение лица с правом вето.
Это логично для формальных, асинхронных процедур. Но в компаниях, где решения традиционно принимались «за одним столом», такой подход разрушает культуру. Люди не видят итогов обсуждения, не знают аргументов коллег, не могут повлиять на решение в диалоге.
Задача: оцифровать процесс так, как он есть на самом деле:
- Все участники собираются в одном чате процесса.
- Идёт живое обсуждение (прямо в CRM).
- Каждый голосует. Голоса видны всем.
- Есть человек, чьё «Против» отменяет любое большинство.
- В конце — протокол, журнал и понятный статус сделки.
Фундамент: без этого процесс не соберётся
Настроена структура компании и роли. Подробнее: [статья про структуру].
- Создана константа Состав_Комитета (тип: Привязка к пользователю). В ней — роли, а не имена сотрудников (например: Руководитель отдела продаж, Финансовый директор, Юрист). Подробнее: [статья про константы].
- Создана константа Лицо_с_правом_вето (тип: Привязка к пользователю). Отдельно, чтобы легко менять «главного».
- Создан Универсальный список «Журнал решений» с полями: Дата, ID Сделки, Решение, Состав, Результаты голосования, Статус. Подробнее: [статья про логирование].
В сделке созданы пользовательские поля (если считаете необходимым):
- UF_CRM_ИтогГолосования (строка: Одобрено / Отказ / На доработку),
- UF_CRM_ПротоколГолосования (текст/привязка к файлу).
⚠️ Важно: Если вы не используете роли и константы, придётся вручную редактировать каждый БП при кадровых изменениях. На этом этапе закладывается масштабируемость.
Сборка:
превращаем схему в работающий БП
Настраиваем шаблон бизнес-процесса:
- В основных настройках снимаем галочки "при добавлении" и "при изменении" - процесс запускается Исполнителем;
- Получаем при запуске Резюме по сделке (создаем в параметрах поле с типом "Файл";
- Создаем локальную переменную бизнес-процесса "Решение" с типом "строка" или "список" (как считаете правильным);
Что вы получили в итоге
Скорость
Вместо 2–3 дней согласования по email — 1 час обсуждения в чате.
Прозрачность
Любое решение можно размотать до протокола и исходных голосов.
Контроль
Журнал решений — это база данных корпоративных прецедентов.
Гибкость
Состав комитета и лицо с вето управляются через константы, а не через редактирование БП.
Культура
Вам нужен не такой же, а ваш собственный процесс?
Я показал конкретную реализацию под конкретное бизнес-правило («ничья = победа»). Но в вашей компании может быть иначе: право вето у двух людей, кворум 2/3, обязательное приложение расчётов и т.д.
Итоговый протокол, журнал и связка со стадиями сделки — это универсальные блоки. А логика подсчёта и вето — всегда уникальна.
Если вам нужен не «шаблонный», а точно сшитый под ваш регламент процесс голосования — опишите свой кейс. Я спроектирую архитектуру и покажу, как она реализуется в CRM.