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

Всем привет, меня зовут Михайлов Михаил, руководитель отдела тестирования Polymatica BI. В сегодняшней статье я расскажу, какие задачи команда решала при создании собственного ETL‑механизма, какие проектные решения оказались критичными и почему стандартных подходов к тестированию здесь недостаточно. Материал будет полезен тестировщикам, QA‑инженерам и всем, кто работает с интеграцией данных и занимается вопросами обеспечения устойчивости ETL в условиях реальной эксплуатации.

Главным драйвером развития ЭДО в России по‑прежнему остается государство. Оно последовательно повышает уровень цифровизации документооборота и переводит в электронный вид все больше процессов — от налогового администрирования и логистики до закупок и архивного хранения, что приводит к высокой динамике изменений нормативной базы. Поэтому ЭДО перестал быть «вопросом выбора» и окончательно превратился в инфраструктурную обязанность бизнеса. При этом компании все чаще сталкиваются не с нехваткой инструментов, а с системным хаосом: в законодательстве, в собственных процессах, в ИТ‑ландшафте и в хранении документов.

В этой статье мы, Юлия Ворожбицкая и Наталья Лапшина (менеджеры продуктов SL Soft Flow), посмотрим на ситуацию с ЭДО к началу 2026 года, разберем ключевые проблемы и вызовы для бизнеса, а также обсудим, как внедрение ИТ‑систем помогает снижать операционные и юридические риски, разгружать сотрудников и строить управляемый, прозрачный документооборот.

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

Всем привет, меня зовут Ирина Севрюкова, руководитель отдела бизнес-анализа Polymatica. В этой статье я на реальных задачах разберу, как современные OLAP‑системы (на примере платформы Polymatica BI) позволяют не просто строить отчеты из больших данных, а проводить живой анализ данных, находить скрытые зависимости и быстро проверять гипотезы.

Несмотря на на то, что статья описывает проблемы заказчика в АПК, аналогичные задачи встречаются во многих отраслях.

Привет, меня зовут Михаил Горбуля, product owner Polymatica BI. За два года работы над данным продуктом я смог из набора разрозненных договоренностей выстроить устойчивую систему работы, состоящую из пяти практик. Они позволяют одновременно справляться с потоком поддержки, который требует гибкости и мгновенной реакции, и сохранять предсказуемость разработки, без которой не бывает релизов и довольных заказчиков.

Если на один из пунктов ниже вы ответите да — статья будет вам полезна.

1. Вы — заказчик или внедренец: вы не можете чётко сказать клиенту, в какой версии будет выпущенная нужная ему фича или исправление, и вынуждены отвечать «скоро».

2. Вы — разработчик: вас постоянно дёргают срочными задачами, которые рушат все планы и убивают фокус.

3. Вы — поддержка: живёте в режиме тушения пожаров, а действительно важные баги тонут в очереди.

4. Вы — руководитель: у вас есть иллюзия «забитого спринта», которая разрушается в первый же день.

На Хабре тысячи статей про OCR, IDP, ML и искусственный интеллект. Все они сходятся в одном: «качественная разметка данных — ключ к точности модели». Но что это значит на практике?

Меня зовут Снежана Игнатенко, я руковожу отделом разметки данных в SL Soft AI. Каждый день моя команда работает с самыми разными документами: печатными, рукописными, строгими формами, свободными текстами, сканами и фотографиями, в которых встречаются печати, подписи, штампы, затертые области, перекосы и артефакты. Наша задача — создавать качественный, точный и контекстно корректный набор размеченных данных, который служит фундаментом для всех интеллектуальных систем класса IDP.

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

Нормативно‑справочная информация (НСИ) — это язык предприятий. Через наименования, коды и атрибуты описываются материалы, оборудование, комплектующие, инструменты — все, что используется в производстве, логистике, закупках, эксплуатации и ремонте. Именно НСИ обеспечивает согласованность ERP, MDM, BI и десятков других систем.

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

Меня зовут Дмитрий Романов, управляющий директор «Преферентум» (кластер SL Soft AI). В этой статье поделюсь, почему именно справочники материально‑технических ресурсов (МТР) превращаются в точку боли, почему «ручные чистки» и классические MDM‑подходы не помогают, и какие технологические решения действительно работают.

Inbox Zero часто воспринимается как лайфхак из мира продуктивности. На самом деле это инженерный подход к управлению входящими задачами, где почта — не хранилище писем, а поток событий, который нужно правильно маршрутизировать.

Все привет, меня зовут Михаил Горбуля, product owner Polymatica BI. Мне пишут коллеги из проектирования и производства, внедренцы, приходят автоматические уведомления из таск‑трекера — не менее 50–80 писем ежедневно. Честно: проблема не в письмах как таковых. Проблема в состоянии неопределённости, которое они создают. Каждое письмо — это чей‑то запрос, висящий на мне, незавершённая задача, источник контекста, который вам нужно удерживать в голове.

В сегодняшней статье о там, как перейти на Inbox Zero и превратить почту из хаоса в управляемый процесс.

Каждый день на Хабре появляются статьи и эксперименты с RAG, fine‑tuning и векторными базами. Это интересные опыты, но все они упираются в один и тот же потолок — низкую точность, отсутствие диалога с пользователем, сложность интеграции и риск утечек данных из‑за использования с облачными LLM‑моделями.

Меня зовут Кристина Бахмаер, продакт‑менеджер SL Soft AI. В сегодняшней статье расскажу, как мы побороли типичные «болячки», создавая свой промышленный продукт SL Soft AI Search. Собрали не только свой опыт, но и ТОП-5 подводных камней, которые жду при внедрении интеллектуального поиска. А еще — список вопросов к поставщикам, он пригодится компаниям при выборе решения.

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

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

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

Меня зовут Юлия Ворожбицкая, я руковожу группой сопровождения и реализации проектов в команде «Цитрос». Мы работаем в высококонкурентном сегменте ECM, и каждый день сталкиваемся с задачами, где недостаточно «делать хорошо» — нужно создавать продукт, который востребован рынком. В этой статье я поделюсь нашим подходом к оценке емкости рынка и проведению CustDev — с методиками подсчета и личными выводами. Материал будет полезен Product Owner в B2B IT.

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

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

Вы думаете, что развернуть Kubernetes без интернета — это просто kubeadm init плюс пара манифестов? Посмотрим, как скрипты решают проблемы, о которых вы даже не задумывались. Спойлер: здесь есть чему удивиться.

Всем пример, меня зовут Даниил Миронюк, DevOps в команде Polymatica EPM. Сегодняшняя статья для тех, кто считает, что оффлайн‑установка Kubernetes — это скучно.

Оценка моделей нейронных сетей играет ключевую роль в выборе наилучшего алгоритма для конкретной задачи. Выбор метрики должен соответствовать целям, поскольку очевидного показателя «Точность» (accuracy) обычно недостаточно. Критерии помогают определить эффективность и корректно сравнить различные подходы.

Меня зовут Александр Агеев, я ML‑разработчик в SL Soft AI. В этой статье я расскажу про методы оценки трех задач: классификации, обнаружения объектов (детекции), сегментации.

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

Со старта нашего проекта Polymatica EPM (бизнес‑платформа для автоматизации процессов стратегического планирования и бюджетирования) мы решили: код должен покрываться тестами. Проект построен на стеке FastAPI + Poetry + Pytest. Из‑за особенностей проекта тесты, в основном, функциональные. Все шло хорошо, команда росла, тесты писались, но запускались только на локальной машине перед коммитами. Наступил момент, когда нужно было внедрить автоматический прогон тестов на этапе Merge Request (MR).
На тот момент у нас был собственный GitLab и настроенный CI/CD, но ресурсы DevOps были ограничены. Поэтому задачу пришлось решать силами разработчиков. Меня зовут Дмитрий Богданов, я старший бэкенд‑разработчик, и в этой статье расскажу, как мы оптимизировали запуск тестов, с какими проблемами столкнулись и почему выбрали именно базовый образ для CI/CD.

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

Поскольку мы разрабатываем собственную Low‑Code BPM платформу и рассказываем клиентам, что около 70% бизнес‑задач решается No‑Code инструментами, 20–25% — Low‑Code, и лишь 5–10% требуют написания кода, то я решила попробовать самостоятельно собрать «Оценку качества» на нашей же платформе, не прибегая к помощи разработчиков. Меня зовут Ирина Головина, я руководитель группы технической поддержки Citeck. Сегодня расскажу, как я это делала, что у меня получилось и не получилось. Материал будет полезен всем, кто интересуется возможностями No‑Code платформ или ищет способ автоматизировать свои процессы.

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

Меня зовут Михайлов Михаил, я работаю руководителем отдела тестирования в команде Polymatica BI. Недавно мне пришлось привести в порядок регрессионное тестирование, что позволило сделать его компактным и эффективным. Оказалось, что несколько простых действий кратно сократят время, необходимое на приведение в порядок регрессионного прогона. В этой статье разберем пять ключевых шагов.

Автоматизация клиентской поддержки с помощью больших языковых моделей — перспективное направление, но без доработки они не всегда способны дать точные и релевантные ответы. Меня зовут Михаил Крюков, технический директор платформы Robovoice (SL Soft), и в этой статье я расскажу, как усиливать LLM с помощью RAG.

Используя реальный кейс, я расскажу о выборе LLM (сравнивали GigaChat MAX, GPT-4o, LLaMA 3.1 70B, YandexGPT 4 и Gemma 2 9b) и RAG (RagFlow, Dify и LangChain Custom + Vector database). Разберу ключевые сложности при интеграции — подготовку датасетов, настройку RAG, борьбу с «галлюцинациями» моделей, затрону вопросы экономики проекта и способов удешевления стоимости диалога. Статья будет полезна разработчикам и бизнесу, планирующим автоматизировать первую линию поддержки с помощью ИИ. Инфраструктура и железо в материале не освещены.

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

Всем привет! Меня зовут Мирза Абдулмеджидов, я руководитель проектов ROBIN компании SL Soft. Сегодня расскажу про интеллектуальную автоматизацию и поделюсь своим опытом внедрения платформы ROBIN для трансформации бухгалтерских процессов на примере одного проекта, реализованного для крупного продуктового ритейлера.

Всем привет! Это завершающая статья в серии по эволюции архитектур нейронных сетей в компьютерном зрении. Она будет полезна тем, кто только погружается в сферу и пробует систематизировать свои знания, поэтому я осознанно не погружаю читателей в глубокие расчеты и вычисления. Посмотрим на R-CNN, Fast R-CNN, Faster R-CNN, Mask R-CNN, SSD, RetinaNet, EfficientDet, YOLO.

Всем привет. Сегодняшний материал — продолжение цикла статей про ключевые события в развитии архитектур нейросетей. В прошлый раз я рассказал о классификации изображений. Сегодня речь пойдет про сегментацию. Статья охватывает FCN, U‑Net, SegNet, DeepLab, PSPNet, Mask R‑CMM и HRNet.