Файл: Моделирование предметной области «Покупка сырья и материалов» с помощью UML.pdf

Помимо элементов, характеризующие события и функции, нотация eEPC позволяет указывать дополнительные информационные параметры бизнес-процесса, такие как используемые документы, роли и ответственные сотрудники и так далее. Основные элементы нотации eEPC в программном инструменте ARIS Express приведены в таблице 2 :

Таблица 2. Графические элементы нотации eEPC в программном средстве ARIS Toolset.

№	Графическое представление	Название	Описание
1		Интерфейс процесса	Элемент в ARIS Express, отображающий внешнюю по отношению к моделируемому процессу функцию или бизнес-процесс. Данный элемент используется в двух различных ключах: Отображает предыдущий / следующий процесс или функцию по отношению к моделируемому бизнес-процессу; Отображает бизнес-процесс, передающий или принимающий объект, участвующий в выполнении моделируемого процесса.
2		Событие	Элемент в ARIS Express, отображающий важное событие или веха, которое контролирует или непосредственно влияет на дальнейшее выполнение бизнес-процесса.
3		Функция	Элемент в ARIS Express для отображения подпроцесса, набора действий, выполняющих с целью получения заданного результата в процессе использования и преобразования входных объектов, таких как документы, продукты.
4		Роль	Элемент в ARIS Express для отображения человека или организации из внешней среды, влияющих на выполнения бизнес-процесса.
5		Сотрудник	Элемент в ARIS Express для отображения внутреннего сотрудника исследуемой организации, выполняющих свои обязанности в рамках бизнес-процесса.
6		Организация	Элемент в ARIS Express для отображения подразделения, организации из внешней среды, непосредственно влияющие на выполнение бизнес-процесса.
7		Информационная система	Элемент в ARIS Express для отображения информационной системы, которая поддерживает бесперебойное выполнение бизнес-процесса.
8		Продукт	Элемент в ARIS Express для отображения продуктов или ресурсов, расходуемые или создаваемые в рамках выполнения бизнес-процесса
9		База данных	Элемент в ARIS Express для отображения базы данных, поддерживающие выполнения функции.
10		Документ	Элемент в ARIS Express для отображения бумажных и электронных документов, поддерживающие выполнение функции.
11		Риск	Элемент в ARIS Express для отображения наличия какого-либо типа риска в процессе выполнения функции.
12		Логический оператор «Исключающее ИЛИ»	Элемент в ARIS Express для отображения ветвления событий последующие после выполнения функции. То есть, если в завершении функции возможны два исхода событий, характеризующиеся разными событиями, то процесс будет продолжаться лишь по одному из сценариев: либо инициируется первый сценарий, либо второй.
13		Логический оператор «ИЛИ»	Элемент в ARIS Express для отображения ветвления бизнес-процесса на различные варианты развития. То есть после выполнения функции инициируются одно или несколько событий, которые происходят параллельно.
14		Логический оператор «И»	Элемент в ARIS Express для отображения ветвления бизнес-процесса на различные варианты его выполнения, выполняющихся параллельно. То есть после выполнения функции инициируются несколько событий, которые происходят параллельно.
15		Связь	Элемент в ARIS Express для отображения логической взаимосвязи между объектами бизнес-процесса.

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

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

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

1.2 Разработка требований к информационной системе

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

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

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

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

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

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

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

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

2. Анализ предметной области

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

2.1 Описание объекта исследования

Вместимость сервисного центра составляет 2 легковых автомобиля, среднее время обслуживания которых составляет 1,5 часа. Рабочий персонал состоит из шести человек – администратор, продавец запчастей и 4 автомеханика со сменным графиком работы. Автосервис оснащен складским помещением под материалы и сырье первой необходимости – машинное масло, инструменты, основные запчасти. Инфраструктурная часть автосервиса состоит из ПК, два из которых расположены на рабочих местах администратора и продавца, подключенные к одной сети, а оставшиеся оборудованы на подъемнике и шиномонтажной установке. Основной документацией сервисного центра является главный журнал учета обслуживаемых автомобилей в формате бумажной тетради. В этот документ заносится информация о дате и времени обслуживания автомобиля с указанием регистрационного номера, причины обращения и списка выполненных работ. Главный журнал заполняется механиками после каждого завершенного обслуживания автомобиля. В распоряжении сервисного центра также имеется документация по учету используемых ресурсов, оставшихся запчастей и доходов/расходов, которые заполняются руководителем.