Сравнение SCMo и

традиционных ERP систем

Питеркин С.В.
Директор Райтстеп

Принципиальные отличия
Традиционные западные ERP системы имеют очень большую и избыточную
функциональность, т.к. в систему, за долгие годы развития, закладываются все возможные,
по мнению разработчика, способы управления предприятием, со всей клиентской базы.
Такая универсальная система, удовлетворяя некоторому усредненному (причем западному)
предприятию, как правило, не подходит конкретному российскому. Иногда, в весьма
существенных мелочах. Не зря, любой поставщик программного обеспечения заявляет, что
модификации софта не должны составлять более 20%, в противном случае, система просто
не подходит предприятию. По факту, модификации внедряемой системы составляют много
более 20%, причем большая их часть приходится на пользовательский интерфейс,
отчетность, и доработки важной функциональности, и часто реализуется силами самого
предприятия. Как результат – либо завышенная стоимость сопровождения, либо вообще
неспособность поставщика оказывать таковое и проблемный переход на новые версии.
В том числе и из-за этого, большая часть времени проекта (60-80%) уходит на обучение,
тестирование и просто привыкания ко всему, часто ненужному функционалу. Как результат,
из 100% используемых функций системы примерно 40% - это «родные» функции
изначальной системы, оставшиеся 60% - доработки предприятия или поставщика.
В отличие от этого, система SCMo «логически» построена по принципу SOA. Т.е. вся
заявленная функциональность системы поставляется в виде отдельных библиотек и/или
хранимых процедур (программ) базы данных, в которых «зашиты» в том числе и «лучшие
практики» управления. Из данных библиотек и программ настраивается и конфигурируется
версия «под предприятие», в которой содержится только то, что необходимо предприятию
для работы. Настройка системы занимает от 1 до 4х месяцев (в сложных случаях). В
результате предприятие получает удобную, настроенную специально под него систему,
которую практически сразу можно запускать. Как результат – короткие сроки реализации
проекта.
Каждая, сконфигурированная таким образом клиентская версия поддерживается
индивидуально. От этого всячески открещиваются поставщики традиционных ERP,
связывая это с невозможностью легкого применения дальнейших обновлений, но, по факту
они (поставщики) все равно вынуждены отслеживать и вести каждую клиентскую версию
отдельно.

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

Реализация планирования в традиционных ERP системах.

Реализация планирования и управления производством «традиционных» систем
значительно ограничивает возможность их применения для таких предприятий. Подробнее.

а. Планирование по MRP.
При планировании по MRP алгоритму источник головной потребности не отслеживается до
нижних уровней спецификации, т.к. при расчете MRP потребности для изделий с одним
кодом консолидируются. Full Pegging (полное прослеживание потребностей) реализован
только в системах SAP (отраслевое решение для A&D) и BaaN (версия 5.0, отраслевое
решение для A&D). В данных версиях этих систем, каждый формируемый расчетом MRP
плановый заказ (-pln) имеет список «головных» потребностей, от которых он был
сформирован. К сожалению, это частичное решение проблемы, т.к. при следующем
планировании эта информация стирается и присваивается вновь созданному плановому
заказу. А при утверждении планового заказа в фиксированный (Производственный Заказ
или Заказ-Наряд на Производство - ЗНП), этот фиксированный заказ «забывает» заказы, для
которых он предназначен.
Кроме того, планирование никак «не видит» распределения запасов материалов или ПКИ
под конкретные заказы. Точнее, детали, произведенные или закупленные специально под
заказ, распределены под него через функцию резервирования или прикрепления к партии,
при планировании будут учтены как имеющиеся в наличии для другого, как более раннего,
так и более позднего заказа. Аналогично, планирование «не видит» производимых и под
конкретный заказ деталей.

b. Планирование по APS.
Указанные недостатки присутствуют и при планировании потребностей с использованием
сетевого позаказного APS алгоритма. Планировщик системы, рассчитывая потребности
позаказно, «отнимает» имеющиеся в наличии и уже распределенные под конкретный запас
детали для другого, более приоритетного заказа. Кроме того, каждое следующее
планирование «забывает» о результатах предыдущего, формирую уже другие потребности
по одни и те же заказы. Подобное «поведение» системы делает невозможным создание
устойчивого и понятного производственникам плана производства или закупок, заставляя
формировать жесткий план из уже утвержденных производственных заданий на
значительный горизонт времени в будущее. А это – крайне неудобно, т.к. менять уже
утвержденные заказы поставщикам или в производство чрезвычайно трудно в любой
системе.

c. Планирование утвержденных производственных заданий.

Попытка обойти указанную проблему через планирование подтвержденных и жестко-
связанных между собой заказов (структура «ЗНП – субЗНП» в Infor ERP SyteLinei,
«связанные производственные заказы/задания» в Infor ERP LN и MS-Dynamics Ax), также
приводит к неудаче, т.к. при таком планировании запасы в наличии головного заказа также
не видны. В результате планирования такой структуры будут созданы заказы на
производство/закупку лишнего количества изделий.

2
SCMo vs. ERP © Райтстеп, ООО, 2008 - 2010
Оценка возможностей механизма планирования
Контрольный вопрос, который может быть ненавязчиво задан при оценке возможности
системы реализовать эту схему будет выглядеть следующим образом: «как
идентифицировать на складе запасы одного и того же изделия, так, чтобы планирование
учитывало их наличие для одних заказов и не учитывало для других, более ранних,
например?»
Примечание. Заявляемая многими функциональность управления «серийными номерами» не
имеет ничего общего с решением указанной выше проблемы, т.к. предназначена только для
присвоения и отслеживания серийного номера уже готовым деталям.
Единственная возможность обойти указанную проблему в традиционных ERP – создавать
каждый раз новые детали в общем справочнике изделий при вводе нового заказа. Очевидно,
что даже при унификации изделий, которая есть даже у самого «позаказного» производства,
такая схема оборачивается огромными неудобствами для работы.

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

Реализация в SCMo
В SCMo указанная функциональность реализована изначально, через следующие
особенности алгоритма планирования и управления запасами.
• При планировании под каждую головную потребность (заказ) виртуально создается и
хранится в базе данных свой состав изделия.
• Запасы в наличии распределяются и «жестко» закрепляются под потребности головного
заказа, для чего используется один из нескольких специальных кодов аналитики
изделий.
• При планировании эти запасы учитываются, как распределенные под каждый
конкретный заказ.
• В случае необходимости (заказ снят или принято решение о передаче изделий с одного
заказа на другой), запасы в наличии перераспределяются между заказами через
специальную функцию перераспределения.
За счет указанного становится очень удобно составлять план производства (план
запуска/выпуска деталей по цеху и/или участку) приоретизируя его, т.е. упорядочивая
очередь деталей перед «входом» на участок, в соответствии с приоритетом заказа, а не по
времени запуска/выпуска, как это делается в традиционных системах. Последнее для наших
(российских) предприятий плохо еще и тем, что нормативная информация по циклам
производства как правило, неточная, поэтому и даты запуска и даты выпуска дают не всегда
корректную информацию.

3
SCMo vs. ERP © Райтстеп, ООО, 2008 - 2010
Состав изделия
В традиционных ERP системах в качестве состава изделия выступает спецификация и
пооперационный техпроцесс. Последний используется для планирования времен
запуска/выпуска. В случае отсутствия достаточно точных временных данных (а это верно
практически для всех предприятий, т.к. пооперационные нормы, как правило, «зарплатные»)
такой подход дает крайне неудовлетворительный результат при планировании. Попытка
«загрубления» данных, т.е. создание упрощенного маршрута (один участок - одна
операция) также не является выходом. Т.к., первое: не позволяет организовать
пооперационный учет при необходимости, и, второе: при большой длительности этой одной
«операции» приводит к сдвигу сроков всего заказа, при планировании по APS «посередине»
операции.
В SCMo данная проблема решается следующим образом.
1. Для каждой детали (и для каждого заказа для данной детали) ведется два маршрута:
ƒ расцеховка, т.е. одна «операция» для одного цехо- или участко-захода, со своими
временными характеристиками, включая время перемещения между
цехами/участками и временем «буфера» для использования при планировании по
правилу ТОС «барабан-буфер-веревка»;
ƒ пооперационный маршрут со своими, традиционными временными
характеристиками.
2. Первый маршрут используется для общего планирования потребностей и формирования
плана производства. Второй – для детального внутрицехового планирования для
пооперационного учета и для формирования себестоимости. При этом в зависимости от
реализуемой на предприятии схемы управления, с использованием данных
конфигураций возможно создание практически любой конфигурации изделия. Как
пример, при наличии точных пооперационных норм первый маршрут может быть
сведен ко второму через приравнивание цехо-захода к операции.
3. Для решения проблемы планирования при планировании «в середине» длительной
операции, в системе предусмотрена возможность закрытия % завершения операции.
Вручную, через ввод закрытых нормо-часов или отработанных смен, или автоматически,
с ежедневным пропорциональным сокращением оставшегося времени производства.

Аналитика, отчетность
Возможность построения непосредственно в SCMo системе обширной аналитики по
объектам управления, а также использование стандартного генератора отчетов базы данных
(MS SQL Report Builder) делает практически ненужным использование дополнительных
аналитических средств типа OLAP или BI приложений. Как пример, ниже приводится
экранная аналитическая форма, очень удобная для отслеживания статуса выполнения
длительных заказов, выполнение которых включает в себя несколько этапов, и не только
производственных (разработка документации, например).

4
SCMo vs. ERP © Райтстеп, ООО, 2008 - 2010
 План
закрытия

Факт
Отставание закрытия

Нормо-часы,
% закрытия Календарные
или сроки (дни-

Технологии
Вместо того, чтобы изобретать свои собственные технологии разработки оболочки как это
делает большинство ERP поставщиков (WinStudio - для Infor ERP SyteLine, как пример) и
постоянно плестись в хвосте прогресса (см.ниже), в качестве базовой платформы SCMo
используются стандартные решения Microsoft, обновляя которые, одновременно
обновляется и сама платформенная часть системы.
Как пример (на конец 2009 года): Infor ERP SyteLine работает на 32х разрядной архитектуре,
на СУБД MS-SQL 2000 (2000го года выпуска) c устаревшей версией генератора отчетов
Crystal Reports (версия 9 при текущей 11-ой) и допотопными, начала столетия, средствами
разработки. Infor ERP LN – также не есть образец современного интерфейса и СУБД.
SCMo переводится разработчиком (и одновременно дистрибутором в России) на
современные платформы сразу, как только выпускаются устойчивые версии последних. Так,
в конце 2009 года система была переведена на следующую архитектуру: 64х разрядная
архитектура, СУБД MS-SQL 2008 с новым встроенным генератором отчетности, Windows 7,
обновленная, последняя версия Microsoft.Net
Кроме того, SCMo в настоящее время – одна из немногих корпоративных систем в мире, и,
по-видимому, единственная в России, которая изначально и полностью сделана для работы
через интернет. Для распределенных производственно-сбытовых структур это крайне
важно. Как важно и для руководителей и владельцев, постоянно находящихся в разъездах,
иметь возможность удаленного мониторинга работы предприятия из любого места с
интернет доступом.

5
SCMo vs. ERP © Райтстеп, ООО, 2008 - 2010
 Infor ERP MS-Dynamics AX 1C: Предприятие.
Параметр SCMo Infor ERP LN IFS
SyteLine v.8.0ii 2009 8.0
Позаказное Есть, полностью Только через Через определение Только через связку Только через связку Нет
планирование связку «ЗНП-сЗНП», кода головного производственных производственных
производства и закупок планирование без изделия для заданий. Сделано заданий.
с учетом позаказного учета плановых заказов. слабо, т.к.
распределения запасов распределенных Без учета производство в
при планировании запасов распределенных системе
запасов под традиционное
изделие. слабое место.
Можно написать
Позаказный учет, Есть, полностью Нет Нет Есть Нет Можно написать
отдельно от
партионного учета
Визуальное Есть, полностью. «Прямо из Нет Нет Нет Нет
отслеживание Очень легкое и коробки» - нет, но
выполнения каждого удобное для всех. может быть
заказа с реализовано с
автоматическим определенными
расчетом даты допущениями.
отставания/опережения
Управление Простота движений «Тяжелый» Очень «тяжелый» «Легкий» западный Очень «тяжелый» Очень легкий и
движениями и 1С с логикой и западный западный транзакционный западный простой, но
документооборот строгостью ERP. транзакционный транзакционный учет. транзакционный позволяющий
Изюминка – учет. учет учет злоупотребления.
автозаполнение
форм, конструктор
движений.
Штрихкодирование Есть. Настраивается Есть, но: Есть. Тяжелое но Есть. Удобное для Нет информации Есть, очень
практически для стандартное – не очень управления удобное, встроено в
любого объекта работоспособно с функциональное. запасами. систему.
нашим
оборудованием.
Как результат -
пишется отдельно
под каждого
клиента. Часто -
силами клиента.
Встроенные средства Есть Нет, доп.модуль Нет, доп.модуль Да, частично Нет Да, частично
аналитики OLAP OLAP
Генератор отчетов Есть, простой. Часть Есть, простой. Но Сложный. «Родной» Есть, простой Сложный. «Родной» Есть, простой
СУБД старая версия. тяжелый, или тяжелый, или
доп.модуль доп.модуль
Современная и Есть Нет Нет Есть Нет Есть
обновляемая
платформа
Полноценная работа Есть Нет (только через Нет (только через ДА/Нет (некоторые ДА/Нет (некоторые ДА/Нет (некоторые
через WEB режим «удаленного режим «удаленного функции) функции) функции)
доступа») доступа»)
Открытые коды Да, все кроме Многие, кроме Почти все закрыто Почти все, по Почти все закрыто Почти все.
некоторых планирования и «слоям»
алгоритмов оболочки
планирования и
оболочки
Большой опыт и Есть Опыт был, команда Есть Опыта мало, Нет ни того ни Нет ни того ни
команда внедрения – распалась, хорошая команда другого другого. Но есть
оставшиеся – есть (GMCS) хорошие
перегружены разработчики.
Общие комментарии Хороший выбор по Хороший выбор Слишком Возможное решение В последнее время Можно рассмотреть
соотношению несколько лет «тяжелая» и для среднего система при желании делать
цена/качество. назад. Сейчас дорогая (по предприятия при позиционируется и проект разработки
Настраивается под развитие системы бюджету внедрения наличии мощного продается на при наличии
предприятие. практически и по трудозатратам производственного предприятия, мощного
Сильная команда, остановлено, у на внедрение) консалтинга и занимающиеся производственного
поднявшая в свое компании за система для хороших сервисным консалтинга и
время Infor ERP последние 3 года средних разработчиков. обслуживанием хороших
SyteLine и компанию ни одного успешно предприятий. (генерация электро разработчиков.
Фронтстеп. завершенного Лучший размер для и тепловой энергии,
Директора и проекта. Но много BaaN’a – авиа и АРЗы)
действующие начатых. авто –
консультанты: предприятия.
Питеркин,
Шлыкова, Мохно

7
SCMo vs. ERP © Райтстеп, ООО, 2008 - 2010
Еще (SCMo vs SL)
Прямое и обратное Проблемы - только
списание через печать КВ или
ПЦЗ
«Супер»-обратное Есть
списание.
Нормативное
списание по всей
структуре или по
части структуры

i
1. Планирование ЗНП-субЗНП не как отдельных объектов, а как связанной структуры, дерева изделия почти никак не реализовано в системе SyteLine и BaaN (последний
пример неудачных проектов с SyteLine– РЭТ (Екатеринбург) и РПЗ (Подмросковье). И вязано это с идеологией написания софта: общий состав изделия планируется
только по текущей структуре изделия с формированием pln, утвержденные задания создаются только на ближайший период и планируются только индивидуально, без
учета связок. Наши попытки сделать решение для SL с APS планированием не увенчались успехом. Точнее – система работала, но не всегда (!!!). Часто получались
совершенно непонятные планы. В результате для НАПО, для цеха, где стоит SyteLine используем планирование SCMo, интегрировав его в SyteLine вместо APS.
2. Кроме того, в общем случае планирование всегда «выбрасывает» структуру типа «ЗНП-СубЗНП» вправо по датам, при малейшем изменении сроков производства
«нижних» ЗНП или если не ввели информацию о завершении операции. Последнее автоматически приводит к необходимости запуска трудоемкого пооперационного
учета, который еще более трудоемок и неподъемен, если нет пооперационных точных норм

ii
Версия 8.0 пока не доступна Российским пользователям. Когда будет доступна - неизвестно.

8
SCMo vs. ERP © Райтстеп, ООО, 2008 - 2010