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

В рамках нашей постоянной рубрики «ИТ-университет» мы представляем новый, очень необычный проект — курс лекций «Фундамент ERP-проекта».

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

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

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

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

О важности «нулевого цикла»

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

Актуальность данного вопроса начала в полной мере осознаваться предприятиями относительно недавно. Действительно, если программная система заявлена как соответствующая концепции MRP II, представляющей собой довольно четко выстроенную конструкцию, то в каждой такой системе должны быть реализованы некоторые общие принципы построения и общие требования к составу данных. Да, в отдельных информационных системах есть свои нюансы описания тех или иных объектов — номенклатурных позиций, спецификаций, рабочих центров, технологических маршрутов, мест хранения запасов и т. д. Но есть и значительная общая часть. Можно сказать, что, различаясь в деталях описания объектов, системы едины в требованиях к составу объектов и к их базовым свойствам. Наличие уже описанного состава данных и их основных атрибутов позволяет лучше подготовиться к процедуре выбора системы, а также лучше подготовить свой персонал к внедрению системы. Этот тезис может быть обоснован двумя основными аргументами:

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

Персонал в процессе подготовки исходных нормативных данных «проникается» их структурой. Часто при этом выполняется классификация объектов и их группировка по различным признакам. Когда встает задача «выстроить» данные по выбранным классификационным признакам, которые потом будут использоваться как для формирования различных их группировок, так и для установки значений различных параметров объектов, можно надеяться на то, что ее решение даст возможность, с одной стороны, автоматизировать процесс переноса нормативных данных в ERP-систему, а с другой — структурировать понимание персоналом состава и свойств объектов. Это облегчит процедуру поддержки данных в дальнейшем, в процессе эксплуатации системы.

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

Стоит также заметить, что ERP-системы весьма требовательны к качеству и своевременности нормативной и оперативной информации. За такими системами, если ставится задача получать от их эксплуатации реальную пользу, надо тщательно «ухаживать», питая их данными о фактическом течении процессов закупок, производства, сбыта и пр. Помимо этого — в силу неизбежного обновления данных о номенклатурных позициях, спецификациях, технологических маршрутах и т. д., происходящего по причине появления новых видов продукции, полуфабрикатов, материалов, установки нового оборудования, появления новых мест хранения запасов, — должна решаться задача создания новых объектов в информационной системе уже после ее запуска в промышленную эксплуатацию. Следовательно, необходимо позаботиться о подготовке персонала, который будет отвечать за качество данных (исполнять функции контроля и оперативной регистрации фактических данных), и о разработке методик контроля качества данных (что, как часто, где и каким способом мы проверяем).

Таким образом, еще на «нулевой» стадии следует обратить внимание на три важных момента:

  • подготовку описания необходимого состава исходных нормативных данных;
  • подготовку персонала предприятия к внедрению и эксплуатации системы класса ERP;
  • подготовку процедур и персонала для контроля качества данных (с точки зрения точности и своевременности) и для оперативного обновления данных о состоянии процессов.

Какие данные можно и нужно готовить?

Можно выделить шесть основных групп данных нормативно-справочного характера, перечень которых достаточно универсален и в целом не зависит от вида программного продукта. Безусловно, некоторые из рассматриваемых атрибутов могут отсутствовать в том или ином программном продукте, однако мы отметим те из них, которые, безусловно, необходимы и широко распространены в ERP-системах.

Итак, для работы системы класса ERP необходимы как минимум следующие данные:

  • о номенклатурных позициях;
  • о спецификациях;
  • о производственной структуре предприятия;
  • о технологических маршрутах;
  • о территориальной структуре предприятия (в части описания мест хранения запасов);
  • о бизнес-окружении предприятия.

Более подробно остановимся на обсуждении данных о номенклатурных позициях. Другие группы данных будут рассмотрены в следующих публикациях.

Номенклатурные позиции

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

Номенклатурная позиция (item) — это любая уникальная (определенная) производимая или закупаемая деталь, материал, полуфабрикат, сборочная единица или готовый продукт.

Стоит отметить, что уникальность здесь понимается как однозначная определенность, а не как своеобразность и «единственность».

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

И учитываемые, и планируемые. «Учитываемые» означает, что поддерживаются данные о складских запасах по данной номенклатурной позиции, «планируемые» — что для расчета потребности в этих номенклатурных позициях используются возможности ERP-системы.

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

Планирование при помощи ERP-системы обычно осуществляется одним из двух методов: календарной точки заказа или статистической точки заказа. Выбор того или иного метода, как правило, базируется на ABC-классификации номенклатурных позиций. Примеры позиций такого типа — основные материалы, сборочные единицы, готовая продукция. Если по производимой номенклатурной позиции выбран рассматриваемый класс описания номенклатурной позиции, мы должны будем определить для нее спецификацию обычного типа (как минимум одну, основную), технологический маршрут производства (как минимум один, основной) и увязать между собой спецификацию и технологический маршрут (то есть описать способ ее производства). Резюмируя, можно сказать, что позиции такого класса существуют и для складской подсистемы, и для подсистемы планирования потребности

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

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

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

Рисунок. Фантом и его спецификация

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

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

Итоги и перспективы

Еще раз отметим, что полезно проводить классификацию номенклатурных позиций с точки зрения их общности (для последующего упрощения создания массивов нормативно-справочной информации в MRP II — системе с использованием возможности переноса данных из одной базы в другую). Ошибки, практически неизбежные при подготовке данных, при использовании такого механизма носят системный характер и достаточно хорошо локализуются, ведь достаточно сделать проверку по одному представителю из каждой группы, в то время как при использовании ввода данных о номенклатурных позициях с клавиатуры неизбежны ошибки случайные, локализовать которые значительно сложнее. Кроме этого, подобный подход дает возможность сформировать «шаблонные» номенклатурные позиции для каждой классификационной группы с приданием им характерных значений параметров их описания по следующим признакам:

  • по параметрам их хранения в запасах;
  • по параметрам их планирования;
  • по бухгалтерскому признаку (обязательная классификация);
  • по другим классификационным группировкам, помимо бухгалтерской (обычно носящим факультативный характер);
  • по зонам ответственности планировщиков и др.

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

Литература
  1. APICS Dictionary. Tenth edition. 2002.
  2. Гаврилов Д. А. Управление производством на базе стандарта MRP II. СПб.: Питер, 2003. 352 с.: ил.

Дмитрий Гаврилов — старший преподаватель Санкт-Петербургского государственного политехнического университета, dmgv@comset.net


Глоссарий

Номенклатурная позиция (item) — любая уникальная (определенная) производимая или закупаемая деталь, материал, полуфабрикат, сборочная единица или готовый продукт.

Плановая спецификация (Planning Bill Of Material) — искусственная группировка номенклатурных позиций или событий в формате спецификации, используемая для облегчения формирования главного календарного плана и планирования потребности в материалах. Она может включать историческую среднюю спроса, выраженную в процентах от общего спроса, для всех опций в рамках свойства (feature) или для определенной номенклатурной позиции готовой продукции в рамках товарной группы (семьи продуктов), которая применяется как норма расхода в плановой спецификации.

Спецификация (Bill Of Material, BOM) — 1. Список всех сборочных единиц, полуфабрикатов, деталей и материалов, которые применяются в родительской сборочной единице, с указанием норм их расхода. Он используется вместе с главным календарным планом производства для определения номенклатурных позиций, для которых должны быть сформированы заявки на закупку и запущены в производство заказы. Для спецификаций существует множество форматов представления данных, включая одноуровневые спецификации, спецификации с отступами (структурированные), модульные (плановые) спецификации, транзитные спецификации, матричные спецификации, учетные спецификации. 2. Список всех материалов, необходимых для изготовления непрерывно одной партии (production run) продукта производителем по контракту (contract manufacturer) из деталей/компонентов для его клиентов. В некоторых отраслях с процессным типом производства спецификация также может быть названа формулой, рецептом или списком ингредиентов.

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

Технологический маршрут (routing) — 1. Информация, описывающая способ производства данной номенклатурной позиции. Включает операции, которые необходимо выполнить, их последовательность, различные используемые рабочие центры, а также нормы времени для подготовки и обработки. В некоторых компаниях технологические маршруты также содержат информацию об инструментальном обеспечении, требования к уровню квалификации рабочих, операциях контроля качества, требования к тестированию и др. 2. В информационных системах процесс определения пути, который сообщение пройдет от одного компьютера к другому. Второй вариант определения включен в глоссарий исключительно ради соответствия APICS Dictionary и напрямую к теме статьи не относится (в этой трактовке он скорее называется просто «маршрут» — Прим. автора).

Транзитная (или фантомная) спецификация (Transient Bill Of Material или Phantom Bill Of Material) — техника кодирования и структурирования спецификаций, используемая преимущественно для транзитных (нескладируемых) сборочных единиц. Для транзитной номенклатурной позиции длительность цикла устанавливается равной нулю, а размер заказа формируется согласно политике «партия для партии». Фантомная спецификация представляет номенклатурную позицию, которая, хотя и производится физически, редко складируется перед тем, как быть использованной на следующем шаге или уровне производства. Это позволяет логике MRP «пропускать» потребности через фантомную номенклатурную позицию «насквозь» к ее компонентам, но MRP-система обычно сохраняет возможность расчета чистой потребности в позиции с использованием данных о случайно имеющихся запасах позиции. Данная техника также облегчает применение для конструирования и производства спецификаций общих компонентов.

Источник: APICS Dictionary, Tenth edition, 2002.