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-е обустроить еще один пруд не было возможности. Как эту проблему помогает решать разработанная нами модель‑подсказчик, расскажу я, дата‑сайентист ЕВРАЗа Александр Варкентин.

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

Был недавно на экскурсии на одном производстве. Где начальник производства с гордостью мне рассказывал, что у него есть ПО, в котором он может оформить сменное задание. «Вот видите, тут я могу выбрать из справочника деталь, вот тут РЦ и участок, все замечательно». И поэтому он искренне не понимает, зачем что-то менять. Я задал вопрос: «а по какой методологии происходит выдача сменных заданий»?
Вопрос поставил в тупик. Ни по какой. Как мне кажется правильным, так я и выдаю сменные задания.
А ведь в реальности такой проблемы, как «оформить сменное задание» попросту не существует. Нет такой проблемы!

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

Управление производством — это ежедневная тактическая система принятия решений. Это не система выдачи заданий, это система принятия решений, включающая в себя инструмент для выдачи заданий"
Что именно я должен запустить в производство сегодня и почему?
На какую деталь и на какой участок я должен выдать сменное задание, чтобы максимально приблизить выход продукции?
Что именно я должен сегодня заказать поставщику, чтобы приблизить выход продукции, а не просто потратить деньги впустую?
Куда сейчас должен поехать карщик и что и куда перевезти?

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

Не тот, кем кажется

Сам вопрос «Где уместно применять ИИ?» возникает потому, что люди ожидают от искусственного интеллекта именно интеллекта. Люди его очеловечивают, наделяют антропоморфными качествами. На самом же деле искусственный интеллект не умеет рассуждать, самостоятельно в чем-то разбираться, проявлять инициативу. Современный генеративный ИИ лишь предугадывает наиболее вероятные следующие события (слово, ноту, пиксель), а это — чисто математический процесс.

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

Представьте локомотив. Тысячи деталей, сотни узлов, десятки систем. Каждый элемент должен быть учтен, его история обслуживания записана, характеристики доступны. Казалось бы, простая задача — наклеить метку и сканировать. Но что если эта метка должна выдержать температуру эксплуатации до 200°C, удары (при транспортировки и ремонте аппарата), вибрацию на скорости 120 км/ч, облитие маслом и дизелем? А еще быть читаемой через 10 лет эксплуатации?

Казалось бы, чего может быть сложного: спроектировали, разработали, протестировали программную информационную систему и все, осталось только ее запустить в продуктивный режим эксплуатации, что обычно неоднократно репетируется. Но так ли это просто? Ответ положительный, если внедряется ERP-система на подразделении с небольшим числом конечных пользователей, уровень владения компьютером у сотрудников плюс-минус нормальный, все участники проекта сосредоточены в одной локации и, наконец, число специфичных требований к системе небольшое. Сейчас мы рассмотрели типовой проект внедрения корпоративной системы (далее – КИС).

Однако, бывают и более масштабные проекты, требующие более тщательного анализа и выбора вариантов запуска ERP-решения. Например, компания имеет распределенную географию работы, число конечных пользователей велико, часть из которых и компьютером то не пользовались, плюс ожидается, что КИС будет сильно кастомизирована под потребности заказчика. Здесь не получится взять и сразу запустить новое ИТ-решение на всех локациях и для всех пользователей. Хотя, нет, получится, но риск того, что все закончится провалом, достаточно велик. Как быть в этом случае? Необходима более разумная и согласованная со всеми стратегия запуска ERP-системы. Подобную стратегию называют по-разному: где-то концепция имплементации, в других источниках – стратегия развертывания, мы же будем называть ее стратегией внедрения.

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

🔥 Серия: Чем болен средний бизнес? Диагностика и лечение управленческих болезней. Статья 4 Миллионы на ветер: как не купить IT-систему, которая вас разорит

[💼 Бизнес-модели*] [📊 Управление проектами*] [💻 IT-инфраструктура*] [📈 Аналитика*]

❓ Почему 9 из 10 IT-проектов превращаются в «черную дыру» для денег? И как попасть в те 10%, у которых все получилось?

😩 Вы устали от обещаний интеграторов и бесконечных счетов за «доработки». Вы видите, как дорогая ERP-система превращается в дорогую иконку на рабочем столе, которой никто не пользуется. Знакомо?

⚠️ Проблема не в том, что вы выбрали «не ту» систему. Проблема в том, что вы играете в игру с заведомо проигрышными правилами.

📉 В этой статье мы разбираем всю цепочку провала - от выбора системы до саботажа сотрудников:

🚫 «Прокрустово ложе» для бизнеса: Как коробочные решения ломают ваши уникальные процессы.
💸 Скрытые затраты: Почему реальная стоимость проекта в 5 раз выше той, что вам показывают в смете.
🧠 Когнитивная ловушка: Почему сложные схемы BPMN и архитектура «1С» обречены на провал на уровне человеческого мозга.

🚀 Но главное - мы поговорим о выходе. В статье я покажу альтернативный путь, основанный не на выборе «модного» софта, а на построении системы, понятной всем — от директора до кладовщика. Узнайте, как язык ДРАКОН и архитектура на базе метамодели меняют правила игры и позволяют, наконец, получить от IT то, чего вы ждали — порядок и управляемость.

🛠️ Хватит латать дыры. Пора строить мосты. Инструкция - внутри.

В комментарии к прошлому посту был вопрос о том, чем принципиально отличается ТОС от других систем менеджмента.

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

Но ключевое отличие ТОС заключается в том, что это математически выверенная концепция управления. Это математика поведения и математика принятия решений.

Более того, концепция ТОС говорит о том, что нет смысла заниматься улучшениями на неузком месте. Это просто бессмысленно, ибо неузкое место ничего не определяет с точки зрения эффективности работы всего предприятия. Вы потратите время на внедрения какого-нибудь кайдзена, но эффекта никакого не получите. Потому что производительность (способность вашей компании зарабатывать деньги) определяется только узким местом. Это значит, что ваши улучшения на неузком месте - выброс времени и денег. А ведь это все требует довольно приличных усилий.

Основа ТОС в том, что производительность всего вашего предприятия в реальности равна производительности вашего самого узкого места. И ваша задача - найти это место (не всегда просто), максимизировать работоспособность узкого места, подчинить этому месту все остальные рабочие места, после чего уже заняться мероприятиями по расширению производительности узкого места.

Вам не нужно проводить совещания, на которых вы будете заряжать сотрудников в стиле “давайте будем производить хорошо, давайте производить быстро”. А как это сделать - пусть каждый сам себе придумает. Если вы все сделаете правильно, вашим рядовым сотрудникам даже не нужно будет знать, что такое ТОС и как это работает. Им нужно просто выполнять то, что написано на экране монитора ровно в той последовательности, в которой это написано.

Привет, я Денис Сумелев, генеральный директор компании ООО «ИНТЕКЕЙ», ИТ  интегратора и разработчика системы управления складом - INTEKEY WMS. Последние 15 лет занимаюсь консалтингом и автоматизацией складов — от небольших распределительных центров до крупных логистических комплексов.

Хочу поговорить с вами об автоматизации склада с архитектурной точки зрения. Почему одни решения работают годами без сбоев, а другие превращаются в бесконечную доработку? Почему ERP часто не справляется с задачами WMS, даже если её «прокачали»? И как выбрать систему, которая не устареет через пару лет? Постараюсь развеять Мифы о WMS функционале в ERP системах.

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

Постараюсь писать без отсылок к нашей системе, я мог бы долго хвалить её, ведь свои дети всегда кажутся самыми умными и красивыми. Но сделаю это только в начале и в конце. За годы мы не только разработали одно из лучших решений в соотношении цена/качество/сроки внедрения, с полноценной интеграцией с 1С, гибким API для любых учётных систем и современными технологиями и архитектурой, но и внедрили её на огромном количестве складов различных размеров — от Uniliver до небольших региональных складов. Но сегодня не про нас, а про принципиальные различия систем.

Прежде, чем приступать к внедрению серьезных перемен, к ним нужно подготовиться. А внедрение Теории Ограничений (TOC) - это очень серьезное изменение компании.

Сначала вам предстоит понять, какова цель этих будущих перемен? Что именно должно в компании измениться? Какой именно показатель деятельности? Чему этот показатель равен сейчас и в чем он измеряется?

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

В контексте именно этих двух показателей и будет цикл моих статей.

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

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

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

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

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

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