CADmaster

Вопрос, вынесенный в эпиграф, носит риторический характер, к тому же ответ на него давно известен — нет правых и нет виноватых. Более того, очевидно: и то и другое неотъемлемые части единого целого — информационной системы предприятия.

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

Однако по порядку.

Прежде всего настало время «рассекретить» предприятие, о котором повествует эта статья, а также предшествующие ей публикации [1, 2, 3].

Речь идет об МПО имени И. Румянцева, которое по праву считается одним из ведущих в области авиационного агрегатостроения. Понимание того, что для сохранения лидирующих отраслевых позиций необходимо в том числе самым серьезным образом относиться к автоматизации производственных процессов, позволило руководству предприятия выполнить ряд масштабных проектов, направленных на создание и эффективное использование информационной системы, важнейшими частями которой являются ERP ¹ (в данном случае BAAN) и АСТПП ² (TechnologiCS).

Как уже упоминалось в [1], проекты по внедрению систем стартовали практически одновременно, при этом предприятие выбрало для АСТПП и ERP разных поставщиков решений — соответственно, процесс внедрения осуществлялся разными командами. И хотя задача интеграции систем была поставлена перед внедренцами изначально, каждая из команд имела собственную точку зрения на способы ее решения. Причем существуют объективные причины, которые объясняют различие взглядов и подходов к интеграции, а также способов ее реализации.

Среди главных причин отметим следующие:

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

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

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

Техническая сторона вопроса

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

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

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

Проиллюстрируем на примерах:

• состав изделия в TechnologiCS представлен в виде совокупности спецификаций. Структура и содержание электронной спецификации при этом однозначно ассоциируются с одноименным конструкторским документом;
• состав изделия в BAAN представлен в виде сущности, называющейся BOM (bill of materials — материальный состав изделия). При этом данная сущность содержит информацию о материале, необходимом для изготовления каждой позиции, включая норму его расхода;
• в TechnologiCS материал заготовки и норма его расхода — неотъемлемая часть сущности «Технологический процесс», другая неотъемлемая ее часть — маршрут изготовления (последовательность технологических операций);
• в BAAN маршрут изготовления — отдельная сущность, при этом для каждой операции должен быть указан так называемый Рабочий центр, представляющий собой однородную по технологическим характеристикам группу оборудования, принадлежащую тому или иному производственному подразделению;
• в техпроцессе TechnologiCS с операциями связаны модели оборудования (либо технологические группы) безотносительно места их установки (можно, конечно, вести справочник Рабочих центров и использовать их в техпроцессе, но это противоречит требованиям технологической документации).

Таких примеров можно привести множество. Как видно, «все смешалось в доме Облонских…»

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

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

На рис. 1 приведен пример подобной «сборки». Формируем BOM из совокупности спецификаций изделия, а также части технологической информации.

Рис. 1. Формирование промежуточных таблиц

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

Рис. 2. Последовательность обмена данными

Казалось бы, всё просто. Но если освещать вопрос полностью, нельзя не упомянуть еще об одном важном моменте. Дело в том, что для работы ERP-системы требуется гораздо больше информации, чем содержится в АСТПП. Эта специфическая информация носит производственный характер и с точки зрения TechnologiCS является избыточной — ненужной для формирования конструкторской и технологической документации. Примерами подобной информации служат дополнительные параметры номенклатуры, характеризующие ее как объекты учета; данные, касающиеся производственных циклов (например, времена межцехового перемещения партий деталей) и так далее.

При совместной работе систем вопрос о том, в какой из них должна возникать подобная информация и кто должен нести за нее ответственность, — очень болезненный. Надо заметить, что в TechnologiCS тоже хранится достаточно много специфических данных, обеспечивающих процессы проектирования и выпуска документации, которые BAAN не нужны — но здесь действительно всё просто, эти данные живут своей жизнью внутри системы и не возникает никаких вопросов относительно их хозяев. Зато в первом случае вопросы появляются неизбежно:

• вменять конструкторам и технологам в обязанность вести подобные данные в TechnologiCS бессмысленно, так как они просто не владеют подобной информацией и по определению не могут нести за нее ответственности;
• привлекать к ведению этих данных в TechnologiCS сотрудников, обладающих подобной компетенцией, нецелесообразно — они будут вынуждены работать одновременно в двух системах (так как основной рабочей средой для них останется BAAN). К тому же возникнут неизбежные трудности, связанные с управлением данными процессами и разделением прав доступа;
• дополнительно вводить недостающую информацию в BAAN? Так может быть, вообще отказаться от «услуг» TechnologiCS и просто ввести все данные в том виде, в котором они нужны BAAN? Полный абсурд…

Выход из ситуации был предложен следующий.

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

• во-первых, были определены специфические данные, ведение которых возможно в системе TechnologiCS силами конструкторских и технологических служб, организованы и настроены соответствующие процессы;
• во-вторых, был выявлен ряд закономерностей, которые позволили организовать дополнительную обработку выгружаемых из TechnologiCS данных по формальным алгоритмам — результатом этой обработки явилась недостающая производственная информация;
• в «сухом» остатке получилось то, что безусловно является прерогативой ERP, и необходимость ведения этих данных в BAAN ни у кого уже не вызвала сомнений.

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

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

Приведем несколько примеров, как последовательно менялись требования BAAN и, соответственно, модернизировалась процедура взаимодействия систем:

• номенклатуру при передаче в BAAN можно анализировать — и формировать номенклатурные группы (рис. 3);
• предварительный маршрут (расцеховку) также надо анализировать и подвергать корректировке по определенному алгоритму (рис. 4);
• в BAAN нужны не все операции технологического маршрута, ряд операций нужно объединять в одну и передавать их с обобщенными параметрами (рис. 5);
• и наоборот, следует формировать искусственные (фантомные) операции, необходимые для организации учета (рис. 6).

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

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

Рис. 3. Анализируем номенклатуру Рис. 4. Обрабатываем расцеховку Рис. 5. Объединяем операции Рис. 6. Формируем фантомные операции

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

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

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

Рис. 7. Запуск процедуры передачи данных

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

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

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

Ряд действий, касающихся совместной работы систем, потребовал сочетания технического и организационного регламентов. Например, номенклатурная позиция (item) из TechnologiCS не всегда может быть передана только как позиция состава, в ряде случаев она сначала появляется в BAAN как объект складского учета. Для того чтобы она при этом синхронно появилась в TechnologiCS и сразу приобрела дополнительные параметры, необходимые в BAAN, потребовались определенные организационные меры (рис. 8).

Таким образом, опыт, полученный в ходе технической реализации интеграционного процесса, позволяет сделать по крайней мере два вывода:

1. Проблема «неявных сущностей» носит объективный характер и надо быть готовым к ее преодолению при любой комбинации интегрируемых систем. Можно минимизировать масштаб бедствия на этапе подбора систем, но это весьма проблематично — требуется глубокое изучение объектных моделей, анализ сущностей систем, а на этапе подбора это вряд ли возможно по понятным причинам.
2. Проблема в любом случае преодолима, но для этого требуется заинтересованное взаимодействие специалистов, осуществляющих внедрение интегрируемых систем. Невозможно качественно решить проблему, просто сформулировав взаимные технические требования, — нужен диалог.

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

…Организационная сторона вопроса

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

Другими словами, чтобы ERP работала, необходимо соблюдение двух условий:

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

В нашем случае выполнение первого условия обеспечено начальным импортом информации [1]. Вся загвоздка — в выполнении второго условия.

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

Возможно ли это сделать если не мгновенно, то очень быстро?

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

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

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

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

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

В нашей ситуации был выработан действительно реальный план освоения АСТПП с максимально возможной в данных условиях скоростью:

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

Все было бы хорошо, но наши темпы никоим образом не устраивали ERP, которой актуальная информация требовалась немедленно, здесь и сейчас. Можно, конечно, произносить заклинания вроде «…база должна быть актуальна к такому-то числу!», но это все равно что пытаться приказывать солнцу закатиться немедленно. Есть объективные условия, определяющие скорость процесса, поэтому для выхода из непростой ситуации необходимо было нестандартное решение — и мы его нашли.

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

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

Кстати, несколько слов о выверке (кто этим занимался, тот знает).

Как невозможно закинуть невод сразу на все море, так невозможно «накрыть» выверкой сразу всю базу. Обычно работа начинается «с краю», носит последовательный характер и выполняется с определенной конечной скоростью. Массовый характер работы требует большого количества рабочих рук, а где же их взять в условиях жесткого дефицита и занятости «боевых единиц»? Вот и привлекаются, как правило, студенты-практиканты. При всем уважении к их старанию и работоспособности высокого качества результатов ждать не приходится.

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

Выверка становится процессом самодостаточным и, следовательно, бесконечным. В данной ситуации самым разумным становится решение о ее прекращении (по аналогии с ремонтом). Что же взамен? Ведь остается нерешенная задача!

Взамен — принципиальное изменение характера процесса исправления ошибок (актуализации базы).

Использовать рабочие механизмы, предусмотренные АСТПП, для исправления ошибок нецелесообразно — это слишком медленно, тем более что нами предусмотрен временный симбиоз новых данных (рождающихся в процессе проектирования) и старых, унаследованных при импорте информации, о чем подробно рассказано в [2].

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

1. Данные понадобились (используются в текущей производственной программе).
2. В данных выявлены ошибки, формируем сигнал — необходимо исправить.
3. Данные должны оперативно поступить автору (хозяину информации).
4. Автор анализирует характер ошибки и принимает решение:
   • ошибка в базе (по сравнению с действующей документацией) — исправляем ошибку и немедленно возвращаем исправленные данные;
   • ошибка в документации (и такое бывает) — требуется проведение изменения. Тем не менее, ошибка немедленно исправляется, но тут же инициируется процедура проведения изменения согласно действующему регламенту.

Осталось распределить роли в данном процессе, а это не составляет никакого труда.

Очевидно, что сигнал об ошибке возникает в момент формирования производственных документов — например, сопроводительных маршрутных карт (а этим занимается BAAN). Соответственно, он и сигнализирует.

Следующий вопрос — кому должен быть адресован сигнал? Наверное, должен существовать некий диспетчерский пункт, который будет регистрировать сигналы и распределять их авторам (прежде всего технологам). Для повышения оперативности обработки ошибок сотрудники данного диспетчерского пункта должны обладать достаточной компетенцией и правами для того, чтобы справляться с простыми случаями (а таких, кстати, большинство). В этом случае обработка сигнала может занимать минуты.

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

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

Можно ли предложенный механизм актуализации базы назвать выверкой? Наверное, можно, но при этом:

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

Цель достигнута.

Конечно же, деятельность данного подразделения носит временный, «проектный» характер. Ведь при этом параллельно и, самое главное, планомерно запускаются процессы рабочего проектирования с использованием АСТПП, к работе подключаются все больше и больше пользователей. Таким образом, рабочие процессы в течение обозримого промежутка времени должны заместить временные и деятельность данного подразделения в качестве «пожарной команды» потеряет актуальность. Работу указанного подразделения в течение переходного периода иллюстрирует рис. 10.

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

Выводы

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

Хочется отметить, что в основе полученного результата лежат три неразрывных составляющих, каждая из которых в равной степени влияет на качество результата:

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

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

Литература

1. Дмитрий Докучаев. Цель подсказывает средства. — CADmaster, № 5/2007, с. 50−55.
2. Дмитрий Докучаев, Елена Кузнецова, Елена Зырянова, Борис Бабушкин. С чего начинается АСТПП. — CADmaster, № 1/2008, с. 30−35.
3. Дмитрий Докучаев, Елена Докучаева. Больше чем документооборот. — CADmaster, № 3/2008, с. 18−29.