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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПООБРАЗОВАНИЮ РФ
НОУ ВПО «СИБИРСКАЯ АКАДЕМИЯПРАВА, ЭКОНОМИКИ И УПРАВЛЕНИЯ»
Факультет: КомпьютерныхТехнологий и Информационных Систем
Кафедра ИнформационныхСистем
ДИПЛОМНАЯ РАБОТА
«Моделирование основныхбизнес-процессов предприятия»
Иркутск 2009
Содержание
Содержание. 2
Введение. 3
1.Теоретическая часть. 9
1.1 Формированиетребований как основной этап в разработке АИС… 9
1.2 Функциональноемоделирование бизнес-процессов. 17
1.3 Среда бизнесмоделирования BPwin. 35
2.Практическая часть. 41
2.1 Анализдеятельности ОАО «АНХК» и структуры предприятия. 41
2.1 Анализ проблемыавтоматизированных информационных систем ОАО «АНХК»  46
2.2 Изучение задачуправления. 52
2.3 Описание входнойинформации. 53
2.5 Описание выходнойинформации. 54
3. Алгоритмфункционирования системы моделирования и его описание. 56
3.1 Информационныйанализ процессов и создание контекстной
диаграммы… 56
3.2 Создание диаграммдекомпозиций. 60
3.3 Создание диаграммыдерева узлов и диаграммы FEO… 67
Списоклитературы… 74
/>/>/>/>/>/>/>/>/>/>/>/>Введение
Целью дипломной работы является изучение проблемысовершенствования информационного обеспечения управления организацией, построениемодели основных бизнес процессов на предприятии. На примере конкретногопредприятия необходимо выполнить построение моделей бизнес процессов,рассмотреть существующее положение дел в изучаемой области, произвестидетальный анализ.
Объектом исследования для построения бизнесмодели является предприятие АНХК. Химическая промышленность в большей степени,чем любая другая основная отрасль индустрии, характеризуется многообразиемиспользуемых технологических процессов. В химическом производстве задействованытысячи технологических установок, выпускающих продукцию, причем принципиальноодинаковые химические процессы зачастую бывают по-разному оформленыконструктивно, вследствие чего типовые решения могут быть применены лишь длянебольшой части общего числа технологических установок.
Поскольку технологические установки составляютоснову химических производств, можно представить, какое разнообразие дастсочетание уникальных установок. Как следствие – сложность проблемы управлениятехнологией не уменьшается по мере интеграции производственных подразделений,хотя появляется возможность типизации решений, касающихся управления крупнымитехнологическими комплексами, на основе общности экономических факторовхимических предприятий [4].
Такое положение дел во многом обусловило путь, покоторому проводилась автоматизация различных иерархических уровней управления,проектировались и развивались автоматизированные системы на предприятияхнефтехимической отрасли. Наибольшее применение получили автоматизированныесистемы управления технологическими процессами (АСУ ТП) [5–8] и системыавтоматизации управленческой и финансово-хозяйственной деятельностью (АСУП)[9]. Гораздо более скромное распространение получили автоматизированные системыоперативного управления [4,10,11] как производством в целом, так и отдельнымицехами (так называемые системы верхнего уровня АСУ ТП или автоматизированныесистемы оперативно-диспетчерского управления – АСОДУ) [12].
Системы АСУ ТП и АСУП – развивались обособленно инезависимо друг от друга [13–14]. Они проектировались и создавались исходя изтребований разных подразделений предприятия и в соответствии с различнымипотребностями. Изначально они не были подчинены единым целям и задачам,оставались слабо связанными физически и информационно, а зачастую и несвязанными вообще.
Кроме того, каждая из этих систем чаще всегостроилась по своим внутренним законам, поэтому они оставались практическиизолированными друг от друга информационно. Ситуация осложнялась еще и тем, чтокаждая из систем могла быть реализована разными коллективами разработчиков наоснове различных аппаратных, программных и информационных стандартов.
Рассматривая системы управления технологическимипроцессами, следует отметить, что не все решения были полностью открытыми [15],т.е. допускающими использование в рамках одной системы разнотипного оборудования,выпущенного в разное время и разными производителями (отечественными изарубежными). В результате предприятие-заказчик зачастую попадал в долгосрочнуюзависимость от одного из производителей и не имел возможности самостоятельноразвивать и модернизировать АСУ ТП. Если же автоматизированная системаразрабатывалась «своими силами», за счет внутризаводских отделов АСУ, томодернизация оборудования практически всегда приводила к разработке системызаново, «с нуля».
Существовали и проблемы «нетехнического характера».Например, автоматизированное решение задач оптимального календарногопланирования в рамках АСУП практически не выполнялось [9]. Одной из причинэтого являлась меньшая заинтересованность самих предприятий в автоматизированномрешении задач планирования. Если на уровне управления установками руководствопредприятия, производства, цеха было и заинтересовано в эффективной работеотдельных элементов производства, то на уровне планирования работы предприятия,существующие в то время административные методы управления со стороныминистерств, зачастую вступали в противоречия с интересами предприятия. Это непозволяло предприятию принимать эффективные для него автоматизированные решения,а иногда и заинтересовывало его в принятии планов заведомо неоптимального характера.
В итоге это приводило к тому, что создававшиесябез комплексного плана, обычно под требования различных подразделений, участкови процессов, не связанные между собой системы автоматизации с многообразием используемыхпрограммных и аппаратных средств очень напоминали «лоскутное одеяло» [16](впоследствии такой путь получил сленговое название «лоскутной автоматизации»).Понятно, что реальная эффективность от внедрения такой автоматизации напредприятии зачастую получалась весьма низкой.
Переломный момент в сложившейся ситуациипроизошел после экономических реформ 90-х годов, перераспределениясобственности и перехода к рыночным отношениям.
Переход предприятий в «частную собственность» перераспределили существенно расширил круг задач, требующих решения на химических инефтехимических производствах. «Когда на предприятии появился хозяин, возниклапотребность в получении объективных данных, характеризующих состояниепроизводства и определяющих конечный результат его деятельности. Такими даннымиявляется информация о реальном ходе технологических процессов, расходематериалов и, сырья, выпуске готовой продукции и многих других факторах» [17, 18].К тому же, помимо традиционных задач контроля и управления, появиласьнеобходимость в решении задач минимизации технологических потерь, ужесточенииконтроля качества выпускаемой продукции, стратегического планирования,логистики, и ряда других.
Свою лепту в изменение ситуации внесло образованиевертикально-интегрированных нефтяных компаний (ВИНК). Термин «вертикально-интегрированные»означает, что эти компании охватывают всю цепочку нефтяного бизнеса: разведку идобычу нефти, нефтепереработку и нефтехимию, оптовый и розничный сбыты продукции(рис. 1).
/>
Рис. 1. Схема вертикально-интегрированных нефтяных компаний
Современные мировые транснациональные ВИНКпредставляют собой гигантские, географически распределенные по всей планетемногофункциональные производственно-коммерческие системы. В отличие от них, дляроссийских ВИНК характерно расположение основных добывающих, перерабатывающих исбытовых мощностей на пространстве бывшего СССР. Поэтому они в большей степениявляются едиными операторами всех своих сырьевых, продуктовых и финансовых потоков.
Задача управления текущей деятельностью дляроссийских ВИНК в основном сосредоточена на размещении собственных добываемыхсырьевых ресурсов по определенным направлениям [19]. А это, в свою очередь,ставит ВИНК в зависимость от того, насколько полной, достоверной и оперативнойбудет информация о состоянии производства, выработки, запасах продукции, еёкачестве от собственных нефтеперерабатывающих заводов и нефтехимическихпроизводств.
Таким образом, возникла необходимость винтеграции существующих на предприятиях разрозненных автоматизированных системдля возможности эффективного межуровневого системного взаимодействия иполучения единого информационного пространства предприятия. Интегрирование информацииосновного технологического и вспомогательного производств позволяет объединитьразнородные подсистемы в единую систему мониторинга и диспетчеризациитехнологических и производственных процессов, что повышает эффективностьоперативного контроля и управления производством в целом и, как следствие,предприятием
Значимымфактором успеха в деятельности предприятия является применение информационныхтехнологий, автоматизации процесса работы, обеспечивающие согласованное ичеткое функционирование всех служб предприятия.
Применениеинформационных технологий позволяет не проиграть в условиях жесткойконкуренции, обеспечивая своевременные и регулярные поставки, низкую стоимостьдополнительных услуг. Для разработки модели основных бизнес процессов напредприятии, рассматривается завод НПЗ.
В дипломной работе проводятся исследования вобласти проектирования и моделирования АИС. Областью исследования являются новейшиетехнологии, позволяющие выполнить моделирование бизнес – процессов. Данныетехнологии предполагают владение инструментами создания графическихизображений, методов и средств функционального, логического и физическогомоделирования.Дляреализации поставленных целей необходимо провести анализ работы предприятия.
В рамках дипломнойработы поставлены следующие задачи:
1.  анализ работы предприятия
2.  теоретическоеисследование состояния конкретной проблемы – разработка бизнес модели;
3.  творческий анализсостояния предприятия и предмета исследования за определенный период,определение и изучение факторов, влияющих на объект и предмет исследования;
4.  применение полученных завремя обучения навыков владения современными технологиями и методиками решенияпрактических задач или вопросов, поставленных в дипломной работе;
5.  разработкаметодологических подходов, предложений и указаний по планированию, организациии совершенствованию;
6.  обобщение полученных врезультате проведенных исследований материалов и формулированиеаргументированных выводов и рекомендаций.
7.  изучить документооборот иинформационные потоки, реализующие бизнес-процессы;
8.  сформировать модельданных, реализующую выделенный бизнес-процесс;
9.  анализ современногосостояния развития технологий разработки бизнес моделей и промышленныхтехнологий проектирования ПО.
Тема дипломнойработы «Построение модели основных бизнес процессов на предприятии», является, несомненно,актуальной, так как задача такого типа решается на любом предприятии. Базаданных позволит вести учет поставок, сбыта, выдавать информацию о наличии сырья,обрабатывать большие объёмы информации, формировать необходимые отчеты изапросы. Использование бизнес моделей, обеспечит быструю и эффективную разработкуавтоматизированной информационной системы, создаст условия для ее хранения ипередачи как внутри предприятия, так и по сети Интернет для работы с поставщиками.
/>/>/>/>/>/>/>/>/>/>/>/>1.Теоретическая часть/>/>/> 1.1 Формирование требований как основной этапв разработке АИС
«Требование –это условие или возможность, которой должна соответствовать система»[1].
В IEEE StandardGlossary of Software Engineering Terminology (1990) [2.1] данное понятие трактуется шире. Требование – это:
-   условия или возможности,необходимые пользователю для решения проблем или достижения целей;
-   условия или возможности,которыми должна обладать система или системные компоненты, чтобы выполнить контрактили удовлетворять стандартам, спецификациям или другим формальным документам;
-   документированноепредставление условий или возможностей для пунктов 1 и 2.
Введем ещеодно определение. Требования – это исходные данные, на основании которыхпроектируются и создаются автоматизированные информационные системы. Первичныеданные поступают из различных источников, характеризуются противоречивостью,неполнотой, нечеткостью, изменчивостью. Требования нужны в частности для того,чтобы Разработчик мог определить и согласовать с Заказчиком временные ифинансовые перспективы проекта автоматизации. Поэтому значительная частьтребований должна быть собрана и обработана на ранних этапах создания АИС.Однако собрать на ранних стадиях все данные, необходимые для реализации АИС,удается только в исключительных случаях. На практике процесс сбора, анализа и обработкирастянут во времени на протяжении всего жизненного цикла АИС, зачастуюнетривиален и содержит множество подводных камней.
Требования кпродукту. В своей основе требования – это то, что формулирует заказчик. Цель,которую он преследует – получить хороший конечный продукт: функциональный иудобный в использовании. Поэтому требования к продукту являются основополагающимклассом требований.
Требования кпроекту. Вопросы формулирования требований к проекту, т.е. к тому, какРазработчик будет выполнять работы по созданию целевой системы, казалось бы, нележат в компетенции Заказчика. Без регламентации процесса Заказчиком легкоможно было бы обойтись, если бы все проекты всегда выполнялись точно и в срок.Однако, к сожалению, мировая статистика результатов программных проектовговорит об обратном. Заказчик, вступая в договорные отношения с Разработчиком,несет различные риски, главными из которых является риск получить продукт сопозданием, либо ненадлежащего качества. Основные мероприятия по контролю иснижению риска – регламентация процесса создания программного обеспечения и егоаудит.
Насколькоподробно Заказчику следует регламентировать требования к проекту – вопросриторический. Ответ на него зависит о множества факторов, таких, как ценностьконечного продукта для Заказчика, степень доверия Заказчика к Разработчику,сумма подписанного контракта, увязка срока сдачи продукта в эксплуатацию сбизнес-планами Заказчика и т.д. Однако со всей определенностью можно сказатьследующее:
1.  регламентация процессаЗаказчиком позволяет снизить его риски;
2.  мероприятия Заказчика порегламентации процесса приводят к дополнительным накладным расходам. Требуетсянайти разумный компромисс между степенью контроля рисков и величиной расходов.
В качестветребований к проекту могут быть внесен регламент отчетов Разработчика,совместных семинаров по оценке промежуточных результатов, определеныхарактеристики компетенций участников рабочей группы, исполняющих проект, ихколичество, указана методология управления проектом. Ниже сформулирован примерформулировки требования к оффшорному проекту (Заказчик и Разработчик физическинаходятся в разных государствах) – в этой ситуации Заказчику требуется жесткийконтроль над Разработчиком.
1.    Разработчик представляетЗаказчику согласованный план работ c детализацией (WorkBreakdownStructure – WBS)с точностью до конкретных исполнителей.
2.    Разработчик осуществляетежедневные сборки, регрессионное тестирование компонент разрабатываемогопродукта и тестирование продукта в целом.
3.    Все управленческие ипроектные артефакты, исходные коды и тестовые примеры размещаются в режимеonline в интегрированной среде разработки Rational ClearCase с возможностью дляЗаказчика осуществления online-мониторинга на базе web-технологий.
Внедрение ИСна предприятии всегда преследует конкретные бизнес-цели – такие, как, например,повышение прозрачности бизнеса, сокращение сроков обработки информации,экономия накладных расходов и т.д. Современные информационные системы – этокрупные программные системы, содержащие в себе множество модулей,функциональных, интерфейсных элементов, отчетов и т.д. Как охватить единымвзором такие разнородные вещи, как цели, преследуемые топ-менеджеромпредприятия Заказчика, описание интерфейса пользователя и характеристикимодуля, осуществляющего расчет себестоимости изделия?
К счастью,человечество уже давно изобрело приемы борьбы со сложностью, широко применяемыев моделировании сложных объектов – абстракцию и декомпозицию. Требованияразделяются по уровням. Уровни требований связаны, с одной стороны, с уровнемабстракции системы, с другой – с уровнем управления на предприятии.
Обычновыделяют три уровня требований.
·          Наверхнем уровне представлены так называемые бизнес-требования (businessrequirements). Примеры бизнес-требования: система должна сократить срокоборачиваемости обрабатываемых на предприятии заказов в три раза.Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
·          Следующийуровень – уровень требований пользователей (user requirements). Примертребования пользователя: система должна представлять диалоговые средства дляввода исчерпывающей информации о заказе, последующей фиксации информации в базеданных и маршрутизации информации о заказе к сотруднику, отвечающему за егопланирование и исполнение. Требования пользователей часто бывают плохоструктурированными, дублирующимися, противоречивыми. Поэтому для созданиясистемы важен третий уровень, в котором осуществляется формализация требований.
·          Третийуровень – функциональный (functional requirements). Пример функциональныхтребований (или просто функций) по работе с электронным заказом: заказ можетбыть создан, отредактирован, удален и перемещен с участка на участок.
Существуютобъективные противоречия между требованиями различных уровней. Так, очевиднымбизнес-требованием является требование о полноте информации, собираемой нарабочих местах пользователей в единую базу данных. Чем полнее информация – темглубже база для анализа деятельности и принятия решений. С другой стороны,конкретному пользователю системы вполне может быть достаточно использованиятолько той части информации, которая влияет на выполнение его основных функций.
Важныеправила внедрения и использования АИС на предприятии – «Одна точка сбора», «Данныесобираются там, где они появляются». Использование этих правил позволяетизбежать затрат на необоснованное дублирование информации и, что важнее – потерьот ошибок учета, неизбежно возникающих при дублировании точек ввода.
Внедрение АИСна предприятии приводит к необходимости оснащения всех точек ввода информацииавтоматизированными рабочими местами (АРМ), обучению персонала и, зачастую,оптимизации и повышению уровня формализации рабочих процессов, выполняемыхперсоналом. Поэтому внедрение АИС – непростой процесс, часто требующий «перекройкичеловеческого материала» и встречающий сопротивление со стороны пользователей,которые не готовы, либо не хотят работать по-новому.
Анализтребований – один из основных рабочих потоков (workflow) программной инженерии,наряду с проектирование интерфейса пользователя, либо программированием.
Для егообозначения в англоязычной литературе, как правило, используется понятие «RequirementProcess». В отечественной практике, наряду с обобщающим термином «анализтребований», принятым, в частности, в ГОСТ Р ИСО/МЭК 12207–99, встречаютсятакже такие термины, как «поток работ «требования», «работа с требованиями», «определениетребований» и т.д., что вносит изрядную путаницу. Для того чтобы внестинекоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Processна составляющие, принятую в SWEBOK, и введем терминологию, которой будет применятьсяв дипломной работе.
SWEBOKпредлагает выделить в Requirement Process следующие основные составляющие:
-   Requirements Elicitation(Извлечение требований),
-   Requirements Analysis(Анализ требований в узком смысле),
-   RequirementsSpecification (Специфицирование требований),
-   Requirements Validation(Проверка требований).
В качествепримера альтернативной декомпозиции потока работ можно рассмотреть взгляд,предложенный в RUP [4.1]. RUP предлагает выделить в основном потоке анализатребований такие компоненты, как:
-  Analyze the Problem (Анализ проблемы),
-   Understand StakeholderNeeds (Понимание потребностей совладельцев),
-   Define the System(Определение системы),
-  Manage the Scope of the System (Управление контекстом системы),
-   Refine the SystemDefinition (Уточнение определения системы).
Обобщая приведенныеметодики, далее будем придерживаться следующей, более удобной в методическомплане схемы декомпозиции потока работ «Работа с требованиями»:
-   Формирование видения;
-   Выявление требований;
-   Классификация испецификация требований;
-   Расширенный анализтребований (моделирование и прототипирование);
-   Документированиетребований;
-   Проверка требований;
-   Управление требованиями;
-   Совершенствование процессаработы с требованиями.
Первые 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]. Работы, посвященныеанализу проблемной области, появились в отечественной литературе в серединепрошлого века; данная тематика неразрывно связано с задачным подходом иинженерией экспертных систем. Первые шаги в области моделирования былипроведены в построении интеллектуальных систем. Для такой «более приземленной» задачи,как задача построения АИС – эти методы начали применяться позднее. Стратегииизвлечения знаний во многом пересекаются с работой аналитика, методы решениязадачи путем редукции на подзадачи и поиска в пространстве состояний нашли своеотражение во множестве методик бизнес-анализа, анализа и синтеза программныхсистем и этот список можно продолжать. В дипломной работе рассматриваетсявопрос насколько результативно применение тех или иных моделей и методов приописании организационных систем.
Что бы решитьэтот вопрос надо определить цели и задачи самого бизнес-анализа, как этапа построенияКИС.
С позициймоделирования, анализ требований (АТ) и анализ проблемной области (АПО) – принципиальноразные процессы.
АПОпреследует классические цели создания модели: налицо объект (автоматизируемоепредприятие или организационная система[4], ОС) и задача аналитика –отразить этот объект в создаваемой модели с требуемой степенью точности схемапроцесса разработки представлена на рисунке 3.
/>
Рис. 3 Схемапроцесса разработки КИС

Анализтребований, напротив, направлен на моделирование воображаемого, еще несуществующего объекта (АИС). Т.е. сначала создается модель, а затем, на ее основании,синтезируется объект. Рассмотрим теперь обобщенную «формулу» создания АИС.
ОС->М(ОС)->М(АИС)->М’(АИС)->М’’ (АИС)->М’’’ (АИС)->АИС
Проведяанализ организационной системы можно создать модель М(ОС). Это – модель бизнес-анализа(проблемной области).
Анализ проблемнойобласти позволяет вычленить:
-   с одной стороны, задачи ифункции, реализуемые внутри ОС и функции коммуникации ОС и среды,
-   с другой – устройствопредметной области (в начале – на уровне концептуальной модели),
-   с третьей – требования кинформации и ее обработке.
Выделив средифункций те, которые подлежат автоматизации, мы получаем основу для выявленияфункциональных требований к системе. Остальная, собранная на этапе АПО,информация служит для поиска нефункциональных требований. В результате получаеммодель АТ, как первое приближение модели АИС, М(АИС).
Углубленныйанализ и проектирование, формируют, соответственно, аналитическую модель М’ (АИС),проектную модель М’’ (АИС) и модель реализации М’’’ (АИС).
Модель уровняреализации позволяет объединить собственно АИС, как совокупность программных,информационных, организационных факторов.
АИС в своюочередь представляет собой модель организационной системы М’ (ОС), замыкая циклмоделирования. Для того, чтобы прояснить связь между этими процессами,необходимо заметить, что создаваемая АИС также является моделью, по отношении кОС. Таким образом, создавая документ АТ, мы тем самым порождаем как бы «модельвторого порядка», т. к. документ АТ является ничем иным, как моделью моделиОС. Не обладая моделью АПО, мы, конечно, можем создать модель АТ. Но при этоммы рискуем тем, что при синтезе оригинала модели (т.е. АИС), не обладая знаниямиоб ОС, мы можем попасть в ситуацию рассогласования: результирующая АИС не будетингерентна (согласована с) ОС и, тем самым, не станет жизнеспособной.
Процессразработки АИС можно отобразить в виде диаграмм в программе BPwin. На рисунке 4 отображеныэтапы разработки АИС. Диаграммы верхнего уровня – Создание программы (рис. 4)состоит из двух диаграмм второго уровня Разработка и Тестирование (рис. 5и рис. 6).
/>
Рис. 4Этап Создание программы
Разработка(рис. 5) состоит из Построения каркаса программы и Создания телапрограммы.

/>
Рис. 5Этап Разработка
Третийуровень Построение каркаса программы (рис. 6)
/>
Рис. 6Этап построение каркаса
Четвертыйуровень (рис. 7) Создание тела программы.

/>
Рис. 7Создание тела программы
Пятый уровень(рис. 8) Тестирование
/>
Рис. 8Этап тестирования
Рассмотревбизнес-моделирование, перейдем к бизнес-процессам. />Изучениеметодологии бизнес-процессов приводит к возможности их деления на три категории:
-   модели, преследующие цельанализа и улучшения организационной системы (например, SWOT, VCM, BPR,CPI/TQM/ISO9000, BSC),
-   модели общего назначения,такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
-   модели, специальноразработанные для использования при автоматизации (например, ISA, BSP, ARIS,RUP).
Наиболееразвитая модель описания проблемной области предлагается в методологии ARIS.Архитектура ARIS [25.5] выделяет в организации следующие подсистемы:
-   Организационная.Определяет структуру организации – иерархию подразделений, должностей иконкретных лиц, многообразие связей между ними, а также территориальнуюпривязку структурных подразделений.
-   Функциональная.Определяет функции, выполняемые в организации.
-   Подсистемы входов / выходов.Определяют потоки используемых и производимых продуктов и услуг.
-   Информационная(подсистема данных). Описывает получение, распространение и доступ к информации(данным).
-   Подсистема процессовуправления. Определяет логическую последовательность выполнения функцийпосредством событий и сообщений. Можно сказать, что подсистема управления – этосовокупность разнесенных во времени сообщений разного рода.
-   Подсистема целейорганизации. Описывает иерархию целей, достигаемых в ходе выполнения того илииного процесса.
-   Подсистема средствпроизводства. Описывает жизненный цикл основных и вспомогательных средствпроизводства.
-   Подсистема человеческихресурсов. Описывает прием на работу, обучение и продвижение по службе персоналаорганизации.
-   Подсистема расположенияорганизационных структур. Описывает территориальное расположениеорганизационных единиц.
Данноеразделение является в определенной мере условным; выделенные «подсистемы» неявляются подсистемами в смысле системного анализа, т.к. взаимопроникают ипересекаются. Они представляют скорее совокупность предметов исследования,разных взглядов на исследуемый объект. Принцип улучшения бизнес-процессовосновывается на четыре подходах: методика быстрого анализа решения (FAST); бенчмарткетингпроцесса; перепроектирование процесса; реинжениринг процесса.
В настоящеевремя существует ряд методик и инструментов, которые применяются при реализациипреобразований. Метод построения иерархических моделей, направленн на описаниеи анализ бизнес-процессов как элементов экономических систем. При этом крайневажно четко сформулировать постановку задачи и цели моделирования, этоопределяет выбор адекватных методик и инструментальных средств.
Для решениязадач функционального моделирования, то есть описания существующих процессовили процессов, которые мы стремимся получить в идеале, широко используетсяметодология структурного анализа и проектирования технология SADT[5].
Основная идеяметодологии SADT – построение древовидной функциональной модели предприятия.Сначала функциональность предприятия описывается в целом, без подробностей. Такоеописание называется контекстной диаграммой. Взаимодействие с окружающим миромописывается в терминах входа (данные или объекты, потребляемые или изменяемыефункцией), выхода (основной результат деятельности функции, конечный продукт),управления (стратегии и процедуры, которыми руководствуется функция) имеханизмов (необходимые ресурсы). При создании контекстной диаграммыформулируются цель моделирования, область (описание того, что будетрассматриваться как компонент системы, а что как внешнее воздействие) и точказрения (позиция, с которой будет строиться модель). Обычно в качестве точкизрения выбирается точка зрения лица или объекта, ответственного за работумоделируемой системы в целом.
В дальнейшемобщая функция разбивается на крупные подфункции. Этот процесс называетсяфункциональной декомпозицией. Затем каждая подфункция декомпозируется на болеемелкие – и так далее до достижения необходимой детализации описания. На рис. 2показано дерево функций, называемое деревом узлов функциональной модели.
/>
Рис. 9.Пример декомпозиции – диаграмма узлов функциональной модели
Каждый узел вдиаграмме соответствует отдельному фрагменту описания диаграммы. Модельпредставляет собой совокупность иерархически выстроенных диаграмм, каждая изкоторых является описанием какой-либо функции или работы (activity).
Работы надиаграммах изображаются в виде прямоугольников (функциональные блоки). Каждаяработа изображает какую-либо функцию или работу и именуется глаголом илиглагольной фразой, обозначающей действие, например «Изготовление изделия», «Обслуживаниеклиента» и т.д. Стрелки помечаются существительным и обозначают объекты илиинформацию, связывающую работы между собой и с внешним миром. В отличие отмоделей, отображающих структуру организации, работа на диаграмме верхнегоуровня в функциональной модели – это не элемент управления нижестоящими работами.Работы нижнего уровня – это то же самое, что работа верхнего уровня, но в болеедетальном изложении.
Разрабатываяновую информационную технологию целесообразно ориентироваться на процессы,реализуемые на конкретном рабочем месте.
Под бизнес – процессомпонимается поток информации, переходящий от одного рабочего места к другому. Взадаче могут быть выделены несколько бизнес – процессов.
На схемахбизнес-процесс рекомендуется использовать следующие обозначения:
Внешняясущность (рис. 10а) – объект (например, поставщик, клиент и т.д.), скоторым взаимодействует данный работник;
Накопитель (рис. 10б) –любое хранилище данных;
Этапбизнеса-процесса (рис. 10в) – совокупность действий работника привыполнении конкретной процедуры (например выписка документа, формированиеотчета и т.д.) В верхней части блока указывается должность работника, в нижнейчасти находится содержание конкретных действий, реализующих процедуру;
Поток данных(рис. 10г) – характеризует связь (над стрелкой рекомендуется указатьнаименование конкретного документа).
/>
Рис. 10Условные обозначения

На рисунке 11приведён пример построения бизнес-процесса «Оформление счета фактуры».
/>
Рис. 11 Пример построения бизнес процесса
Анализ данныхзаключается в следующем:
a.   Для каждой задачисоставляется перечень данных, необходимых для её решения, возможна ихклассификация. Различают данные: входные(исходные), нормативно-справочные,результативные (выходнын, расчетные);
b.  Определяется структураданных: название(имя), тип, свойства;
c.   Формирование информационныхобъектов (ИО);
d.  Установление связей междуинформационными объектами.
Каждыйинформационный объект образует совокупность логически связанных реквизитов. Втаблице 1 приведен пример ИО:
Таблица 1. ИО«Журнал учета организаций-клиентов»
ИО (документ)
Название реквизита
Условное обозначение реквизита Журнал учета организаций-клиентов
1)    Название организации
2)    Должность лица, с которым осуществляется непосредственный контакт
3)    Телефон
4)    Фамилия имя отчество
5)    Адрес организации
6)    Реквизиты банка
Название
Должность
Телефон
Ф.И.О.
Адрес
БАНК

Составреквизитов определяет структуру ИО. Каждый ИО имеет уникальное имя.
Экземпляр-этосовокупность конкретных значений реквизитов. ИО имеет множество экземпляров.Каждый экземпляр ИО должен однозначно определяться ключем, который состоит изодного или нескольких реквизитов.
Информационно-логическаямодель является моделью данных, отражающих предметную областьв видесовокупности информационных объектов и структурных связей между ними.
На рисунке 12приведен пример ИЛМ
/>
Рис. 12Пример ИЛМ
Формируетсяпапка – набор документов, выстраивается декомпозиция всей системы. Папканаправляется эксперту предметной области (т.е. человеку, хорошо разбирающемусяв моделируемом фрагменте деятельности предприятия) для проведения экспертизы.На уровне контекстной диаграммы это может быть управляющий предприятия, науровне первой декомпозиции – начальник отдела и т.д., вплоть до рядовогоисполнителя. Прежде чем декомпозировать далее, на текущем уровне необходимовнести в диаграмму все замечания экспертов. Таким образом, каждый из экспертовдополняет модель в той ее части, в которой он наиболее компетентен. Врезультате получается полностью адекватная системе модель, которая позволяетнаглядно представить существующие недостатки, перенаправить и усовершенствоватьбизнес-процессы, провести анализ стоимости производства, а также послужитьосновой для создания информационной системы.
Анализ программбизнес моделирования позволяет сделать вывод, что для ведения бизнес процессовмоделирования, BPwin является уникальной программой, которая позволяет создаватьмодели процессов и поддерживает в одной модели в дополнение к IDEF0 еще два стандарта(нотации) моделирования – DFD и IDEF3. Каждая из этих трех нотаций позволяетрассмотреть различные стороны деятельности предприятия:
1)        диаграммыIDEF0 предназначены дляописания бизнес-процессов на предприятии, они позволяют понять, какие объектыили информация служат сырьем для процессов, какие результаты производят работы,что является управляющими факторами и какие ресурсы для этого необходимы;
2)        нотацияIDEF0 позволяет выявитьформальные недостатки бизнес-процессов, что существенно облегчает анализдеятельности предприятия;
3)        диаграммыпотоков данных (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применяется для того, чтобы понять происхождение затрат и облегчить выборнужной модели работ при реорганизации деятельности предприятия (BusinessProcess Re-engineering, BPR). С помощью стоимостного анализа можно решить такиезадачи, как определение действительной стоимости производства продукта,определение действительной стоимости поддержки клиента, идентификация работ,которые стоят больше всего (те, которые должны быть улучшены в первую очередь),и др. в каждой из моделей AS-IS и ТО-ВЕ.
Таким образом,делаем вывод, что стоимостный анализ позволяет оценить, каковы будутпоследствия внедрения информационной системы, действительно ли это приведет кповышению производительности и экономическому эффекту и к какому именно.
Кроме этого BPwinпозволяет делать достаточно эффективные оценки стоимости, но при этом непретендует на высокую точность таких оценок. Для точных вычислений затрат можновоспользоваться специализированным средством стоимостного анализа EasyABC.BPwin поддерживает двунаправленный экспорт – импорт в EasyABC. Результатыстоимостного анализа наглядно представляются на специальном отчете BPwin – ABC.ABC позволяет оценить стоимостные и временные характеристики системы. Еслистоимостных показателей недостаточно, имеется возможность внесения собственныхметрик – свойств, определенных пользователем UDP.
В рамкахданной дипломной работы будут рассматриваться элементы линейки AllFusion компанииComputer Associates.
Изучивпервоисточники и проанализировав их, а также само средство – программу BPwin сделаем выводы: любуюдеятельность или структуру предприятия можно спроектировать и представить ввиде, что позволит оптимизировать работу организации, проверить её насоответствие стандартам ISO9000, спроектировать структуру, снизить издержки,исключить ненужные операции, повысить гибкость и эффективность. BPwin поддерживает сразу тринотации моделирования: IDEF0[6], IDEF3 и DFD и является уникальнымпрограммным средством в области проектирования автоматизированныхинформационных систем. Проанализировав все процессы, в завершение параграфапредставлен рисунок 14, демонстрирующий все процессы такие как анализтребований и другие рабочие потоки программной инженерии.
/>/>
Рис. 14Рабочие потоки программной инженерии
Поток работ «деловоемоделирование» служит основой для анализа и формирования требований к АИС,позволяет избежать ошибок. Поток работ «управление средой» предоставляетисходную информацию для рабочей группы АТ, регламентирующую форматы оформления,CASE-средства, регламенты работы.
Поток работ «управлениепроектом» основывается на спецификации требований. Стратегическое и тактическоепланирование, формирование промежуточных вех (ожидаемых результатов) тесноувязано с требованиями к системе.
Поток работ «анализи проектирование» осуществляется на основе исходных данных, предоставленных АТ.В определенной мере эти потоки работ проводятся параллельно. При обнаружениипроблем, связанных с требованиями, возникает обратная связь от этого потокаработ к потоку работ АТ.
Поток работ «испытание»во многом базируется на модели требований и дополнительных спецификациях,регламентирующих процесс тестирования (тестовые сценарии и пр.).
Для потокаработ «реализация» связь с требованиями не указана. Между тем закономерно, чтотребования должны анализироваться и учитываться во всех рабочих потокахпроекта, даже если это формально не предусмотрено выбранным группой процессом.Людям свойственно ошибаться и ошибки, совершенные на ранних стадиях проекта,при движении от этапа к этапу нарастают, как снежный ком. Поэтому любомуучастнику команды, заинтересованному в успехе проекта, нелишне заглянуть в спецификациютребований и убедиться в том, что та работа, которая ему поручена,соответствует тому или иному требованию. Это позволяет организовать обратнуюсвязь, позволяющую отследить ошибки в спецификациях. Многие проекты зашли в тупикименно из-за оторванности группы, отвечающей за реализацию от группы сбора ианализа требований./>/>/> 1.3 Средабизнес моделирования BPwin
Интерфейссреды BPwin (рис. 15) достаточно простой и интуитивно понятный пользователю,дающий возможность аналитику создавать сложные модели при минимальных усилиях.

/>
Рис. 15.Интегрированная среда разработки модели BPwin 4.0
При запускеBPwin появляется основная панель инструментов, палитра инструментов (видкоторой зависит от выбранной нотации) и, в левой части, навигатор модели – ModelExplorer.
Данныйпрограммный продукт предназначен для пользователей в различных отрасляхдеятельности, а также для самостоятельного выбора персонального компьютера. Присоздании новой модели возникает диалог, в котором следует указать, будет лисоздана модель заново, или она будет открыта из файла либо из репозиторияModelMart, внести имя модели и выбрать методологию, в которой будет построенамодель (рис. 16).
/>
Рис. 16. Диалог создания модели

Как былоуказано выше, BPwin поддерживает три методологии – IDEF0, IDEF3 и DFD, каждаяиз которых решает свои специфические задачи. В BPwin возможно построениесмешанных моделей, т.е. модель может содержать одновременно как диаграммыIDEF0, так и диаграммы IDEF3 DFD. Состав палитры инструментов изменяетсяавтоматически, когда происходит переключение с одной нотации на другую.
После щелчкапо кнопке ОК появляется диалог Properties for New Models (рис. 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 диалога ActivityProperties
Кроме того,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 – текст отчетов.
Инструмент навигации ModelExplorer имеет три вкладки – Activities,Diagrams и Objects. Вкладка Activities (рис. 19) показывает в видераскрывающегося иерархического списка все работы модели. Одновременно могутбыть показаны все модели, открытые в BPwin. Работы с диаграмм IDEF0 показываютсязеленым цветом, IDEF3 – желтым и DFD – голубым.
/>
Рис. 19. Model Explorer
Щелчок поработе во вкладке Activity переключает левое окно BPwin на диаграмму, накоторой эта работа размещена. Для редактирования свойств работы следуетщелкнуть по ней правой кнопкой мыши. Появляется контекстное меню со свойствамиработы.
Проанализироваввозможности BPwin, изучив инструментальную среду, рассмотрим технологию бизнесмоделирования.
Выводы: таккак областью исследования в дипломной работе являются технологии проектированияи моделирования бизнес – процессов, то данные технологии потребуют освоенияинструментов создания графических изображений, методов и средствфункционального, логического и физического моделирования. При проектированииАИС важно разработать единые требования к системе, чтобы не было в дальнейшемнеобходимости переделывать проект. В современном мире компьютерных технологийважную роль играют программы бизнес моделирования, которые позволяют создатьмодель АИС. Для успешной реализации проекта необходимо чтобы инструментальныесредства были достаточно гибкими и легко приспосабливались к изменяющимсятребованиям. В результате проведенных теоретических исследований былоустановлено, что таким средством является Case – средство верхнегоуровня-BPwin, поддерживающий методологию IDEF0 (функциональная модель),IDEF3 (WorkFlow Diagram) и DFD (Dataflow Diagram).
/>/>/>/>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]
1.    производствопродуктов нефтепереработки, нефтехимии и химической продукциипроизводственно-технического назначения;
2.    хранениенефти, газов и продуктов их переработки
3.    производствотоваров народного потребления;
4.    осуществлениекоммерческой деятельности;
5.    торгово-закупочнаядеятельность;
6.    общественноепитание;
7.    осуществлениевнешнеэкономической деятельности;
8.    производствостроительной продукции;
9.    строительно-монтажныеи ремонтные работы;
10.   забор воды,водоснабжение, канализование и очистка сточных вод;
11.   сбор, утилизация,складирование, размещение, перемещение, использование, уничтожениепромышленных, в том числе опасных, и иных отходов (кроме радиоактивных);
12.   эксплуатациястационарного сооружения, предназначенного для хранения радиоактивных веществ,радиационных источников, эксплуатация аппаратов и комплексов, в которыхсодержатся радиоактивные вещества;
13.   научно-исследовательскиеи проектно-конструкторские работы;
14.   осуществление всех видовгражданско-правовых сделок с патентообладателями, владельцами «ноу-хау» иавторами иных видов интеллектуальной собственности;
15.   информационно-вычислительныеработы и разработка программных продуктов;
16.   подготовка и повышениеквалификации кадров;
17.   использование драгоценныхметаллов для нужд производства;
18.   транспортно-экспедиционнаядеятельность;
19.   медицинское, санаторное,восстановительно-реабилитационное и лечебно-профилактическое обслуживание,обеспечение лекарственными препаратами и изделиями медицинского назначения;
20.   закуп по импорту и вРоссийской Федерации, хранение, отпуск, оптовая и розничная реализациялекарственных средств, этилового спирта, изделий медицинского назначения ифармацевтической продукции;
21.   изготовление всех видовлекарственных форм, в том числе наркотических, ядовитых, психотропных исильнодействующих для населения и лечебно-профилактических учреждений города порецептам врачей и на основе лекарственных средств, зарегистрированных в РФ;
22.   приобретение, получение,перевозка, хранение, распределение, отпуск, реализация и уничтожение ядовитых,сильнодействующих, наркотических и психотропных средств, анаболиков этиловогоспирта;
23.   сбор и переработка лекарственныхтрав, изготовление и реализация фитотерапевтической продукции;
24.   приобретение, реализация,сбор и ремонт очковой оптики;
25.   проведениедезинфекционных, дезинсекционных и дератизационных работ;
26.   оздоровление населения набазах отдыха и в детских лагерях;
27.   туристическая иэкскурсионная деятельность;
28.   добыча минеральных вод изисточников, розлив ее в бутылки и реализация населению.
В компанииактивно ведется реконструкция и модернизация действующих и пуск новыхпроизводств. В ОАО «АНХК» выпускается более ста наименований товарнойпродукции, которая находит, сбыт практически во всех районах от Урала до Тихогоокеана, и далее за рубежом – в Японии, Китае, Монголии, Сингапуре и другихстранах Юго-Восточной Азии. Особый подход у компании – в решенииприродоохранных задач. В компании разработана и действует долгосрочнаяпрограмма по снижению выбросов загрязняющих веществ в окружающую среду.
За качествовыпускаемой продукции, реализацию природоохранных проектов ОАО «АНХК»неоднократно награждалась медалями и дипломами российских и международныхвыставок. По итогам 2005 года Ангарская нефтехимическая компания вошла врейтинг 100 ведущих предприятий России. 10 видов продукции маркированы золотымии серебряными знаками «Сто лучших товаров России»./> 2.1Анализ проблемы автоматизированных информационных систем ОАО «АНХК»
Проведенноеобследование деятельности основных управленческих служб Компании позволяетсделать следующие выводы:
-  методология учета,анализа и планирования в значительной степени зависит от человеческого фактора;
-  обработка первичныхдокументов, даже при наличии существующих средств автоматизации, все ещесвязана с использованием большого количества ручного труда, вследствие чего соблюдениетребуемых сроков формирования бухгалтерских отчетных документов становитсятрудновыполнимой задачей;
-  аналитический учет вфункциональных подразделениях и аналогичный учет в бухгалтерии основаны нанезависимой обработке одних и тех же первичных документов. То же самое относитсяк аналитическому и синтетическому учету в бухгалтерии;
-  объединение игруппирование информации в регистры бухгалтерского учета, а также ваналитические ведомости функциональных служб производится без использованияединой нормативно-справочной информации и единой системы классификации икодирования информации.
Рассмотримподробнее сложившуюся в Компании ситуацию в планово-экономической деятельности,дающую основание для такого рода заключений.
В планово-финансовуюдеятельность Компании вовлечено более десятка функциональных подразделений ипочти такое же количество секторов центральной бухгалтерии. Все эти службы,имея собственные оперативные задачи, должны быть связаны по роду деятельностиобщими целями и задачами бухгалтерской отчетности, экономического анализа ипрогнозирования экономической ситуации.
В связи сэтим, данные службы связаны единым документооборотом, состоящим из большогоколичества первичных документов, являющихся основой для совершения хозяйственныхопераций, ведомостей аналитического учета, подробно отражающих текущую ситуациюв том или ином аспекте планово-финансовой деятельности, а также синтетическихведомостей, содержащих обобщенные показатели состояния экономической ситуацииза определенный период времени.
Обработкауказанных документов производится таким образом, что каждая служба сначалаобрабатывает документы для получения необходимых ей результатов, а затем передаетдокументы в другие заинтересованные службы, где проводится их повторная,независимая от предыдущих обработок.
Все этоприводит к тому, что помимо увеличения затрат ручного труда на ввод в ЭВМ илина неавтоматизированную обработку документов, вследствие отдельных ошибок привводе или учете, результаты обработки одних и тех же документов дают различныерезультаты, причем, поиск ошибок чрезвычайно затруднен из-за частогонесовпадения разрезов ведения аналитического учета в различных службах.
В этихусловиях чрезвычайно важна единая методология ведения аналитического учета иподчинения его в различных службах единой цели – своевременному и качественномуформированию обобщенных показателей, характеризующих общую ситуацию напроизводстве, в сбыте или снабжении.
Однако, вусловиях отсутствия единой интегрированной автоматизированной системы обработкиданных, введение новых дополнительных разрезов ведения аналитического учета,напрямую не нужных для отдельных функциональных подразделений и служб, аимеющих своей целью улучшение качества и повышение оперативности сбора и формированияобобщенных экономических показателей, зачастую наталкивается на непонимание ипротиводействие со стороны данных служб, так как ведет к увеличению затратручного труда, не давая прямых результатов непосредственно для самих служб.
В качествепримера можно привести ситуацию, сложившуюся на стыке финансового отдела исектора учета банковских операций бухгалтерии. В финансовом отделе чрезвычайноважен оперативный учет оплаченных и неоплаченных документов в разрезеплательщиков. Банковскому сектору бухгалтерии такой учет не нужен, так какосновной задачей этого сектора является обработка платежных документов с цельюформирования бухгалтерских проводок и распределения сумм оплаты по балансовымсчетам. В результате для обеспечения совпадения данных об оплате за некоторыйпериод в финансовом отделе и банковском секторе бухгалтерии необходимо завеститакой же подробный аналитический учет, как и финансовом отделе, что в условияхручной, независимой друг от друга, обработки первичных документов представляетсобой существенную дополнительную нагрузку на сотрудников общего отделабухгалтерии.
Другимхарактерным примером является ситуация с отслеживанием поступления денежныхсредств от сторонних организаций за готовую продукцию, либо, наоборот, уплатыденег Компанией за поставляемое ей сырье или материалы. На уровнефункциональных подразделений (УПТК, Коммерческий отдел), непосредственноакцептующих счета по оплате сырья или материалов и фиксирующих факты отгрузкиготовой продукции, аналитический учет ведется в разрезе контрагентов иконкретных договоров на поставку или отгрузку, причем, для этих службчрезвычайно важно оперативное состояние баланса взаиморасчетов на текущиймомент по каждому договору. Подразделения центральной бухгалтерии не имеютвозможности вести аналитический учет на таком же уровне и с тем же качеством,так как, во-первых, для них не так существенно состояние баланса взаиморасчетовпо конкретному договору, а важно общее состояние дебиторской и кредиторскойзадолженности по организации и, во-вторых, поскольку документы поступают вбухгалтерию неравномерно в течение отчетного периода, а порциями и обычно концентрируютсяк концу периода, задача оперативного учета в подразделениях бухгалтерии вообщетеряет смысл.
Кроме того,первичные документы, передаваемые из функциональных подразделений вбухгалтерию, зачастую вообще не имеют уточняющих реквизитов (номеров счетов,платежных документов, договоров и т.д.), которые приходится получать путемвыяснения по телефону и другим средствам связи.
Подобныенедостатки могут быть устранены в единой интегрированной системе обработкиданных, где будет исключена необходимость повторного ввода и обработки одних итех же документов в различных службах, а введение дополнительных разрезованалитического учета не будет связано с увеличением затрат ручного труда.
Однако и наэтом пути есть существенные препятствия, вытекающие из сложившейся в Компанииситуации. Необходимым и важнейшим условием построения и внедрения единойинтегрированной системы обработки данных является наличие во всех службах,существующих в едином процессе сбора и обработки информации, единой системыклассификации и кодирования нормативно-справочной информации, регламентирующейобъекты, по которым будет осуществляться группирование и обобщение информации.
Приотсутствии такой системы, являющейся по существу единым языком общенияразличных служб и подразделений, единая система обработки данных невозможно.Другим важнейшим условием, определяющим эффективность единой системы обработкиданных, является введение на предприятии системы обобщенных показателей,характеризующих общую экономическую ситуацию на производстве (критериевэффективности работы завода) и обеспечивающих проведение на основе сбора данныхпо этим показателям качественного экономического анализа. После утвержденияданных показателей необходимо подчинить деятельность всех служб и подразделенийцели ведения аналитического и синтетического учета в разрезе данных показателей.К сожалению, в настоящее время в Компании отсутствует единая система нормативно-справочнойинформации, не осуществляется сбор информации в единых разрезах,характеризующих общую экономическую эффективность работы объединения.
Компанияпроизводит некоторые виды сырья и приобретает их у компаний-поставщиков.Основными процедурами являются:
-   Поступлениесырья от поставщиков;
-   Приемменеджерами заказов от клиентов;
-   Группировказаказов по подразделениям;
-   Выполнениезаказов и поступление их на склад готовой продукции;
-   Отправказаказов;
В отделепоставок находится информации о всевозможных видах сырья. Ведутся справочникипо сырью и по поставщикам. Осуществляется закупка необходимых сырьевыхкомпонентов у поставщиков, сырьё отправляется на склад, со склада поступают в цехаи подразделения по производству продукции, готовый продукт поступает на складготовой продукции. База данных позволяет вводить и выводить данные по компонентам,добавлять записи по новым наименованиям, удалять компоненты, корректировать данные,кодам, ценам, количеству. Схема информационных потоков предполагает наличиечетырех участников:
поставщика – предоставляетинформацию о ценах и условиях поставок в отдел сбыта; с ним заключается договорна поставку товаров;
склада сырья иготовой продукции;
производственныеотделы;
финансовыйотдел.
Диаграммапотоков данных представлена на рисунке 20.
/>
Рис. 20Диаграмма потоков данных
Основной задачейуправления является координация деятельности подразделений для наиболееэффективного их использования по решению стратегических, тактических и текущихзадач предприятия. Этому должен способствовать не только профессионализм, но иширокая информационная поддержка анализа состояния и тенденций развития.Управление бизнес-процессами требует комплексного рассмотрения как внешних, таки внутренних факторов, к которым могут относиться: неопределенность среды,обострение конкуренции, постоянно меняющаяся правовая среда и другие. Поэтомудля эффективного решения описанных задач, необходимо внедрение информационнойсистемы управления, которая бы не только обеспечивала информацией о текущемсостоянии дел, но и координировала работу подразделений предприятия, а такжепозволяла прогнозировать последствия тех или иных изменений.
В работерассмотрен процесс производства. Основные процессы информационной системы:
– информированиезаказчиков;
– ведениенормативно-справочной информации;
– организацияудобства ввода, вывода, просмотра поступающего товара;
– выборпоставщиков;
– созданиенеобходимой вторичной выходной информации./>/>/>/> 2.2Изучение задач управления
Проектразрабатывается с целью построения бизнес-модели предприятия «АНХК».Организационно-функциональная схема которого представлена на рисунке 21.
Производясбор и хранение информационных массивов, на ЭВМ необходимо упорядочитьинформацию по различным признакам, с целью обеспечения возможности быстрогопоиска нужной информации. Большое значение при этом приобретаетструктурирование данных (это введение соглашений о представлении и отображенииданных).

/>
Рис. 21 Организационно-функциональная схема предприятия«АНХК»
/>Служащие могут легко понять и узнать, какие данные имеются в ихраспоряжении, доступ к данным должен быть простым, исключающий возможныеошибки; БД может увеличиваться и изменяться без нарушения имеющихся способовиспользования данных; пользователь БД может обращаться с самыми различнымизапросами по поводу хранимых в ней данных./>/>/>/>/>/>/>/>/>/>/> 2.3 Описание входной информации
Еслирассматривать хранимую информацию с точки зрения поставок, то можно выделить несколькоеё составляющих:
1.        информацияо поставщиках предполагается хранение информации о действующих в настоящеевремя поставщиках, наименование фирмы поставщика, юридический адрес телефон;
2.        информацияо поставках, сведения о том какой конкретно товар поставили, сведения окачестве этого товара, дату поставки;
3.        информацияоб оплате;
4.        информацияоб остатках товара на складе, какой товар находится на складе, какого производителя,в каком количестве.
Пользователямиперечисленной информации являются директор, начальник отдела сбыта, маркетолог,начальник финансового отдела, бухгалтер и клиент.
Приоформлении заказа у поставщиков заводится запись в таблице «Учет клиентов» внеё вноситься информация о клиенте. К документам предметной области можноотнести так же информацию о продукции предприятия, сформированную в видеотчетов и предложенную для ознакомления клиенту./>/>/>/>/>/>/>2.5 Описание выходной информации
Выходнаяинформация представляется двумя видами:
1.        ввиде отчетов, которые создаются на основе требуемых запросов, по базе данных.Их цель – предоставление наглядной информации. Они могут быть не толькопредставлены в ПК, но и распечатаны для удобства выбора;
2.        ввиде запросов, которые создаются в соответствиями с информационными требованиями;
3.        ввиде форм, предназначенных для ведения нормативно-справочной информации
В результатеанализа деятельности и структуры предприятия, были сформированы достаточноцельные и систематизированные знания области исследования, которые в дальнейшембудут реализованы в построении диаграмм бизнес процесса. Анализ проблемавтоматизации показал, что на предприятии не существует единой корпоративнойинформационной системы, не существует и единого банка данных./>/>/>/> 
/>/>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) строятся для иллюстрации отдельных фрагментов модели, дляиллюстрации альтернативной точки зрения либо для специальных целей.
Диаграммыдекомпозиции содержат родственные работы, т.е. дочерние работы, имеющие общуюродительскую работу. Для создания диаграммы декомпозиции следует щелкнуть покнопке +. Возникает диалог 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 диалога ModelProperties (меню Model/ModelProperties).
Словарьстрелок редактируется при помощи специального редактора Arrow Dictionary, в которомопределяется стрелка и вносится относящийся к ней комментарий.

/>
Рис. 26Словарь стрелок
Словарьстрелок решает очень важную задачу. Содержимое словаря стрелок можнораспечатать в виде отчета (меню Tools/Reports/Arrow Report) и получить темсамым толковый словарь терминов предметной области, использующихся в модели.
Диаграммысоздаются аналитиком для того, чтобы провести сеанс экспертизы, т.е. обсудитьДиаграмму со специалистом предметной области. В любой предметной областиформируется профессиональный жаргон, причем очень часто жаргонные выраженияимеют нечеткий смысл и воспринимаются разными специалистами по-разному. В товынужден употреблять те выражения, которые наиболее понятны экспертам.Поскольку формальные определения часто сложны, восприятия, аналитик вынужденупотреблять профессиональный жаргон, а, чтобы не возникло неоднозначныхтрактовок, в словаре стрелок каждому понятию можно дать расширенное и, если этонеобходимо, формальное определение (рис. 27).

/>
Рис. 27Начальный этап построения
ICOM(аббревиатура от Input, Control, Output и Mechanism) – коды, предназначенныедля идентификации граничных стрелок. Код ICOM содержит префикс, соответствующийтипу стрелки (I, С, О или М), и порядковый номер (рис. 28).
/>
Рис. 28 Диаграммы декомпозиции работы А0 с кодами ICOM
/>/>/>/>3.3 Создание диаграммы дерева узлов идиаграммы FEO
Диаграммадерева узлов показывает иерархическую зависимость работ, но не взаимосвязимежду работами. Диаграмм деревьев узлов может быть в модели сколь угодно много,поскольку дерево может быть построено на произвольную глубину и не обязательнос корня.
Процесссоздания модели работ является итерационным, следовательно, работы могут менятьсвое расположение в дереве узлов многократно, чтобы не запутаться и проверитьспособ декомпозиции, следует после каждого изменения создавать диаграмму дереваузлов. Впрочем, BPwin имеет мощный инструмент навигации по модели – ModelExplorer, который позволяет представить иерархию работ и диаграмм в удобном икомпактном виде, однако этот инструмент не является составляющей стандарта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может не иметь стрелок управления и выхода.
С целью обсужденияопределенных аспектов модели с экспертом предметной области может быть созданадиаграмма только с одной работой и одной стрелкой, поскольку стандартнаядиаграмма декомпозиции содержит множество деталей, не относящихся к темеобсуждения и дезориентирующих эксперта. Но если FEO используется для иллюстрацииальтернативных точек зрения (альтернативный контекст), рекомендуется все-такипридерживаться синтаксиса IDEF0. Для создания диаграммы FEO следует выбратьпункт меню Diagram/Add FEO Diagram. В возникающем диалоге Add New FEO Diagramследует указать имя диаграммы FEO и тип родительской диаграммы.
/>
Рис. 32. Диалог создания FEO-диаграммы

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


/>/>/>/>Заключение
Любойпроизводственный проект начинается с планирования. Планирование – это процессразработки и последующего контроля за ходом реализации плана и егокорректировки в соответствии с изменяющимися условиями, т.е. планирование – этопроцесс обработки информации по обоснованию предстоящих действий, определениеэкономически эффективных способов достижения цели. Для достижения наибольшегоэкономического эффекта предприятие должно использовать такие методыпроизводства, которые являются эффективными, как с технологической стороны, таки с экономической точки зрения. Важными факторами также будет эффективноераспределение ресурсов, система цен, эффективность и другие.
В результатеанализа деятельности и структуры предприятия «АНХК», были сформированыдостаточно цельные и систематизированные знания в области исследования, которыев дальнейшем будут реализованы в построении диаграмм бизнес процесса.
Анализпроблем автоматизации показал, что на предприятии не существует единойкорпоративной информационной системы, не существует и единого банка данных, чтопорождает несогласованность и не оперативность в работе подразделений.
Предприятиюрекомендуется, используя инструментальную среду моделирования, выполнитьпроектирование АИС, разработать единый банк информации, использовать для работыраспределенные системы обработки информации. А так же использовать технологииоптимального календарного планирования по кварталам, месяцам.
На примере конкретного предприятия выполненопостроение моделей бизнес процессов, рассмотрено существующее положение дел визучаемой области, произведен детальный анализ алгоритмов построения бизнес процессовсредствами инструментальной среды BPwin.
Сделаны следующие выводы:
1.        реализациюкрупных проектов следует разбивать на стадии анализа проектирования,непосредственного кодирования, тестирования и сопровождения;
2.        крупныйпроект невозможно реализовать в одиночку;
3.        жизненныйцикл ИС равен примерно 2 годам, столько же требуется времени на разработку ИС,для создания крупной информационной системы жизненно необходим инструмент,который бы значительно уменьшал время разработки ИС;
4.        таккак жизненный цикл довольно продолжителен и существует возможность получить напоследней стадии продукт, который будет не совсем удовлетворять новым требованиям,жизненно необходима инструментальная среда способная быстро приспособится кизменившимся требованиям установлено, что таким требованиям вполнеудовлетворяет среда BPwin, такие модели представляют информационные потребности в удобном инаглядном для восприятия виде, что делает их хорошим средством коммуникациимежду проектировщиками и пользователями в процессе уточнения постановки задач.Любой разработчик заинтересован, чтобы описание концептуальной модели былоиспользовано для создания спецификаций, описывающих структуру и основныекомпоненты будущей системы. Полученные в BPwin компоненты системы могутбыть преобразованы в реальные объекты базы данных, экранные формы и отчеты.
Целью дипломной работыявлялось изучение проблем совершенствования информационного обеспеченияуправления организацией, построение модели основных бизнес процессов напредприятии. В результате выполнения дипломной работы, поставленные цели изадачи выполнены. 

/>/>/>/>/>/>/>Список литературы
1.    О недрах: федеральныйзакон РФ от 21.02.1992 г. №2395–1 (ред. от 29.06.2004 г.)[электронный ресурс] // Консультант Плюс. Версия Проф.
2.    Армяков М. РусскиеИнвесторы / М. Армяков // Экономика России: ХХI век. – 2002. – №2. –С. 7–10.
3.    Анисимов В.В. 50 летуспешной вахты. Научно-технические достижения и передовой опыт / В.В. Анисимов //Нефтепереработка и нефтехимия. – 2003. – №8. – С. 3–4.
4.    Батюнин В.А. Снижениеэнергозатрат – путь к повышению эффективности производства / В.А. Батюнин,В.Ю. Абрамов // Нефтепереработка и нефтехимия. – 2003. – №8. – С. 52–53.
5.    Безруков А.А. Аппетитныесоседи / А.А. Безруков // Нефтегазовая отрасль. – 2004. – №7. – С. 23–24.
6.    Белобородов К.Г. Экспортироватьбензин станет дороже / К.Г. Белобородов // Коммерсант. – 2004. – №194. – С. 6–7.
7.    Беспалов Ю.А. О закрытииряда химических производств ОАО «Ангарская нефтехимическая компания» / Ю.А. Беспалов //Время. – 2001. – 18 февр.
8.    Бирюков Н.Н. Бизнеси нефть / Н.Н. Бирюков // БИКИ. – 2001. – №2. – С. 39.
9.    Воеводин Г.А. Нефтьи Россия: планы на будущее / Г.А. Воеводин // Ведомости. – 2004. – №32.– С. 9.
10. Воронина Н.В. Мировой рынок нефти:тенденции развития и особенности ценообразования / Воронина Н.В. //Практический маркетинг. – 2003. – №10. – С. 12–18.
11. Вяземский О.В. Сколько стоит нашебудущее / О.В. Вяземский // Ведомости. – 2004. – №37. – С. 12.
12. Гаврилова Н.А. Итоги деятельности ОАО «АНХК»/ Н.А. Гаврилова // Восточно-Сибирская правда. – 2004. – №87. – С. 8.
/>/>/>/>13.ДэниелО'Лири ERP системы. Современное планирование и управление ресурсамипредприятия. Выбор, внедрение, эксплуатация М.: ООО «Вершина», 2004. – 272с, [Пер. с англ. Ю.И. Водопьяновой
/>/>14. Меняев М.Ф Информационныетехнологии управления: Книга 3: Системы управления организацией М.: Омега-Л,2003. – 464 с
/>/>15. Автоматизированные информационныесистемы, базы и банки данных. Вводный курс: Учебное пособие М.: Гелиос АРВ,2002. – 368 с., ил
/>/>16. Б.Н. Гайфуллин, И.А.ОбуховАвтоматизированные системы управления предприятиями стандарта ERP/MRPII.Производственное издание М. «Богородский печатник», 2001, 104 с
/>/>17. Петров В. Н Информационныесистемы СПб.: Питер, 2002. – 688 с
/>/>18.IEEE Standard Glossary of Software Engineering Terminology IEEEStd 610.12–1990
/>/>19. Вигерс Карл Разработкатребований к программному обеспечению Пер, с англ. – М.: Издательско-торговыйдом «Русская Редакция», 2004. -576 с.: ил
/>/>20. Леффингуелл Д., УидригДПринципы работы с требованиями к программному обеспечению М.: ИД «Вильямс»,2002
/>/>21. Алистер Коберн Современныеметоды описания функциональных требований к системам М.: издательство «Лори»,2002. – 263 с
/>/>22. Мацяшек Лешек Анализтребований и проектирование систем. Разработка информационных Пер. с англ. – М.:Издательский дом «Вильямс», 2002. – 432 с.: ил. – Парал. тит. Англ
/>/>23. Орлик С., Булуй Ю Введениев программную инженерию и управление жизненным циклом ПО Программная инженерия.Программные требованияCopyright © Сергей Орлик, 2004–2005
/>/>24.IEEE Guide to the Software Engineering Body of Knowledge(1) – SWEBOK®,2004
/>/>25. ГОСТ Р ИСО/МЭК 12207/99.Государственный стандарт РФ. Информационная технология. Процессы жизненногоцикла информационных систем Издание официальное. – М., 1999
/>/>/>/>/>/>/>/>/>/>/>/>/>/>/>/>/>/>26.Каменова,Громов Моделирование бизнеса. Методология ARIS М.: Весть-МетаТехнология, 2001
/>/>/>/>/>/>27. А. Якобсон, Г. Буч, Дж. РамбоУнифицированный процесс разработки программного обеспечения СПб.: Питер, 2002. –496 с
/>/>28. Э.В. Попов Искусственныйинтеллект: в 3 книгах, кн. 2. Модели и методы М.: Радио и связь. – 1990
/>/>29. Марка Д.А Методологияструктурного анализа и проектирования СПб.: Питер, 1995. – 235 с
/>/>30. Марка Д., МакГоуэн К Методологияструктурного анализа и проектирования М.: МетаТехнология, 1993
/>/>31. ГОСТ 34.601–90.Информационная технология. Автоматизированные системы. Стадии создания
/>/>32. Фаулер М, Скотт К UML вкратком изложении. Применение стандартного языка объектного моделирования Пер.с англ. – М.: Мир, 1999. – 191 с., ил
/>/>33. Алистер Коберн Современныеметоды описания функциональных требований к системам
/>/>34. Леоненков Самоучитель UML
/>/>35. Маклаков С.В Bpwin ErwinCase-средства разработки информационных систем Москва «ДиалогМифи» – 2000
/>/>/>/>36.ГОСТ19.201–78 «Техническое задание, требования к содержанию и оформлению»
/>/>/>/>37.Соммервилл,Иан Инженерия программного обеспечения, 6-е издание Пер. с англ. – М.:Издательский дом «Вильямс», 2002. – 624 с.: ил. – Парал. тит. англ
/>/>38. Орлик С Программная инженерия.Качество программногообеспечения (Software Quality) Copyright © Сергей Орлик,2004–2005
/>/>39. Калянов Г. Н Консалтингпри автоматизации предприятий: Научно-практическое издание Серия «ИнформатизацияРоссии на пороге XXI века». – М.: СИН-ТЕГ, 1997
/>/>/>/>/>/>40. Мальков А.С. Проект автоматизациифинансово-хозяйственной деятельности ОАО «Ангарская нефтехимическаякомпания». – М.: 2002 г.
41. Галкин А.А. Дегтярь Р.М. Теорияи практика оценки эффективности эксплуатации ERP системы. – М.: Корпоративныйменеджмент. №7 2002 г.
42. Высочин С.Н., Фролов Е.Е. Управлениецеховым складом, как элемент системы ресурсосберегающей организациипроизводства. – М.: САПР и графика. №11, 2000 г.
43. Шебек С.С. Практика разработки корпоративныхстандартов. – СПб: Планета КИС. 2000 г.
44. Шаракшанэ А.С., Халецкий А.К., Морозов И.А. Оценкахарактеристик сложных автоматизированных систем. – М., Машиностроение, 1993. – 272 с.
45. Чембровский О.А., Топчеев Ю.И., СамойловичГ.В. Общие принципы проектирования систем управления. – М.,Машиностроение, 1972. -414 с.
46. Уайт О.У. Управление производством иматериальными запасами в век ЭВМ. М.: Прогресс. 1978, C. 302. //OliverW. Wight. Production and inventory management in the computer age. Macmillan of Canada, 1974
47. Компьютерные системы исети: Учеб пособие / В.П. Косарев и др. / Под ред. В.П. Косарева и Л.В. Еремина.– М.: Финансы и статистики, 1999.