Денис Елисеев

Администратор и интегратор Битрикс24, Python-разработчик. Автоматизирую процессы вокруг CRM - от настройки воронок до собственных сервисов, которые довозят данные в портал и обратно.

telegram @eliseevde email mail@eliseevdenis.ru github des-e локация Санкт-Петербург · GMT+3 формат удаленно

// о себе

С 2022 года строю и чиню процессы вокруг CRM: чтобы данные попадали в систему сами, а не руками, и чтобы было видно, когда что-то сломалось.

Работаю с облачными и коробочными порталами Битрикс24, в том числе на 1000+ пользователей в редакции «Энтерпрайз»: бизнес-процессы, кастомные активити, серверная логика на PHP внутри БП, права доступа, аудит безопасности, интеграции с 1С, телефонией и внешними сервисами через REST API.

Сейчас работаю с коробочным порталом «Энтерпрайз Холдинг» примерно на 1 400 пользователей: дорабатываю и оптимизирую его, разрабатываю и внедряю решения, веду бизнес- и системную аналитику, администрирую. До этого вел проекты для клиентов интегратора - недвижимость, лизинг, подбор персонала - от сбора требований до поддержки в боевой эксплуатации. Пишу на Python: FastAPI-сервисы, парсеры недокументированных API, боты для Telegram и MAX.

Отдельное направление - ИИ: собираю рабочие инструменты для команды, внедряю ИИ в рабочие и повседневные процессы.

// кейсы

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

Расчеты Лизинговый калькулятор: от Excel-файла до рабочего сервиса Excel по почте→сервис с единой моделью FastAPI · PostgreSQL · reportlab · openpyxl · Bitrix24 REST

Задача

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

Решение

Собрал сервис, который заменил файл целиком.

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

Работа идет в закрытом портале с авторизацией и двумя ролями - менеджер застройщика и брокер, у каждой своя форма; если человек и то и другое, роль выбирается при входе. Доступ выдается флагом в карточке сотрудника в CRM: сняли - действующая сессия гасится на следующем же запросе, без участия разработчика.

Все условия расчета переехали в CRM: застройщики, жилые комплексы, дома, типы помещений, глобальные константы. Заказчик правит карточку в портале - бизнес-процесс шлет вебхук, сервис обновляет справочник. Параметры наследуются по цепочке дом → комплекс → застройщик → общие настройки, так что задавать нужно только отличия.

Каждый расчет фиксируется в CRM: сервис собирает график платежей в PDF и график к застройщику в XLSX и сам кладет их в сделку вместе с параметрами. Видно, кто, кому и на каких условиях считал.

Результат

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

Дубликаты Поиск дублей заявок штатными средствами ручной разбор→окупаемость 1,5 месяца Bitrix24 · Бизнес-процессы · Анализ данных

Задача

Крупная платформа финансовых и страховых продуктов, поток заявок на КАСКО: невысокий чек, короткий цикл сделки, высокий спрос. Один и тот же человек оставлял в среднем три заявки, в пике - одиннадцать. Менеджеры тратили время на заведомо лишние лиды, выясняли между собой, чья это заявка, руководитель объединял карточки руками. Реальные новые обращения в это время ждали в очереди, а при коротком цикле сделки скорость реакции прямо влияет на конверсию.

Решение

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

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

Обработку построил так, чтобы ничего не терялось. Новый лид помечается, уходит в отказ с причиной и ссылкой на первоисточник; в карточку первичной заявки падает комментарий с данными нового обращения; ответственному менеджеру приходит уведомление со ссылкой. Дубль перестал быть мусором и стал сигналом: клиент активен, возможно, хочет пересчитать у другого страховщика - и менеджеру есть что ему предложить. Если заявок подряд несколько и ни одна не взята в работу, в живых остается последняя.

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

Результат

Доля дублей впервые измерена - 7% всего потока. У отдела освободилось порядка 75 часов в месяц, это около 180 тысяч рублей в квартал по фонду оплаты труда. Разработка заняла 49 человеко-часов и обошлась примерно в 165 тысяч рублей - окупаемость около полутора месяцев. Реальные заявки стали разбираться быстрее, а у менеджеров сократилось число висящих карточек.

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

Процессы Поиск ответственного вынесен в переиспользуемый процесс правка в 100 местах→в одном Bitrix24 · Бизнес-процессы · Универсальные списки

Задача

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

Логику поиска прописывали внутри каждого процесса заново. Процессов было около тридцати, в некоторых - десятки веток, и по факту это был копипаст: одна и та же громоздкая ветка, размноженная по всему порталу. Цена вылезала при каждой перестановке: сменился человек или сотрудник перешел в другой департамент - и надо править порядка сотни мест, отыскав их во всех процессах. Что-то забывали, где-то ошибались, согласование уходило не туда и зависало; отдельные решения и подписи шли неделями.

Решение

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

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

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

Результат

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

Кадры Учет стажа и надбавок для сотрудников вне портала вручную→−90% времени Bitrix24 · Смарт-процессы · Бизнес-процессы · 1С · Вебхуки

Задача

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

Решение

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

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

Результат

Ежедневная сверка таблиц исчезла - система сама сообщает, у кого изменился стаж, и сама двигает согласование. Время обработки таких сотрудников в отделе кадров сократилось на 90%, переписка по почте из процесса ушла. Побочный эффект оказался ценнее исходной задачи: рабочие вне портала стали полноценными участниками процессов и дальше использовались в других сценариях.

Боты Фиксация клиентов у застройщиков из мессенджера вне CRM→каждая фиксация в CRM Python · aiogram · MAX API · Bitrix24 REST · SQLite

Задача

Агенты по недвижимости фиксируют клиентов в партнерском сервисе застройщиков. Каждая фиксация - длинная форма с повторяющимися полями, заполняется вручную; с телефона это неудобно, и часть заявок не доводилась до конца. Руководитель при этом не видел картины: данные жили в чужом сервисе и с CRM никак не были связаны.

Решение

На разборе задачи выяснилось, что у сервиса есть API со Swagger-описанием. Поднял отдельный сервер и написал бота - сначала для Telegram, затем второго для MAX на той же логике и общей базе агентов.

Агент открывает чат, бот сам логинится во все его партнерские учетки сразу и подтягивает доступные агентства и объекты - остается заполнить четыре поля: имя, фамилия, телефон, комментарий. Телефон приводится к формату сервиса. Заявка уходит партнеру, а ответ - номер, статус, агентство, объект - тут же ложится в смарт-процесс Bitrix24. Каждая попытка, удачная и неудачная, пишется в общий реестр.

Доступ разведен через карточку агента в портале: руководитель ставит флаг - агент получает функцию и уведомление в мессенджер, снимает - функция пропадает. Новые агенты регистрируются прямо из бота, карточка заводится в портале автоматически.

Результат

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

ИИ ИИ-разбор чужих бизнес-процессов десятки часов→минуты FastAPI · Claude API · SQLite · SSE

Задача

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

Решение

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

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

Результат

Разбор незнакомого процесса из «сесть и читать день» превратился в несколько минут. Инструментом пользуется команда и заказчики - он сэкономил сотни часов на проектах с унаследованными процессами.

Контроль Сторожевой процесс против правок в обход сделки правки в обход→автоматический откат Bitrix24 · Смарт-процессы · Бизнес-процессы

Задача

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

Решение

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

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

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

Результат

Данные в связанных карточках гарантированно совпадают с согласованными. Производство перестало получать противоречивые вводные - ушла причина брака и переделок, а с ней расход материалов и труда на исправление. Каждая попытка правки в обход фиксируется, поэтому разбор ситуаций перешел из плоскости «кто виноват» в чтение лога. Реализация заняла 50 часов.

Парсер данных Выгрузка базы кандидатов из сервиса без API ручная работа→выгрузка без потерь Python · PostgreSQL · JSON:API · JWT

Задача

HR-команда ведет отклики на вакансии в стороннем сервисе подбора, а работа компании идет в CRM. Каждый отклик переносили руками; пока это не сделано, кандидата для компании как бы нет. Нужно было забрать базу целиком и дальше получать новые отклики автоматически. Сложность в том, что у сервиса нет ни публичного API, ни документации, ни выгрузки, а запросы к нему закрыты защитой от автоматического трафика.

Решение

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

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

Результат

База перенесена полностью и без потерь: 1920 кандидатов, 2000 откликов, 1920 резюме, ноль ошибок на финальном прогоне. Хранилище стало основой для следующего шага - автоматической доливки новых откликов в CRM.

Поддержка Бот первичной обработки обращений с маршрутизацией по ключевым словам 14 мин→4 мин Python · aiogram · Открытые линии · Bitrix24 REST

Задача

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

Решение

Поставил на вход Telegram-бота. Он принимает обращение, дособирает недостающие данные прямо в диалоге - ведет по шагам и не дает отправить полупустую заявку, - и определяет тему по ключевым словам в тексте.

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

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

Результат

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

Прием заявок Заявки стороннего сервиса в CRM ручной ввод→авто-сделка FastAPI · SQLite · Bitrix24 REST · systemd · nginx

Задача

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

Решение

Простой путь - выдать отправителю вебхук портала и пусть заводит сущности сам. Но заказчик очень просил не выпускать наружу токен с правами в CRM - отдавать его стороннему сервису он не хотел. Ответом на эту просьбу и стала архитектура: между отправителем и порталом встал отдельный приемник - наружу смотрит один узкий адрес, который умеет ровно одно, принять заявку, а ключ от портала не покидает контур заказчика. На этом же слое я заодно закрыл то, чего на стороне отправителя быть не могло: дубли и спам.

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

Дальше обработка. Телефон чистится до пригодного вида; если его нет - заявка сохраняется, но в CRM не уходит, чтобы не плодить пустые карточки. Повтор по тому же телефону в коротком окне помечается как спам и дубля не создает. Контакт переиспользуется, если человек уже приходил, сделка создается и привязывается к нему, попадая сразу в нужную воронку и стадию с проставленным источником.

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

Отдельно - устойчивость. Временная ошибка на стороне CRM (перегрузка, лимит запросов, таймаут) заявку не теряет: она помечается и повторяется отдельным воркером с паузой, до четырех попыток. Повтор идемпотентен - уже созданный контакт не создается заново. Постоянные ошибки не ретраятся вовсе, чтобы не молотить впустую. Поводом стала ровно одна потерянная заявка из семисот - ее нашли и после этого закрыли класс проблемы целиком.

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

Код при этом намеренно простой - без ORM и лишних слоев: сервис живет на инфраструктуре заказчика, и поддерживать его должен его администратор, а не только автор.

Результат

Через сервис проходит около 750 заявок в месяц: они попадают в CRM без ручного этапа и без дублей, каждая имеет след в базе, а состояние сервиса видно из рабочего чата, без захода на сервер. Доступ внешней стороны сузился с полного вебхука портала до одного адреса, умеющего принять заявку. Развернут у заказчика: отдельный поддомен, HTTPS, наружу открыт только прокси.

Справочники Единый справочник агентов вместо таблицы Google Sheets→Bitrix24 Bitrix24 Lists · Вебхуки · SQLite · Python

Задача

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

Решение

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

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

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

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

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

Результат

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

Инфраструктура Переезд стека между провайдерами переезд→без простоя Docker Compose · Caddy · systemd

Задача

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

Решение

Описал сервер как код - Docker Compose и Caddy с авто-TLS. Собрал стек параллельно на новой площадке, прогнал проверки, затем переключил DNS. Старая площадка какое-то время оставалась живой как путь отката.

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

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

Результат

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

// опыт работы

Август 2026 -
настоящее время
·
3 месяца

Грузовичкоф

Администратор Битрикс24

Администрирование и развитие корпоративного портала Битрикс24, коробочная версия «Энтерпрайз Холдинг», около 1 400 пользователей.

Обновление платформы и модулей, сопровождение обновлений PHP и MySQL, BitrixVM
Перенос портала на новый сервер со сменой домена и лицензии, развертывание из резервной копии
Резервное копирование и проверка восстановления, планирование отката
Аудит портала: бизнес-процессы, роботы, смарт-процессы, интеграции, доработки в /local, решения Маркетплейса
Прохождение «Монитора качества», проверка ядра на модификации, проактивная защита, двухфакторная аутентификация администраторов
Управление пользователями, структурой компании и LDAP-каталогами, ролями и правами доступа CRM
Бизнес- и системная аналитика: разбор процессов, сбор требований, проектирование решений и постановка задач
Проектирование CRM: воронки, стадии, смарт-процессы, пользовательские поля, универсальные списки
Бизнес-процессы и роботы, PHP-код внутри БП, отчеты по CRM
Разработка собственных модулей на PHP (D7, агенты, обработчики событий)
Миграции и массовые операции с данными через REST API и PHP-скрипты, с пробным прогоном и сверкой
Интеграции: Jira, 1С, Zabbix, АТС, BI-конструктор, Авито, HH, Яндекс Работа
Управление дисковым пространством, политика хранения данных
Документация, регламенты и инструкции для сотрудников, массовые рассылки об изменениях
Взаимодействие с руководством, сисадминами, ИБ и техподдержкой вендора

Октябрь 2024 -
Август 2026
·
1 год 11 месяцев

ИП Елизаренко А. В. (ExCode)

Специалист по внедрению и автоматизации Битрикс24 / Интегратор Битрикс24

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

Комплексное внедрение, сопровождение и архитектурное развитие Битрикс24 - облачная и коробочная версии, включая Enterprise
Глубокая настройка CRM и проектирование пути клиента: воронки, пользовательские поля, списки, смарт-процессы, карточки компаний и контактов, складской учет
Бизнес-процессы, роботы, триггерные сценарии; разработка модулей, компонентов и кастомных активити
Кастомная серверная логика на PHP внутри бизнес-процессов через PHP-активити
Интеграция с 1С: миграция данных и синхронизация справочников
Интеграции с внешними сервисами: IP-телефония, мессенджеры, Авито, E-Staff, МойСклад, Google Sheets
Разработка на Python: FastAPI-сервисы, парсеры, боты для Telegram и MAX
Развертывание и эксплуатация: Docker, Docker Compose, Caddy, nginx, systemd, мониторинг с алертами
Инструменты на базе ИИ: Claude API и Whisper в рабочих процессах, потоковая генерация, маршрутизация запросов между моделями
Аудит безопасности портала, роли и права доступа, резервное копирование
Code Review, Git, тестирование доработок перед релизами, ведение базы знаний и регламентов

Январь 2022 -
Июнь 2024
·
2 года 6 месяцев

ООО «Альма медиа»

Специалист по внедрению и автоматизации Битрикс24 / Интегратор Битрикс24

Внедрение Битрикс24 и автоматизация бизнес-процессов, включая проекты на коробочной версии для компаний с 1000+ пользователей.

Анализ потребностей компании, аудит и оптимизация бизнес-процессов для развития корпоративного портала
Настройка и автоматизация: смарт-процессы, кастомные сущности, роботы, триггеры, права доступа
Кастомная бизнес-логика на PHP через PHP-активити внутри бизнес-процессов
Автоматизация документооборота, обработки заявок и распределения лидов
Интеграции с 1С, телефонией и Telegram через REST API и вебхуки
Telegram-боты на Python и aiogram для работы технической поддержки
Code Review, версионирование в Git, CI/CD-пайплайны, тестирование и устранение багов
Администрирование портала, права доступа, миграция данных, резервное копирование

// собственные продукты

Не пет-проекты: работают в проде, ими пользуются коллеги.

BPT Analyzer LIVE

Веб-сервис разбора бизнес-процессов Bitrix24: загрузка .bpt, анализ структуры, автогенерация документации, отчет о готовности к миграции, диалог по процессу. Маршрутизация запросов между моделями снижает стоимость обращения к API до 75%.

FastAPIClaude APISSESQLite

bpt.eliseevdenis.ru ——→

Транскрибатор созвонов В РАБОТЕ У КОМАНДЫ

Локальная расшифровка аудио и видео без облака: Whisper, саммаризация через собственный API-сервис, таймлайн с подсветкой сегментов, инлайн-редактирование, экспорт SRT.

PythonWhisperClaude API

github.com/des-e/transcribe ——→

Мониторинг торгов PROD

Парсер государственных торговых площадок с фильтрацией по регионам и характеристикам лотов, уведомления в Telegram. Геоблокировка источника обойдена собственным egress-прокси.

PythonaiogramDocker

Инфраструктура как код LIVE

Личный сервер целиком в Docker Compose и Caddy: авто-TLS, статика, реверс-прокси, хост-мониторинг с алертами в Telegram. Разворачивается на чистой машине одной командой.

Docker ComposeCaddysystemd

// стек

Битрикс24

Коробка и облако · «Энтерпрайз Холдинг» · CRM: воронки, смарт-процессы, универсальные списки · бизнес-процессы и роботы · кастомные активити · модули D7 · права доступа · REST API и вебхуки · BitrixVM

Интеграции

1С · телефония · Jira · Zabbix · BI-конструктор · Авито, HH · боты Telegram и MAX · внешние API, в том числе недокументированные

ИИ в бизнесе и CRM

Внедрение ИИ в бизнес-процессы и CRM · Claude · RAG

Разработка

Python · FastAPI · aiogram · SQLAlchemy · PHP · SQL

Базы и инфраструктура

PostgreSQL · MySQL · SQLite · Docker · nginx · Caddy · Git

Аналитика и процессы

Бизнес- и системная аналитика · требования · техническая документация · регламенты · Code Review

// образование

2010
·
неоконченное высшее

НИУ ИТМО, Санкт-Петербург

Прикладная математика и информатика - математик, системный программист