схема бизнес-процесса голосования с правом вето
Примеры автоматизации

Уровень Продвинутый

ГОЛОСОВАНИЕ С НЕЯВНЫМ ПРАВОМ ВЕТО — КАК СОХРАНИТЬ «ЗАСТОЛЬНЫЙ» ПРИНЦИП В ЦИФРЕ

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

«Сначала все, потом президент» — почему этот сценарий не подходит живому бизнесу

Откройте любую инструкцию по настройке голосования в Битрикс24. Сценарий везде одинаков:

  1. Первый этап — голосуют все, кроме руководителя.
  2. Если большинство «За», запускается второй этап — финальное решение лица с правом вето.

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

Задача: оцифровать процесс так, как он есть на самом деле:

  • Все участники собираются в одном чате процесса.
  • Идёт живое обсуждение (прямо в CRM).
  • Каждый голосует. Голоса видны всем.
  • Есть человек, чьё «Против» отменяет любое большинство.
  • В конце — протокол, журнал и понятный статус сделки.
Результат: цифра не ломает привычки, а делает их прозрачными и управляемыми.


Фундамент: без этого процесс не соберётся

ПРЕДВАРИТЕЛЬНЫЕ НАСТРОЙКИ: ЧТО ДОЛЖНО БЫТЬ В СИСТЕМЕ ДО НАЧАЛА НАПИСАНИЯ БИЗНЕС-ПРОЦЕССА

Настроена структура компании и роли. Подробнее: [статья про структуру].


  • Создана константа Состав_Комитета (тип: Привязка к пользователю). В ней — роли, а не имена сотрудников (например: Руководитель отдела продаж, Финансовый директор, Юрист). Подробнее: [статья про константы].
  • Создана константа Лицо_с_правом_вето (тип: Привязка к пользователю). Отдельно, чтобы легко менять «главного».
  • Создан Универсальный список «Журнал решений» с полями: Дата, ID Сделки, Решение, Состав, Результаты голосования, Статус. Подробнее: [статья про логирование].

В сделке созданы пользовательские поля (если считаете необходимым):
  • UF_CRM_ИтогГолосования (строка: Одобрено / Отказ / На доработку),
  • UF_CRM_ПротоколГолосования (текст/привязка к файлу).

⚠️ Важно: Если вы не используете роли и константы, придётся вручную редактировать каждый БП при кадровых изменениях. На этом этапе закладывается масштабируемость.

Сборка:

превращаем схему в работающий БП

Настраиваем шаблон бизнес-процесса:

  1. В основных настройках снимаем галочки "при добавлении" и "при изменении" - процесс запускается Исполнителем;
  2. Получаем при запуске Резюме по сделке (создаем в параметрах поле с типом "Файл";
  3. Создаем локальную переменную бизнес-процесса "Решение" с типом "строка" или "список" (как считаете правильным);

Шаг 1. Создаём процесс и собираем «зал»

Триггер (начало): запуск вручную исполнителем бизнес-процесса из сделки (БП «Провести голосование»).

Действие 1: Создаем элемент списка "Заседаний"

Действие 2: Добавляем комментарий в тайм-лайн сделки о начале голосования (позволяет зафиксировать время и отслеживать изменения в параметрах сделки)

Действие 3: Получить из константы Состав_Комитета участников и отправляем им личное уведомление (если требуется).

Действие 4: Получаем данные об элементе списка "Заседаний".

Настраиваем блок Голосования

5. Параметры (выборочно):

  • Утверждают сотрудники:{{Глобальные константы}}
  • Тип утверждения: Голосование сотрудников
  • Описание задания:На утверждение вынесен документ {=Параметры->документ :PROPERTY_DOKUMENT_PRINTABLE} по сделке "{{Название}}"
  • Устанавливать текст статуса: Да
  • Текст статуса: Проголосовало #PERCENT#% (#VOTED# из #TOTAL#)
    Утвердили: #APPROVERS#
    Отклонили: #REJECTERS#

5/1 и 5/2 - записываем результаты голосования в элемент списка и в переменную "Решение"

Реализация неявного права вето:

6 - используем конструкцию "Условие" для проверки итогов голосования и исправления значения переменной "Решение" -> значение в поле Решение в журнале. Не забываем про "пустой путь" на случай ошибки для выхода из конструкции

Фиксируем результат голосования

7. Актуализируем данные по элементу списка "журнал"

8. Добавляем комментарий в тайм-лайн сделки об итогах голосования

9. Заполняем поле с итогами голосования в Журнале

10. Создаем Протокол

11. Добавляем файл "Протокол" в элемент журнала

12. Уведомляем участников об итогах

Финальные действия в сделке

13. Добавляем конструкцию "условие" для выбора сценария

14. При положительном решении - меняем стадию в сделке. При отрицательном - на Ваше усмотрение

Что вы получили в итоге

Скорость

Вместо 2–3 дней согласования по email — 1 час обсуждения в чате.

Прозрачность

Любое решение можно размотать до протокола и исходных голосов.

Контроль

Журнал решений — это база данных корпоративных прецедентов.

Гибкость

Состав комитета и лицо с вето управляются через константы, а не через редактирование БП.

Культура

Вы не заставили бизнес меняться ради CRM. Вы оцифровали то, как люди привыкли работать.

Вам нужен не такой же, а ваш собственный процесс?

Я показал конкретную реализацию под конкретное бизнес-правило («ничья = победа»). Но в вашей компании может быть иначе: право вето у двух людей, кворум 2/3, обязательное приложение расчётов и т.д.

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

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