Контрольная работа моделирование бизнес процессов

Моделирование бизнес-процессов

СОДЕРЖАНИЕ

Введение

1. Моделирование бизнес-процессов

2. Классификация бизнес-процессов

3. Стандарты моделирования бизнес-процессов

Заключение

Список используемых источников

ВВЕДЕНИЕ

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

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

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

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

1. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

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

Существует несколько
подходов к определению понятия «моделирование бизнес-процессов»:

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

моделирование
бизнес-процессов —
это эффективное средство поиска возможностей улучшения деятельности
предприятия;

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

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

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

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

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

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

Рисунок 1 — Причины, по которым
принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает
многие аспекты деятельности компании:

изменение
организационной структуры;

оптимизацию
функций подразделений и сотрудников;

перераспределение
прав и обязанностей руководителей;

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

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

Моделирование
бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов
организации может выполняться в нотации IDEF0 с использованием инструментария
BPwin или на языке UML с использованием инструментария Rational Rose. Детальное
моделирование выполняется на языке UML.

На этапе структурного
моделирования в модели должны быть отражены:

существующая
организационная структура;

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

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

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

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

Детальная модель
бизнес-процесса должна включать:

набор прецедентов
отражающих возможные варианты выполнения бизнес-процессов «как есть»;

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

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

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

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

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

Бизнес-Модель — это то, что делает компания и
благодаря чему она зарабатывает деньги (Том Мэлоун)

Бизнес-стратегия есть теория, бизнес-модель —
гипотеза (Николас Карр)

Бизнес-модель — это представление набора связанных
модельных элементов, определяющих внутреннюю и внешнюю среду компании в рамках
единой системы [2].

2. КЛАССИФИКАЦИЯ
БИЗНЕС-ПРОЦЕССОВ

Выделяют
следующую классификацию [5]:

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

горизонтальные процессы –
процессы, отражающие взаимодействие по горизонтали;

индивидуальные
горизонтальные процессы – процессы, выполняемые отдельными работниками
(организационными единицами);

межфункциональные
горизонтальные процессы – процессы, выполняемые многими работниками
(организационными единицами);

вертикальные процессы –
процессы, отражающие взаимодействие работников (организационных единиц) по
вертикали;

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

В зависимости от степени
их сложности выделяют:

монопроцессы –
односложные процессы;

вложенные процессы —
монопроцессы, входящие в состав более сложного процесса (макропроцесса);

связанные процессы –
выделенные и последовательно реализуемые по определенному алгоритму
монопроцессы.

В зависимости от их
предназначения:

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

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

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

В зависимости от их места
в иерархии целей организации:

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

бизнес-процессы среднего
уровня – бизнес-процессы, направленные на реализацию тактических целей;

бизнес-процессы нижнего
уровня бизнес-процессы, направленные на реализацию оперативных целей.

В зависимости от степени
их детализации [4]:

субпроцессы –
бизнес-процессы имеющие степень детализации необходимую для описания бизнес-процессов
среднего уровня;

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

В рамках основных
составляющих сбалансированной системы показателей:

финансовые
бизнес-процессы;

клиентские бизнес-процессы;

бизнес – процессы
производства;

бизнес-процессы развития,
обучения и роста.

3. СТАНДАРТЫ
МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ

Стандарт
функционального моделирования IDEF0

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

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

Модель IDEF0 представляет собой серию диаграмм с сопроводительной
документацией, разбивающих сложный объект на составные части, которые
изображены в виде блоков. Детали каждого из основных блоков показаны в виде
блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией
блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма
предыдущего уровня называется родительской для более детальной диаграммы. Общее
число уровней в модели (включая контекстный) не должно превышать 5-6. Практика
показывает, что этого вполне достаточно для построения полной функциональной
модели современного предприятия любой отрасли [2].

Стандарт
информационного моделирования IDEF1

Стандарт IDEF1 был
разработан как инструмент для анализа и изучения взаимосвязей между
информационными потоками в рамках коммерческой деятельности предприятия.
Применение методологии IDEF1 как инструмента построения наглядной модели
информационной структуры предприятия по принципу «как должно быть». Пример построения
модели показан на рисунке 2.

Рисунок 2 – Пример
построения модели IDEF1

Основными составляющими
компонентами информационной модели являются:

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

словарь – значение
каждого элемента модели описывается текстовым фрагментом.

Базовым понятием в
методологии IDEF1 является понятие сущности. Сущность определяется как
реальный или абстрактный объект, набор отличительных свойств которого,
называемых атрибутами, известен. Каждая сущность имеет имя и атрибуты [2].

Стандарт
динамического моделирования IDEF2

IDEF2 — Simulation Model Design —
методология динамического моделирования развития систем.

В связи с весьма
серьезными сложностями анализа динамических систем от этого стандарта
практически отказались, и его развитие приостановилось на самом начальном
этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации,
позволяющие превращать набор статических диаграмм IDEF0 в динамические модели,
построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);

Стандарт моделирования
процессов IDEF3 –
IDEF14

Как и в методе IDEF0,
основной единицей модели IDEF3 является диаграмма. Другой важный компонент
модели — действие, или в терминах IDEF3 «единица работы». Диаграммы
IDEF3 отображают действие в виде прямоугольника. Действия именуются с
использованием глаголов или отглагольных существительных, каждому из действий
присваивается уникальный идентификационный номер. Этот номер не используется
вновь даже в том случае, если в процессе построения модели действие удаляется.
В диаграммах IDEF3 номер действия обычно предваряется номером его родителя [2].

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

Соединения «и»
инициируют выполнение конечных действий. Все действия, присоединенные к
сворачивающему соединению «и», должны завершиться, прежде чем
начнется выполнение следующего действия. После обнаружения пожара инициируются
включение пожарной сигнализации, вызов пожарной охраны, и начинается тушение
пожара. Запись в журнал производится только тогда, когда все три перечисленных
действия завершены [2].

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

Соединение
«или» предназначено для описания ситуаций, которые не могут быть
описаны двумя предыдущими типами соединений. Аналогично связи нечеткого
отношения соединение «или» в основном определяется и описывается
непосредственно аналитиком. Соединение J2 может активизировать проверку данных
чека и/или проверку суммы наличных. Проверка чека инициируется, если покупатель
желает расплатиться чеком, проверка суммы наличных — при оплате наличными. И
то, и другое действие инициируются при частичной оплате, как чеком, так и
наличными [2].

IDEF4 – методология построения объектно-ориентированных
систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и
заложенные принципы их взаимодействия, тем самым позволяя анализировать и
оптимизировать сложные объектно-ориентированные системы [2].

IDEF5 – методология исследования сложных
систем.

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

IDEF6 — Design Rationale Capture — Обоснование проектных действий.
Назначение IDEF6 состоит в облегчении получения «знаний о способе»
моделирования, их представления и использования при разработке систем
управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства,
скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще
говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель
получилась такой, какой получилась?» Большинство методов моделирования
фокусируются на собственно получаемых моделях, а не на процессе их создания.
Метод IDEF6 акцентирует внимание именно на процессе создания модели [2].

IDEF7 —
Information System Auditing — Аудит информационных систем. Этот
метод определён как востребованный, однако так и не был полностью разработан
[2].

IDEF8 — User Interface Modeling — Метод разработки интерфейсов
взаимодействия оператора и системы (пользовательских интерфейсов). Современные
среды разработки пользовательских интерфейсов в большей степени создают внешний
вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на
программировании желаемого взаимного поведения интерфейса и пользователя на
трех уровнях: выполняемой операции (что это за операция); сценарии
взаимодействия, определяемом специфической ролью пользователя (по какому
сценарию она должна выполняться тем или иным пользователем); и, наконец, на
деталях интерфейса (какие элементы управления, предлагает интерфейс для
выполнения операции) [2].

IDEF9 — Scenario-Driven IS Design (Business Constraint Discovery
method) — Метод исследования бизнес ограничений был разработан для
облегчения обнаружения и анализа ограничений в условиях которых действует
предприятие. Обычно, при построении моделей описанию ограничений, оказывающих
влияние на протекание процессов на предприятии уделяется недостаточное
внимание. Знания об основных ограничениях и характере их влияния, закладываемые
в модели, в лучшем случае остаются неполными, несогласованными, распределенными
нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что
построенные модели нежизнеспособны, просто их реализация столкнется с
непредвиденными трудностями, в результате чего их потенциал будет не
реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании
структур или адаптации к предсказываемым изменениям, знания о существующих
ограничениях имеют критическое значение [2].

IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный,
однако так и не был полностью разработан [2].

IDEF11 — Information Artifact Modeling. Этот метод определён как
востребованный, однако так и не был полностью разработан [2].

IDEF12 — Organization Modeling — Организационное моделирование. Этот
метод определён как востребованный, однако так и не был полностью разработан
[2].

IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование
преобразования данных. Этот метод определён как востребованный, однако так и не
был полностью разработан [2].

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

Стандарт
моделирования потоков данных DFD

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

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

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

внешние сущности;

системы и подсистемы;

процессы;

накопители данных;

потоки данных.

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

Подсистема (или система)
на контекстной диаграмме изображается так, как она представлена на рисунке 3.

Рисунок 3 – Подсистема
по работе с физическими лицами (ГНИ — Государственная налоговая инспекция)

Номер подсистемы служит
для ее идентификации. В поле имени вводится наименование подсистемы в виде
предложения с подлежащим и соответствующими определениями и дополнениями.

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

Процесс на диаграмме
потоков данных изображается, как показано на рисунке 4.

Рисунок 4 –
Графическое изображение процесса

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

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

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

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

Накопитель данных
идентифицируется буквой «D» и произвольным числом. Имя накопителя
выбирается из соображения наибольшей информативности для проектировщика.

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

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

Построение
иерархии диаграмм потоков данных.

Главная цель построения
иерархии DFD заключается в том, чтобы сделать описание системы ясным и понятным
на каждом уровне детализации, а также разбить его на части с точно
определенными отношениями между ними [3].

ЗАКЛЮЧЕНИЕ

В последние годы интерес
в России к методологиям семейства IDEF неуклонно растет. При этом интерес к
таким стандартам, как IDEF3–5 является теоретическим, а к IDEF0 вполне
практически обоснованным.

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1.  
Войнов И.В.
Моделирование экономических систем и процессов. Опыт построения ARIS-моделей
[Текст]: монография / И.В. Войнов – М.: ЮУрГУ, 2002. – 392 с.

2.  
Волков О.Н. Стандарты и методологии моделирования бизнес-процессов [Текст]:
учеб. пособие для вузов / О.Н. Волков. – М.: АСВ, 2000. – 145 с.

3.  
Григорьев Д.И.
Моделирование бизнес-процессов предприятия [Текст]: учеб. пособие / Д.И.
Григорьев. – М.: ИРЦ, 2006. – 214 с.

4.  
Калянов Г.Н.
Моделирование, анализ, реорганизация и автоматизация бизнес-процессов [Текст]:
учеб. пособие / Г.Н. Калянов. – М.: Финансы и статистика, 2006. – 319 с.

5.  
Пинаев Д.К. Моделирование
бизнес-процессов: доступно о сложном [Текст]: справ. пособие / Д.К. Пинаев. –
М.: РГАС, 2003. – 247 с.

Контрольная работа: Моделирование основных бизнес-процессов предприятия

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ РФ

НОУ ВПО «СИБИРСКАЯ АКАДЕМИЯ ПРАВА, ЭКОНОМИКИ И УПРАВЛЕНИЯ»

Факультет: Компьютерных Технологий и Информационных Систем

Кафедра Информационных Систем

ДИПЛОМНАЯ РАБОТА

«Моделирование основных бизнес-процессов предприятия»

Иркутск 2009

Содержание

Содержание

Введение

1. Теоретическая часть

1.1 Формирование требований как основной этап в разработке АИС

1.2 Функциональное моделирование бизнес-процессов

1.3 Среда бизнес моделирования BPwin

2. Практическая часть

2.1 Анализ деятельности ОАО «АНХК» и структуры предприятия

2.1 Анализ проблемы автоматизированных информационных систем ОАО «АНХК»

2.2 Изучение задач управления

2.3 Описание входной информации

2.5 Описание выходной информации

3. Алгоритм функционирования системы моделирования и его описание

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

3.2 Создание диаграмм декомпозиций

3.3 Создание диаграммы дерева узлов и диаграммы FEO

Список литературы

Введение

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

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

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

Такое положение дел во многом обусловило путь, по которому проводилась автоматизация различных иерархических уровней управления, проектировались и развивались автоматизированные системы на предприятиях нефтехимической отрасли. Наибольшее применение получили автоматизированные системы управления технологическими процессами (АСУ ТП) [5–8] и системы автоматизации управленческой и финансово-хозяйственной деятельностью (АСУП) [9]. Гораздо более скромное распространение получили автоматизированные системы оперативного управления [4,10,11] как производством в целом, так и отдельными цехами (так называемые системы верхнего уровня АСУ ТП или автоматизированные системы оперативно-диспетчерского управления – АСОДУ) [12].

Системы АСУ ТП и АСУП – развивались обособленно и независимо друг от друга [13–14]. Они проектировались и создавались исходя из требований разных подразделений предприятия и в соответствии с различными потребностями. Изначально они не были подчинены единым целям и задачам, оставались слабо связанными физически и информационно, а зачастую и не связанными вообще.

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

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

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

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

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

Переход предприятий в «частную собственность» перераспределил и существенно расширил круг задач, требующих решения на химических и нефтехимических производствах. «Когда на предприятии появился хозяин, возникла потребность в получении объективных данных, характеризующих состояние производства и определяющих конечный результат его деятельности. Такими данными является информация о реальном ходе технологических процессов, расходе материалов и, сырья, выпуске готовой продукции и многих других факторах» [17, 18]. К тому же, помимо традиционных задач контроля и управления, появилась необходимость в решении задач минимизации технологических потерь, ужесточении контроля качества выпускаемой продукции, стратегического планирования, логистики, и ряда других.

Свою лепту в изменение ситуации внесло образование вертикально-интегрированных нефтяных компаний (ВИНК). Термин «вертикально-интегрированные» означает, что эти компании охватывают всю цепочку нефтяного бизнеса: разведку и добычу нефти, нефтепереработку и нефтехимию, оптовый и розничный сбыты продукции (рис. 1).

/>

Рис. 1. Схема вертикально-интегрированных нефтяных компаний

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

—PAGE_BREAK—

Задача управления текущей деятельностью для российских ВИНК в основном сосредоточена на размещении собственных добываемых сырьевых ресурсов по определенным направлениям [19]. А это, в свою очередь, ставит ВИНК в зависимость от того, насколько полной, достоверной и оперативной будет информация о состоянии производства, выработки, запасах продукции, её качестве от собственных нефтеперерабатывающих заводов и нефтехимических производств.

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

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

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

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

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

анализ работы предприятия

теоретическое исследование состояния конкретной проблемы – разработка бизнес модели;

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

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

разработка методологических подходов, предложений и указаний по планированию, организации и совершенствованию;

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

изучить документооборот и информационные потоки, реализующие бизнес-процессы;

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

анализ современного состояния развития технологий разработки бизнес моделей и промышленных технологий проектирования ПО.

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

1. Теоретическая часть

1.1 Формирование требований как основной этап в разработке АИС

«Требование – это условие или возможность, которой должна соответствовать система»1.

ВIEEE Standard Glossary of Software Engineering Terminology (1990) [2.1] данноепонятиетрактуетсяшире. Требование – это:

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

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

документированное представление условий или возможностей для пунктов 1 и 2.

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

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

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

Насколько подробно Заказчику следует регламентировать требования к проекту – вопрос риторический. Ответ на него зависит о множества факторов, таких, как ценность конечного продукта для Заказчика, степень доверия Заказчика к Разработчику, сумма подписанного контракта, увязка срока сдачи продукта в эксплуатацию с бизнес-планами Заказчика и т.д. Однако со всей определенностью можно сказать следующее:

регламентация процесса Заказчиком позволяет снизить его риски;

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

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

Разработчик представляет Заказчику согласованный план работ c детализацией (WorkBreakdownStructure – WBS) с точностью до конкретных исполнителей.

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

Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме online в интегрированной среде разработки Rational ClearCase с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий.

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

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

Обычно выделяют три уровня требований.

На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.

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

Третий уровень – функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

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

Важные правила внедрения и использования АИС на предприятии – «Одна точка сбора», «Данные собираются там, где они появляются». Использование этих правил позволяет избежать затрат на необоснованное дублирование информации и, что важнее – потерь от ошибок учета, неизбежно возникающих при дублировании точек ввода.

    продолжение
—PAGE_BREAK—

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

Анализ требований – один из основных рабочих потоков (workflow) программной инженерии, наряду с проектирование интерфейса пользователя, либо программированием.

Для его обозначения в англоязычной литературе, как правило, используется понятие «Requirement Process». В отечественной практике, наряду с обобщающим термином «анализ требований», принятым, в частности, в ГОСТ Р ИСО/МЭК 12207–99, встречаются также такие термины, как «поток работ «требования», «работа с требованиями», «определение требований» и т.д., что вносит изрядную путаницу. Для того чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK, и введем терминологию, которой будет применяться в дипломной работе.

SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:

Requirements Elicitation (Извлечение требований),

Requirements Analysis (Анализ требований в узком смысле),

Requirements Specification (Специфицирование требований),

Requirements Validation (Проверка требований).

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

Analyze the Problem (Анализпроблемы),

Understand Stakeholder Needs (Понимание потребностей совладельцев),

Define the System (Определение системы),

Manage the Scope of the System (Управлениеконтекстомсистемы),

Refine the System Definition (Уточнение определения системы).

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

Формирование видения;

Выявление требований;

Классификация и спецификация требований;

Расширенный анализ требований (моделирование и прототипирование);

Документирование требований;

Проверка требований;

Управление требованиями;

Совершенствование процесса работы с требованиями.

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

Найти ответ на первый вопрос может помочь общая классификация задач, работ и операций программной инженерии, представленная в ГОСТ Р ИСО/МЭК 12207–99. Другая, более поздняя по времени классификация, присутствует в SWEBOK. Однако нужно отметить, что данные руководящие документы рассматривают общий случай, а в частном проекте может быть задействован далеко не весь арсенал работ.

Сложнее – с решением второго вопроса. На сегодня существуют и имеют примеры успешного применения десятки и сотни различных методологий (процессов), среди наиболее известных – MSF, RUP, Oracle PJM, XP, FDD, SCRUM, PSP, Crystal, DSDM. Методологии подразделяются на 3 «волны»: каскадные (исторически первые), прогнозирующие (например, RUP) и «быстрые» (agile), вошедшие в широкую практику на рубеже тысячелетий [4.3].

Описания методологий существенно разняться объемом (от десятков до тысяч страниц текста), наборами базовых работ и рабочих квалификаций, акцентами (работа с моделями, управление рисками, построение команды и пр.). Но авторы их описаний обычно сходятся в одном: лучшая из методологий, которой нужно следовать, чтобы добиться успеха – именно та, которую предлагает (описывает, рекламирует) автор. Редким исключением являются работы А. Коберна, автора группы методологий Crystal, где он предлагает брать за основу не «самый лучший» из процессов, а тот, который, во-первых, наилучшим образом соответствует проектной задаче, а во вторых – команде, которая будет его реализовывать. В [24.3] вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.

Не все работы и операции, известные в программной инженерии, используются в той или иной методологии и, тем более, конкретном проекте. рабочий поток АТ является несомненно необходимым в цепочке рабочих потоков создания информационной системы и на него несомненно стоит тратить время. Проанализировав требуемый объем результатов от АТ можно утверждать что как этап разработки ИС, невозможно пропустить АТ, этот этап закладывает фундамент всего процесса проектирования и реализации системы. Уровень проработки АТ может быть различным: от совершенно неформальной записки, представленной на одной странице, до развернутой системы документов, моделей и прототипов, построенной в соответствии с принципами одной из прогнозирующих методологий, например, RUP. Это зависит от следующих основных факторов: размеров проекта, величины имеющихся ресурсов и степени рисков. Невысокая глубина проработки приемлема для небольших проектов, характеризующихся небольшим ресурсом и невысокими рисками. Хорошо проработанные требования позволяют:

выработать общее понимание между Заказчиком и Разработчиком;

определить рамки проекта;

более точно определить финансовые и временные характеристики проекта;

обезопасить Заказчика от риска получить продукт, в котором он не сможет работать,

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

Анализ требований – это процесс (бизнес-процесс) и, следовательно, к нему подходят методы и средства процессного подхода к управлению2.

Один из ключевых вопросов, позволяющих оценить результативность процесса – что является выходом (результатом) процесса. В чем результат АТ? Результатом рабочего потока «анализ требований» является набор артефактов. Это могут быть текстовые документы, модели UML, либо других языков моделирования, прототипы программного обеспечения.

Проанализируем другой важный вопрос – какие цели преследует процесс. RUP предлагает следующие цели для потока работ АТ:

добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система;

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

определить границы системы;

определить интерфейс пользователя и системы.

Выдвинутые цели отражены в рис. 2

/>

Рис. 2. Контекст технологической операции проектирования

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

1.2 Функциональное моделирование бизнес-процессов

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

Заказчик и Разработчик всегда говорят на разных языках. Общее понимание вырабатывается с трудом, этот процесс занимает время, но важность его трудно переоценить: ведь успешная реализация проекта в области и внедрения АИС во многом зависит от того, удастся ли выработать и документировать их общее представление о предмете разработки. Если же Разработчик идет еще дальше и вникает в особенности ведения дел на предприятии Заказчика – он, во-первых, сможет добиться лучшего понимания требований к АИС и, во-вторых, участвовать наряду с Заказчиком в формулировке требований, анализе пропущенных требований и пр.

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

Что бы решить этот вопрос надо определить цели и задачи самого бизнес-анализа, как этапа построения КИС.

    продолжение
—PAGE_BREAK—

С позиций моделирования, анализ требований (АТ) и анализ проблемной области (АПО) – принципиально разные процессы.

АПО преследует классические цели создания модели: налицо объект (автоматизируемое предприятие или организационная система4, ОС) и задача аналитика – отразить этот объект в создаваемой модели с требуемой степенью точности схема процесса разработки представлена на рисунке 3.

/>

Рис. 3 Схема процесса разработки КИС

Анализ требований, напротив, направлен на моделирование воображаемого, еще не существующего объекта (АИС). Т.е. сначала создается модель, а затем, на ее основании, синтезируется объект. Рассмотрим теперь обобщенную «формулу» создания АИС.

ОС->М(ОС)->М(АИС)->М’ (АИС)->М’’ (АИС)->М’’’ (АИС)->АИС

Проведя анализ организационной системы можно создать модель М(ОС). Это – модель бизнес-анализа (проблемной области).

Анализ проблемной области позволяет вычленить:

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

с другой – устройство предметной области (в начале – на уровне концептуальной модели),

с третьей – требования к информации и ее обработке.

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

Углубленный анализ и проектирование, формируют, соответственно, аналитическую модель М’ (АИС), проектную модель М’’ (АИС) и модель реализации М’’’ (АИС).

Модель уровня реализации позволяет объединить собственно АИС, как совокупность программных, информационных, организационных факторов.

АИС в свою очередь представляет собой модель организационной системы М’ (ОС), замыкая цикл моделирования. Для того, чтобы прояснить связь между этими процессами, необходимо заметить, что создаваемая АИС также является моделью, по отношении к ОС. Таким образом, создавая документ АТ, мы тем самым порождаем как бы «модель второго порядка», т. к. документ АТ является ничем иным, как моделью модели ОС. Не обладая моделью АПО, мы, конечно, можем создать модель АТ. Но при этом мы рискуем тем, что при синтезе оригинала модели (т.е. АИС), не обладая знаниями об ОС, мы можем попасть в ситуацию рассогласования: результирующая АИС не будет ингерентна (согласована с) ОС и, тем самым, не станет жизнеспособной.

Процесс разработки АИС можно отобразить в виде диаграмм в программе BPwin. На рисунке 4 отображены этапы разработки АИС. Диаграммы верхнего уровня – Создание программы (рис. 4) состоит из двух диаграмм второго уровня Разработка и Тестирование (рис. 5 и рис. 6).

/>

Рис. 4 Этап Создание программы

Разработка (рис. 5) состоит из Построения каркаса программы и Создания тела программы.

/>

Рис. 5 Этап Разработка

Третий уровень Построение каркаса программы (рис. 6)

/>

Рис. 6 Этап построение каркаса

Четвертый уровень (рис. 7) Создание тела программы.

/>

Рис. 7 Создание тела программы

Пятый уровень (рис.  Тестирование

/>

Рис. 8 Этап тестирования

Рассмотрев бизнес-моделирование, перейдем к бизнес-процессам. Изучение методологии бизнес-процессов приводит к возможности их деления на три категории:

модели, преследующие цель анализа и улучшения организационной системы (например, SWOT, VCM, BPR, CPI/TQM/ISO9000, BSC),

модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,

модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).

Наиболее развитая модель описания проблемной области предлагается в методологии ARIS. Архитектура ARIS [25.5] выделяет в организации следующие подсистемы:

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

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

Подсистемы входов / выходов. Определяют потоки используемых и производимых продуктов и услуг.

Информационная (подсистема данных). Описывает получение, распространение и доступ к информации (данным).

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

Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе выполнения того или иного процесса.

Подсистема средств производства. Описывает жизненный цикл основных и вспомогательных средств производства.

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

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

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

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

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

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

В дальнейшем общая функция разбивается на крупные подфункции. Этот процесс называется функциональной декомпозицией. Затем каждая подфункция декомпозируется на более мелкие – и так далее до достижения необходимой детализации описания. На рис. 2 показано дерево функций, называемое деревом узлов функциональной модели.

/>

Рис. 9. Пример декомпозиции – диаграмма узлов функциональной модели

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

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

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

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

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

Внешняя сущность (рис. 10а) – объект (например, поставщик, клиент и т.д.), с которым взаимодействует данный работник;

    продолжение
—PAGE_BREAK—

Накопитель (рис. 10б) – любое хранилище данных;

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

Поток данных (рис. 10г) – характеризует связь (над стрелкой рекомендуется указать наименование конкретного документа).

/>

Рис. 10 Условные обозначения

На рисунке 11 приведён пример построения бизнес-процесса «Оформление счета фактуры».

/>

Рис. 11 Пример построения бизнес процесса

Анализ данных заключается в следующем:

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

Определяется структура данных: название(имя), тип, свойства;

Формирование информационных объектов (ИО);

Установление связей между информационными объектами.

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

Таблица 1. ИО «Журнал учета организаций-клиентов»

ИО (документ)

Название реквизита

Условное обозначение реквизита

Журнал учета организаций-клиентов

Название организации

Должность лица, с которым осуществляется непосредственный контакт

Телефон

Фамилия имя отчество

Адрес организации

Реквизиты банка

Название

Должность

Телефон

Ф.И.О.

Адрес

БАНК

Состав реквизитов определяет структуру ИО. Каждый ИО имеет уникальное имя.

Экземпляр-это совокупность конкретных значений реквизитов. ИО имеет множество экземпляров. Каждый экземпляр ИО должен однозначно определяться ключем, который состоит из одного или нескольких реквизитов.

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

На рисунке 12 приведен пример ИЛМ

/>

Рис. 12 Пример ИЛМ

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

Анализ программ бизнес моделирования позволяет сделать вывод, что для ведения бизнес процессов моделирования, BPwin является уникальной программой, которая позволяет создавать модели процессов и поддерживает в одной модели в дополнение к IDEF0 еще два стандарта (нотации) моделирования – DFD и IDEF3. Каждая из этих трех нотаций позволяет рассмотреть различные стороны деятельности предприятия:

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

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

диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации.

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

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

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

Для ответа на вопрос как должно работать предприятие в будущем? Какой выигрыш (проигрыш) даст реорганизация? Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (Как будет) – модели новой организации бизнес-процессов. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных / лучших путей выполнения работы и документирования того, как предприятие будет функционировать в будущем. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается наилучшая (рис. 7). Например, каждая из моделей ТО-ВЕ может соответствовать определенной информационной системе.

/>

Рис. 13. Построение моделей ТО-ВЕ как результат анализа модели AS-IS

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

Программа BPwin предоставляет аналитику два инструмента для оценки модели – стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями для идентификации движителей затрат в организации.

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

Обычно ABC применяется для того, чтобы понять происхождение затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), и др. в каждой из моделей AS-IS и ТО-ВЕ.

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

Кроме этого BPwin позволяет делать достаточно эффективные оценки стоимости, но при этом не претендует на высокую точность таких оценок. Для точных вычислений затрат можно воспользоваться специализированным средством стоимостного анализа EasyABC. BPwin поддерживает двунаправленный экспорт – импорт в EasyABC. Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin – ABC. ABC позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик – свойств, определенных пользователем UDP.

В рамках данной дипломной работы будут рассматриваться элементы линейки AllFusion компании Computer Associates.

    продолжение
—PAGE_BREAK—

Изучив первоисточники и проанализировав их, а также само средство – программу BPwinсделаем выводы: любую деятельность или структуру предприятия можно спроектировать и представить в виде, что позволит оптимизировать работу организации, проверить её на соответствие стандартам ISO9000, спроектировать структуру, снизить издержки, исключить ненужные операции, повысить гибкость и эффективность. BPwinподдерживает сразу три нотации моделирования: IDEF6, IDEF3 и DFDи является уникальным программным средством в области проектирования автоматизированных информационных систем. Проанализировав все процессы, в завершение параграфа представлен рисунок 14, демонстрирующий все процессы такие как анализ требований и другие рабочие потоки программной инженерии.

/>

Рис. 14 Рабочие потоки программной инженерии

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

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

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

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

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

1.3 Среда бизнес моделирования BPwin

Интерфейс среды BPwin (рис. 15) достаточно простой и интуитивно понятный пользователю, дающий возможность аналитику создавать сложные модели при минимальных усилиях.

/>

Рис. 15. Интегрированная среда разработки модели BPwin 4.0

При запуске BPwin появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели – Model Explorer.

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

/>

Рис. 16. Диалог создания модели

Как было указано выше, BPwin поддерживает три методологии – IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т.е. модель может содержать одновременно как диаграммы IDEF0, так и диаграммы IDEF3 DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

После щелчка по кнопке ОК появляется диалог PropertiesforNewModels(рис. 17), в котором следует внести свойства модели.

/>

Рис. 17. ДиалогProperties for New Models

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Пункты контекстного меню Font и Color вызывают диалог Arrow Properties или Activity Properties для установки шрифта (в том числе его размера и стиля) и цвета объекта. В нижней части вкладки Font диалогов Arrow Properties и Activity Properties (рис. 18) находятся группа опций Apply setting to, позволяющих изменить шрифт для всех работ или стрелок на текущей диаграмме, в модели, и группа Global, позволяющая изменить шрифт одновременно для всех объектов модели.

/>

Рис. 18. ВкладкаFont диалогаActivity Properties

Кроме того, BPwin позволяет установить шрифт по умолчанию для объектов определенного типа на диаграммах и в отчетах. Для этого следует выбрать меню Model/Default Fonts, после чего появляется каскадное меню, каждый пункт которого служит для установки шрифтов для определенного типа объектов:

Context Activity – работа на контекстной диаграмме;

Context Arrow – стрелки на контекстной диаграмме;

Decomposition Activity – работы на диаграмме декомпозиции;

Decomposition Arrow – стрелки на диаграмме декомпозиции;

Node Tree Text – текст на диаграмме дерева узлов;

Frame User Text – текст, вносимый пользователем в каркасе диаграмм;

Frame System Text – системный текст в каркасе диаграмм;

Text Blocks – текстовые блоки;

Parent Diagram Text – текст родительской диаграммы;

Parent Diagram Title Text – текст заголовка родительской диаграммы;

Report Text – текст отчетов.

ИнструментнавигацииModel Explorer имееттривкладки– Activities, Diagrams иObjects. Вкладка Activities (рис. 19) показывает в виде раскрывающегося иерархического списка все работы модели. Одновременно могут быть показаны все модели, открытые в BPwin. Работы с диаграмм IDEF0 показываются зеленым цветом, IDEF3 – желтым и DFD – голубым.

/>

Рис. 19. Model Explorer

Щелчок по работе во вкладке Activity переключает левое окно BPwin на диаграмму, на которой эта работа размещена. Для редактирования свойств работы следует щелкнуть по ней правой кнопкой мыши. Появляется контекстное меню со свойствами работы.

Проанализировав возможности BPwin, изучив инструментальную среду, рассмотрим технологию бизнес моделирования.

Выводы: так как областью исследования в дипломной работе являются технологии проектирования и моделирования бизнес – процессов, то данные технологии потребуют освоения инструментов создания графических изображений, методов и средств функционального, логического и физического моделирования. При проектировании АИС важно разработать единые требования к системе, чтобы не было в дальнейшем необходимости переделывать проект. В современном мире компьютерных технологий важную роль играют программы бизнес моделирования, которые позволяют создать модель АИС. Для успешной реализации проекта необходимо чтобы инструментальные средства были достаточно гибкими и легко приспосабливались к изменяющимся требованиям. В результате проведенных теоретических исследований было установлено, что таким средством является Case – средство верхнего уровня-BPwin, поддерживающий методологию IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (Dataflow Diagram).

    продолжение
—PAGE_BREAK—

2. Практическая часть

2.1 Анализ деятельности ОАО «АНХК» и структуры предприятия

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

В графическом виде структура АНХК представлена в Приложении 1.

Нефтеперерабатывающий завод

В составе НПЗ 3 установки по первичной переработке, 7 установок по вторичной переработке нефти. Ежегодный объем нефтепереработки – от 8,2 до 8,7 млн. тонн. Выход светлых – 64,4%, глубина переработки – 77,4%. Начиная с 2001 года осуществляется последовательная модернизация основных производственных установок, что позволило наладить выпуск новой, пользующейся спросом продукции.

Выпускаемая продукция:

Бензины автомобильные Аи – 76, Аи – 80, Аи – 92, Премиум – 95, Супер Аи – 98.

Топливо дизельное: зимнее, летнее.

Топливо дизельное экологически чистое.

Топливо для реактивных двигателей.

Битумы нефтяные (строительные, кровельные, дорожные вязкие, модифицированные).

Кокс электродный для алюминиевой промышленности.

Химический завод

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

Выпускаемая продукция:

Спирты бутиловые

Серная кислота

Метанолы

Метиламины

Метилтретбутиловый эфир

Завод масел

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

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

Выпускаемая продукция:

Моторные масла (дизельные и универсальные)

Трансмиссионные и гидравлические масла

Энергетические масла

Индустриальные масла

ОАО «Ангарский завод катализаторов и органического синтеза»

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

Выпускаемая продукция:

Катализаторы риформинга

Катализаторы процесса Клауса

Катализаторы гидрирования

Катализаторы окисления

Катализаторы конверсии

Катализаторы-адсорбенты

Носители

ОАО «Восточно-Сибирский машиностроительный завод»

ОАО «Востсибмаш» – самое мощное машиностроительное предприятие в Восточной Сибири. Имеет котельно-сварочное, механосборочное, литейное, кузнечно-термическое производство. Имеющееся оборудование позволяет изготовить аппараты из углеродистых, низколегированных, высоколегированных, а также теплоустойчивых сталей, титана и биметалла.

Выпускаемая продукция:

Колонны ректификационные и абсорбционные

Запасные части к грунтовым насосам

Емкостное оборудование

Теплообменная аппаратура

Трубопроводная арматура

Нестандартное оборудование

Основные направления инвестиционной политики:

Обеспечение поставки топлив на Российский рынок и на экспорт в соответствии с требованиями стандартов по качеству (ЕВРО – 3, ЕВРО – 4);

Конвертирование мазута в светлые нефтепродукты для экспорта и внутреннего рынка;

Освоение выпуска масел повышенного уровня качества;

Повышение эффективности производства;

Повышение экологической и промышленной безопасности.

Основными видами деятельности Общества являются:7

производство продуктов нефтепереработки, нефтехимии и химической продукции производственно-технического назначения;

хранение нефти, газов и продуктов их переработки

производство товаров народного потребления;

осуществление коммерческой деятельности;

торгово-закупочная деятельность;

общественное питание;

осуществление внешнеэкономической деятельности;

производство строительной продукции;

строительно-монтажные и ремонтные работы;

забор воды, водоснабжение, канализование и очистка сточных вод;

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

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

научно-исследовательские и проектно-конструкторские работы;

осуществление всех видов гражданско-правовых сделок с патентообладателями, владельцами «ноу-хау» и авторами иных видов интеллектуальной собственности;

информационно-вычислительные работы и разработка программных продуктов;

подготовка и повышение квалификации кадров;

использование драгоценных металлов для нужд производства;

транспортно-экспедиционная деятельность;

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

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

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

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

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

приобретение, реализация, сбор и ремонт очковой оптики;

проведение дезинфекционных, дезинсекционных и дератизационных работ;

оздоровление населения на базах отдыха и в детских лагерях;

туристическая и экскурсионная деятельность;

    продолжение
—PAGE_BREAK—

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

В компании активно ведется реконструкция и модернизация действующих и пуск новых производств. В ОАО «АНХК» выпускается более ста наименований товарной продукции, которая находит, сбыт практически во всех районах от Урала до Тихого океана, и далее за рубежом – в Японии, Китае, Монголии, Сингапуре и других странах Юго-Восточной Азии. Особый подход у компании – в решении природоохранных задач. В компании разработана и действует долгосрочная программа по снижению выбросов загрязняющих веществ в окружающую среду.

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

2.1 Анализ проблемы автоматизированных информационных систем ОАО «АНХК»

Проведенное обследование деятельности основных управленческих служб Компании позволяет сделать следующие выводы:

методология учета, анализа и планирования в значительной степени зависит от человеческого фактора;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поступление сырья от поставщиков;

Прием менеджерами заказов от клиентов;

Группировка заказов по подразделениям;

Выполнение заказов и поступление их на склад готовой продукции;

Отправка заказов;

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

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

склада сырья и готовой продукции;

производственные отделы;

финансовый отдел.

Диаграмма потоков данных представлена на рисунке 20.

/>

Рис. 20 Диаграмма потоков данных

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

В работе рассмотрен процесс производства. Основные процессы информационной системы:

информирование заказчиков;

ведение нормативно-справочной информации;

организация удобства ввода, вывода, просмотра поступающего товара;

выбор поставщиков;

создание необходимой вторичной выходной информации.

2.2 Изучение задач управления

    продолжение
—PAGE_BREAK—

Проект разрабатывается с целью построения бизнес-модели предприятия «АНХК». Организационно-функциональная схема которого представлена на рисунке 21.

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

/>

Рис. 21 Организационно-функциональная схема предприятия «АНХК»

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

2.3 Описание входной информации

Если рассматривать хранимую информацию с точки зрения поставок, то можно выделить несколько её составляющих:

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

информация о поставках, сведения о том какой конкретно товар поставили, сведения о качестве этого товара, дату поставки;

информация об оплате;

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

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

При оформлении заказа у поставщиков заводится запись в таблице «Учет клиентов» в неё вноситься информация о клиенте. К документам предметной области можно отнести так же информацию о продукции предприятия, сформированную в виде отчетов и предложенную для ознакомления клиенту.

2.5 Описание выходной информации

Выходная информация представляется двумя видами:

в виде отчетов, которые создаются на основе требуемых запросов, по базе данных. Их цель – предоставление наглядной информации. Они могут быть не только представлены в ПК, но и распечатаны для удобства выбора;

в виде запросов, которые создаются в соответствиями с информационными требованиями;

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

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

3. Алгоритм функционирования системы моделирования и его описание

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT – Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна «Методология структурного анализа и проектирования SADT» (М.: Метатехнология, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

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

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

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

Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:

Почему этот процесс должен быть замоделирован?

Что должна показывать модель?

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

Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only), которые будут рассмотрены в дальнейшем.

IDEFO-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties. Во вкладку Purpose следует внести цель и точку зрения, а во вкладку Definition – определение модели и описание области.

Основными процедурами производства являются:

Приём заказов менеджерами от клиентов;

Группировка заказов;

Производство заказанной продукции;

Отгрузка продукции заказчику.

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

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

/>

Рис. 22. Контекстная диаграмма А(0)

3.2 Создание диаграмм декомпозиций

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

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

    продолжение
—PAGE_BREAK—

Диаграммы декомпозиции содержат родственные работы, т.е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке +. Возникает диалог Activity Box Count, в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции. Допустимый интервал числа работ 2–8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3 до 6 блоков на одной диаграмме.

Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке SsM на палитре инструментов, а затем по свободному месту на диаграмме.

Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему (рис. 23).

/>

Рис. 23 Диаграмма декомпозиции

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

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

/>

Рис. 24 Пример диаграммы декомпозиции Производство продукции

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

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

Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. «Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой. Если цель работы изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.

Выход (Output) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. Механизм (Mechanism) – ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т.д. Стрелка механизма рисуется как входящая в нижнюю грань работы.

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

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

ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы (рис. 25). В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 – это не элемент управления нижестоящими работами. Работы нижнего уровня – это то же самое, что и работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня – это то же самое, что и границы диаграммы декомпозиции.

/>

Рис. 25. Фрагмент диаграммы декомпозиции ICOM-кодам (11, С1 и С2)

BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes навкладкеDisplay диалогаModel Properties (менюModel/Model Properties).

Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary, в котором определяется стрелка и вносится относящийся к ней комментарий.

/>

Рис. 26 Словарь стрелок

Словарь стрелок решает очень важную задачу. Содержимое словаря стрелок можно распечатать в виде отчета (меню Tools/Reports/Arrow Report) и получить тем самым толковый словарь терминов предметной области, использующихся в модели.

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

/>

Рис. 27 Начальный этап построения

ICOM (аббревиатура от Input, Control, Output и Mechanism) – коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (рис. 28).

/>

Рис. 28 Диаграммы декомпозиции работы А0 с кодами ICOM

3.3 Создание диаграммы дерева узлов и диаграммы FEO

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

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

Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram/Add Node Tree (рис. 29).

/>

Рис. 29 Диалог настройки диаграммы дерева узлов

Создадим диаграмму дерева узлов модели

Возникает эксперт создания диаграммы дерева узлов Node Tree Wizard. В первом диалоге эксперта необходимо внести имя диаграммы дерева узлов, узел верхнего уровня и глубину дерева – Number of Levels (по умолчанию 3). Поскольку дерево узлов не обязательно в качестве верхнего уровня должна иметь контекстную работу и иметь произвольную глубину.

В одной модели можно создавать множество диаграмм деревьев узлов. Имя дерева узлов по умолчанию совпадает с именем работы верхнего уровня, а номер диаграммы автоматически генерируется как номер узла верхнего уровя плюс литера «N», например A0N. Если в модели создается два дерева узлов, имеющих в качестве верхнего уровня одну и ту же работу, то по умолчанию диаграммы получат идентичные номер и имя. Поэтому рекомендуется при создании диаграммы дерева узлов внести имя диаграммы, отличное от значения по умолчанию (рис. 29).

/>

Рис. 29. Диаграмма дерева узлов Обеспечить продукцией

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

/>

Рис. 30 Редактирование диаграммы

Следующим шагом создадим диаграмму FEO(Diagram-Add-FEO)

/>

Рис. 31 Создание диаграммы FEO

Диаграммы «только для экспозиции» (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку, по сути, являются просто картинками – копиями стандартных диаграмм и не включаются в анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и выхода.

    продолжение
—PAGE_BREAK—

С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной работой и одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относящихся к теме обсуждения и дезориентирующих эксперта. Но если FEO используется для иллюстрации альтернативных точек зрения (альтернативный контекст), рекомендуется все-таки придерживаться синтаксиса IDEF0. Для создания диаграммы FEO следует выбрать пункт меню Diagram/Add FEO Diagram. В возникающем диалоге Add New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы.

/>

Рис. 32. Диалог создания FEO-диаграммы

Новая диаграмма получает номер, который генерируется автоматически, на рисунке 33 отображен номер родительской диаграммы по узлу + постфикс F, A0F.

/>

Рис. 33 Диаграмма FEO

В практической части диплома была рассмотрена конкретная технология разработки, основанная на решениях создания бизнес-модели предприятия. Было выбрано средство BPwin, поддерживающее методологию IDEF0 и DFD. В результате проведенных исследований выяснено, что методология IDEF0 позволяет построить иерархическую систему диаграмм-единичных описаний фрагментов системы. Алгоритм функционирования следующий: сначала производится описание системы и её взаимодействия с окружающим миром (контекстная диаграмма), после чего производится функциональная декомпозиция.-система разбивается на более мелкие- и так далее, до достижения нужной степени подробности.

Заключение

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

В результате анализа деятельности и структуры предприятия «АНХК», были сформированы достаточно цельные и систематизированные знания в области исследования, которые в дальнейшем будут реализованы в построении диаграмм бизнес процесса.

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

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

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

Сделаны следующие выводы:

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

крупный проект невозможно реализовать в одиночку;

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

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

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

Список литературы

О недрах: федеральный закон РФ от 21.02.1992 г. №2395–1 (ред. от 29.06.2004 г.) [электронный ресурс] // Консультант Плюс. Версия Проф.

Армяков М. Русские Инвесторы / М. Армяков // Экономика России: ХХI век. – 2002. – №2. – С. 7–10.

Анисимов В.В. 50 лет успешной вахты. Научно-технические достижения и передовой опыт / В.В. Анисимов // Нефтепереработка и нефтехимия. – 2003. – №8. – С. 3–4.

Батюнин В.А. Снижение энергозатрат – путь к повышению эффективности производства / В.А. Батюнин, В.Ю. Абрамов // Нефтепереработка и нефтехимия. – 2003. – №8. – С. 52–53.

Безруков А.А. Аппетитные соседи / А.А. Безруков // Нефтегазовая отрасль. – 2004. – №7. – С. 23–24.

Белобородов К.Г. Экспортировать бензин станет дороже/ К.Г. Белобородов // Коммерсант. – 2004. – №194. – С. 6–7.

Беспалов Ю.А. О закрытии ряда химических производств ОАО «Ангарская нефтехимическая компания» / Ю.А. Беспалов // Время. – 2001. – 18 февр.

Бирюков Н.Н. Бизнес и нефть / Н.Н. Бирюков // БИКИ. – 2001. – №2. – С. 39.

Воеводин Г.А. Нефть и Россия: планы на будущее / Г.А. Воеводин // Ведомости. – 2004. – №32. – С. 9.

Воронина Н.В. Мировой рынок нефти: тенденции развития и особенности ценообразования / Воронина Н.В. // Практический маркетинг. – 2003. – №10. – С. 12–18.

Вяземский О.В. Сколько стоит наше будущее / О.В. Вяземский // Ведомости. – 2004. – №37. – С. 12.

Гаврилова Н.А. Итоги деятельности ОАО «АНХК» / Н.А. Гаврилова // Восточно-Сибирская правда. – 2004. – №87. – С. 8.

Дэниел О’Лири ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение, эксплуатация М.: ООО «Вершина», 2004. – 272 с, [Пер. с англ. Ю.И. Водопьяновой

Меняев М.Ф Информационные технологии управления: Книга 3: Системы управления организацией М.: Омега-Л, 2003. – 464 с

Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие М.: Гелиос АРВ, 2002. – 368 с., ил

Б.Н. Гайфуллин, И.А. ОбуховАвтоматизированные системы управления предприятиями стандарта ERP/MRPII. Производственное издание М. «Богородский печатник», 2001, 104 с

Петров В. Н Информационные системы СПб.: Питер, 2002. – 688 с

IEEE Standard Glossary of Software Engineering Terminology IEEE Std 610.12–1990

Вигерс Карл Разработка требований к программному обеспечению Пер, с англ. – М.: Издательско-торговый дом «Русская Редакция», 2004. -576 с.: ил

Леффингуелл Д., Уидриг ДПринципы работы с требованиями к программному обеспечению М.: ИД «Вильямс», 2002

Алистер Коберн Современные методы описания функциональных требований к системам М.: издательство «Лори», 2002. – 263 с

Мацяшек Лешек Анализ требований и проектирование систем. Разработка информационных Пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 432 с.: ил. – Парал. тит. Англ

Орлик С., Булуй Ю Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требованияCopyright © Сергей Орлик, 2004–2005

IEEE Guide to the Software Engineering Body of Knowledge(1) – SWEBOK®, 2004

ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ. Информационная технология. Процессы жизненного цикла информационных систем Издание официальное. – М., 1999

Каменова, Громов Моделирование бизнеса. Методология ARIS М.: Весть-МетаТехнология, 2001

А. Якобсон, Г. Буч, Дж. Рамбо Унифицированный процесс разработки программного обеспечения СПб.: Питер, 2002. – 496 с

Э.В. Попов Искусственный интеллект: в 3 книгах, кн. 2. Модели и методы М.: Радио и связь. – 1990

Марка Д.А Методология структурного анализа и проектирования СПб.: Питер, 1995. – 235 с

Марка Д., МакГоуэн К Методология структурного анализа и проектирования М.: МетаТехнология, 1993

ГОСТ 34.601–90. Информационная технология. Автоматизированные системы. Стадии создания

Фаулер М, Скотт К UML в кратком изложении. Применение стандартного языка объектного моделирования Пер. с англ. – М.: Мир, 1999. – 191 с., ил

Алистер Коберн Современные методы описания функциональных требований к системам

Леоненков Самоучитель UML

Маклаков С.В Bpwin Erwin Case-средства разработки информационных систем Москва «ДиалогМифи» – 2000

ГОСТ 19.201–78 «Техническое задание, требования к содержанию и оформлению»

Соммервилл, Иан Инженерия программного обеспечения, 6-е издание Пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 624 с.: ил. – Парал. тит. англ

Орлик С Программная инженерия. Качество программногообеспечения (Software Quality) Copyright © Сергей Орлик, 2004–2005

Калянов Г. Н Консалтинг при автоматизации предприятий: Научно-практическое издание Серия «Информатизация России на пороге XXI века». – М.: СИН-ТЕГ, 1997

Мальков А.С. Проект автоматизации финансово-хозяйственной деятельности ОАО «Ангарская нефтехимическая компания». – М.: 2002 г.

Галкин А.А. Дегтярь Р.М. Теория и практика оценки эффективности эксплуатации ERP системы. – М.: Корпоративный менеджмент. №7 2002 г.

Высочин С.Н., Фролов Е.Е. Управление цеховым складом, как элемент системы ресурсосберегающей организации производства. – М.: САПР и графика. №11, 2000 г.

Шебек С.С. Практика разработки корпоративных стандартов. – СПб: Планета КИС. 2000 г.

Шаракшанэ А.С., Халецкий А.К., Морозов И.А. Оценка характеристик сложных автоматизированных систем. – М., Машиностроение, 1993. – 272 с.

Чембровский О.А., Топчеев Ю.И., Самойлович Г.В. Общие принципы проектирования систем управления. – М., Машиностроение, 1972. -414 с.

Уайт О.У. Управление производством и материальными запасами в век ЭВМ. М.: Прогресс. 1978, C. 302. //Oliver W. Wight. Production and inventory management in the computer age. Macmillan of Canada, 1974

Компьютерные системы и сети: Учеб пособие / В.П. Косарев и др. / Под ред. В.П. Косарева и Л.В. Еремина. – М.: Финансы и статистики, 1999.

1 Методология моделирования UML: синтаксис и семантика моделей

*****

2 Ситуационно (практическая) часть

2.1 Ситуационно (практическая) задача № 1

Процесс обслуживания посетителя поликлиники предполагает выполнение следующих функций:

 назначение анализов;

 регистрация обращения граждан,

 регистрация жалоб,

 первичный осмотр пациента;

 выписка карточки больного;

 назначение лечения;

 выписка направления на стационарное лечение (операцию);

 резервирование очереди к специалисту;

 анализ результатов анализов;

 контроль наличия страхового полиса;

 выписка рецептов;

 проведения диагностических исследований;

 выписка больничного листа.

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

2.2 Ответ на задачу № 1

*****