Как сделать автоматизацию бизнеса прозрачной и понятной

Автоматизация в бизнесе часто начинается не с вопроса «какую систему выбрать», а с более приземлённого: где компания теряет время, деньги, данные или контроль. Мы в Компании РМС к этому пришли через несколько этапов: от сервисных заявок в блокноте до собственной CRM, от ручной сборки заказов до WMS и терминалов сбора данных на складе и от переписки в мессенджерах до структурированных задач в Битрикс.

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

Как понять, что процесс пора автоматизировать

В Компании РМС путь к автоматизации начинался примерно так же. Ещё в 2015 году, когда привычных мессенджеров почти не было, многие общались в Аське, а про системную автоматизацию бизнеса почти никто не говорил, РМС начала переводить рабочие процессы в цифровой формат и подключила Битрикс. Одним из инициаторов был сооснователь Компании РМС Владимир Сурков. Он продвигал идею, которая сначала казалась непривычной: задачи и договорённости нужно фиксировать не «где‑то в переписке», а в CRM системе.

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

Битрикс: задачи, коммуникации, внутренние сервисы и ограничения

Битрикс в РМС начинался с базовых сценариев: задачи, клиенты, сделки, переписка между сотрудниками. Со временем стало понятно, что инструмент можно использовать шире — для коммуникаций, календаря, заявок, HR‑процессов, внутренних сервисов и работы с партнёрами.

Правила работы: задачи, встречи, проекты, лента. Внедрить цифровой инструмент недостаточно. Если сотрудники используют его по‑разному, порядок не появляется. В РМС начали формировать правила работы в Битрикс. Не абстрактные регламенты, а практические договорённости, которые появлялись из реальных проблем.

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

То же самое произошло с задачами. В РМС начали прописывать, как ставить задачу, кого добавлять исполнителем, когда использовать соисполнителей, как работать с чек‑листами и как фиксировать результат. Эти правила собраны в корпоративном Welcome book для новых сотрудников, но к нему возвращаются и опытные коллеги — чтобы свериться с договорённостями.

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

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

В РМС новый подход закрепляли постепенно. Руководители и инициаторы сами работали через систему. Для сотрудников описывали не только «что теперь нужно делать», но и как именно: как поставить задачу, какие поля заполнить, где смотреть результат, как закрыть обращение.

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

Так инструмент перестал восприниматься только как контроль. Он стал способом не терять договорённости и не собирать информацию вручную.

Какие сценарии могут быть полезны для бизнеса? В РМС используют несколько сценариев внутри Битрикс.

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

Свободные слоты. Раньше назначение встречи могло превращаться в длинную переписку: «Когда удобно?», «А в это время можете?», «Тогда давайте завтра». Сейчас сотрудник может отправить ссылку на свободные слоты, а коллега или партнёр сам выбирает подходящее время. Событие появляется в календаре.

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

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

Воронки. Изначально воронки воспринимались как инструмент продаж, но в РМС их используют шире. Например, для задач юристу, работы с новинками, подбора и адаптации сотрудников. В HR воронки связаны с HH и мессенджерами: при изменении стадии может меняться статус резюме и уходить сообщение кандидату.

От первых приложений к «Единому окну»

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

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

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

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

Так появилась идея собрать всё в один ресурс — «Единое окно».

Смысл «Единого окна» в том, чтобы сотрудник не искал нужный сервис по разным разделам. Он открывает приложение, выбирает нужный модуль, заполняет форму и отправляет заявку. Дальше система создаёт задачу, назначает ответственных, передаёт данные и сохраняет историю.

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

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

Кейс: как мы сэкономили 200 тысяч

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

Стандартный функционал онлайн‑записи в CRM‑системе не подошёл: он больше рассчитан на сценарий, где на один слот записывается один человек. А РМС нужно было записывать много сотрудников на одно мероприятие.

Сначала попробовали формы. Они работали, но были неудобны: сотрудники вручную вводили фамилию, имя, отчество и отдел. Кто‑то ошибался в имени, кто‑то неправильно писал отдел. Данные приходилось чистить и перепроверять.

Затем РМС обратилась к интеграторам. Те предложили решение примерно за 200 тысяч рублей. Оно строилось на связке воронок, списков, задач и бизнес‑процессов. Конструкция получалась сложной и потенциально трудной в поддержке.

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

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

Минусы Битрикс и когда он может не подойти

У любого инструмента есть ограничения, и их нужно учитывать до внедрения.

РМС использует облачную версию Битрикс. Это снижает нагрузку на собственную инфраструктуру, но создаёт зависимость от серверов поставщика. Если у сервиса сбой, у компании тоже возникают проблемы. В облаке есть ограничения по тарифу: до 250 сотрудников и 3 терабайт хранилища. Коробочная версия даёт больше контроля над данными и кастомизацией, но требует собственной инфраструктуры и компетенций.

Ещё один риск — изменения в API. У РМС многое завязано на интеграции и собственные приложения. Если сервис меняет методы API без предварительного уведомления, часть логики может перестать работать. Тогда команда сначала сталкивается с проблемой, а уже потом вместе с поддержкой CRM‑системы разбирается, что изменилось.

Есть ограничения мобильной версии. Для РМС это чувствительно, потому что есть полевые сотрудники. Например, из календаря нельзя напрямую перейти в комментарии к событию — нужно идти через ленту и искать нужную запись. А ссылки на Zoom часто отправляют именно в комментарии.

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

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

Собственная CRM: как РМС автоматизировала сервисные заявки и внутренние процессы

Сервисные заявки в РМС сначала вели в обычном блокноте. Так работали с 2019 по 2022 год. Когда звонил клиент, сотрудник записывал основную информацию от руки, потом вручную переносил данные в 1С. Если каких‑то сведений не хватало, их дозапрашивали через мессенджеры. Заявку в 1С нельзя было провести, пока не заполнены все обязательные поля, поэтому процесс растягивался: сначала нужно было принять обращение, потом собрать недостающие данные, затем вручную оформить заявку в учётной системе.

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

В декабре 2022 года Компания РМС протестировала собственную CRM, а с января 2023 года полностью перешла в неё.

Почему выбрали собственную CRM. РМС не покупала готовую CRM для сервисных заявок. Систему писали под свои процессы и продолжают дорабатывать.

Причина простая: сервисная заявка в компании — это не просто запись обращения. В ней есть несколько сценариев: консультация, ремонт мастером, подбор изделия, доставка запчастей, замена товара, инструкция, обращение интернет‑магазина. Для части заявок нужна связь с мастером, для части — передача данных в 1С, для части — контроль сроков и повторные напоминания.

Готовый инструмент пришлось бы либо долго адаптировать, либо подстраивать процесс под логику продукта. В РМС выбрали другой путь: сначала описали, как заявка проходит внутри компании, а потом сделали систему под этот маршрут.

Как работает заявка в CRM. Когда заявка создаётся, ей автоматически присваивается статус: «Обращение принято, запрошена первичная информация». На получение этой информации отводится 3 часа.

Если за это время статус не изменился, сотруднику в Битрикс приходит уведомление: нужно связаться с клиентом. Напоминания повторяются каждые 3 часа, пока заявка не будет дополнена.

После получения информации ставится следующий статус: «Заявка создана на доставку или мастера». С этого момента на выполнение даются сутки. Если заявка не закрыта, система напоминает проверить статус.

Если клиент перестаёт выходить на связь, заявка не исчезает из поля зрения. Она «засыпает» и напоминает о себе через 3 дня. Если клиент попросил перезвонить в конкретное время, сотрудник ставит соответствующий статус, указывает дату, и система сама напомнит в нужный момент.

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

Связка с мастерами и 1С. В заявке можно назначить мастера из базы. У нас более 500 мастеров‑партнеров по всей стране. В карточке мастера видна вся история его заявок, и из неё можно перейти в каждую конкретную заявку.

CRM также связана с 1С. Когда заявка закрывается, сотрудник нажимает кнопку «Передать в 1С», и заявка автоматически формируется в учётной системе. Раньше сотрудники заполняли её вручную.

Интеграция с 1С нужна по двум причинам.

Первая — логистика. Если заявка предполагает доставку запчастей или нового изделия, логист обрабатывает её в 1С. Туда же уходит погрузочный лист.

Вторая — учёт запчастей. У каждого мастера есть запчасти на ответственном хранении. В учётной системе мастера фактически работают как виртуальные склады, и списание использованных деталей проходит через 1С.

Какие ещё процессы ведутся через CRM. Собственная CRM в РМС используется не только для сервисных заявок.

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

Командировки тоже отображаются в Битрикс. Уведомление в общий чат не уходит, но при добавлении сотрудника в событие коллеги видят, что человек не в офисе.

Ещё один пример — банк идей. Форма подачи, статусы рассмотрения и выплаты ведутся в CRM. Сотрудник получает уведомления в Telegram‑бот: заявка принята, взята в работу, отклонена, назначена выплата. Если идея принимается комиссией, в Битрикс автоматически создаётся задача на исполнителя с перенесёнными данными из заявки.

В случае РМС автоматизация была нужна не для того, чтобы «завести CRM», а чтобы убрать конкретные проблемы: блокнот, ручной перенос в 1С, забытые дозвоны, заявки без статуса, отсутствие статистики и зависимость от памяти сотрудника.

Автоматизация склада: ТСД и собственная WMS

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

Поэтому на складе РМС автоматизация пошла через терминалы сбора данных и собственную WMS.

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

Сборка заказов через ТСД

Один из ключевых кейсов — сборка заказов через терминал сбора данных.

Раньше заявка на 10 позиций весом около 50 кг обрабатывалась примерно 20 минут. После внедрения ТСД время сократилось до 5–7 минут.

Это дало РМС возможность справляться с ростом продаж без пропорционального увеличения штата. Людей не увольняли — их перераспределили по сменам.

ТСД также снижает риск пересорта и недостачи. Логика процесса такая: сотрудник должен сканировать каждую единицу товара. Если нужно отобрать 10 леек, он берёт одну, сканирует, кладёт в тару — и так 10 раз.

Ошибки появляются, когда человек нарушает технологию: например, сканирует одну лейку 10 раз подряд, а потом кладёт товар «на глаз», или вводит количество вручную. Поэтому сама система не отменяет дисциплину процесса. Она помогает контролировать его соблюдение.

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

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

Приёмка товара через ТСД

Второй важный кейс — приёмка товара.

Раньше специалист по приёмке держал в руках лист А4, глазами искал нужную номенклатуру и сверял её с тем, что выгружают. Теперь он сканирует штрихкод или QR‑код, а терминал показывает, что это за товар.

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

Изменилась и адаптация новичков. Раньше обучение занимало много времени: нюансов было много, и каждый нужно было объяснять отдельно. Сейчас новый специалист за 2–3 рабочих дня понимает, что от него требуется, и выходит на полноценную работу.

Почему WMS писали с нуля. РМС рассматривала готовые WMS. Коробочные решения закрывали часть задач, но вход в такие проекты начинался от 10+ миллионов рублей. При этом систему всё равно пришлось бы дописывать под процессы компании. В некоторых местах пришлось бы перестраивать процессы под чужое решение.

В итоге РМС решила писать WMS с нуля под себя. Это дольше и сложнее, но компания получает логику, которая соответствует складу.

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

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

Чек‑лист перед автоматизацией бизнес‑процесса

Процесс повторяется регулярно?

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

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

В процессе есть ручной перенос данных?

Ручной перенос — один из главных сигналов для автоматизации. Он отнимает время и создаёт риск ошибки.

Пример РМС: сервисные заявки раньше вручную переносили в 1С, упаковочные листы проходили через менеджера, оператора, кладовщика и сборщика. После автоматизации часть этих действий ушла в CRM, 1С, WMS и ТСД.

Есть ошибки, потери, просрочки или зависимость от одного сотрудника?

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

Пример РМС: CRM напоминает о заявках, ТСД фиксирует операции на складе, Битрикс показывает задачи, ответственных и статусы.

Можно описать вход, выход, статусы и ответственных?

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

Пример РМС: в сервисной CRM есть статусы заявки, сроки реакции, ответственный сотрудник, мастер, тип обращения и передача в 1С.

Понятно, как измерить результат после внедрения?

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

Пример РМС: на складе сравнили время обработки заявки до и после ТСД — было около 20 минут, стало 5–7 минут.

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

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

Пример РМС: правила работы с задачами, встречами, проектами и лентой описаны в Welcome book, а внутренние приложения получают администраторов модулей.

Известны ограничения выбранного инструмента?

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

Пример РМС: в Битрикс есть ограничения облачной версии, мобильного приложения, почтового клиента и зависимость от изменений API. Поэтому для склада компания использует WMS и ТСД, а для сервисных заявок — собственную CRM.