АСУ для оперативной полиграфии: взгляд изнутри

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

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

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

Типичная АСУ в полиграфии — это, как правило, программный продукт, построенный по технологии «клиент-сервер» и устанавливающийся на персональных компьютерах и/или серверах, входящих в локальную вычислительную сеть (ЛВС) предприятия. В редких случаях система включает аппаратную часть. В зависимости от сложности решаются различные задачи, среди которых выделим: расчёт заказов, управление производством, складом и взаимоотношениями с поставщиками, организацию взаимоотношений с клиентами, бухгалтерский учёт, управленческую отчётность.

Очевидно, что системы для предприятий ОП должны отвечать определённым требованиям, которые мы и обсудим, а также попытаемся представить, какой должна быть качественная АСУ с точки зрения программного и аппаратного обеспечения.

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

А что нам надо…

Каковы же основные требования к системе для ОП? Начнём с максимальной поддержки технологических особенностей производства. Производственный процесс здесь имеет последовательно-параллельную структуру. Это означает, что в технологической цепи выполнения заказа присутствуют как последовательные, так и параллельные участки. Например, блок и обложка журнала могут печататься одновременно — это параллельные участки цепи. Склейка блока и обложки, упаковка готовых экземпляров — последовательные участки. Подобная специфика непременно должна находить отражение в соответствующих механизмах оперативного планирования и диспетчеризации, реализованных в системе.

Заказы в ОП тяжело поддаются стандартизации с точки зрения технологического процесса. Особенности издания (сложные вставки в журнале и т. п.) могут значительно повлиять на качественный и количественный состав операций, необходимых для выполнения заказа; система должна учитывать подобные нюансы. Но следует помнить, что излишне жёсткая привязка к технологическому процессу — серьёзный минус. При модернизации схемы производства (например, при отказе от плёночной технологии и переходе к CtP) АСУ не должна стать камнем преткновения.

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

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

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

Возможность быстрого перепланирования, включающего смену критериев оптимизации, — важнейшее обстоятельство, которое надо учитывать при выборе или разработке системы. Нередко заказчик, заявляя одни параметры издания, меняет их в момент передачи электронного макета в типографию. В лучшем случае требуется дополнительное время на правку макета, в худшем (грубое несоответствие фактического формата издания заявленному, наличие дополнительных цветов и т. д.) — перепланирование с использованием других материалов и оборудования. Вообще, перепланирование — краеугольный камень АСУ. Современные системы класса ERP (Enterprise Resource Planning — планирование ресурсов предприятия), ориентированные в основном на финансовые функции, поддержку принятия стратегических решений и управленческую отчётность, позволяют перепланировать, в среднем, не чаще раза в сутки. Для сравнения, системы классов MES (Manufacturing Execution System — производственная исполнительная система) и APS (Advanced Planning and Scheduling — усовершенствованное планирование и диспетчеризация), больше привязанные к производственным процессам, увеличивают частоту на порядок.

Ещё одна тонкость — использование материалов заказчика. Нередко клиенты привозят собственную бумагу для печати своего тиража. Если предприятие принимает заказы на печать на бумаге заказчика, это обязательно должно быть предусмотрено АСУ на уровне планирования ресурсов, особого управления складом и в рамках бухгалтерского учёта.

Всё чаще от разработчиков АСУ для полиграфии можно услышать о поддержке формата JDF (Job Definition Format) — стандарта описания полиграфического заказа на всех этапах его выполнения. Первоначальная спецификация была разработана в 2000 г. компаниями Adobe, Agfa, Heidelberg и MAN Roland, а реализуется он группой CIP4 (The International Cooperation for the Integration of Processes in Prepress, Press and Postpress). JDF описывает конечный продукт (намерение) и шаги, необходимые для его воплощения (процесс). Основа стандарта — билет задания (job ticket), содержащий информацию о параметрах заказа в период всего цикла производства. Физически JDF — это XML-документ, что обеспечивает открытость формата, следовательно, безграничные возможности по его расширению и адаптации. В дополнение к JDF был разработан формат JMF (Job Messaging Format) — своеобразный язык двустороннего обмена данными между подсистемами (программными и аппаратными), входящими в состав АСУП и АСУТП и поддерживающими JDF. Не будем подробно описывать правила формирования данных и команд в соответствии с форматами JDF и JMF, эти сведения легко найти в открытых источниках, в т. ч. и в Интернете. Остановимся лишь на нескольких интересных моментах. Прежде всего, необходимо понимать, что JDF — это стандарт представления данных, а вовсе не стандарт документооборота. Его гибкость позволяет построить модель, максимально учитывающую особенности конкретного предприятия. Системы, поддерживающие JDF, могут сильно отличаться по функциональности и производительности. Во-вторых, реальную пользу JDF даёт только при полной поддержке стандарта всеми системами, входящими в АСУ предприятия. В противном случае затраты на конвертирование и синхронизацию потоков данных между подсистемами могут оказаться слишком большими. Наконец, нужно быть готовым к тому, что ни одна из предлагаемых разработчиками схем, реализованных на базе стандарта JDF, не подойдёт для вашего конкретного случая, и придётся создавать собственные расширения (т. н. «наследование»). Забегая вперёд, отмечу, что идеология, заложенная в JDF, когда одна сущность содержит информацию и о данных, и о правилах работы с ними, очень похожа на объектно-ориентированный подход, широко применяющийся в проектировании различных систем. Это стоит принять во внимание при выборе технологий проектирования и разработки АСУ, если компания решила создавать систему собственными силами.

Мы строили, строили…

Рассмотрим структуру и архитектуру АСУ как программно-аппаратного комплекса. Уже говорилось, что большинство АСУ на полиграфических предприятиях представляют собой чисто программные продукты (персональные компьютеры и серверы не в счёт). Но наличие аппаратной части, обеспечивающей автоматизированный ввод первичной информации и контролирующей соблюдение запланированной последовательности технологических операций, может перевести подсистему автоматизации управления, отвечающую за производство, в разряд систем реального времени, что увеличит быстродействие комплекса в целом и повысит степень актуальности данных, циркулирующих в системе. Простейший пример — датчики, фиксирующие количество листопрогонов на печатной машине. Более сложные устройства отличают макулатуру от чистой бумаги (такие модули установлены в типографии «Немецкая Фабрика Печати», где работает автор), подавая точные и детальные сведения о затраченных ресурсах. Я прекрасно понимаю сложность проектирования и изготовления такой аппаратной части, не говоря уже о серийном производстве соответствующих модулей. Тем не менее, прецеденты их использования есть и в России, и за рубежом. Другой пример — устройства идентификации персонала при работе с оборудованием. Применение смарт-карт или других технологий в сочетании с грамотной политикой безопасности в компании может предотвратит множество неприятностей.

Есть над чем подумать и при воплощении программной части АСУ. Речь не только о применении передовых технологий программирования, но и об архитектуре комплекса в целом. Большинство отечественных специализированных систем автоматизации основаны на классической архитектуре «клиент-сервер». Это даёт ряд преимуществ: работу в многопользовательском режиме, централизацию хранения данных, относительную простота реализации и т. д. Но есть и недостатки. Реализация бизнес-правил в такой системе ложится на клиентскую либо серверную часть. В первом случае приходится создавать сложные клиентские приложения, а для их модификации обновлять соответствующие приложения (или их части) у всех пользователей системы. Во втором — реализацией бизнес-правил занимается серверная сторона, т. е. СУБД. Теоретически, возможности языка SQL, как правило, использующегося для этого, достаточно широки, но и это не лучшее решение. Реализацией алгоритмов должны заниматься алгоритмические языки программирования.

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

Пришел, увидел и… внедрил!

Очень часто АСУ предприятия превращается в самоцель. Между тем, именно управленческие решения разного уровня (пусть даже принимаемые системой автоматически) — конечный результат внедрения и использования системы. Кроме того, в процессе разработки и внедрения нельзя забывать о т. н. «принципе первого лица», сформулированном ещё в советские времена академиком В. М. Глушковым: любые информационные потоки, циркулирующие в системе, должны соответствовать потребностям «первого лица» — конечного потребителя информации. Причём в его качестве может выступать не только высший менеджмент компании, но и руководители подразделений разного уровня, принимающие ответственные управленческие решения. «Принцип первого лица» поможет решить, как минимум, две важные задачи: позволит избежать превращения АСУ в «чёрный ящик», когда никто, кроме самих разработчиков, толком не понимает, что происходит в системе; функции будут оптимизированы под потребности пользователей.

При внедрении АСУ надо чётко знать, на что способна система. Возьмём системы планирования и диспетчеризации для оперативной полиграфии. Часто это всего лишь электронная версия т. н. «доски диспетчеризации», т. е. программа, отражающая снимки состояния производства в определённые моменты времени. Ни о какой реальной автоматизации речи нет, поскольку связь с производством односторонняя. Более развитые системы имеют двустороннюю связь и вдобавок следят за состоянием дел в реальном времени. Оператор может вмешаться и скорректировать план загрузки оборудования вручную, в автоматическом режиме или оставить без изменений. Высшим пилотажем считается постоянный контроль над производством со своевременным информированием всех заинтересованных служб о потенциальных и фактических отклонениях от плана, а также оптимизация процессов на основе итеративного анализа сценариев «что, если».

Предприятие ОП может получить от внедрения АСУП гораздо больший эффект, чем кажется на первый взгляд. Не секрет, что отечественные типографии практикуют скидки заказчикам по принципу «постоянный клиент» (простор для пресловутого «человеческого фактора»!). Это может оказаться убыточным, поскольку обязательный, но «неудобный» тираж может стать причиной неоптимальной загрузки оборудования, что приведёт к потерям, перекрывающим прибыль от его выполнения. Гораздо эффективнее предоставлять скидки на заказы, для выполнения которых используется минимально загруженное (или простаивающее) оборудование. Западные компании уже поняли это, и некоторые производители систем планирования и диспетчеризации для полиграфии начинают закладывать в свои продукты алгоритмы, связывающие логику управления отношений с клиентами с реальным состоянием производства.

Заключение

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

Об авторе: Олег Оксеноид, руководитель проекта АСУ ООО «Немецкая Фабрика Печати».

Системы автоматизации полиграфического предприятия, представленные на российском рынке

APP System

Разработчик: APP System.com

Система специализирована для автоматизации расчёта заказов в типографиях. Функции: расчёт стоимости выполнения заказа, работа с основными справочниками, контроль прохождения оплаты, анализ продаж и оплат, формирование отчётов по заданным критериям. Особенность — доступ к исходным кодам при покупке соответствующей лицензии. Построена по технологии «клиент-сервер», в качестве серверной части выступает СУБД Microsoft Access 2000/XP, клиентской — оригинальное ПО, созданное в среде VBA. Аппаратная платформа — IBM PC, программная — семейство ОС Microsoft Windows 9x и выше.

SyteLine

Разработчик: MAPICS; представитель в России — «Фронтстеп СНГ»

Группа программных продуктов SyteLine (SyteLine ERP/APS/Configuration/Business Intelligence/Workflow Automation) предназначена для комплексной автоматизации деятельности промышленных предприятий. На их базе разработчики предлагают отраслевые решения, в т. ч. и для полиграфии. Функции распределяются так: базовая система автоматизации SyteLine ERP — ведение клиентской базы, расчёт заказов, управление потребностями в материалах и ресурсах, планирование производства и управленческую отчётность; система усовершенствованного планирования и диспетчеризации SyteLine APS оптимизирует производственный график и моделирует сценарии производства; SyteLine Configuration — общее и детальное конфигурирование продукции, взаимодействие с внешними справочниками (каталогами и прайс-листами); SyteLine Business Intelligence — анализ структуры спроса и потребности клиентов, выявление тенденций рынка; модуль автоматизации документооборота SyteLine Workflow Automation — связь и синхронизация бизнес-процессов между партнёрами компании.

«Аплер Типография 2003»

Разработчик: Profound Solutions

Система для автоматизации всего спектра деятельности полиграфического предприятия с акцентом на расчёт заказов и производство. Основные функции: ведение списка контрагентов, расчёт заказов с поддержкой двух вариантов ценообразования (на основе набора технологических операций или по формуле «себестоимость + рентабельность»), расчёт потребности в материалах под открытые заказы, управление расходованием материалов, составление оперативных планов производства (планирование загрузки оборудования), управление складом готовой продукции, ведение управленческой отчётности. Построена по технологии «клиент-сервер», в качестве клиентского приложения используется оригинальное ПО. Поддерживается разграничение прав доступа к данным и функциям системы, на основе которого формируются автоматизированные рабочие места (АРМ) пользователей. В качестве серверной стороны выступает СУБД MS SQL Server 2000. Аппаратная платформа — IBM PC, программная платформа — ОС MS Windows 98 и выше.

«Печатный цех»

Разработчик: ФГУП «Типография ? 12 им. М. И. Лоханкова»

Система построена на базе «1C-Предприятия 7.7», чем объясняется её специализация на отчётные и аналитические функции. Основные задачи: расчёт стоимости заказов, учёт движения ТМЦ, контроль над прохождением заказа в производстве, анализ плановых и фактических показателей по производству, отчётные функции. Спроектирована на базе типовой конфигурации 1С «Бухгалтерский учёт», в которой сформирован набор АРМ — бухгалтера, специалиста планового отдела, менеджера по работе с клиентами и т. д. Аппаратная и программная платформы определяются требованиями «1C-Предприятия» (IBM PC и семейство ОС MS Windows 9x и выше, соответственно). Разработчики настаивают на использовании в качестве СУБД MS SQL Server 7.0/2000