Автоматизация адаптации в Make в России — это не про моду на no-code, а про выживание HR-ов под 152-ФЗ и соседствующих регуляторов. Когда автоматизация адаптации становится частью нормальной рутины, а не разовой спецоперации, новые сотрудники входят в компанию быстрее, ошибки с персональными данными снижаются, а DPO перестает жить в Excel. В этом тексте я разберу, как собрать рабочий шаблон make адаптации под российскую реальность 2025-2026 годов, чтобы и Роскомнадзор был доволен, и HR не ночевал в офисе. Писать буду как обычно — простыми словами, с легкой иронией и привязкой к реальным процессам, а не к мифическому «идеальному» бизнесу.
Чтобы было не теоретично, давай познакомлю тебя с Ильей, HR-директором небольшой московской продуктовой компании на 120 человек. Илья пришел ко мне после очередной проверки, когда им намекнули, что журналы, согласия, уведомления и локализация ПД — это не «когда-нибудь потом», а прямо сейчас, и желательно задним числом. У них onboarding нового сотрудника растягивался на 5-7 рабочих дней: отдел кадров не успевал оформить договор, IT медлил с доступами, руководитель терял письмо с задачами на испытательный срок, а часть документов по ПД подшивалась уже «по факту». Мы с ним сели, налили кофе (который, конечно, успел остыть) и решили собрать в Make прозрачную и законопослушную воронку адаптации, где каждый шаг фиксируется, обрабатывается и не забывается.
Дальше я покажу, как мы разложили этот процесс на модули, где Make действительно помогает, а где по-прежнему нужен человек с мозгами и правами доступа. Без иллюзий про «одна кнопка — и всё само», но с очень конкретным шаблоном, который можно адаптировать под свою компанию, не нарушая 152-ФЗ и здравый смысл.
Когда HR в России говорит «адаптация новых сотрудников», я практически всегда слышу за этим тихий вздох. Бумаги, согласия, журналы, корпоративная почта, VPN, доступы в 1С или в облачную CRM, обучение по безопасности, чек-лист руководителя, контроль испытательного срока — и всё это должно при этом дружить с требованиями по персональным данным. Я, как человек с корнями во внутреннем аудите и ИТ-рисках, довольно быстро вижу, где этот хрупкий баланс рвется: Excel-таблички живут своей жизнью, согласия подписываются «потом», уведомление в Роскомнадзор забыли отправить, а в политике обработки вообще не описан процесс адаптации сотрудников. В 2025-2026 годах росконадзорный фон стал еще плотнее: авто-скан сайтов, история с «Антифрод-2», ревизия оснований обработки, отдельный интерес к кадровым ПД и биометрии. Под это добро старые HR-подходы «заведем табличку и будем внимательнее» просто не работают.
Я заметила, что главная точка боли — это несшитость процессов. HR живет в своих формах и мессенджерах, IT — в тикет-системе, юристы — в папках с шаблонами и внутренних регламентах, DPO — в своих реестрах и внутреннем учете. Новенький сотрудник в это время ждет доступы, а компания, по сути, ведет сразу четыре параллельных процесса обработки ПД: сбор, хранение, доступ и уничтожение. Когда всё это делается вручную, шанс на ошибку растет не линейно, а экспоненциально, особенно если у вас каждый месяц по 5-10 новых людей. И да, штрафы за ошибки с ПД сотрудников сейчас не те, что были в 2016-м, когда можно было отделаться предупреждением и «обещанием исправиться».
Вот как это выглядит на практике: к вам приходит новый маркетолог, вы собираете у него паспортные данные, ИНН, СНИЛС, сведения об образовании, семейное положение для налоговых вычетов, контактные данные, иногда сведения о здоровье для медосмотров. Все это — персональные данные, часть из них чувствительная. Формально вы должны быть зарегистрированы как оператор ПД, иметь внятную политику обработки, реестр процессов, модель угроз, набор организационно-распорядительных документов, журналы учета носителей, акты передачи, сроки хранения. Если вы всё это делаете руками, адаптация превращается в марафон, а любая интеграция с внешними сервисами несет риск утечки.
Поэтому автоматизация адаптации сотрудников через Make — это не про «ой, мы такие цифровые», а про снижение операционного и регуляторного риска. Здесь работает следующее: вы берете бизнес-процесс, режете его на шаги, определяете, какие системы участвуют (почта, корпоративный портал, кадровая система, тикеты, DLP, хранилище документов), и строите между ними связки через Make так, чтобы данные двигались по понятным правилам, фиксировались в журналах и не улетали за пределы РФ. Это критично, потому что в 152-ФЗ и подзаконных актах всё больше внимания к маршрутам данных и к тому, кто и на каком основании к ним прикасается.
Чтобы не бросаться сразу в схемы, я хочу зафиксировать одну мысль: автоматизация не спасет хаотичный процесс, она просто сделает хаос быстрым. Поэтому перед тем как открывать Make и собирать первый сценарий, стоит ответить на спокойный вопрос: «Где у нас начинается адаптация, какие шаги проходят все новички, кто за них отвечает и где хранятся данные на каждом из этапов?». Без этого любая настройка превратится в набор разрозненных автоматизаций «под задачу», а не в целостный шаблон make адаптации, который выдерживает проверку регулятора.
Как устроить автоматизацию адаптации в Make так, чтобы не поседеть от 152-ФЗ
Если разложить автоматизацию адаптации в Make на крупные блоки, получится довольно приземленная картина: триггер входа нового человека, сбор минимально необходимых данных, юридическое оформление (договор, локальные акты, уведомления), заведение в учетные системы, обучение и контроль, а затем — фиксация всего этого добра в реестрах обработки ПД. Вся сложность в том, что Make сам по себе — просто оркестратор: он тянет данные из одной системы, передает в другую, добавляет немного логики, но не думает за вас, какие поля собирать, что шифровать, а где лучше свериться с DPO. Поэтому начинать нужно не с кнопки «Create a new scenario», а с карты процесса и перечня систем, которые вообще можно использовать с точки зрения локализации данных.
На практике я делю воронку адаптации на пять опор: точка входа (откуда приходит новичок), юридическая база (на каком основании мы обрабатываем его ПД), операционная часть (создание учеток, доступов, задач), обучающая (инструктажи, политики, тесты) и реестровая (что и где у нас зафиксировано для Роскомнадзора и внутреннего контроля). Под каждую из этих опор в Make можно собрать отдельный модуль, связанный общим ID сотрудника. Это означает, что вы не делаете один гигантский сценарий на 40 модулей, а строите связку из нескольких сценариев: входящий запрос, кадровый контур, IT-контур, обучение, отчетность по ПД.
Я заметила, что Make хорошо ложится на связку «форма — таблица — задача — уведомление». Например, первый сценарий: приходит заполненная форма кандидата или уже принятого сотрудника (через корпоративный портал, Google Forms, QForm или встроенную форму на сайте), Make забирает эти данные через webhook, проверяет обязательные поля, присваивает уникальный ID, кладет в таблицу (например, в российский аналог Google Sheets или в Битрикс24), создает черновик трудового договора на основе шаблона и уведомляет HR и руководителя в Telegram. Звучит банально, но уже на этом этапе сокращается риск, что кто-то потеряет письмо с анкеты, а персональные данные будут пересылаться в открытом виде по почте.
Вот здесь полезно зафиксировать в виде короткого текста, какие шаги вообще нужно покрыть автоматизацией, прежде чем лезть в технику:
- Вход нового сотрудника: от резюме до подтвержденного оффера, сбор базовых ПД.
- Юридическое оформление: договор, уведомления, включение в реестр процессов обработки.
- Техническая адаптация: учетные записи, доступы, корпоративные сервисы.
- Обучение и безопасность: инструктаж по ПД, ИБ, подписка на локальные акты.
- Контроль и отчетность: журналы, акты, выгрузки для DPO и Роскомнадзора.
Каждый из этих шагов может быть отдельным сценарием в Make, который общается с соседними через общие поля (ID сотрудника, статус адаптации, дата выхода). Звучит странно, но именно такая кусочная архитектура дает устойчивость: если один модуль «упадет», не встанет весь процесс, а HR спокойно дотянет руками конкретный шаг. Это особенно ценно, когда DPO просит выгрузить реестр по всем сотрудникам за последние два года, а вы вместо эпопеи «собери по людям из пяти разных папок» нажимаете один запуск сценария отчетности.
В российском правовом поле здесь есть пару тонкостей. Во-первых, кадровые ПД сотрудников почти всегда можно и нужно обрабатывать на основании трудового договора, а не согласия (которое позже человек может отозвать через Госуслуги). Во-вторых, хранить эти данные нужно в ИС, локализованных в РФ; значит, любые интеграции Make с зарубежными сервисами нужно фильтровать или ограничивать (нет, подожди, лучше даже не тянуть чувствительные данные в такие системы вовсе). Я в таких случаях выношу в Make только сервисные идентификаторы и технические статусы, а сами ПД хранятся в защищенной HR-системе или локальной базе.
Когда мы с Ильей делали общий набросок их адаптации, мы прямо на доске отметили, где какие поля возникают, какие из них чувствительные, где нужен журнал учета, где — приказ, где достаточно записи в реестре обработки. Потом рядом положили требования 152-ФЗ, подзаконных актов и регуляторных писем, и оказалось, что большая часть «ужаса» укладывается в аккуратную логику: зачем нам это поле, кто его видит, где оно хранится, как автоматически ограничить доступ и не забыть уничтожить данные по истечении срока. Получается, автоматизация в Make — это просто усилитель этой логики, а не замена ей.
Как подобрать архитектуру Make-сценариев под адаптацию сотрудников в России
Я часто вижу ошибку, когда компании пытаются собрать один «супер-сценарий» в Make, который делает всё: от регистрации новичка до акта уничтожения его личного дела через пять лет. В теории это красиво, на практике — хрупко и плохо управляемо. Гораздо устойчивее работает подход модульности: несколько небольших сценариев, каждый отвечает за свой кусок адаптации, общаются они через общие сущности, а данные по ПД минимизируются на каждом переходе. В российских реалиях это еще и снижает риски: не обязательно везде тащить ФИО, СНИЛС и паспорт, достаточно внутреннего ID и ссылки на защищенную систему, где эти поля уже лежат.
Я поняла, что для make адаптации удобно выделить три слоя. Первый — фронтовый: формы, порталы, письма, где сотрудник или HR взаимодействуют с интерфейсом (заполняют анкету, подтверждают оффер, читают инструктаж). Второй — оркестрационный: собственно, сценарии в Make, которые принимают вебхуки, пишут в базы, заводят задачи, вызывают API российских сервисов. Третий — хранилищный: HRM-системы, 1С, Битрикс24, QForm, PrivacyLine, 152DOC и прочие, где ведутся журналы, реестры, приказы, дела.
Чтобы показать суть, проще один раз сформулировать как небольшую конструкцию, которую можно держать в голове:
Хорошая автоматизация адаптации — это когда Make не хранит ПД, а только двигает их между системами, строго по маршрутам, согласованным с DPO и описанным в реестре обработки.
Здесь действительно работает принцип минимизации: если для создания задач руководителю достаточно внутреннего номера сотрудника и его роли, то не стоит тащить туда паспортные данные и просто надеяться, что никто не заметит. То же самое касается уведомлений в мессенджеры: я почти никогда не отправляю в Telegram персональные данные, кроме, может быть, имени и должности; все чувствительное живет в защищенных каналах.
Технически в Make это выглядит так: вы создаете несколько сценариев — «Новый сотрудник», «Юридическое оформление», «Доступы и сервисы», «Инструктаж и обучение», «Отчетность и журналы». Каждый сценарий имеет свой триггер (вебхук, изменение статуса в таблице, новый элемент в Битрикс24) и заканчивается либо обновлением общей карточки сотрудника, либо запуском следующего сценария. Да, звучит чуть более сложно, чем «один большой процесс», но отлаживать и проверять такие куски на соответствие 152-ФЗ и внутренним политикам намного проще.
Небольшой нюанс: Make, как платформа иностранного происхождения, поднимает вопрос локализации данных. Я обычно выстраиваю архитектуру так, чтобы Make видел только технические идентификаторы и служебные поля, а любые наборы ПД хранились в российских системах. В сценариях остаются ссылки: ID сотрудника, код процесса, путь к делу, номер приказа. Это тот случай, когда чуть больше абстракции спасает от очень реальных рисков. Илья, кстати, сначала хотел тащить всю анкету сотрудника прямо через Make, но, посмотрев на свежие регуляторные кейсы, довольно быстро согласился с моделью «Make — мозг, российские ИС — память».
Что нужно учесть по 152-ФЗ, когда автоматизируешь адаптацию через Make
Юридическая часть адаптации часто кажется HR «чем-то отдельным», что делает юрист или DPO, а автоматизация будто бы про другое. На деле если вы строите make адаптацию и при этом игнорируете 152-ФЗ, получится аккуратная цифровая машинка, которая просто ускоряет нарушение закона. В России кадровые ПД — одна из самых чувствительных тем: здесь и трудовое законодательство, и 152-ФЗ, и модель угроз, и ФСТЭК, и иногда ФСБ, если вы задеваете гостайну или критическую инфраструктуру. Поэтому процессы адаптации почти всегда попадают в фокус проверок, потому что именно там ПД собираются, размножаются и начинают жить своей жизнью.
В 2025-2026 годах регуляторный ландшафт поменялся: согласия больше не волшебная палочка, особенно для сотрудников, гораздо больше внимания к законным основаниям (договор, закон, уставные цели), ревизии оснований через «Антифрод-2», к биометрии и чувствительным данным подключаются силовые блоки, Роскомнадзор запускает авто-скан сайтов и политик, а количество зарегистрированных операторов переваливает за пару миллионов. На практике это означает, что вам нужно четко понимать, какие именно ПД вы обрабатываете в процессе адаптации, на каком основании, где они хранятся и кто к ним имеет доступ. И да, это надо не только DPO, это приходится учитывать еще на уровне архитектуры Make-сценариев.
Я заметила, что есть четыре опорных юридических вопроса, которые нужно закрыть до того, как нажать «Run once» в Make. Первый: вы точно зарегистрированы как оператор ПД, и в уведомлении описан хотя бы общий контур кадровых процессов. Второй: все ваши формы, анкеты и порталы корректно ссылаются на политику обработки, где адаптация описана как отдельный процесс, а не «обработка всего на свете». Третий: у вас есть реестр процессов обработки ПД, где адаптация выделена и прозрачно описана (цели, категории, основания, сроки, ИС). Четвертый: вы провели хотя бы базовую модель угроз для информационных систем, в которых хранятся кадровые ПД.
Чтобы не расползаться, я хочу подвесить здесь одну простую формулировку, которая помогает не потеряться между Make и 152-ФЗ:
Каждый шаг адаптации, который вы автоматизируете, должен быть отражен и в процессной карте, и в реестре ПД, и в локальных актах.
Если чего-то из этого нет, автоматизировать рано — вы просто поставите красивый интерфейс поверх неоформленной обработки, и это рано или поздно всплывет. Когда мы с Ильей смотрели их текущие документы, оказалось, что про адаптацию в политике обработки ПД написано аккурат одно предложение, а реестра процессов нет вовсе, есть только «список систем». На словах все понимали, что кадровые данные обрабатываются, но описанного процесса не было, а значит, и автоматизировать было особо нечего, кроме отдельных шагов. Пришлось сначала выстроить бумажную часть, а уже под нее натягивать Make.
Как встроить Make-процесс адаптации в реестр обработки ПД и не запутаться
Представь себе ситуацию: к вам приходит проверка, спрашивают, как обрабатываются персональные данные сотрудников при приеме и адаптации. Если вы достаете реестр, а там написано «обработка ПД работников в HR-системе», а на самом деле данные гуляют между формами, почтой, Make, 1С, Битриксом и парой локальных папок, картина получается не очень. В российской логике комплаенса нужно, чтобы в реестре было видно: вот процесс «Адаптация новых сотрудников», цели — оформление трудовых отношений и ввод в должность, основания — ТК РФ и трудовой договор, категории ПД — кадровые, иногда специальные, перечень ИС — конкретно перечисленные системы, маршруты передачи — кому, что и зачем.
Я поняла, что здесь проще всего идти от пути данных: берем момент, когда кандидат принял оффер и мы начали собирать у него ПД для оформления, и до момента, когда его личное дело уходит в архив (или уничтожается по истечении срока). На этом пути отмечаем все точки: форма сбора, HR-система, файловое хранилище, системы учета зарплаты и налогообложения, Make как оркестратор, почта, мессенджеры. Потом рядом приклеиваем жизненный цикл данных: сбор, запись, использование, передача, хранение, уничтожение. Получается довольно конкретная схема, под которую уже можно и реестр, и локальные акты подтянуть.
Чтобы это не осталось теорией, я часто оформляю для компаний небольшую текстовую вставку вроде:
Обработка ПД в процессе адаптации сотрудников включает сбор данных через электронные формы, их передачу в HR-систему и бухгалтерский контур, создание учетных записей и доступов, документирование инструктажей и обучение, последующее хранение в личном деле с ограниченным доступом.
Под такой формулировкой уже можно аккуратно проложить конкретные технические шаги в Make, не забывая каждую интеграцию описывать как передачу данных третьим лицам, если это внешний сервис, либо как внутреннее взаимодействие между ИС. Здесь всплывает один тонкий момент (я сама в первый раз его недооценила): Make как платформа сам по себе может считаться информационной системой обработки, если вы в нем храните логи с ПД. Поэтому я принципиально настраиваю сценарии так, чтобы логи были обезличены или максимально урезаны, а полные наборы ПД записывались только в российские ИС, которые уже покрыты моделью угроз и мерами защиты.
Вместо беспорядочного перечисления «у нас есть Make, QForm, Битрикс, 1С, еще какая-то база» вы получаете осмысленную конструкцию: есть бизнес-процесс адаптации, есть реестр обработки ПД, есть список ИС и сторонних операторов, а Make — это просто узел маршрутизации, который, по-хорошему, вообще не должен знать, что именно он двигает, кроме технических полей. Роскомнадзору такая честная и прозрачная картина нравится куда больше, чем выдуманные формулировки про «обработку ПД работников в целях исполнения договора без уточнения каналов передачи».
Чего точно не стоит делать при автоматизации адаптации под 152-ФЗ
Когда компании впервые пытаются автоматизировать адаптацию сотрудников, я часто вижу один и тот же набор ошибок: собирают слишком много данных на ранних этапах, тащат ПД во все интеграции подряд, смешивают кадровые и маркетинговые процессы, используют согласия «на всякий случай» и полагаются на облачные сервисы за пределами РФ. Это выглядит как «мы просто хотели удобства», но на языке 152-ФЗ звучит как «мы без ограничений распространяем персональные данные сотрудников по неопределенному кругу лиц». Утрирую, но не сильно.
На практике я выделяю несколько практик, от которых лучше отказаться сразу (хотя сама я так делала ровно один раз в самом начале, когда только входила в тему ИТ-рисков). Во-первых, не нужно запрашивать у кандидата полный пакет документов до момента подтвержденного оффера: до этого этапа достаточно минимальных контактных данных и резюме. Во-вторых, не стоит отправлять файлы с паспортами и сканами трудовых книжек через обычную почту или мессенджеры, даже если «так быстрее». В-третьих, любой внешний сервис, с которым вы интегрируете Make, должен быть либо локализован, либо использоваться строго без передачи ПД.
Чтобы зафиксировать это в одном месте, я обычно формулирую ограничения в таком виде:
В сценариях Make, связанных с адаптацией, нельзя обрабатывать полные наборы ПД сотрудников, если эти сценарии интегрируются с зарубежными сервисами или не покрыты моделью угроз и ОРД.
Еще одна частая ловушка — путаница между согласием и договором как основанием. Для сотрудников в РФ куда надежнее опираться на трудовой договор и ТК РФ, чем на согласие, которое человек легко отзовет через Госуслуги. Здесь Make помогает, если собрать цепочку так, чтобы после подписания договора сценарий переключался с «кандидат» на «сотрудник», и весь последующий поток обработки был завязан именно на договор, а не на формальные галочки в формах согласий.
Помнишь историю с остывшим кофе в начале? У Ильи как раз была ситуация, когда кандидат отзывал согласие через пару недель после начала работы, и они впадали в легкую панику: «А что теперь с его ПД, договорами, выплатами?». После ревизии процессов и перенастройки Make мы оставили согласие только там, где оно действительно необходимо (например, для использования фото в корпоративных материалах), а всю кадровую логику перевели на договор и законные основания. Жизнь сразу стала спокойнее, а автоматизация — предсказуемее.
Как по шагам собрать рабочий шаблон make адаптации для новых сотрудников
Когда базовая логика и юридические рамки понятны, начинается самая приятная часть — превращение всего этого в живой сценарий в Make. Я люблю здесь идти с конца: представляем идеальную картину мира, где новый сотрудник выходит в понедельник, через 15-30 минут после старта рабочего дня у него уже есть корпоративная почта, доступ в чаты, первые задачи в таск-трекере, письмо с программой адаптации и инструктажом по ПД, а HR видит в одной системе, что все шаги пройдены. Потом смотрим, какие именно события и триггеры должны для этого сработать, и раскручиваем цепочку назад до самого начала — заполнения анкеты и формирования оффера.
Я тестировала разные наборы инструментов, но в российской реальности чаще всего выигрывает связка: форма (QForm или кастомная форма на сайте) — Make — Битрикс24 / 1С / внутренняя HRM — Telegram/почта для уведомлений. Параллельно крутится реестр обработки ПД в PrivacyLine или аналогичном решении, куда часть данных попадает автоматически через Make. Здесь работает следующая логика: Make не заменяет ваши кадровые и юридические системы, он связывает их и помогает не забыть ни один шаг адаптации.
Чтобы не распыляться, я разложу шаблон make адаптации на шесть последовательных шагов. Я не буду показывать скриншоты модулей, но опишу, какие блоки в сценарии обычно появляются и как они между собой говорят. Это не догма, а отправная точка, которую можно подстроить под себя, сохранив логику и соответствие 152-ФЗ.
Как настроить точку входа: от заявки HR до уникального ID сотрудника
Кто-то начинает адаптацию с момента подписания трудового договора, но я предпочитаю чуть более раннюю точку — когда HR заносит в систему подтвержденного кандидата как «нового сотрудника с датой выхода». В этот момент у нас уже есть достаточно данных, чтобы не дергать человека десять раз, но еще нет потока паспортов и сканов во все стороны. Триггером для первого сценария в Make может быть запись в таблицу «Новые сотрудники» (в Битрикс24, Airtable-аналоге, базе внутри 1С) или вебхук с формы, куда HR заносит базовые данные: ФИО, должность, отдел, руководитель, дата выхода, контактный e-mail и телефон.
На практике это выглядит так: HR открывает свою форму «Создать нового сотрудника», заполняет несколько полей, нажимает кнопку отправки. Форма через вебхук отправляет данные в Make, там сценарий первым делом проверяет заполненность обязательных полей, генерирует уникальный внутренний ID сотрудника (который мы позже будем использовать вместо ФИО во внутренних связках), записывает эту запись в таблицу и создает в HR-системе базовую карточку «Сотрудник в статусе pre-onboarding». Параллельно Make отправляет уведомление руководителю в Telegram или корпоративный мессенджер со сводкой: кто приходит, когда, на какую роль.
Я люблю на этом этапе проговаривать, какие данные мы считаем критичными, а какие можно запросить позже. Например:
На этапе запуска адаптации достаточно знать: ФИО, должность, отдел, дату выхода и контакт для связи — остальное подтягивается уже в процессе оформления и не должно утекать в интеграции раньше времени.
Дальше сценарий может автоматически создавать задачу юристу или кадровику «Подготовить пакет документов по новому сотруднику» в вашей таск-системе, привязывая туда тот самый уникальный ID. Вся дальнейшая магия адаптации крутится вокруг этого ID: IT создает учетку в домене и почте, HR ведет карточку, DPO отслеживает процесс в реестре. Если человек в итоге не выходит на работу, вы по этому ID можете аккуратно остановить все сценарии и инициировать уничтожение данных, не перебирая кучу разных хранилищ вручную.
Возвращаясь к Илье: у них раньше точкой входа была почта с темой «Новый сотрудник», которую HR отправлял в общий адрес. Кто-то отвечал, кто-то нет, темы ветвились, и через месяц найти подтверждение, что адаптация была пройдена, было сложно. После перехода на Make HR тратит те же 2-3 минуты на заполнение формы, зато у нас появляется четкий журнал: когда создан сотрудник, какие шаги прошли, где застряли.
Как автоматизировать юридическую и кадровую часть без нервного тика
Юридический блок — это место, где при автоматизации чаще всего «съезжает» либо буква закона, либо здравый смысл. С одной стороны, хочется, чтобы договор, приказы, личная карточка, согласие (если нужно) и политика ПД подшивались и фиксировались почти автоматически. С другой стороны, подписи, проверки, уникальные условия договора и человеческий контроль никто не отменял. Я обычно строю Make-сценарий так, чтобы он готовил черновики, собирал статусы, напоминал и вел журналы, а критические точки оставались за человеком.
В российской практике выглядит это так: после того как создана базовая карточка сотрудника, сценарий Make берет нужные поля (ФИО, должность, оклад, дату выхода, подразделение), подставляет их в шаблон трудового договора и локальных актов (через интеграцию с документ-сервисом или прямо в 1С), генерирует черновики файлов и складывает их в защищенную папку. Параллельно ставится задача юристу или кадровику проверить и утвердить эти документы. После утверждения запускается следующий блок: отправка документов сотруднику на подпись (через контур ЭДО или офлайн), фиксация статуса «подписано/не подписано», запись в учетную систему.
Я заметила, что удобно разделить этот процесс на две части и проговорить самим себе их границы:
Автоматизация готовит и отслеживает, юрист/HR принимает финальные решения и ставит подпись/визу, особенно там, где речь о трудовом договоре и локальных актах.
После того как договор подписан, сценарий Make меняет статус сотрудника на «Оформлен», фиксирует это в таблице, обновляет реестр обработки ПД (через интеграцию с PrivacyLine или аналогичной системой) и отправляет сигнал в следующий сценарий — про создание доступов и включение в рабочие системы. В этот момент важно, чтобы у нас уже была четкая связь с 152-ФЗ: сотрудник вступает в трудовые отношения, основанием обработки становится договор, согласия на стандартную кадровую обработку не нужны, но если вы используете фото на сайте или даете доступ к дополнительным сервисам, там согласия могут подключаться точечно.
Звучит немного бюрократично, но в Make это превращается в очень конкретный набор шагов: модуль «Watch new employee», модуль генерации документов, модуль записи в реестр, модуль уведомления заинтересованных лиц. Я иногда ловлю себя на мысли, что не столько автоматизирую HR-процесс, сколько учу компанию формулировать его внятно — а без этого 152-ФЗ всё равно не обойти.
Как раздать доступы и запустить обучение, не сломав ИБ
Техническая адаптация — то, что сотрудники чувствуют особенно остро: есть ли почта, добавили ли в чаты, открылись ли нужные папки, работает ли VPN, видно ли задачи. Здесь автоматизация через Make дает самое заметное «вау» внутри команды, но именно здесь же сидит много рисков по ИТ-безопасности, если раздавать доступы слишком щедро и без учета ролей. Я на своей практике стараюсь сочетать RBAC (ролевую модель доступа) с гибкой оркестрацией в Make, чтобы новый сотрудник получал только то, что нужно для его роли, и ничего лишнего.
На практике сценарий выглядит так: после статуса «Сотрудник оформлен» Make запускает цепочку вызовов к вашим системам — доменная учетная запись, почта, корпоративные порталы, задачи в трекере, чаты. Вместо того чтобы админ руками создавал каждую учетку, он один раз задает шаблоны ролей: маркетолог, разработчик, аналитик, менеджер продаж. Для каждой роли заранее определен минимальный набор доступов. Make берет роль сотрудника из карточки и по заранее заданной карте вызывает нужные API, создает аккаунты, фиксирует результаты в таблице.
Я поняла, что чтобы не утонуть в роутинге прав, полезно сначала описать текстом, кому что можно, а потом уже переносить это в Make. И да, здесь пригодится одна четкая формулировка:
При автоматизации выдачи доступов сначала проектируется модель прав, и только потом пишется сценарий в Make — иначе вы просто сделаете быстро то, что раньше и так делали неправильно.
Параллельно с доступами запускается обучающий блок: Make отправляет новому сотруднику письмо или сообщение в мессенджер с программой адаптации, ссылками на тренинги по ПД и ИБ, выдает задания «ознакомиться с политикой обработки ПД», «пройти вводный инструктаж по безопасности», «подтвердить прочтение документов». Результаты прохождения могут фиксироваться автоматически в журнале инструктажей (через интеграцию с QForm или внутренней системой). Если сотрудник не прошел что-то в срок, Make напоминает ему и его руководителю.
Помнишь про кофе из начала? В компании Ильи раньше админ сидел по понедельникам и руками создавал учетные записи каждому новичку, потом ходил по кабинетам, проверял, что всё работает, параллельно успевал отвечать на просьбы «а добавь меня в еще один чат». После настройки Make цепочка запускается сама, а админ только смотрит отчет: у кого что создалось, где были ошибки. У него наконец появилось время выпить свой кофе горячим, а не на пятой попытке.
Как связать Make, российские сервисы и реестры по ПД, чтобы всё жило в одном контуре
Когда базовый сценарий адаптации собран, возникает следующий вопрос: как всё это подружить с нашим зоопарком российских систем, не разорвав логику и не устроив себе новый Excel, только на уровне интеграций. В России редко встретишь компанию, где HR-процессы живут в одном-единственном продукте. Чаще это какая-то комбинация: 1С для кадров и зарплаты, Битрикс24 или другая CRM/портал для задач и общения, специализированные решения типа QForm для форм, PrivacyLine или 152DOC для реестров ПД и ОРД, внутренние базы и файлохранилища. Make в этом наборе — как диспетчер, который должен знать, когда, кому и что переслать, и при этом не превратиться в единую точку отказа.
На практике я вижу, что make адаптация сотрудников в России хорошо работает, когда вы честно выписываете все системы, через которые проходит новый человек в первые 30 дней: где он заполняет данные, где видит задачи, где проходит обучение, где хранятся его документы. Потом рядом с этим выписываете все регуляторные требования: 152-ФЗ, подзаконные акты по ИСПДн, ОРД, внутренние политики, отраслевые регуляторы (если вы, например, в финтехе). И только после этого решаете, какие действия будут происходить в Make, а какие останутся внутри систем на их собственных сценариях.
Я заметила, что есть набор интеграций, которые почти всегда оказываются полезными: связка Make + Битрикс24 для создания карточек сотрудников и задач адаптации, Make + QForm для автоматизированного формирования журналов и актов, Make + PrivacyLine для обновления реестров обработки ПД, Make + Telegram для уведомлений руководителей и сотрудников. Иногда подключается 1С, если она открыта по API или через промежуточный слой. Важно, чтобы каждое такое соединение было описано и в технической документации, и в документах по ПД — кто кому что передает и на каком основании.
Чтобы не потерять фокус, я люблю собирать вот такую простую формулировку, вокруг которой дальше группирую решения:
Make — оркестратор, российские системы — источники истины, реестр ПД и ОРД — карта, по которой они общаются между собой.
Параллельно с этим всегда поднимается тема DLP, VPN, шифрования, контроля доступа к самим сценариям Make (да, туда тоже не надо пускать всех подряд). В российских условиях вы не можете просто «повесить» обработку ПД на облачный инструмент без оглядки на ИБ. Значит, доступ к Make должен быть ограничен, учетные записи — персонализированы, логи — сохранены, а сами сценарии — описаны в документах. Это не убивает гибкость, но заставляет относиться к make адаптации как к части информационной инфраструктуры, а не к игрушке энтузиаста.
Как использовать QForm, PrivacyLine и другие российские решения вместе с Make
Когда HR впервые слышит про QForm или PrivacyLine, часто возникает ощущение «еще одна система, которую нужно кормить данными». Я смотрю на это иначе: это как раз те системы, куда Make может аккуратно докладывать кусочки информации, которые раньше HR тащил туда вручную. Для адаптации сотрудников это особенно удобно: журналы инструктажей, акты о доступе и об ограничении, учет носителей, реестры процессов, ОРД — всё это живет в своих продуктах, а Make просто шлет туда структурированные данные.
Вот как это выглядит вживую: новый сотрудник прошел вводный инструктаж по ПД и ИБ через онлайн-курс или форму QForm, в конце нажал «ознакомлен». QForm отправляет вебхук в Make, сценарий ловит это событие, связывает его по ID сотрудника с основной карточкой и отправляет запись в систему, где ведется журнал инструктажей. Если это PrivacyLine, то там обновляется запись «Сотрудник прошел инструктаж по процессу обработки ПД в целях кадрового учета» с датой и ответственным. Если это другой инструмент, логика похожая — мы не плодим журналы в Excel, а ведем один живой реестр.
Я поняла, что интеграция с такими решениями сильно меняет ощущение от 152-ФЗ: вместо «еще один документ ради галочки» появляется конкретное действие в процессе. Чтобы подчеркнуть это, я часто формулирую для команд небольшой ориентир:
Если журнал или реестр нельзя обновить автоматически на базе событий в Make, задумайтесь, нужен ли он в текущем виде или его нужно перепридумать.
Конечно, не все документы можно полностью автоматизировать, но часть рутинных записей по адаптации вполне. Акты о предоставлении доступа, фиксация дат прохождения инструктажей, связи сотрудника с конкретными процессами обработки — всё это ровно то, что забывается в ручном режиме и довольно легко ложится в автоматизацию. При этом сами ПД (паспорт, адрес, состав семьи) остаются в защищенных кадровых системах, а интеграция оперирует только служебными идентификаторами.
На стороне HR это выглядит как облегчение: вместо того чтобы раз в месяц садиться и вспоминать, кто из новичков прошел какой инструктаж, вы открываете интерфейс реестра и видите все статусы в одном месте. DPO перестает мучить отдел кадров бесконечными запросами «скиньте список тех, кто прошел обучение», а Make тихо делает эту работу в фоне. Иногда это почти уютно 🙂
Как не увлечься интеграциями и не потерять контроль над ПД
Есть одна странная, но повторяющаяся история: как только у команды появляется Make, они начинают интегрировать всё со всем. «А давайте подключим еще вот этот сервис рассылок, а вот здесь пусть подгружаются данные в Google Sheets, а вот здесь в Notion, а что если мы будем слать уведомления сразу во все мессенджеры?» С точки зрения ИБ и 152-ФЗ это выглядит как кошмар оператора ПД, где данные размазываются по десятку внешних сервисов без четкого понимания, кто за это ответит. Звучит жестко, но иногда приходится говорить: забудь, что я только что сказала — сначала режем интеграции, потом строим новые.
Я заметила, что здоровая архитектура адаптации в Make строится на ограничении, а не на бесконечном подключении всего подряд. Есть базовый набор систем, через которые должен пройти новый сотрудник, и есть набор «nice to have» инструментов, которые можно добавить позже, когда основной контур стабилен. Любая новая интеграция с внешним сервисом должна проходить через фильтр: нужны ли там ПД, локализован ли сервис, есть ли договор и модель угроз, что будет, если этот сервис завтра исчезнет или «ляжет» на неделю.
Чтобы это не звучало просто как «бояться всего», я люблю фиксировать для команд понятное ограничение:
Для процессов адаптации в Make разрешены только те интеграции, которые либо не трогают ПД вообще, либо работают с ними в зашифрованном и юридически оформленном контуре.
В компании Ильи в начале пути было около десяти разных форм и трекеров, куда «на всякий случай» дублировались данные о сотрудниках. Мы честно посчитали, где реально нужны ФИО и контакты, а где достаточно ID и ссылки на карточку в HR-системе, выкинули лишние интеграции и сильно упростили сценарии Make. Автоматизации стало не меньше, но она перестала разбрасывать ПД по цифровому пространству без контроля.
Какие метрики и ошибки показывают, что автоматизация адаптации действительно работает
На каком-то этапе любой проект по автоматизации упирается в простой вопрос: а что мы в итоге выиграли, кроме красивой схемы? С адаптацией сотрудников это особенно отчетливо: HR хочет видеть экономию времени, руководители — скорость выхода новичка «в строй», DPO — снижение регуляторных рисков, IT — стабильность и предсказуемость нагрузки. Если вы не договоритесь заранее о метриках, то через пару месяцев кто-то обязательно скажет «да мы и руками сделали бы не хуже». А через год никто уже не вспомнит, сколько нервов экономит Make каждый понедельник, пока новые сотрудники плавно встраиваются в процессы.
Я заметила, что для make адаптации хорошо работают четыре основных показателя. Первый — среднее время от «подтвержден оффер» до «сотрудник полностью готов к работе» (включая доступы, обучение, документы). Второй — количество ручных действий HR и IT на одного нового сотрудника (сколько писем, сколько ручных задач, сколько ручных записей в журналах). Третий — количество сбоев адаптации: забытые доступы, непроведенные инструктажи, неоформленные документы к дате выхода. Четвертый — регуляторные показатели: количество замечаний от DPO и проверяющих органов по кадровым ПД.
Когда мы с Ильей запускали их шаблон make адаптации, я попросила зафиксировать значения «до» и «после». До автоматизации HR тратил на одного новичка в среднем 3-4 часа чистого времени, разбросанных на неделю, IT — около часа, плюс периодические «хвосты». Документы успевали оформить в срок в 80% случаев, инструктажи по ПД проходили вовремя в половине кейсов. Через три месяца после стабильной работы сценариев в Make среднее суммарное время HR на адаптацию упало до 40-50 минут, IT — до 15 минут, а процент полноты и своевременности действий вырос до 95%.
Чтобы не утонуть в цифрах, я иногда записываю для себя и команды один короткий ориентир:
Если после автоматизации вы не можете показать, что время и ошибки по ключевым шагам адаптации сократились в 2-3 раза, значит, вы либо меряете не то, либо автоматизировали не тот участок.
При этом важно честно смотреть не только на успехи, но и на ошибки. Где сценарий падает? Где люди всё равно делают руками и почему? Где автоматизация создает лишнюю нагрузку («еще одна форма, еще один чек-лист»)? Здесь всплывают интересные вещи: иногда HR продолжает дублировать данные в свои привычные таблицы «на всякий случай», потому что не доверяет системе. Иногда руководители игнорируют уведомления в мессенджере, потому что там слишком много шумных автоматических сообщений. Эти вещи не решаются «еще одной интеграцией», здесь нужно менять поведение и договариваться о правилах.
Как использовать данные из Make для аудита процессов и 152-ФЗ
Один из приятных побочных эффектов автоматизации адаптации через Make — это появление очень честных логов. Каждый запуск сценария, каждый шаг, ошибки, сроки выполнения — всё это записывается и может быть выгружено. Для человека с прошлым во внутреннем аудите это просто подарок: вы наконец перестаете спорить «кто когда что делал», а смотрите на факты. Для DPO это тоже полезно: можно наглядно показать, что процесс обработки ПД по адаптации не только описан в документах, но и реально работает по понятным шагам.
Я тестировала разные форматы отчетности, но лучше всего заходит простая ежемесячная сводка: сколько сотрудников прошли адаптацию, сколько времени это заняло, где были задержки, сколько было ручных вмешательств. Эти данные можно строить прямо из сценариев Make, если предусмотреть запись в отдельную таблицу «лог адаптации», или через встроенную аналитику, если вы ее подключите. Дальше эту сводку можно подложить к внутреннему отчету по ПД, и у вас появляется живое подтверждение, что меры по упорядочиванию обработки не только написаны на бумаге, но и технически реализованы.
Чтобы подчеркнуть важность такой связки, я люблю формулировать для команд небольшой акцент:
Отчет по работе сценариев Make по адаптации — это такая же часть документации по ПД, как политика обработки или реестр процессов, просто в более живом формате.
Когда у вас есть эти цифры, разговор с Роскомнадзором и внутренними аудиторами меняется. Вместо «мы всё делаем, честно-честно» вы показываете динамику: вот мы запустили автоматизацию, вот на сколько сократили риски пропуска инструктажей, вот где еще остались ручные «дыры», вот наш план их закрыть. В условиях 2025-2026 годов, когда проверяющие начинают использовать свои автоматизированные сканеры и системы анализа, такой честный и структурированный подход сильно повышает шансы выйти из диалога без тяжелых последствий.
У Ильи, например, через полгода после запуска make адаптации прошла повторная проверка, и один из самых приятных моментов был таким: проверяющий спрашивает, как фиксируются факты инструктажа по ПД, HR не достает блокнот, а показывает интерфейс с выгрузкой по всем сотрудникам с точными датами, ссылаясь на события из Make и QForm. Вопросов по этому блоку больше не было. В этот момент я снова подумала, что автоматизация — это про уважение к себе в будущем.
Чему учат сбои: где make адаптация чаще всего ломается
К сожалению (или к счастью), ни один сценарий не живет идеально. Где-то падает интеграция, где-то меняется API стороннего сервиса, где-то HR случайно меняет структуру формы, а где-то новый руководитель решает «обойти систему» и делает всё по старинке. Я на своей практике научилась относиться к этим сбоям как к диагностике: они показывают, где процесс был построен слишком хрупко или где люди не разделяют логику, заложенную в автоматизацию.
Технически слабые места в make адаптации часто сидят в форматах данных (кто-то добавил новое поле без обновления сценария), в внешних интеграциях (сервер лег, API поменялось), в отсутствии таймаутов и обработчиков ошибок. Процессно — в нечетких ролях: кто отвечает за шаг, что делать, если сценарий не сработал, как человек поймет, что нужно вмешаться. Нормальной практикой становится регулярный «здоровый» аудит сценариев: раз в квартал или при больших изменениях в HR-процессах.
Здесь работает странный, но честный принцип:
Если автоматизация ломается в одном и том же месте чаще двух раз подряд, проблема не в Make, а в процессе или договоренностях между людьми.
Я видела, как команды по три раза чинили одну и ту же интеграцию с внешним сервисом, вместо того чтобы признать: этот сервис слишком нестабилен, чтобы на нем держать критический шаг адаптации. Или как HR раз за разом забывали обновить форму, потому что не чувствовали себя «владельцами процесса». Решение оказывалось не в еще одном модуле уведомлений, а в простом шаге — закрепить ответственность и провести короткое обучение с объяснением не «как нажимать», а «почему это влияет на ПД и проверки».
В истории с Ильей самый громкий сбой случился, когда один из модулей Make, отвечающий за запись данных в таблицу, молча падал на трех конкретных полях. В итоге три новых сотрудника вышли, а их статусы в системе так и остались «pre-onboarding». Ситуацию заметили только через неделю, когда у одного из них нужно было формировать первый отчет по испытательному сроку. Мы подняли логи, нашли ошибку в типе данных и заодно настроили отдельное оповещение «Сценарий не завершился корректно». С тех пор любое незавершенное выполнение стало видимым, а не пряталось где-то на фоне.
Как это выглядит изнутри компании: история Ильи от хаоса к спокойствию
Я обещала в начале, что история Ильи не останется подвешенной, так что самое время заглянуть внутрь. Когда он впервые пришел ко мне, ситуация была такая: небольшая IT-компания на 120 человек, активный рост, по 5-7 новых сотрудников в месяц, HR-отдел из двух человек, кадровик на аутсорсе, DPO совмещает эту роль с ИТ-безопасностью. Адаптация новых людей напоминала квест: анкеты в почте, договоры в одной папке, сканы паспортов в другой, инструктажи по ПД на бумаге в папке «Обучение», реестра обработки как такового нет, только список систем и общее описание в политике. Проверка намекнула, что так дальше жить нельзя.
Мы начали с двух встреч: первая — чисто процессная, где мы с Ильей и его HR рисовали маркером на доске путь нового сотрудника. Вторая — юридико-технологическая, где я принесла выдержки из 152-ФЗ, подзаконных актов и реальных кейсов проверок 2024-2025 годов. Мы соединили эти два слоя, получили скелет процесса адаптации и список систем, после чего стало понятно, что без Make, или нативных интеграций, или десятка новых кадровиков они просто не вывезут. Выбор пал на Make как на достаточно гибкий и понятный инструмент, который хорошо дружит с их уже стоявшим Битриксом, QForm и локальной базой.
Дальше включился тот самый «расширенный режим» работы мозга: нужно было одновременно не перегрузить HR, не напугать DPO, не сломать привычки руководителей и при этом сделать сценарий, который не рассыплется от первого изменения формы. Мы пошли итерациями: сначала построили минимально жизнеспособный сценарий «точка входа — оформления — базовые доступы», потом добавили блоки по инструктажам и реестру ПД, потом — отчетность и дополнительные метрики. На каждом этапе я просила команду честно отвечать, стали ли им жить проще или только добавили обязанностей.
Получился довольно честный вывод, который я потом стала использовать как внутренний ориентир:
Хорошая автоматизация адаптации ощущается не как «ну ладно, будем еще и в Make что-то заполнять», а как «мы заполняем одну форму, а всё остальное происходит само и предсказуемо».
Сейчас у Ильи ситуация выглядит иначе: HR создают нового сотрудника через одну структурированную форму, Make сам заводит его в Битрикс, ставит задачи юристу, IT и руководителю, следит за прохождением инструктажей, отправляет данные в реестр обработки ПД, формирует ежемесячный отчет по адаптации. Если что-то идет не так, сценарий поднимает флажок, а не молча падает. Да, иногда они допиливают шаги, меняют тексты писем, обновляют шаблоны, но это уже не «мы снова всё с нуля», а нормальная жизнь живой системы.
Где автоматизация не заменит живого HR и здравый смысл
При всех плюсах make адаптации есть зоны, где я категорически против «автоматизировать всё». Это моменты, когда новому сотруднику нужно живое человеческое внимание: первое приветственное общение, обсуждение ожиданий, обратная связь по испытательному сроку, реакция на его вопросы и тревоги. Никакой сценарий Make не заменит нормальный разговор с руководителем или HR, и попытки засунуть это в «бота» обычно заканчиваются ощущением бесчеловечной машины, которая как бы всё делает, но человеку в ней не по себе.
Я заметила, что лучшая комбинация получается тогда, когда Make берет на себя то, что человек делает по чек-листу, а человеку оставляют там, где нужно думать, слушать, подстраиваться. Например, письмо «Добро пожаловать в компанию» может быть шаблонным и уходить автоматически, но встреча с новым сотрудником в первый день — живой разговор. Напоминания руководителю о том, что пора дать обратную связь по итогам первых двух недель, может слать Make, но содержание этой обратной связи сценарий не напишет (нет, подожди, написать-то он может, но лучше пусть это делает человек).
Чтобы это не осталось общими словами, я для себя держу в голове такую формулировку:
Автоматизация адаптации освобождает время на человеческое взаимодействие, а не подменяет его собой.
У Ильи спустя полгода после запуска автоматизации случился занятный эффект: у HR впервые за долгое время появилось «окно» по часу-полтора в день, которое не было забито рутиной. Они начали тратить его на то, что давно откладывали: персональные встречи с новыми сотрудниками, сбор обратной связи по адаптации, доработку материалов по обучению. В какой-то момент один из новичков сказал им на общем созвоне: «У вас как-то всё очень организованно, но при этом по-человечески». Для меня это был лучший маркер, что баланс между Make и живыми людьми найден.
Какие уроки можно забрать для своих процессов адаптации
Наблюдая за тем, как разные компании в России внедряют make адаптацию, я для себя собрала несколько повторяющихся выводов. Во-первых, начинать имеет смысл не с «ставим Make», а с честного описания того, как у вас сейчас устроена адаптация, где люди тонут, где ПД разбегаются, где проверки ругаются. Это больно, но без этого автоматизация просто ускорит существующий бардак. Во-вторых, лучше двигаться итерациями: сначала минимально рабочий сценарий, потом мелкие улучшения. Пытаться сразу оцифровать всё — прямой путь к выгоранию HR и падению доверия к инструменту.
В-третьих, без участия DPO и ИБ вся эта история рискует стать миной замедленного действия. Да, можно технически собрать сценарий без их участия, но в российской правовой реальности это как строить дом без фундамента и коммуникаций. В-четвертых, важно договориться про метрики: что вы хотите уменьшить, что увеличить, по каким цифрам через три месяца будете судить, получилось ли. И да, в-пятых, стоит закладываться на то, что сценарии будут ломаться, а процессы меняться — важно не строить монолиты, а оставлять место для гибкости.
Если ты читаешь это и мысленно перекладываешь на свои процессы, то, скорее всего, уже видишь 2-3 участка, где автоматизация через Make даст быстрый выигрыш: генерация документов и задач, раздача доступов, фиксация инструктажей, напоминания по контрольным точкам адаптации. Начать можно с чего-то одного, а не со «священного Грааля» полного цифрового HR. Потом, когда почувствуешь вкус, всегда можно расшириться.
К чему всё это привело: время, нервы и немного спокойствия
Я люблю возвращаться к началу истории, чтобы посмотреть, насколько изменился фон. Когда Илья в первый раз написал мне, в письме было что-то вроде: «У нас каждый новый сотрудник — маленькая трагедия HR, DPO нервничает, IT злится, что его дергают в последний момент, а в документах по ПД мы регулярно находим «дыры». Хотим автоматизацию, но боимся, что станет только сложнее.» Спустя год после запуска make адаптации тон писем поменялся: «Мы тут добавили новый этап в адаптацию, сценарий Make допилили за вечер, HR теперь не боятся проверок, а DPO использует наши отчеты как аргумент в разговорах с руководством.»
Если перевести эту историю в цифры, получится довольно конкретная картина. Время HR на одного нового сотрудника сократилось с 3-4 часов до примерно 50 минут, IT — с часа до 15-20 минут, при этом качество оформления и полнота выполнения шагов адаптации выросли почти до 100%. Количество «ручных» ошибок по ПД в процессе адаптации (неподшитые согласия там, где они нужны, забытые инструктажи, неактуальные журналы) за первые полгода упало в несколько раз. Проверки перестали быть поводом для срочных ночных разборов, превратились в предсказуемый разговор «вот наши процессы, вот сценарии, вот логи».
Илья даже пошутил как-то, что самый неожиданный результат автоматизации в Make — это то, что его HR впервые за долгое время успевают вовремя уходить домой и не боятся утра понедельника. При этом у DPO появилась возможность не утонуть в ручном сборе доказательств, а сосредоточиться на более стратегических задачах: обновлении моделей угроз, анализе новых регуляторных требований, работе с другими процессами обработки ПД. Получается, автоматизация освободила время не только для «человечности» в адаптации, но и для более зрелого управления рисками.
Возвращаясь к самому началу, к тому остывшему кофе и хаосу из писем и файлов, я понимаю, почему тема автоматизации адаптации в Make так резонирует у HR и ИТ-рисковиков в России. Это редкий пример, когда один и тот же инструмент помогает одновременно и соблюдать закон, и делать людям чуть менее больно в повседневной работе. Не магия, не «одна кнопка», а аккуратная сборка процессов, где каждый шаг понятен, прозрачен и подкреплен как технически, так и документально.
И здесь есть одна мысль, которой я обычно завершаю такие разговоры. Автоматизация ради автоматизации быстро надоедает и рассыпается. Автоматизация ради возвращения людям времени и снижения системных рисков — живет долго. Если смотреть на make адаптации именно так, то каждая новая интеграция, каждый сценарий и каждая настройка начинают чувствоваться как инвестиция в устойчивость компании, а не как очередная «игрушка для HR и айтишников».
Если хочется не только прочитать про это, но и посмотреть, как такие штуки разбираются и собираются вживую, я периодически разбираю реальные кейсы и схемы адаптации через Make и n8n в своем Telegram-канале MAREN. Там же можно задать мне конкретный вопрос по своему процессу и посмотреть, как другие компании решают похожие задачи. А если интересно глубже понять, чем я вообще занимаюсь и какие еще процессы автоматизирую и ставлю на «автопилот», можно заглянуть на сайт promaren.ru — я стараюсь, чтобы там было не про «хайповые нейросети», а про честные процессы и экономию часов.
Что ещё важно знать про автоматизацию адаптации в Make
Вопрос: Как начать автоматизировать адаптацию, если в компании пока нет формализованного процесса?
Ответ: Я бы начала с описания текущей реальности простым языком: кто, когда и как сейчас принимает нового сотрудника в работу. Это можно сделать на одной доске или в документе, не усложняя. Потом выдели обязательные шаги (договор, доступы, инструктажи) и посмотри, какие из них чаще всего «провисают». Первую автоматизацию в Make стоит строить именно вокруг этих провисаний, оставляя остальное как есть, чтобы не перегрузить команду.
Вопрос: Можно ли использовать Make для адаптации, если часть сотрудников работает как самозанятые или по ГПХ?
Ответ: Да, но юридическая логика будет отличаться от классического трудового договора. Для самозанятых и ГПХ других основание обработки ПД, другие сроки хранения и иногда другие объемы данных. В Make это имеет смысл отражать через отдельные типы «сотрудников» или сценарии, чтобы не смешивать процессы. При этом требования 152-ФЗ по защите ПД остаются, поэтому архитектура хранения и передачи данных будет очень похожей.
Вопрос: Что делать, если руководство боится выносить часть логики адаптации в облачный Make из-за требований по локализации данных?
Ответ: В таком случае я бы предложила архитектуру, где Make оперирует только техническими идентификаторами и статусовыми полями, а сами ПД хранятся и обрабатываются в российских системах. То есть Make знает, что «сотрудник с ID 123 перешел на этап ‘оформлен'», но не хранит паспорт или СНИЛС. Это снижает регуляторные риски и делает разговор с безопасностью и DPO гораздо спокойнее. Если опасения все еще сильны, можно рассмотреть частичную замену Make на локальные решения, сохранив общую логику процессов.
Вопрос: Как убедить HR-команду перейти от Excel и почты к автоматизации в Make?
Ответ: Лучший аргумент для HR — не архитектура и не «красивые сценарии», а честно сэкономленное время и снижение риска ошибок. Поэтому я бы предложила пилот на одном участке адаптации, который HR сами выбирают как самый болезненный. После запуска стоит замерить, сколько времени и нервов стало тратиться «до» и «после» и показать это на цифрах. Если автоматизация сделана аккуратно, обычно команда сама начинает предлагать, что еще можно передать в Make, вместо сопротивления.
Вопрос: Можно ли полностью отказаться от бумажных документов при автоматизации адаптации?
Ответ: В 2025-2026 годах в России уже много где можно перейти на электронный документооборот, но не всегда это возможно юридически и технически именно в вашем контуре. Я бы шла от требований отрасли и регуляторов: если закон и внутренние политики позволяют использовать ЭДО и ЭП для трудовых документов и актов, Make отлично поможет автоматизировать этот поток. Если часть документов по-прежнему должна быть на бумаге, автоматизация все равно полезна: она помогает не забыть подготовить, подписать и подшить эти бумаги и фиксирует статусы в журналах.
Вопрос: Что делать, если в компании мало технических ресурсов, а Make кажется слишком сложным для HR?
Ответ: В такой ситуации имеет смысл начинать с очень простых сценариев и подключать кого-то, кто понимает базовую логику интеграций, хотя бы на этапе запуска. HR не обязательно самим настраивать модули и API, им важно понимать, какие шаги автоматизированы и что от них требуется. Часто достаточно одного человека, который «дружит» с техникой, чтобы поддерживать сценарии, а HR дают обратную связь и помогают улучшать процесс. Со временем часть HR вполне осваивает базовый уровень работы с Make, если видеть в нем не «код», а визуальный конструктор процесса.
Метки: ai-agents, makecom, n8n, автоматизация, автопостинг, контент-план