Размещено на http://www.allbest.ru/

Содержание

Введение

1. АНАЛИЗ ДЕЯТЕЛЬНОСТИ ЗАО «КОМБИНАТ КРУПНОПАНЕЛЬНОГО ДОМОСТРОЕНИЯ»

1.1 Цели и задачи функционирования ЗАО «Комбинат Крупнопанельного домостроения»

1.2 Организационная структура ЗАО «Комбинат Крупнопанельного домостроения»

1.3 Автоматизация бетонно-смесительного цеха в ЗАО «Комбинат Крупнопанельного домостроения»

1.4 Исследование процесса планирования производства в бетонно-смесительном цеху

1.5 Формальная модель процесса производства в бетонно-смесительном цеху

1.6 Проблемы процесса производства в бетонно-смесительном цеху

1.7 Полная постановка задачи дипломной работы

ГЛАВА 2. МОДЕЛИРОВАНИЕ И ОПТИМИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ БЕТОННО-СМЕСИТЕЛЬНОГО ЦЕХА

2.1 Оптимизация формальной модели производства в бетонно-смесительном цеху

2.2 Математическая модель процесса планирования производства бетона

2.2 Нахождение способа и алгоритма реализации предложений по оптимизации

2.3 Реинжиниринг бизнес-процессов

2.3.1 Выбор методологии моделирования

2.3.2 Выбор CASE-средств

2.3.3 Модель бизнес-процессов с учетом реинжиниринга

ГЛАВА 3. РАЗРАБОТКА ПРОЕКТА ИНФОРМАЦИОННОЙ СИСТЕМЫ ОПТИМИЗАЦИИ РАБОТЫ БЕТОННО-СМЕСИТЕЛЬНОГО ЦЕХА ЗАО «КОМБИНАТ КРУПНОПАНЕЛЬНОГО ДОМОСТРОЕНИЯ»

3.1 Обзор существующих проектных решений, выявление их достоинств и недостатков

3.2 Выбор архитектуры информационной системы

3.4 Описание концептуальной модели информационной базы

ГЛАВА 4 РАЗРАБОТКА ИНФОРМАЦИОННЙ СИСТЕМЫ ОПТИМИЗАЦИИ РАБОТЫ БЕТОННО-СМЕСИТЕЛЬНОГО ЦЕХА ЗАО «КОМБИНАТ КРУПНОПАНЕЛЬНОГО ДОМОСТРОЕНИЯ»

4.1 Разработка модуля мониторинга складских запасов

4.1.1 Выбор языка программирования

4.1.2 Физическое описание базы данных

4.1.3 Выбор типа базы данных

4.1.4 Описание объектов базы данных

4.1.5 Описание типов блокировок

4.1.6 Описание модуля мониторинга складских запасов

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

4.2.1 Графическое представление программы

4.3 Работа с программой

4.3.1 Схема программы

ГЛАВА 5: СОЦИАЛЬНЫЙ АСПЕКТ РАЗРАБОТКИ

ГЛАВА 6: ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ

6.1 Описание целесообразности проектирования с точки зрения коммерческого использования

6.1.1 Описание предметной области

6.2 Расчет экономической эффективности проекта

6.2.1 Расчет затрат на функционирование предприятия до и после внедрения

6.2.2 Расчет экономии от увеличения производительности труда пользователя

6.2.3 Стоимостная оценка проекта

6.3 Оценка экономического эффекта от внедрения

ГЛАВА 7: Безопасность и экологичность разработки

7.1 Оценка напряженности трудового процесса

7.2 Разработка мероприятий по улучшению условий труда

7.2.1 Организационные методы

7.2.2 Организационно-технические методы

7.2.3 Технические методы

7.2.4 Основные требования к организации работы с ЭВМ

7.3 Пожарная и электробезопасность

7.3.1 Пожарная безопасность

7.3.2 Электробезопасность

7.4 Экологичность проекта

ЗАКЛЮЧЕНИЕ



Введение

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

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



1. АНАЛИЗ ДЕЯТЕЛЬНОСТИ ЗАО «КОМБИНАТ КРУПНОПАНЕЛЬНОГО ДОМОСТРОЕНИЯ»

1.1 Цели и задачи функционирования ЗАО «Комбинат Крупнопанельного домостроения»

Основной целью ЗАО «Комбинат Крупнопанельного домостроения» является получение прибыли путем эффективного использования принадлежащего ему имущества.

К задачам, которые решает ЗАО «Комбинат Крупнопанельного домостроения» относится прием заказов от физических и юридических лиц, выполнение работ по заказу клиента, уточнение требований заказчика, обеспечение его своевременной информацией о состоянии выполнения заказа [1].

ЗАО «Комбинат Крупнопанельного домостроения» выполняет следующие функции:

· Строительство объектов недвижимости;

· Проектирование объектов недвижимости;

· Реконструкция объектов недвижимости;

· Ремонт объектов недвижимости;

· Услуги перевозки крупногабаритных грузов и строительных материалов;

· Услуги лаборатории по контролю качества продукции;

· Производство железобетонных конструкций, товарного бетона и раствора.

1.2 Организационная структура ЗАО «Комбинат Крупнопанельного домостроения»

ЗАО «Комбинат Крупнопанельного домостроения» в своем составе насчитывает 8 отделов. Руководство осуществляют генерального директор, его заместитель и главный инженер. На рисунке 1.1 показана организационная диаграмма структуры ЗАО «Комбинат Крупнопанельного домостроения»:

Рисунок 1.1. Организационная структура ЗАО «Комбинат Крупнопанельного домостроения»

Опишем организационную структуру на основе приведенной диаграммы (см. таблицу 1.1)

Таблица 1.1. - Организационно-функциональная структура ЗАО «Комбинат Крупнопанельного домостроения»

№ п/п	Наименование подразделения	Функции подразделения
1	Производственно-технический отдел (ПТО)	подготовка и составление проектно-сметной документации на все виды работ
2	Отдел материально-технического снабжения (ОМТС)	обеспечение производственных подразделений предприятия материально-техническими ресурсами, подготовка и заключение договоров на поставку материально-технических ресурсов, организация рационального использования материально-технических ресурсов
3	Бухгалтерия	Формирование полной и достоверной информации о деятельности предприятия и его имущественном положении, необходимой внутренним и внешним пользователям бухгалтерской отчетности, предотвращение отрицательных результатов хозяйственной деятельности предприятия и выявление внутрихозяйственных резервов обеспечения финансовой устойчивости
4	Отдел сбыта	Осуществление сделок с клиентами, документирование сделок, взаимодействие с клиентами по вопросу выполнения заказов, поиск новых клиентов, развитие клиентско-партнерских связей, обеспечение бухгалтерии информацией о сделках
5	Аппарат управления (АУП)	сбор, систематизация, передача и обработка информации, выработка команд по управлению и реализацией выработанных решений, обеспечение предприятия кадрами, юридическое и правовое обеспечение функционирования предприятия
6	Бетонно-смесительный цех (БСЦ)	переработка поставленного ОМТС сырья, учет и контроль количества переработанного сырья, контроль качества производимого раствора и бетона
7	Участок транспорта и механизмов (УТиМ)	Разработка годовых, квартальных, месячных и оперативно-календарных планов-графиков транспортных перевозок на основе плана отгрузки готовой продукции и выполнения плана производства структурными подразделениями предприятия, контроль за своевременным выполнением планов поставок транспортных средств, тары, планов погрузочно-разгрузочных работ, обеспечение приема на склад, подготовки, хранения и отгрузки готовой продукции в номенклатуре и в сроки, установленные договорами, Оформление сопровождающей транспортные операции документации, организация рационального использования привлеченного транспорта общего пользования и контроль фактически выполненных им объемов работ
8	Линейный персонал	выполнение основных работ, осуществляемых ЗАО «Комбинат Крупнопанельного домостроения»

Перейдем от общей организационной диаграммы к ее части, которая будет подробно исследована в рамках моей дипломной работы. В качестве границ предметной области выберем конечный набор бизнес-процессов предприятия, представляющих интерес с точки зрения автоматизации и реинжиниринга. Для этого рассмотрим схему бизнес-процессов в ЗАО «Комбинат Крупнопанельного домостроения», разделяя ее на три основные группы:

1. Основные бизнес-процессы, связанные с выполнением услуг по строительству, производству товарного бетона и т.д., выполняемые рабочим персоналом предприятия;

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

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

Схема бизнес-процессов приведена на рисунке 1.2.



Рисунок 1.2. Схема бизнес-процессов ЗАО «Комбинат Крупнопанельного домостроения»

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

1.3 Автоматизация бетонно-смесительного цеха в ЗАО «Комбинат Крупнопанельного домостроения»

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

Рисунок 1.3 Интерфейс АСУТП БСУ

планирование информационный складской запас

Функции системы

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

· визуальный контроль за работой системы на табло контроллеров и дисплее компьютера;

· звуковое оповещение обслуживающего персонала в случае возникновения аварийной (нестандартной) ситуации;

· сохранения в архив полной информации о работе системы;

· распечатки рапортов и прочей необходимой информации из архива;

· связи по компьютерной сети с другими системами (компьютерами) предприятия, для оперативного обмена информацией (получения рецепта, передача данных в форматах ОРС, SQL, DBF);

· интегрирование в АСУТП цеха или завода через общезаводскую сеть.

Краткое описание работы

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

· на нижнем уровне стоят дозирующие микропроцессорные контроллеры Master 110.2, Master 110.4, Master 210.3. Это вполне самодостаточные приборы, способные управлять одно- и многокомпонентными дозаторами. При этом настройка и ввод заданий на дозирование вводятся с клавиатуры приборов. Пуск и стоп процесса дозирования могут производиться как с клавиатуры приборов, так и с внешних кнопок, в том числе и общих для всех дозаторов (пуск/стоп линии).

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

· верхний уровень - автоматизированное рабочее место оператора (АРМ). АРМ разработан на базе SCADA системы MasterSCADA и обеспечивает быстрый дистанционный ввод заданий дозирующим контроллерам, в том числе и из заранее подготовленных файлов рецептов при большом ассортименте продукции; дистанционный пуск и остановку процессов смешивания подачи сырья, отгрузки продукции и т. д. Одной из важнейших функций АРМ является протоколирование производственного процесса. Программа АРМ ведёт автоматический учёт расходуемого сырья, журналы аварийных и технологических сообщений, при необходимости формирует и хранит тренды токовых нагрузок оборудования, температурных режимов и т.д., выдаёт и хранит отчёты по каждому произведённому отвесу дозаторов. Обмен информацией с дозирующими контроллерами осуществляется по интерфейсу RS 485, с управляющим контроллером - по сети Ethernet.

Технические характеристики

· Система обеспечивает управление до 32х одно- и (или) многокомпонентных дозаторов

· Точность дозирования, в зависимости от типов дозирующих контроллеров и применяемых приводов дозаторов, 0,1% 0,3% от наибольшего предела взвешивания дозатора

· Система рассчитана на круглосуточную работу при температуре +5°C +45°С и влажности воздуха 85%, без образования конденсата

· Питание системы осуществляется от сети ~220 В. Потребляемая мощность до 0,4 кВт.

1.4 Исследование процесса планирования производства в бетонно-смесительном цеху

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

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



Рисунок 1.4 Сценарий работы бетонно-смесительного цеха

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

1. Каждая смена начинает работу с получения заказ-нарядов на производство, при этом неотработанные прошлой сменой заказ-наряды поступают в новую.

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

3. Необходимое для производства сырье доставляется в цех

4. Параллельно диспетчер производства вносит программу в АСУ ТП, и готовит ее к запуску.

5. Выполняется производство и отгрузка бетона.

В приведенном сценарии видно, что не учитываются два важных момента:

1. Не учитывается фактическая доступность сырья и его количество

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

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

1.5 Формальная модель процесса производства в бетонно-смесительном цеху

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

S = {S1,…, S5}.



Однако каждое состояние системы Si представляет собой совокупность трех состояний: начальное состояние Si0, внутреннее состояние Si и конечное состояние Sik.

Si = {Si0, Si, Sik}, где i = 1,…,12.

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

C = {C1,…C4}

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

Так как при наступлении события Сi система должна развиваться строго по заданному направлению и занять определенное состояние системы, то мы можем полагать, что нам заранее известна функция перехода системы из состояния в состояние - F = {F1,…F12}, где i = 1,…,12 (также имеет двенадцать нумераций, т.к. после утилизации начинается новый виток жизненного цикла).

Если исходное состояние системы Sik, а состояние, в которое необходимо перейти автомату Si+1;0 при наступлении какого-либо события Сi, то по функции перехода новое состояние определяется как Si+1;0=Fi( Sik,Ci) (Рис.1.3).

Рисунок 1.3 - Наступление события Ci и переход системы из состояния Sik в состояние Si+1,0 по функции перехода Fi( Sik,Ci).

Причем нахождение системы в том или ином состоянии и время перехода из состояния в состояние должно быть минимизировано.

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

Si+1;0(t+1)=Fi((Sik(t),Ci), где i = 1,…,12 и промежуток времени нахождения системы в определенном состоянии (определенном этапе) стремится к минимуму. При этом время длительности события Ci считается ничтожно малым.

Таким образом, каждое предприятие можно представить диаграммой состояний - в виде графа. Причем вершинами данного графа являются состояния данной системы - множество S, а дуги, заданные функциями перехода Fi, - переходы из состояния в состояние. Данный граф и является конечным автоматом (далее - КА) (рис.1.5). Причем на каждом этапе развития КА начинает работать из состояния Si0.



Рисунок 1.5 - Конечный автомат формальной модели процесса планирования и производства

В таблице 1.2. Дано описание графа.

Таблица 1.2. - Описание графа конечного автомата.

Состояние	Начальное состояние Si 0	Внутреннее состояние Si	Конечное состояние Sik	Событие входа Ci	Событие выхода Cj
Подготовка производства	Получены заказ-наряды	Выбран заказ-наряд	Выбранный заказ передан в производство	-/Производственный цикл окончен	Получены заказ-наряды
Получение сырья	Определено необходимое сырье	Сырье запрошено	Сырье получено	Получены заказ-наряды	Получено сырьё
Программа АСУ ТП	Получен заказ-наряд и объемы производства	Программа вносится в АСУ ТП	Программа внесена и готова к запуску	Получено сырьё	Программа введена
Производство	Загрузка сырья	Производство	Подготовка к отгрузке	Программа введена	Бетон произведен
Отгрузка	Бетон готов к отгрузке	Погрузка в цистерны	Отправка	Бетон произведен	Производственный цикл окончен

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

1.6 Проблемы процесса производства в бетонно-смесительном цеху

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

Основная проблема формулируется достаточно просто: Отсутствие средств оперативного планирования производства.

Эта проблема связана со следующими недочетами и вызывает ряд негативных последствий:

· Наличие на складе по результатам производства большого числа неиспользованных материалов;

· Снижение прибыли предприятия за счет утраченной выгоды;

· Отсутствие обратной связи между процессом производства и процессом планирования.

1.7 Полная постановка задачи дипломной работы

Целью моей работы является оптимизация работы по производству бетона в бетонно-смесительном цеху ЗАО «Комбинат Крупнопанельного домостроения: следует ввести механизмы, позволяющие моделировать с математической точки зрения процесс производства и осуществлять на основе этой модели оперативное планирование производства. Это позволит использовать более эффективным способом имеющиеся у предприятия запасы сырья. В рамках цели предполагается решение следующих задач:

1) оптимизация математической модели;

2) реинжиниринг бизнес-процессов производства;

3) проектирование информационной системы;

4) разработка информационной системы;

5) технико-экономическое обоснование разработки;

6) освещение вопросов безопасности жизнедеятельности и экологичности проекта;

7) оценка социальной значимости разработки.



ГЛАВА 2. МОДЕЛИРОВАНИЕ И ОПТИМИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ БЕТОННО-СМЕСИТЕЛЬНОГО ЦЕХА

Раздел дипломной работы описывает результаты оптимизации исследуемой предметной области, как в математическом представлении, так и в визуальном.

2.1 Оптимизация формальной модели производства в бетонно-смесительном цеху

Перейдем к оптимизации полученной в п. 1.4 формальной модели. Введем недостающую обратную связь между процессами производства и планирования и состояние расчета плана производства. Таким образом, будет получена новая диаграмма состояний - в виде графа. Данный граф также является конечным автоматом (рис.2.1). Причем на каждом этапе развития КА продолжает работать из состояния Si0.



Рисунок 2.1 - Конечный автомат оптимизированной формальной модели

Таблица 2.1. - Описание графа конечного автомата.

Состояние	Начальное состояние Si 0	Внутреннее состояние Si	Конечное состояние Sik	Событие входа Ci	Событие выхода Cj
Подготовка производства	Получены заказ-наряды	Выбран заказ-наряд	Выбранный заказ передан в производство	-/Производственный цикл окончен	Получены заказ-наряды
Расчет плана производства	Получены заказ-наряды и данные о запасах сырья	Расчет плана производства	План производства рассчитан	Получены заказ-наряды	Определен план производства
Получение сырья	Определено необходимое сырье	Сырье запрошено	Сырье получено	Получены заказ-наряды	Получено сырьё
Программа АСУ ТП	Получен заказ-наряд и объемы производства	Программа вносится в АСУ ТП	Программа внесена и готова к запуску	Получено сырьё	Программа введена
Производство	Загрузка сырья	Производство	Подготовка к отгрузке	Программа введена	Бетон произведен
Отгрузка	Бетон готов к отгрузке	Погрузка в цистерны	Отправка	Бетон произведен	Производственный цикл окончен

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

2.2 Математическая модель процесса планирования производства бетона

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

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

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

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

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

Нужно определить максимум линейной целевой функции (линейной формы)

при условиях

при .

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

Такую задачу называют "основной" или "стандартной" в линейном программировании.

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

Задача линейного целочисленного программирования формируется следующим образом: найти такое решение (план) X = (x1,x2,...,xn), при котором линейная функция

(1)

принимает максимальное или минимальное значение при ограничениях

=bi, i=1, 2…,m. (2)

хj 0, j=1, 2,...,n.(3)

xj -- целые числа (4)

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

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

Задачи линейного программирования имеет следующий вид:

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

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

Некоторое предприятие производит n типов продукции, затрачивая при этом m типов ресурсов. Известны следующие параметры: aij - количество i-го ресурса, необходимое для производства единичного количества j-й продукции; aij0 (i=1,…,m; j=1,…,n);

bi-запас i-го ресурса на предприятии, bi>0;

cj-цена единичного количества j-й продукции, cj>0.

Предполагается, что затраты ресурсов растут прямо пропорционально объему производства. Пусть xj - планируемый объем производства j-й продукции. Тогда допустимым является только такой набор производимой продукции x=(x1,x2,…,xn), при котором суммарные затраты каждого вида i-го ресурса не превосходят его запаса:

(1)

Кроме того, имеем следующее ограничение: xj0; j=1,…,n. (2)

Стоимость набора продукции x выражается величиной: (3)

Задача планирования производства ставится следующим образом: среди всех векторов x, удовлетворяющим ограничениям (1), (2), найти такой, при котором величина (3) принимает наибольшее значение.

Алгоритм симплекс-метода формулируется для задачи линейного программирования следующим образом:

Шаг 1. Формулировка задачи линейного программирования в канонической форме на основе метода искусственного базиса, так чтобы в матрице ограничений существовала единичная базисная матрица. Для этого необходимо дополнить матрицу ограничений единичными столбцами, которые должны в совокупности с исходными столбцами матрицы ограничений обеспечивать существование единичной базисной матрицы. При этом естественным образом должны быть введены соответствующие искусственные переменные, которые включаются в целевую функцию с большими положительными весовыми коэффициентами для задачи на минимум. В результате запишем исходную матрицу ограничений . в симплекс-таблицу(*), а коэффициенты целевой функции запишем в строку этой таблицы. В таблицу 2.2. также включим компоненты исходного базисного решения, определяемого вектором



Таблица 2.2 - Симплекс-таблица

#№

Базисные столбцы

Bs

Базисное решение Xs

C1

C2

…

Cm

Cm+1

…

Ck

…

Cn

A1

A2

…

Am

Am+1

…

Ak

…

An

1

A1

1

0

…

0

…

…

2

A2

0

1

…

0

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

l

Al

0

0

…

0

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

m

Am

0

0

…

1

…

…

Оценки

…

…

…

Шаг 2. Вычисление характеристических разностей (оценок) по формулам и запись оценок в -ю строку симплекс-таблицы.

Шаг 3. Вычисление оценки , удовлетворяющей условию:

Если все , то в соответствии с выполнением критерия оптимальности вектор -- оптимальное решение, и далее следует перейти к шагу 9, иначе -- к шагу 4.

Шаг 4. Вычисление нового базисного решения из условия:

Шаг 5. Вычисление компонент нового базисного решения по формулам:

Шаг 6. Вычисление элементов новой симплекс-таблицы для -й итерации метода по формулам:

Шаг 7. Корректировка симплекс-таблицы с учетом изменений коэффициентов целевой функции, соответствующих новому базисному решению.

Шаг 8. Переход к шагу 2.

Шаг 9. Остановка, регистрация оптимального решения.

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

2.2 Нахождение способа и алгоритма реализации предложений по оптимизации

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

Алгоритм показан на блок - схеме (см. рисунок 2.2):



Рисунок 2.2 - Блок-схема алгоритма работы механизма расчета плана производства

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

- Расширение должностных обязанностей имеющихся сотрудников и моделирование ими вручную;

- Наём дополнительных сотрудников и моделирование ими вручную;

- Разработка и внедрение информационной системы;

1. Выберем критерии, по которым будем сравнивать механизмы и упорядочим их по важности:

1. Скорость формулировки плана;

2. Скорость сбора данных;

3. Затраты на создание;

4. Затраты на использование.

2. Присвоим наиболее важному критерию оценку 100 баллов. Исходя из попарного отношения критериев по важности, дадим в баллах оценку каждому из критериев (таблица 2.3):

Таблица 2.3 - Оценка критериев

Критерии	Баллы
Скорость формулировки	100
Скорость сбора данных	85
Затраты на создание	65
Затраты на использование	40

3.Сложить полученные баллы. Произведём нормировку весов критериев, разделив присвоенные баллы на сумму весов:

Wi = ,

где Ai - баллы критерия,

n - количество критериев.

Результаты нормировки приведены в таблице 2.4.



Таблица 2.4 - Нормирование оценки критериев

Критерии	Баллы	Нормированный балл
Скорость формулировки	100	0,344827586
Скорость сбора данных	85	0,293103448
Затраты на создание	65	0,224137931
Затраты на использование	40	0,137931034
Сумма баллов	290	1

4. Измерить значение каждой альтернативы по каждому из критериев по шкале от 0 до 100 баллов.

Таблица 2.5 - Измерение альтернатив по каждому критерию

Альтернативы	Критерии
	Скорость формулировки	Скорость сбора данных	Затраты на создание	Затраты на использование
Имеющиеся сотрудники	50	50	95	95
Дополнительный сотрудник	70	60	50	50
Информационная система	90	85	50	80

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

где Вi оценка альтернативы по каждому критерию (таблица 2.6)



Таблица 2.6 - Общие оценки альтернатив

Альтернативы	Критерии
	Скорость формулировки	Скорость сбора данных	Затраты на создание	Затраты на использование	Общая оценка
Имеющиеся сотрудники	17,241379	14,655172	21,293103	13,103448	66,293103
Дополнительный сотрудник	24,137931	17,586206	11,206896	6,8965517	59,827586
Информационная система	31,034482	24,913793	11,206896	11,034482	78,189655

6.Выбрать как лучшую альтернативу, имеющую наибольшую общую оценку.

Вывод: лучшей альтернативой является Информационная система.

2.3 Реинжиниринг бизнес-процессов

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

2.3.1 Выбор методологии моделирования

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

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

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

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

Функциональная методика IDEF0. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique) [3]. Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

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

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

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

· верхняя сторона имеет значение "Управление" (Control);

· левая сторона имеет значение "Вход" (Input);

· правая сторона имеет значение "Выход" (Output);

· нижняя сторона имеет значение "Механизм" (Mechanism).

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

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

В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей".

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 -- диаграмм, функциональных блоков, интерфейсных дуг -- существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения(Viewpoint).

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

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

Выделение подпроцессов. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком - Child Box). В свою очередь, функциональный блок -- предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели.

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот -- отдельные дуги нижнего отражать на диаграммах более высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, - в таком случае они сначала "погружаются в туннель", а затем при необходимости "возвращаются из туннеля".

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

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

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

· Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:

Что поступает в подразделение "на входе"?

o Какие функции и в какой последовательности выполняются в рамках подразделения?

o Кто является ответственным за выполнение каждой из функций?

o Чем руководствуется исполнитель при выполнении каждой из функций?

o Что является результатом работы подразделения (на выходе)?

На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

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

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

Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов:

· абстрагирование;

· инкапсуляция;

· модульность;

· иерархия;

· типизация;

· параллелизм;

· устойчивость.

Основными понятиями объектно-ориентированного подхода являются объект и класс.

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

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

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

Диаграмма (Diagram) -- это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы.

Объектно-ориентированный подход обладает следующими преимуществами:

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

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

· Объектная модель естественна, поскольку ориентированна на человеческое восприятие мира.

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

Сравнение существующих методик

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

Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу "сверху-вниз", когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления.

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

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

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

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

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

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