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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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