Файл: Построение объектной модели информационной системы Автосервис Построение объектной модели информационной системы Автосервис.docx

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 22.11.2023

Просмотров: 314

Скачиваний: 12

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.


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

1.2. Основные бизнес-процессы


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

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

- учет и хранение данных по приходным накладным,

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

- получение и обработку запросов из филиалов,

- формирование отправок,

- получение и регистрацию запасных частей,

- хранение и движение запасных частей на складе,

- отгрузку отправок,

- составление расходных документов,

-учет и хранение данных расходных документов.

Кратко движение запасных частей представлено на eEPC диаграмме бизнес-процессов на центральном складе (рис.1.2).



Рис.1.2. Бизнес –процессы на центральном складе

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

Данную систему можно оптимизировать, сменив приоритеты, как на рис.1.3.


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


Рис.1.3. Модель оптимизированной работы центрального склада.

Коротко опишем другие информационные системы и обозначим их слабые места. Начнем с бухгалтерии. Используется ИС 1С Бухгалтерия, данная область бизнес процессов достаточно формализована и алгоритмизирована за счет финансовых расчетов, правил, требований, поэтому информационные системы автоматизирующие бухгалтерские процессы и потоки данных максимально оптимизированы и эффективны. Улучшить систему в этом случае можно, только за счет сокращения расходов на ее приобретение, исходя из того, что все системы бухгалтерского направления имеют схожий функционал и базируются на одних и тех же формулах. Еще одним фактором выбора системы является GUI – графический интерфейс пользователя. Удобство работы с интерфейсом определяется понятием юзабилити. Что можно определить как человекоориентированность, смысл юзабилити заключается в том, что информационная система должна быть комфортна в использовании иметь адаптивный дизайн и должна реализовывать максимальное количество функций при минимальном количестве действий. Для информационной системы актуально понятие «интуитивно понятна». Любая информационная система сложна, исходя из сложности программного обеспечения, поэтому в случае предприятия использование 1С можно оправдать качественным интерфейсом.

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



Для эффективной работы отдела была разработана информационная система, которая носит название ServiceDesk системы.



Рис.1.4. Информационные прцессы в системе обслуживания компьютерной техники автосалона

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

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

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

- регистрация заявки непосредственно у специалиста 1-го уровня.

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

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

ГЛАВА 2. ПОСТРОЕНИЕ ОБЪЕКТНОЙ МОДЕЛИ (Актеры: механики (различных участков), начальник смены, мастер-приемщик и клиент.


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

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


Методология UML имела на начало только одного серьезного конкурента – методологию SADT, которая также использовалась в проектировании и разработке программного обеспечения, но имела несколько иную направленность, а именно – использовалась при проектировании и разработке информационных систем. Однако несколько позже возможности UML, в направлении четкого графического описания функций, потоков данных и процессов, позволили ее использование в бизнесе при анализе и проектировании информационных и бизнес систем. Таким образом, UML вытеснило SADT из бизнеса и сейчас нотации IDEF0, DFD и IDEF3 можно встретить только в вопросах разработки информационных систем.

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

Сначала на его место претендовала методология ARIS со своей группой диаграмм, которые получили условное название дом ARIS. Однако основой данной методологии, наиболее информативной диаграммой является EPC диаграмма, которая практически копирует диаграммы активности UML.

Сегодня наиболее распространенной среди бизнес-аналитиков является методология BPMN 2.0. Но следует отметить, что в основе данной технологии лежат те же принципы и диаграммы UML, в частности диаграммы прецедентов, последовательности и активности. С другой стороны, потеря некоторых позиций в бизнес-аналитике не снимает актуальности с использовании UML при проектировании бизнес –систем. В любом случае знание данной методологии позволяет более быстро и глубоко разобраться с методологиями ARIS и более современной BPMN 2.

2.1. SADT


Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы. Сейчас чаще всего говорят о IDEF0, наиболее часто используемом фрагменте данной методологии в которую еще входит IDEF3.

Эта методология описывает функциональный аспект информационной системы, при этом она конкурирует с методологией, которая ориентирована на описание потоков данных (DFD). В отличие от этих методологий IDEF0 позволяет:

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

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


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

Эта методология при описании функций информационной системы конкурирует с методами, описания потоков данных (DFD). В отличие от них IDEF0 позволяет:

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

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

2.1.1. IDEF0 AS-IS




Рис.2.1. Бизнес процесс обработки заявки клиента



Рис.2.2. Декомпозиция процесса обслуживания клиента

2.1.2. IDEF0 TO-BE




Рис.2.3. Внедрение ИС в процесс обслуживания



Рис.2.4. Роль ИС в бизнес процессах регистрации заявки

2.2. DFD




2.5. Диаграмма потоков данных процесса регистрации заявки в базе системы

2.3. BPMN 2


Наиболее перспективной и современной с точки зрения моделирования бизнес-процессов информационных систем является методология BPMN 2. Исследуем бизнес процесс прохождения заявки клиента нашего предприятия («Автосервис») средствами нотации BPMN 2 c использованием бесплатного редактора Aris Express (рис.2.6)



Рис.2.6. Процесс принятия заявки от клиента менеджеров в ремонтном цеху

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

Рассмотрим BPMN 2.0 диаграмму процесса продажи автомобиля (рис.2.7)



Рис.2.7. Процесс продажи автомобиля

2.4. UML 2


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

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