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

Автор работы: Пользователь скрыл имя, 08 Декабря 2015 в 16:08, дипломная работа

Описание работы

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

Файлы: 1 файл

Диплом.doc

— 778.00 Кб (Скачать файл)

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

1.4. АСУ для оперативной полиграфии

 

Вряд ли найдётся сегодня отрасль, в которой активное применение современных информационных технологий не является важнейшим фактором успеха и конкурентоспособности. Господство калькулятора и 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, когда одна сущность содержит информацию и о данных, и о правилах работы с ними, очень похожа на объектно-ориентированный подход, широко применяющийся в проектировании различных систем. Это стоит принять во внимание при выборе технологий проектирования и разработки АСУ, если компания решила создавать систему собственными силами [12].

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

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

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

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

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

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

Информация о работе Разработка базы данных для автоматизированной системы склада готовой продукции малого полиграфического предприятия