В предыдущей колонке мы остановились на том, что основой бизнес-систем является, как правило, SQL-база данных. Это означает, что АСУ ТП открыта для «общения» с участками производства — начиная от принятия заказа и заканчивая отгрузкой. Другими словами, программные системы на участках должны быть частью бизнес-системы и быть интегрированными с нею «в обе стороны» — как на получение, так и передачу информации, что позволит разбить процесс внедрения АСУ ТП и по участкам, и по времени.
При этом важно, чтобы занимался этой задачей один специалист, который должен быть: а) профессионалом и б) заинтересован в корректной постановке, решении и внедрении задачи. Решение «под ключ» на отдельном участке может внедряться независимо от других. Но должно быть понимание, какая бизнес-система будет (или уже имеется) во главе и каким требованиям по взаимодействию с нею это решение должно соответствовать. Мы уже говорили, что ручной ввод данных от бизнес-системы, например, в CAD/CAM-систему проектирования упаковки и, наоборот, данных проектирования в бизнес-систему, — это самое плохое решение, даже если процесс прикрыт «фиговым листком» в виде электронных таблиц.
Для любого заказа крайне желательно хранить следующие данные: его номер, название заказчика, менеджер, тип коробки, располагаемый парк оборудования (печатного, высечного и т. д.), база данных материалов. Конструктор, получая задание на разработку коробки, должен получить и все эти данные. Завершив работу, конструктор добавляет к этому набору «свои» данные, полученные в результате разработки или расчётов на основе этих данных. Новый массив данных уходит, допустим, на участок допечатной подготовки. Естественно, здесь данные дополняются и передается дальше. И так далее, вплоть до отгрузки — естественно, по пути какие-то данные становятся ненужными (они уже сыграли свою роль, хотя остаются необходимыми атрибутами заказа). Теперь представьте себе, что это должна быть за таблица и как ей пользоваться?
Поэтому при выборе «локальных» программно-аппаратных решений для АСУ ТП сразу необходима оценка, как они будут взаимодействовать с бизнес-системой.
В жизни производители и их дилеры часто предлагают «решения под ключ», но, увы, в большинстве случаев они оказываются только решениями для конкретного этапа процесса производства. В целом в этом нет ничего плохого, но решения-то бывают разные. И возможна ли будет для них настройка взаимодействия с АСУ ТП, остаётся большим вопросом…
Но, положа руку на сердце, много ли найдётся производителей, которые могут предложить все компоненты полной АСУ ТП только «от себя»? А есть ли вообще такие? Очень трудно быть лучшим везде — как в финансово-управленческой сфере, так и в технологиях производства упаковки. Разделение труда для этого и было придумано.
Среди бизнес-систем, решений для допечатного производства, конструкторов, технологов и т. п. есть лидеры де-факто. Но вопрос взаимодействия программных частей этих систем между собой остаётся открытым. Я знаю несколько примеров, когда предприятиям пришлось заменять ПО, в частности, для конструкторов, так как уже имеющееся привычное не могло быть интегрировано в АСУ ТП предприятия. Либо способ интеграции компанию не устраивал. Например, если для одной средней компании может подойти вариант экспорта/импорта данных между бизнес-системой и ПО для локального участка, то для большой, да ещё имеющей много филиалов, это будет неприемлемым и не даст желаемого снижения издержек. Хотя прямой экспорт/импорт на каждом технологическом участке уже намного лучше таблицы, сопровождающей заказ по всей технологической цепочке.
Теперь вернёмся к базе данных АСУ ТП. Если программа, создающая «локальное управление», также имеет интегрированную SQL-базу данных, то вопрос её интеграции с главной программой не должен быть проблемой. Но следует учитывать, что и для файловых структур хранения информации используется SQL-оболочка, которая отвечает за управление, хранение связей между файлами. Мы же говорим об SQL-базах данных, реально интегрированных в ПО. В этом случае связь между базами данных может быть организована напрямую, без импорта/экспорта, т. е. данные из таблиц, полей одной БД можно сделать доступными для другой.
|
Что это даёт? Простая иллюстрация: конструктор получает задание на разработку не в виде письма или распечатки, а АСУ ТП формирует это задание внутри конструкторской программы. То есть номер заказа, название заказчика и т. п. уже находятся в БД конструкторской программы. Списки оборудования, менеджеров, материалов не вводятся и не отслеживаются конструктором вручную, а берутся из БД АСУ ТП. А когда конструктор завершит свою работу, все полученные и необходимые для производства данные передаются в БД управляющей программы.
Об авторе: Виктор Миленин (vmilenin1954@gmail.com) — эксперт в области цифровой резки и инструментов для конструирования упаковки.