ERP-системы *

И так, у нас ключевая цель - выпуск заказов вовремя.

Невозможно своевременно выпускать заказы в хаосе. Только случайно. Для начала нужен просто порядок. На основе порядка можно построить качественное управление. Результатом качественного управления как раз и будет своевременный выпуск заказов. А там глядишь и запасы даже станут пониже.

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

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

Существует множество различных сводов знаний, применимых к комплексным программным системам: PMBoK для управления проектами, BABoK для бизнес-анализа, BPM CBOK для управления бизнес-процессам, EABoK для управления кооперативной архитектурой, а также SWEBoK по программной инженерии. Практически во всех сводах знаний делается акцент именно на внедрение и смежные активности, забывая про то, что имплементация программного продукта завершается его передачей в поддержку. Одним из немногих литературных источников по данной тематике является ITIL [2], описывающий четыре домена знаний, позволяющих осуществлять сопровождение решения после его реализации.

В контексте BABoK и расчета бизнес-кейса, выполняемого при предпроектном обследовании, довольно часто рассчитывается показатель TCO (Total Cost of Ownership, совокупная стоимость владения), демонстрирующий постоянные и переменные затраты, которые понесет компания при внедрении программного обеспечения. Одной из постоянных статей затрат является сумма поддержки и развития информационной системы. Таким образом, знание особенностей выполнения этапа поддержки и развития программной системы позволяет рационально планировать затраты и разумно ограничивать содержание проекта имплементации.

Динамические списки использование в разработке редактирования документов выпуска продукции в ERP (часть2)

В статье мы, команда Внедренческого центра «Раздолье», обобщили опыт внедрения 1С:ERP на двух процессных производствах из разных отраслей: пищевой и химической. На их примере руководители проектов постарались описать схему комплексного подхода к автоматизации на подобных предприятиях с охватом важных этапов — от планирования до точного выполнения сменных заданий и обеспечения материалами. 

Для ускорения работы складов мы использовали автоматизированные рабочие места с терминалами сбора данных (ТСД). Предусмотрено автоматическое формирование отчетов и интеграции с системой «Честный знак» для маркировки продукции. По завершении проектов автоматизированным компаниям удалось полностью исключить работу диспетчеров в Excel и с документами на бумажных носителях. Это привело к снижению риска ошибок, более эффективному управлению запасами и росту производительности. Хотя эта статья не является пошаговым учебным инструктажем, все же многим будет полезна.

Когда тебе кажется, что ты уже видел всё в мире корпоративных внедрений 1С, приходит крупная лизинговая компания и говорит: «А давайте сделаем ERP на базе 1С:Бухгалтерия 3.0, но так, чтобы всё было заточено под наши уникальные процессы, ФСБУ-25, МСФО, сложные лизинговые схемы, кредиты, страхование и прочие радости жизни». К этому вызову добавляются сложная релизная политика, требование бесшовной интеграции с действующими смежными системами и жёсткие стандарты качества, которые невозможно было обеспечить без полноценного покрытия автотестами. И вот тут начинается настоящее веселье.

Привет, меня зовут Гродская Ольга, я технический менеджер проекта, и мы в К2Тех за два года переработали типовую 1С:Бухгалтерию 3.0 и превратили её в единую ERP-систему для крупной лизинговой компании. В проекте: 250 доработок, 70 автоматизированных бизнес-процессов, 10 интеграционных потоков, переход на инвестиционную фазу в МСФО, сквозная автоматизация казначейства, лизингового портфеля, кредитов, страхования и др. Результат — поэтапный отказ от старых систем, рост точности отчётности и сокращение трудозатрат большинства служб.

Как аналитикам, продуктовым менеджерам и разработчикам избежать хаоса при переходе на новую ставку НДС (22%) с 1 января 2026 года.

С 1 января 2026 года нас ждет ключевое налоговое изменение: ставка НДС повышается с 20% до 22%. Законопроект уже внесен в Госдуму, и компаниям пора готовиться. Для IT-специалистов, чьи системы так или иначе работают с финансами, это не просто новость, а полноценный проект с жестким дедлайном.

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

Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:

Часть 1. «Цифровая пена» всё сильнее затягивает

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

С другой стороны, начиная с 30-х годов прошлого века, изменения в производственных системах, развитие компьютеров и аналитики, а также миллиарды долларов, вброшенные в консалтинг, породили вокруг бесконечное количество информации, моделей, систем, программных продуктов. Часто начинает казаться, что современные руководители, просто тонут в этой «цифровой пене», не всегда понимая, как соединить «теплое» с «белым», например, внедрение ERP, желание повысить скорость выпуска и сделать завод более рентабельным, а также развивать «мягкие навыки» (soft skills). И вокруг армия консультантов: «Вам нужно внедрить Бережливое производство», «У вас нет нормального управленческого учета», «Вам срочно нужно ERP», «Зачем тратить большие бюджеты, давайте всё сделаем в экселе» и так далее

В России ситуация осложнилась тем, что в 90-е годы была уничтожена советская научная школа управления производством и в течение 20 лет мы утратили собственные наработки и системно не взяли чужие, за исключением лидеров отраслей. В итоге сегодня видим засилье литературы из серии «Богатый папа — бедный папа» или «Коучинг — наше всё», а также разные курсы МВА, где руководителей и собственников бизнеса учат в основном лучшим практикам финтеха и ИТ.

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

Цель этой статьи — «подумать письмом» о том, что такое SAP UI5, каковы его особенности, преимущества и недостатки. Так же, рамках статьи попытаемся ответить на вопрос, стоит ли его использовать, а если стоит то, когда и зачем.

Точнее такой она была изначально. А на самом деле, преследуя исключительно личные корыстные интересы, я решил провести небольшое исследование, на обширную и трудно формулируемую тему «а не посмотреть ли мне в сторону web разработки на SAP UI5».

Основная целевая аудитория — это в первую очередь SAP ABAP разработчики и сочувствующие, которых интересуют похожие вопросы, а во вторую и последнюю — все остальные любопытствующие ИТ‑шники:)

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

Продолжаю делиться кейсами организаций, которые развивают свои решения в открытом формате и/или осуществляют вклад в общемировые open source-проекты.

На этот раз опытом поделился Михаил Скворцов, основатель специализированной компании-интегратора по внедрению платформы Odoo в России и сопредседатель Rudoo, российского консорциума разработчиков ERP-решений при ИСП РАН.

Давайте честно: интегрированное бизнес-планирование редко ассоциируется с чем-то увлекательным. Но если оглянуться назад, можно проследить путь развития — от учета пива и зерна у шумеров до сложных систем, которые сегодня управляют целыми корпорациями в условиях постоянной неопределённости.
Меня зовут Глеб Канин, я продуктовый директор «Оптимакрос», и сегодня мы погрузимся в историю, которая началась с шумеров и египтян, а развилось в методолгию IBP.

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

Заказчик ведет учет в 1С: ERP, принимает от давальца материалы в переработку, производит одинаковую продукцию для себя и для давальца в одних и тех же подразделениях. Учет по назначениям не ведет.

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

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

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

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

Привет, Хабр! Если вы читали мою прошлую статью Сапёр в эпоху LLM: Повайбкодим на ABAP , то уже знаете, что попытка «повайбкодить» на ABAP с помощью LLM — затея, мягко говоря, неоднозначная. Модели «галлюцинируют», выдумывают несуществующие BAPI и таблицы, и в целом чувствуют себя в закрытой экосистеме SAP не очень уверенно. Как говорится, вайбкодинг не задался.
В комментариях к статье прозвучала здравая мысль: будь у модели больше контекста, она бы справилась лучше.Раз появились такие идеи — значит, пора воплощать их в жизнь. На этот раз — новая серия экспериментов: в этот раз займемся переводом вопросов по SAP из обычного языка в SQL-запросы, плюс построим агента с необходимыми для этого инструментами.

Стратегия является ключевым документом, описывающим предполагаемый подход к решению той или иной задачи. В области внедрения ERP-систем выделяют такие концепции доставки содержания, как: анализа, проектирование, реализация, ролей и полномочий, миграции, обучения, тестирования, технической подготовки системы, бизнес-катовера, изменений и поддержки. Основой использования стратегий в проектах имплементации ERP-систем служит теория корпоративных информационных систем, предложенная в работе [1]. Анализ литературных источников в области корпоративных информационных систем и стратегий доставки включает множество работ [2-14], однако в них лишь косвенно указана первопричина формирования концепции, что, следовательно, делает выбор того или иного способа недоказательным.

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

Современные системы состоят из множества различных сервисов и одной из основных задач является обеспечение обмена данными между компонентами системы. Для обеспечения этой функциональности используются шины данных (Enterprise Service Bus, ESB), интегрирующие различные приложения и системы в единую информационную среду. Она выступает в роли «посредника», минимизируя прямые связи между отдельными системами и обеспечивая гибкость взаимодействия. Таким образом, основная цель внедрения ESB — оптимизировать и унифицировать взаимодействие внутри информационного ландшафта предприятия.

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

Вопрос замены ERP актуален для многих компаний, так как требуется перейти на российское ПО или модернизировать технологии. На первый взгляд, задача может выглядеть неподъемной — масштаб проекта огромен, бизнес должен работать непрерывно, сроки и бюджет никто не отменял. Успех или провал во многом зависит от правильного выбора методологии замены ERP. 

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

Если спросить клиентов, они назовут Виктора гением. Настоящим, недооценённым, всё как положено. Если спросить коллег, Виктора назовут везучей бестолочью, без надлежащего образования, знаний, навыков и вообще. Если спросить начальство и продавцов, то Виктор окажется затычкой последней инстанции — к нему обращаются в последнюю очередь, когда никто другой не справился. Потому что на работе Виктора не получается заработать.

Виктор — программист 1С, который, помимо прочего, увлекается решением задач производительности. Всё, что начинается с «у нас 1С тормозит» или «1С вылетает» — любимый десерт Виктора. Судя по тому, что он мужчина весьма худой, нетрудно догадаться, что десерт ему достаётся редко. Почему?

Потому что, положа руку на сердце, Виктор очень плохо разбирается в деталях производительности. Он понятия не имеет, что такое индексы и индексирование. Он никогда в жизни не видел план запроса. Не знает ни одной модели процессора, памяти, чем отличается DDR2 от DDR3, как считается APDEX, какой должна быть скорость передачи данных между СУБД и серверной частью приложения и т. д. Ну, вы поняли. Любой мало‑мальски подготовленный специалист по производительности заткнёт Виктора за резинку трусов.

Но Виктор решает задачи производительности. Решает! Быстро и дёшево. Крайне редко рекомендует потратить денег на апгрейд железа или ПО (раз 5 за 20 лет практики). Максимальная сумма, которую Виктор предъявил клиенту за решённую задачу, примерно равна минимальной сумме, которую называют сертифицированные эксперты — а они называют сумму за предварительный анализ, который проблему только выявит (скорее всего).

Правда ведь, Виктор — исключительный? Нет, конечно. Это я его так назвал. Потому что Виктор знает один метод решения проблем производительности — метод исключения.

Сегодня модно говорить «мы data driven», но на деле это часто означает лишь наличие управленческой отчетности раз в месяц. Давайте разберёмся, что стоит за этим термином, почему без системы показателей он не работает и как встроить подход в бизнес. Термин data driven буквально означает "основанный на данных" и описывает подход к принятию решений, планированию и управлению, в котором главным источником аргументов являются факты, полученные из данных, а не только интуиция, опыт или авторитетное мнение.

Для нашей заводской ТЭЦ на ЕВРАЗ ЗСМК в Новокузнецке жизненно важно поступление из пруда воды определенной температуры. Она нужна для охлаждения конденсатора паровой турбины — одного из важнейших элементов данного агрегата. С помощью турбины осуществляется выработка электроэнергии. Для эффективной работы ТЭЦ одного водоема‑охладителя мало, нужен второй, но его нет: в дефицитные 90-е обустроить еще один пруд не было возможности. Как эту проблему помогает решать разработанная нами модель‑подсказчик, расскажу я, дата‑сайентист ЕВРАЗа Александр Варкентин.