ERP-системы *

Всем привет! Меня зовут Дмитрий Воронцов и я хочу кратко рассказать о своей новой low-code платформе NodaLogic, построении решений с помощью узлов(нодов) и свое видение будущего. Я автор мобильного фреймворка SimpleUI которому скоро исполняется 7 лет и в этой статье будут некоторые пересечения с ним – я хочу рассказать, зачем я сделал отдельную архитектуру, а не стал продолжать SimpleUI.

7 лет назад, когда я начинал Simple я хотел сделать LowCode фреймворк на котором разработчик может быстро разработать мобильное решение, как дополнение к своей учетной системе. Тогда еще не было LLM.  Но ориентиры во все времена одинаковые – чтобы решение было легко поддерживать и развивать, масштабировать – оно должно быть простым, компактным, читаемым. Объем кода может быть и не точный показатель, но когда на один и тот же функционал требуется в 10 (а то и в 100) раз больше/меньше строчек это сигнал. Этот ориентир у меня остался и для новой системы, как важнейший. Ведь не важно, что теперь разработчику не нужно писать, но ему нужно «читать решение», анализировать что ему нагенерила  нейросеть, чтобы направлять ее. И понятно, что можно взять любой стек и язык программирования и сгенерировать решение на нем, но будет ли при этом достигнут тот уровень простоты и читаемости как в LowCode фреймворке?

Платформа позволяет делать клиент-серверные решения с мобильными самостоятельными оффлайн/онлайн фронтами-приложениями (Android) веб-клиентами и серверами. Естественно, единая семантика на веб и на мобильную платформу. Также можно делать и чисто мобильные фронты, мобильные приложения без сервера.  

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

Доступен ряд научно-популярных работ, описывающих различные подходы к построению ИТ-архитектуры, которые обобщены в терминах корпоративная архитектура и архитектура предприятия. Методологии построения корпоративной архитектуры представлены такими подходами как: FEAF, DoDAF [1], а также широко известная и наиболее популярная TOGAF [2]. Несмотря на кажущееся обилие стратегий к формированию ИТ-архитектуры, по большому счету, они апеллируют едиными сущностями, изначально предложенными в модели Захмана.

Не взирая на то, что модель Захмана предоставляет широкий теоретический аппарат, который лежит в основе понимания любой архитектуры предприятия, ее использование как в контексте разработки, так и непосредственно в ходе имплементации корпоративного ПО, часто остается незамеченным [3]. Однако применение именно данной модели делает методологии внедрения ИС такими, какие они есть сейчас: структурированными и гибкими, генерализованными и специализированными, а также прозрачными и эффективными.

Цель текущей работы состоит в анализе модели Захмана и ее применимости в проектах реализации корпоративных информационных систем. Достижение сформулированной цели потребует решения следующих задач:

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

Меня зовут Герман, я 8 лет занимаюсь B2B‑продуктами и сложными производственными системами.

В последнее время слово «инженер» мало употребляется в IT-индустрии. Есть программист, разработчик ПО, техлид, архитектор. Но одно только знание технологий не дает гарантии, что человек хорошо выполнит бизнес-задачу. Инженерное мышление — это особый дар, который позволяет решить сложную, возможно, даже ранее не решенную проблему с использованием существующих технологий.     

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

Рынок медицинских услуг в России продолжает расти как на дрожжах. По данным аналитиков, в 2025-2026 годах мы наблюдаем устойчивый рост частной медицины на 12-15% ежегодно. Вслед за этим бумом неизбежно следует лавинообразный рост предложений IT-услуг. Кажется, что для каждой, даже самой узкой задачи, существует отдельное SaaS-решение: агрегаторы записи, ORM-системы для сбора отзывов, CRM для колл-центра, ERP для склада, МИС для врачей... Список можно продолжать бесконечно.

Добавьте сюда ужесточение контроля со стороны государства (ЕГИСЗ, РЭМД, маркировка, ЭДО, новые приказы Минздрава), и вы получите идеальный шторм.

Я занимаюсь автоматизацией бизнесов и IT-консалтингом в медицине уже много лет. Недавно мне довелось сравнить, как выглядит IT-ландшафт стоматологии в 2018 году и многопрофильной клиники в 2026-м. И знаете что? Картина, за редким исключением, абсолютно идентична. Разве что зоопарк стал больше, а сотрудники в регистратуре матерятся громче.

В этой статье я хочу разобрать, почему попытка собрать инфраструктуру из «лучших» точечных решений превращается в ад для бизнеса, почему это дорого, неэффективно, и почему единственным спасением в 2026 году становится путь «цельного решения» — экосистемного подхода.

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

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

Чтобы находить такие ошибки, была создана экспертная система с использованием искусственного интеллекта. Она анализирует настройки ERP и выявляет потенциальные конфликты.

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

Российский бизнес переживает эпоху «Великого перехода». Санкционное давление и уход западных вендоров заставили компании в спешке мигрировать на отечественное ПО. Но гонка за новыми платформами обнажила старую как мир проблему: наши системы полны «мусора».

На многочисленных проектах по миграции с SAP и западных CRM на российские решения наблюдается одна и та же картина: бизнес ждет «магии» от новой системы, а получает перенос хаоса. Аналитики и ИТ-специалисты приходят к выводу: битва за качество данных проигрывается не из-за отсутствия талантливых разработчиков, а потому что бизнес-анализ как дисциплина в России до сих пор не воспринимает данные как стратегический актив.

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

Перед вами человеческий лонгрид без капельки участия ИИ. Неприлизанный, с ошибками, нестыковками и потерей нити изложения. Ещё и про 1С.

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

Подход холиварный, не всем понравится, не всем подойдёт. Но проектов, выполненных по этому концепту, становится всё больше (да их и было много). А сейчас – становится всё больше, по совокупности причин.

Ну всё, переходим к делу. Итак, у нас УПП, и нам надо перейти на ЕРП – побыстрее и подешевле.

В первой публикации «Автоматический импорт банковских выписок в SAP с использованием FEB_FILE_HANDLING» был рассмотрен базовый сценарий применения FEB_FILE_HANDLING для автоматического импорта банковских выписок в XML формате, получаемых через сервисы коммуникации с банками. Именно под такой сценарий FEB_FILE_HANDLING изначально спроектирована.

В данной публикации показывается, как использовать функциональные возможности FEB_FILE_HANDLING для импорта текстовых форматов, специфических для стран, в том числе получаемых из систем «Банк-Клиент» через выгрузку файлов. Под этими форматами имеются в виду форматы выписок странового уровня: формат обмена «Клиент -> 1С» для России и Казахстана (с некоторыми различиями) и типы запросов 400 и 600 национальной системы электронных платежей Республики Беларусь, которые, в отличие от международных форматов MT94x, достаточно информационны и не зависят от особенностей заполнения конкретными банками.

Эти свойства формата «Клиент -> 1С» (для России и Казахстана) и типов запросов 400 и 600 (для Беларуси) делает переход на XML‑форматы и использование сервисов коммуникации с банковскими системами не столь обязательным решением и «горящей» задачей для улучшения процессов обработки банковских выписок, например, повышения оперативности получения информации об остатках и операциях на банковских счетах и ускорения разнесения входящих платежей.

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

В моей практике решения по импорту банковских выписок в SAP часто сталкиваются со следующими проблемами: сервисы коммуникации с банками разрабатываются «под каждый банк» при одновременном сохранении унаследованных сценариев загрузки файлов из систем «Банк‑клиент», загружаемые данные выписок не используются для управления остатками денежных средств (денежной позицией), а разнесение входящих платежей выполняется уже после обработки выписки. Всё это обесценивает переход на новый технологический уровень обмена данными через сервисы коммуникации с банками.

Данная публикация открывает серию материалов, посвященных автоматическому импорту банковских выписок в SAP с использованием функциональности FEB_FILE_HANDLING (New Bank Statement Import). В центре внимания — как выстроить в системе единый сквозной процесс обработки выписок: от получения файлов из банков до автоматического разнесения платежей с оперативным предоставлением информации для управления остатками денежных средств (денежной позиции).

Данные материалы будут полезны SAP‑консультантам и архитекторам, работающим с модулями FI и Cash Management, а также специалистам казначейства и финансовых служб по банковским выпискам, разнесению платежей и управлению ликвидностью.

Сегодня уже можно говорить о том, что налоговый мониторинг перестал быть экспериментальной моделью. По данным ФНС России, с 1 января 2026 года в этом режиме уже работают 870 компаний из более чем 20 отраслей экономики. Это подтверждает, что мониторинг становится устойчивым форматом взаимодействия с налоговой службой для крупного бизнеса. А с учетом текущего вектора цифровой трансформации налогового администрирования можно предположить, что в ближайшее время количество участников режима будет только увеличиваться.

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

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

Привет! Меня зовут Юрий Силантьев, я руководитель практики «ERP и финансы» в К2Тех, отвечаю за проекты внедрения 1С.

Мы занимаемся крупными внедрениями уже 15 лет. В нашей практике — проекты со сложной архитектурой, высокой нагрузкой и широким функциональным объемом. В прошлом году, например, мы рассказывали, как за семь месяцев перевели крупное химическое предприятие ПАО «КуйбышевАзот» с Oracle на 1С:ERP. И в таких проектах быстро становится понятно, что успех зависит не столько от количества разработчиков, сколько от методологии. Если этапы не структурированы, роли не определены, а результаты не отделимы друг от друга, даже сильная команда будет постоянно «догонять» сам проект.

Это первая статья из цикла о нашем подходе к крупным внедрениям 1С. Берите на вооружение — наша методологию сэкономила нам сотни часов на реальных проектах.

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

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

Детективный контроль позволяет выявлять подобные случае по мере возникновения неблагоприятных событий. Наоборот, предиктивный контроль пресекает подобные исходы на корню. Именно на последних мы и остановим внимание в данной статье. Применительно к программному обеспечению подобный вид проверок тесно связан с термином SOD (Segregation of Duties).

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

За последние два десятилетия архитектура ERP-систем эволюционировала от монолитных приложений к сервисно-ориентированным решениям и микросервисным моделям. В настоящее время развитие искусственного интеллекта, технологий представления знаний и автономных агентных систем инициирует новый этап трансформации ERP-архитектуры.

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

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

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

Именно такой формат электронного онлайн-взаимодействия то будущее, которое готовит нам ФНС. Техническую и правовую базу АУСН я уже разбирал в статье «АУСН: налоговый оазис или цифровой концлагерь для бизнеса?». А в этой статье разберу инфраструктуру налогового мониторинга. Что этот режим представляет собой на практике, и где чаще всего «ломается» интеграция.

Привет, меня зовут Дмитрий Черняев, я руководитель отдела аналитики в компании «Эволюция». Как партнеры Битрикс24 мы помогаем компаниям внедрять CRM, автоматизировать бизнес-процессы и с 2022 года, создаем решения для автоматизации.

В этой статье расскажу о том, как с помощью кастомных и типовых решений в Битрикс24 можно автоматизировать HR-департамент для компании с более чем 250 сотрудников. 

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

Мы собрали разрозненные HR-сценарии в едином контуре, создали раздел «HR-департамент» — отдельное цифровое рабочее место, в котором реализованы 4 инструмента:

Привет, Хабр! Меня зовут Евгений и я ведущий разработчик отдела SAP разработки.

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

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

Интересно? Читайте статью под катом.

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

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

В этой статье разберём:
• какие типы запросов в поддержку можно убрать дизайном;
• как находить точки, где продукт «ломается»;
• какие UX-решения реально снижают нагрузку на поддержку;
• с чего начать, если ресурсы ограничены.

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

В обоих случаях потребовалось грамотное и эффективное управление ИТ-проектами. В информационном пространстве доступно множество литературных источников по данной тематике [1-3]. Но для них всех фактически пред источником является свод знаний по управлению проектами, наиболее полно освещающий вопросы и проблематику проектного управления.

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

Когда речь заходит о выборе ERP-платформы и системного интегратора, почти всегда звучит слово «конкурс». Формально процесс выглядит структурированным: несколько поставщиков, демо, презентации, референсы, коммерческие предложения.

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

Не потому, что компании «не умеют выбирать».
А потому, что процесс выбора нередко начинается с инструмента, а не с методологии.

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

Недавно я обсуждал проект с партнёром, который предложил:
«Давайте сделаем серию демо и на основе впечатления выберем».

В разговоре выяснилось, что на старте отсутствовали: