Своя дистанция | Дмитрий Рыбаков

Всем привет! Продолжаю #марафон технологических проектов. Сегодня поговорим про доработку коннектора Directum HR Pro и 1С:ЗУП. В одном из проектов к нам обратился интегратор Directum. Он внедрял HR Pro для крупной организации, где кадровые процессы были выстроены вокруг управленческой структуры. И здесь возникла проблема. Типовой коннектор Directum — 1С работал с регламентированными подразделениями. Для стандартного сценария этого достаточно. Но у конечного клиента внутренние HR-процессы, согласования и назначение ответственных строились по другой логике. Если бы оставить всё как есть, заказчику пришлось бы перестраивать свои процессы под типовой коннектор. Мы доработали коннектор под управленческую структуру. Что сделали: ▫️ проанализировали типовую логику обмена; ▫️ заменили обращения к регламентированной структуре на управленческую; ▫️ сохранили связанную логику по документам, печатным формам и правам доступа; ▫️ адаптировали синхронизацию оргструктуры; ▫️ доработали обмен по кадровым процессам; ▫️ после обновления Directum актуализировали коннектор под новую версию. В результате данные между Directum HR Pro и 1С:ЗУП стали синхронизироваться автоматически. Ручное дублирование кадровых документов и изменений структуры ушло из процесса. 🪄Типовой коннектор закрывает типовой сценарий. Но в проектах почти всегда нужно сначала понять, как у клиента устроены данные, структура и маршруты согласования.🪄 И только потом решать, хватит ли типовой интеграции или нужна адаптация. Для таких проектов мы подготовили технологическую анкету по интеграции 1С и Directum RX / HR Pro. Её можно использовать как чек-лист на старте: зафиксировать системы, справочники, документы, роли, маршруты, структуру подразделений и заранее понять, где могут появиться риски. ➡️ Забирайте для своих проектов: https://disk.360.yandex.by/i/LxvY_cfpW5gaIw

Про ИИ сейчас говорят много. Рынок уже примерно полгода штормит от новых инструментов, агентов, LLM-моделей и разных сценариев автоматизации. Но мне кажется, ценность не в том, чтобы просто написать: «мы используем ИИ». Вопрос в другом: где он встроен в проект и какую задачу закрывает. 🌟 У нас сейчас есть такой пример в большом MDM-проекте. Клиент собирает данные о физических лицах, клиентах и контрагентах из разных источников: внешних систем, мобильных приложений, Битрикса и других каналов регистрации. Задача — понять, что человек, который пришёл из одной системы, потом зарегистрировался через другую, а позже появился в третьей, — это один и тот же человек. 🌟 Это классическая задача MDM и формирования «золотой записи». В архитектуре решения объединяются MDM, Datareon Platform, PostgreSQL как корпоративное хранилище данных и отдельный блок с локальной LLM-моделью, которая работает внутри контура enterprise-клиента. Сейчас мы прорабатываем, как такая модель должна войти в целевую архитектуру. Она нужна для конкретного участка: нормализации данных, очистки и нечеткого сопоставления там, где обычного сравнения по полям уже недостаточно. 🌟 Для меня это хороший пример того, как ИИ должен появляться в корпоративных проектах. И становится частью архитектуры, где понятно: какую задачу он решает, какие у него ограничения и как команда проверяет результат. #мнение

🌟 Мы сейчас пробуем использовать связку Jira + Claude для работы с проектной информацией. По итогам дейликов и встреч у нас постоянно меняется состояние задач: где-то поменялся статус, где-то появились новые вводные, где-то нужно добавить комментарий, обновить описание, сдвинуть плановую дату или связать задачу с другой задачей. Раньше всё это нужно было руками переносить в Jira. 🌟 Сейчас часть этой работы мы закрываем через Claude. Он видит контекст встречи и проекта, помогает актуализировать задачи и привести их состояние в порядок: обновить описание, комментарии, статусы, сроки, связи между задачами и дополнительные пользовательские поля. 🌟 Отдельный сценарий — планирование спринта. Когда появляется новый блок работ, связка Jira + Claude может подготовить заготовки задач: разложить их по эпикам и фазам проекта, добавить базовую структуру, ответственных и плановые сроки. Команда потом всё это проверяет и правит, но уже не начинает с пустого листа. 🌟 Ещё один полезный сценарий — анализ динамики по задачам. Можно быстрее увидеть, какие задачи долго стоят без движения, где есть зависимости, почему по какой-то задаче потрачено больше времени, чем ожидалось, и что нужно вынести на встречу или в отчёт для заказчика. По сути, здесь идёт работа с проектными данными. Jira хранит состояние проекта, а Claude помогает быстрее разобраться, что именно происходит с состоянием задач, где есть зависимость, почему столько времени было потрачено и что нужно вынести на встречу. Для нас это способ сделать управление проектом более оперативным. 🌟 А какие ИИ-инструменты вы используете в управлении проектами? Если интересно подробнее, как мы используем Jira + Claude в проектной работе, пишите в комментариях.

🌟 Посмотрел разбор по свежему Gartner Magic Quadrant for Analytics & BI Platforms 2026 На схеме видно распределение вендоров по двум осям: Ability to Execute и Completeness of Vision. То есть Gartner оценивает не только текущие возможности платформ, но и то, насколько они соответствуют развитию рынка. Но здесь интереснее не то, кто оказался в лидерах, а кто сместился в другой квадрант. Важнее общий сдвиг: BI всё меньше воспринимается как отдельный инструмент для отчётов и дашбордов. 🌟 В фокусе оказываются подготовка данных, семантический слой, управление качеством, governance, conversational analytics и сценарии с использованием ИИ. И это хорошо совпадает с тем, что мы видим в проектах. 🌟 Когда компания приходит за BI, вопрос редко начинается только с выбора инструмента визуализации. Сначала нужно понять, где лежат данные, как они связаны между собой, кто отвечает за мастер-данные, как устроены обмены и почему один и тот же показатель в разных системах считается по-разному. 🌟 Хороший пример — проект для российского производителя функциональной бытовой химии. Там мы делаем не внедрение BI-системы, а слой подготовки данных: витрины на MS SQL через PROSTO.DWH. По сути, это DWH-слой, в котором данные собираются, приводятся к нужной структуре и уже в агрегированном виде передаются дальше в BI-платформу. 🌟 Если не выстроить транспортный слой и слой хранения, BI не решит проблему. Он просто быстрее и нагляднее покажет беспорядок в данных. Поэтому проекты вокруг аналитики всё чаще становятся технологическими проектами вокруг данных. Там рядом появляются DWH, MDM, ESB, интеграции, семантический слой и только потом визуализация. Ценность BI не в визуальной привлекательности отчётов. Она определяется качеством и надёжностью данных, которые лежат в их основе. #мнение

🌟 Всем привет! Продолжаю #марафон технологических проектов. Сегодня поговорим про переход с 1С:Документооборот 2.1 на 1С:Документооборот 3.0. В чём смысл перехода на 3.0? В новой версии часть сценариев, которые раньше приходилось решать доработками, стала типовой или настраиваемой. Например: работа одного пользователя от разных организаций и должностей, реестры документов под разные подразделения, расширение доступа через связанные документы, визуализация простой электронной подписи. Один из таких проектов мы делали для Generium. Generium — крупная биотехнологическая компания с численностью больше 1500 человек. В системе вели документооборот по нескольким организациям, при этом один сотрудник мог работать в разных юрлицах, на разных должностях и с разными руководителями. Для заказчика было важно перейти на функционал 1С:ДО 3.0, чтобы дальше проще поддерживать и развивать систему. Что нужно было учесть: ▫️ работу сотрудников от разных организаций и должностей; ▫️ визуализацию простой электронной подписи; ▫️ настройку отдельных реестров документов под разные подразделения; ▫️ расширение доступа к документам через связанные документы; ▫️ перенос действующих процессов из 1С:ДО 2.1 в 1С:ДО 3.0; ▫️ снижение зависимости от старых доработок. 👉 Одна из главных сложностей была в миграции. В компании существовали процессы, полный жизненный цикл которых занимал больше полугода. Просто остановить работу в старой версии и одномоментно перевести всех пользователей в новую было нельзя. 🌟 Поэтому миграция данных заняла почти год. Какое-то время пользователи работали сразу в двух версиях: задачи уже отображались в 1С:ДО 3.0, но процессы, начатые в 1С:ДО 2.1, нужно было корректно завершить в старой системе. Что сделали в рамках проекта: ▫️ обновили действующую базу 1С:ДО 2.1 до актуального релиза перед переходом; ▫️ провели миграцию в тестовом контуре и проверили основные процессы; ▫️ перенесли данные на рабочие серверы; ▫️ настроили работу пользователей от разных сотрудников, организаций и должностей; ▫️ сделали визуализацию простой электронной подписи в карточке документа и листе согласования; ▫️ настроили реестры документов для разных наборов видов документов; ▫️ реализовали автоматическое расширение доступа через связанные документы. 🌟 Отдельно интересный момент — доступы. В 1С:ДО 2.1 для расширения доступа к связанным документам ранее приходилось делать отдельную доработку. Например, если документ поступления создан на основании договора, бухгалтер мог видеть поступление, но не иметь доступа к самому договору. В 1С:ДО 3.0 этот сценарий уже можно настроить типовым механизмом: права к связанным документам синхронизируются автоматически по заданным правилам. В результате компания получила более управляемую систему: ▫️часть старых доработок ушла в типовые механизмы; ▫️ обновления на новые релизы стали проходить проще; ▫️ пользователи получили более удобную работу с реестрами; ▫️ согласования от разных должностей и организаций стали прозрачнее; ▫️ доступы к связанным документам начали управляться автоматически. 👉 Поэтому я бы не рассматривал такие проекты только как техническое обновление. Переход на 1С:ДО 3.0 — это возможность пересмотреть накопленные доработки, аккуратно перенести живые процессы и сделать систему проще для дальнейшего развития.

🌟 Всем привет! Продолжаю #марафон технологических проектов. Хочу запустить небольшую рубрику «Технологические проекты: что внутри». Начну с интеграции приложений. Например, возьмем ритейл-компанию. Есть ERP, WMS, TMS, 1С, сайт, маркетплейсы и внешние сервисы. Каждая система отвечает за свой участок, но данные должны постоянно передаваться между ними: остатки, заказы, отгрузки, статусы, документы. Когда систем немного, данные часто передаются напрямую между приложениями. На старте этого обычно достаточно. Но дальше компания растет, систем становится больше, и простая задача «подключить еще одну систему» превращается в отдельный проект. Нужно снова описывать логику обмена, настраивать правила, проверять ошибки и думать, что изменится в соседних системах. В таких случаях помогает интеграционный слой. Системы обмениваются данными не напрямую друг с другом, а через единый контур. Например, можно подключить WMS к ERP, TMS, 1С и внешним системам без остановки складских процессов и без перестройки всей архитектуры. Про похожую логику на DATAREON Platform я уже рассказывал в кейсе про интеграции ECM и 1С. Там заказчику был нужен не разовый обмен под одного клиента, а тиражируемый коннектор для разных внедрений. Оставлю ссылку здесь. Еще один пример — интеграции через «1С:Шину». Когда баз 1С становится больше, отдельные обработки и прямые обмены постепенно усложняют поддержку. В такой ситуации централизованный обмен сообщениями становится более понятным решением. Пост об этом тоже оставлю здесь. Для меня главный смысл интеграции приложений в том, чтобы ИТ-ландшафт можно было развивать дальше: подключать новые системы, менять правила обмена и не пересобирать старые связи каждый раз с нуля.

🌟 Всем привет! Недавно у нас прошёл вебинар про интеграции Directum и 1С, а сегодня делюсь новым анонсом. 2 июля Programming Store и DATAREON проведут вебинар «Как сократить затраты до 15% на поддержку ИТ-ландшафта с DATAREON Platform». Вебинар проведут Никита Перевозчиков, эксперт по цифровой трансформации Programming Store, и Ярослав Синюков, руководитель отдела по работе с партнёрами DATAREON. Расскажут, почему интеграция «точка-точка» незаметно съедает до 15% ИТ-бюджета и создаёт информационные разрывы между отделами. Покажут, как DATAREON Platform как единый центр управления с low-code инструментами и отказоустойчивостью помогает снизить количество ошибок в данных на 30% без перегрузки учётных систем. Приглашают собственников, ИТ-директоров и архитекторов систем, которым полезно узнать: ▫️ как не платить за бесконечные доработки того, что и так должно работать; ▫️ как собрать легко масштабируемую систему без лишней боли. Вебинар будет полезен, если вы: 🌟 cталкиваетесь с расхождением данных в разных системах и интеграцией «точка-точка» под каждую новую систему; 🌟 принимаете решения по несовпадающим цифрам, а внедрение новых систем затягивается на месяцы; 🌟 хотите избежать ошибочных закупок, кассовых разрывов, репутационных потерь и паралича отгрузок. 📅 2 июля, 16:00 мск 💻 Онлайн, участие бесплатное 🌟 Зарегистрироваться

🌟 «У вас такие высокие показатели. Как вы этого добились?» «Мы просто неправильно считаем». К сожалению, это не всегда шутка. Когда руководители перестают доверять BI, часто начинают разбирать сам отчёт: не тот график, не тот показатель, не так настроили визуализацию. Но я бы начинал раньше. BI — это финальная точка. До него данные нужно забрать из разных источников, передать, преобразовать, проверить, сложить в хранилище и только потом показать в отчёте. 🌟 И дело не только в оперативности. Компания может видеть данные быстро. Но если они недостоверные, неактуальные, неполные или не отражают текущую картину бизнеса, скорость уже не помогает. Если развивать эту мысль на практике, проблема может выглядеть так: из одной системы данные забрали, а из другой — нет, потому что не подошёл коннектор. Где-то обмен прошёл с ошибкой. Где-то данные доехали, но справочник задвоился. Где-то показатель попал в BI, но уже после ручной правки или с задержкой. На выходе дашборд есть. Цифры есть. Но доверия нет. Поэтому я бы смотрел на весь путь данных до BI: ▫️откуда они забираются; ▫️ как подключены источники; ▫️ как устроен транспортный слой; ▫️ где маршрутизируются данные; ▫️ как работают ETL-процессы; ▫️где хранятся сырые данные; ▫️ где они очищаются и агрегируются; ▫️ как формируются таблицы КХД; ▫️ где проверяются дубли, полнота и актуальность. Если эта цепочка не выстроена, BI будет просто показывать проблемы, которые появились раньше. В этом и есть смысл платформенного подхода. Не поставить ещё одну систему ради системы, а собрать управление данными в одном контуре: подключение к источникам, маршрутизация, правила преобразования, контроль полноты, актуальности и дублей. Тогда у команды появляется нормальная видимость того, что происходит с данными. Видно, что загрузилось, что не доехало, где возникла ошибка, где появились дубли и что нужно поправить. 🌟 И вот тогда BI действительно начинает приносить пользу. А что для вас главное в BI? Поделитесь своим опытом в комментариях. #мнение

🔥 Спасибо всем, кто был с нами на вебинаре «Сквозные процессы документооборота: как связать Directum и 1С в единый контур». Вместе с Рустемом Фатхуллиным разобрали, как связать согласование в Directum и учет в 1С в единый процесс без избыточной кастомизации на старте. На примере договорного процесса поговорили про контроль лимитов, финансовые обязательства, работу с документами и границу между типовым коннектором и адаптацией под задачи бизнеса. Для участников и тех, кто не успел подключиться, подготовили запись вебинара. Смотреть вебинар🔽 • Youtube • Rutube Спасибо за вопросы и интерес к теме!

🌟 Всем привет! Делюсь новой статьей на VC. Читать ➡️ https://vc.ru/dev/2972419-upravlenie-proektami-esb-mdm-i-bi-otlichiya-ot-erp В ней разбираю, почему ESB, MDM, BI и корпоративные хранилища данных нельзя вести как классическое внедрение ERP. В статье показываю это на наших кейсах: ✅замене Oracle на 1С:ЗУП, где интеграционную шину изначально рассматривали как обычный модуль большого внедрения; ✅проекте ESB + MDM на новой платформе, где трудозатраты выросли больше чем в два раза; ✅внутреннем внедрении BI и корпоративного хранилища данных, где мы сами были и заказчиком, и исполнителем. Также разбираю: 🌟почему закрытые задачи в Jira еще не означают работающий результат; 🌟 как legacy-системы, грязные данные и скрытые зависимости ломают сроки; 🌟почему технологическим проектам нужны другие метрики и контрольные точки. Буду рад, если прочитаете и поддержите статью. Хороших вам выходных!

🌟 Всем привет! Поделюсь новым кейсом из нашей практики: разработали расширение для 1С для вендора ECM-системы. Заказчик — крупный российский разработчик ECM-платформы для электронного документооборота и управления процессами. Ему нужен был не разовый обмен между ECM и 1С под одного клиента, а тиражируемый коннектор для внедрений у среднего и крупного бизнеса. Основные требования: не изменять типовую конфигурацию 1С, дать пользователям возможность настраивать сопоставление реквизитов и правила обработки данных, а также обеспечить масштабирование через многопоточность. 🌟 Проект выполнили за 7 месяцев командой из двух разработчиков при участии архитектора. Что сделали: ▫️ реализовали двусторонний обмен между 1С и ECM-системой; ▫️ настроили передачу контрагентов, договоров и связанной информации; ▫️ обеспечили открытие карточек объектов из одной системы в другой; ▫️ организовали взаимодействие через HTTP-запросы и OData; ▫️ добавили пользовательскую настройку сопоставления реквизитов; ▫️ реализовали правила обработки данных до и после выполнения операций; ▫️ внедрили многопоточную обработку с настройкой количества потоков; ▫️ предусмотрели возможность подключения новых справочников и объектов без переработки ядра. 🌟В результате заказчик получил собственный коннектор к 1С для продуктовой линейки ECM-платформы. Его можно использовать у конечных клиентов, сокращать сроки интеграции и не разрабатывать новый контур обмена с нуля для каждого проекта. Подробнее о кейсе — на сайте компании. Кстати, тему интеграций ECM и 1С продолжим на вебинаре: на примере Directum и 1С покажем, как адаптировать типовой коннектор под процессы бизнеса. Зарегистрироваться 🔗

🌟 Всем привет! 17 июня проведу вебинар «Сквозные процессы документооборота: как связать Directum и 1С в единый контур». Буду выступать вместе с Рустемом Фатхуллиным, исполнительным директором РосА и экспертом по внедрению решений на базе Directum. Разберём типичную проблему крупных компаний: согласование идет в ECM, учет — в 1С, финансовые обязательства контролируются отдельно, а часть данных переносится вручную. Из-за этого процессы сложнее масштабировать, данные синхронизируются не полностью, а нагрузка на ИТ-команду растет при каждом изменении. На вебинаре покажем, как связать Directum и 1С в сквозной процесс без избыточной кастомизации на старте. На примере договорного процесса разберём создание, согласование и исполнение договора, контроль лимитов и финансовых обязательств, работу с финансовыми документами, а также границу между типовым коннектором и адаптацией под процессы бизнеса. До встречи на вебинаре! 📅 17 июня, 16:00–17:30 мск 💻️ Онлайн, участие бесплатное 🌟 Зарегистрироваться

3 мая бежал Казанский марафон Для меня это уже своего рода ежегодная традиция. Планировал этот старт еще в прошлом году, даже рассказывал, что готовлюсь. Но если честно, готовился я минимально. Май получился очень плотным. В какой-то момент это выбило меня из обычного тренировочного графика. Тем приятнее, что на марафон все-таки удалось выбраться. Результат получился хороший, бежал с удовольствием. После финиша поймал простую мысль. Иногда результат держится не на идеальной подготовке к конкретному старту, а на базе, которую ты накапливал до этого. 🌟 В технологических проектах похоже. Не каждую задачу начинаешь с чистого листа. В проектах многое держится на накопленном опыте: что уже пробовали, какие решения можно переиспользовать. Один из таких примеров сейчас делаем с коллегами из «Битмастер»: коннектор к системе «1С:Управление автотранспортом». Раньше мы уже разбирались с похожей задачей для себя. Теперь этот опыт помог сделать решение для партнеров, которое можно будет использовать не как разовую доработку, а как основу для похожих сценариев. Так и накапливается экспертиза: задача за задачей, решение за решением. В этом смысле марафон продолжается. 🌟 А как у вас прошел май?

В технологических проектах не всегда проблема в сроках, подрядчиках или команде. Иногда причина глубже — в ИТ-архитектуре. Компания растет, систем становится больше, интеграции усложняются, данные начинают расходиться, а простая доработка внезапно превращается в отдельный проект. В этот момент становится понятно, что архитектура — это уже не просто внутренняя техническая история, а вещь, которая напрямую влияет на то, как быстро бизнес может двигаться и сколько стоят любые изменения. Об этом написал материал для РБК: как понять, что бизнес уперся в архитектурный потолок, и что с этим делать. Читать ➡️ https://companies.rbc.ru/news/JQdb8YXN5p/it-arhitektura-kak-ogranichenie-rosta-kak-kompanii-teryayut-dengi/ Буду рад обратной связи ✍️

🌟 Всем привет! Продолжаю #марафон технологических проектов. Сегодня расскажу про интеграции 1С через «1С:Шину». Когда в компании несколько баз 1С, обмен между ними часто начинается с простых решений: обработка, прямой обмен, отдельная доработка под конкретную задачу. Для небольшого контура это может работать. Но когда систем становится больше, появляется типовая проблема: каждая новая интеграция требует отдельной логики, отдельной настройки и отдельного сопровождения. 🌟 В итоге обмен данными вроде бы есть, но управляемости мало. ▫️Не всегда понятно, где настроено правило обмена. ▫️Ошибки приходится разбирать вручную. ▫️Подключение новой базы снова превращается в проект. ▫️Типовые конфигурации приходится дорабатывать сильнее, чем хотелось бы. «1С:Шина» как раз помогает уйти от прямых связок между системами к централизованному обмену сообщениями. 🌟 Она отвечает за маршрутизацию, обработку, преобразование и доставку сообщений между участниками обмена. То есть становится единым интеграционным слоем, а не еще одной точечной связкой. Но есть нюанс. Чтобы подключить базу 1С к «Шине», все равно нужно: настроить каналы, сервис интеграции, обработчики входящих сообщений, правила выгрузки и загрузки, регламентные задания. Чтобы упростить этот участок, мы сделали расширение «ПростоКоннектор». Это расширение для 1С, легко встраиваемое в любую современную конфигурацию и позволяет без разработки в конфигураторе настраивать правила выгрузки и загрузки сообщений в каналы. Что умеет «ПростоКоннектор»: ▫️ загружает каналы обмена из «1С:Шины» в базу 1С; ▫️ Позволяет настроить правила выгрузки несколькими способами (КД2, КД3, Код на встроенном языке, СКД) ▫️ Регистрирует и позволяет отслеживать статус отправки сообщений в канал; ▫️ Встроенная подсистема замера производительности позволет отслеживать скорость передачи данных. Сценарий становится понятнее: установили расширение, указали адрес сервиса и ключи, загрузили каналы, настроили правила обмена, включили регламентные задания. При этом выгрузку можно настроить разными способами: через код на встроенном языке 1С, правила конвертации данных, EnterpriseData или СКД. Для проектного офиса это важная история. 🌟 Интеграция должна не просто заработать, а быть удобной в поддержке после запуска. Чтобы команда понимала, как подключать новые базы, где искать ошибки, как менять правила обмена и что происходит с сообщениями в системе. Иначе даже стабильный обмен со временем превращается в технический долг. 🌟 Отдельно приятно, что наш материал про «ПростоКоннектор» попал в подборку по «1С:Шине». Если вам актуальна тема интеграций через «1С:Шину» или интересен «ПростоКоннектор» — напишите мне в личку. Расскажу подробнее, как он устроен и в каких проектах может быть полезен. 🌟 А вы в проектах 1С чаще используете прямые обмены или уже переходите к шине?

⚡ Всем привет! Поделюсь новым кейсом из нашей практики: +1 проект по DATAREON. Заказчик — компания из нефтяной отрасли. На фоне импортозамещения переходили с зарубежных систем на российский стек, в основном на решения на базе 1С. Проект уже был в активной фазе, поэтому DATAREON внедряли не «с чистого листа». В 1С уже работала штатная бесшовная интеграция, часть обменов шла через нее, а новый контур нужно было запускать параллельно — без остановки процессов, дублей и расхождений в данных. В контуре участвовали MDM, две инстанции 1С для разных видов учета, система согласования документов, расчет зарплаты, внешние сервисы и веб-порталы. Целевая нагрузка — до 3000 пользователей в 1С. Ключевая сложность была в управлении переходом. Нужно было точечно переносить обмены, сохранять порядок обработки сообщений при многопоточности, учитывать legacy-логику на стороне смежной системы расчета зарплаты и не перегружать 1С прямыми запросами от внешних порталов. Что сделали: ▫️ выстроили централизованный обмен через DATAREON Platform; ▫️ закрепили MDM как источник мастер-данных; ▫️ использовали DATAREON как диспетчер и маршрутизатор потоков; ▫️ разработали около 50 бизнес-процессов обработки сообщений; ▫️ подготовили около 120 обработчиков 1С для выгрузки и загрузки данных; ▫️ подключили внешние системы через REST API; ▫️ реализовали постраничную выборку данных из 1С для веб-порталов; ▫️ добавили валидацию входящих запросов по итогам нагрузочного тестирования; ▫️ вынесли часто запрашиваемые данные в Банк Данных DATAREON, чтобы снизить прямую нагрузку на 1С и дать порталам единую точку доступа. Результат: ▫️ на 60% сократили время запуска новых интеграционных сценариев; ▫️ на 45% снизили количество ошибок ручного ввода и конфликтов в справочниках; ▫️ на 30% снизили нагрузку на одну из систем 1С за счет Банка Данных. 🌟 Интересно, какой подход вы считаете более надежным в таких проектах: сначала максимально детально картировать все существующие обмены или переносить их итерационно, фиксируя конфликты уже на пилотных потоках? Подробнее о кейсе — на сайте.

🔥Спасибо всем, кто был с нами на вебинаре «Сколько стоит бизнесу обновление 1С и как сократить расходы до 50%»! Поговорили о том, из чего складываются затраты на обновление 1С, где чаще всего возникают риски и как автоматизация помогает сделать релизы более предсказуемыми. Для всех участников и тех, кто не успел подключиться, собрали материалы: 📎 презентация вебинара 📈 калькулятор ROI Запись уже доступна, можно посмотреть в удобное время. Смотреть вебинар🔽 • Youtube • Rutube Отличных вам выходных!

🌟 Всем привет! Продолжаю #марафон технологических проектов. В проектном офисе мы занимаемся не только интеграциями и DATAREON. В работу попадают ESB, MDM, BI, ETL, DevOps для 1С, заказные интеграционные решения и проекты, где важно отвечать за результат целиком. Сегодня поговорим про DevOps для 1С. Сразу скажу: DevOps нужен не всем. Если контур 1С небольшой, доработки редкие, пользователей немного, а ошибка после обновления не останавливает работу компании, ручного процесса может хватать. ▫️Но если без 1С уже нельзя нормально продавать, отгружать, производить, закрывать смены или обмениваться данными с внешними системами, ручной релиз становится риском. Особенно если на 1С завязаны кассы, склад, производство, маркировка, внешние API, тиражный продукт, SLA или высокая нагрузка. Проблема не в том, что сотрудники плохо работают. Проблема в том, что ручной процесс плохо масштабируется. Код может пройти проверку на тестовой базе, но сломаться на реальных данных. Небольшое изменение может затронуть смежные сценарии. А после сбоя команда тратит время на разбор: что изменили, что попало в релиз и почему это не заметили раньше. Для меня DevOps для 1С начинается не с GitLab, Jenkins или SonarQube. Он начинается с трех вопросов: 🌟 что именно изменилось; 🌟 что проверили до релиза; 🌟 кто будет поддерживать этот процесс дальше. Дальше уже появляются инструменты: контроль изменений, статический анализ, дымовые и сценарные тесты, отчеты, CI/CD-конвейер. Они нужны чтобы ошибка попадала в отчет до релиза, а не к пользователю в продуктиве. Из практики. ▫️В PROSTO:СКУД (отдельный коробочный продукт нашей компании) мы автоматизировали регрессионное тестирование и проверку стандартов разработки. Проверки стали запускаться после изменений, техлид перестал вручную ловить типовые нарушения, количество ошибок сократилось на 50%. ▫️В проекте для нашего партнера «СИТЕК» с 1С:WMS полный прогон тестов со временем стал занимать до 14 часов. Проверки распараллелили по нескольким базам, чтобы команда получала актуальный отчет к началу рабочего дня. ▫️ На проекте для крупного производителя гофротары 1С:ERP работала в производственном контуре 24/7, а техническое окно было минимальным. Планировщик Windows запускал цепочку скриптов, дымовые тесты проверяли базовую работоспособность, отчеты показывали проблемы до переноса в продуктив. За первый месяц после внедрения критических ошибок в продуктивной среде не было. 🌟 Поэтому вопрос не в том, нужен ли DevOps для 1С всем. Нет, не всем. Правильный вопрос: сколько стоит ошибка в вашем релизе. ▫️ Если ошибка может остановить продажи, склад, производство или внешний сервис, выпуск обновлений должен быть понятным инженерным процессом. 🌟 А вы как сейчас выпускаете обновления 1С: вручную или уже через автоматизированный контур?

🌟 Всем привет! 6 мая проведём вебинар «Сколько стоит бизнесу обновление 1С и как сократить расходы до 50%». Буду выступать вместе с Максимом Нифонтовым, руководителем DevOps-направления. Разберём, почему обновления 1С обходятся бизнесу дороже, чем кажется: где теряются деньги, как ручные операции влияют на сроки и бюджет релизов, качество изменений и загрузку команды. Максим покажет, какие задачи можно автоматизировать, как меняется цикл релиза и за счёт чего снижаются затраты без расширения команды. Я разберу управленческую сторону: где теряется управляемость, почему команды упираются в потолок по скорости и какие бизнес-эффекты даёт переход к DevOps-практикам. Отдельно посчитаем экономику на ROI-калькуляторе: сравним текущий процесс и автоматизированный подход, посмотрим, где появляется экономия и за какой срок она окупается. Все секреты раскрывать не буду, встретимся на вебинаре 😉 📅 6 мая, 16:00 мск 💻 Онлайн, участие бесплатное 🌟 Зарегистрироваться