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

УДК 004

МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ И РЕМОНТА В АВТОСЕРВИСЕ

Саганенко А.А.1, Стебелев П.Н.2, Назарова О.Б.3
1Магнитогорский государственный технический университет им. Г.И. Носова, студентка группы АПИп-14
2Магнитогорский государственный технический университет им. Г.И. Носова, студент группы АПИп-14
3Магнитогорский государственный технический университет им. Г.И. Носова, канд. пед. наук, доц. ИЭиАС

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

Ключевые слова: моделирование бизнес-процессов

SIMULATION OF MAINTENANCE BUSINESS PROCESSES AND REPAIR SERVICE STATION

Saganenko A.A.1, Stebelev P.N.2, Nazarova O.B.3
1Nosov Magnitogorsk State Technical University, student
2Nosov Magnitogorsk State Technical University, student
3Nosov Magnitogorsk State Technical University, candidate. ped. Sciences, Assoc.

Abstract
This article describes the simulation of maintenance business processes and repair service station.

Библиографическая ссылка на статью:
Саганенко А.А., Стебелев П.Н., Назарова О.Б. Моделирование бизнес-процессов технического обслуживания и ремонта в автосервисе // Современная техника и технологии. 2016. № 11. Ч. 2 [Электронный ресурс]. URL: https://technology.snauka.ru/2016/11/11430 (дата обращения: 24.02.2023).

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

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

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

Результаты анализа документооборота, сопровождающего техническое обслуживание и ремонт автотранспорта, представлены в виде  диаграммы IDEF0 на рис.1-2.

Рисунок 1 – Диаграмма верхнего уровня (А0) функциональной модели деятельности автосервиса

Обобщение диаграммы верхнего уровня (А0) в контекстную диаграмму (А-0) выполняется на следующем этапе построения функциональной модели. Также нужно отметить, что не все граничные дуги на диаграмме А0 нашли свое отражение на диаграмме А-0. Для этих целей использовался туннель «не в родительской диаграмме» [4].

Рисунок 2 – Контекстная диаграмма (А-0) функциональной модели деятельности автосервиса

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

−        ручной документооборот;

−        длительное составление отчетности;

−        возможность потери документов;

−        высокие риски организации и выполнения технического и сервисного обслуживания.

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

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

а также позволит:

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

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

Для начала сформулируем цель – минимизировать риски в процессе технического и сервисного обслуживания и определим первичные причины, влияющие на ее достижение: мониторинг, работники, метод, управление, материалы (в основе правило «шести М»).

Это правило состоит в том, что в общем случае существуют следующие шесть возможных причин тех или иных результатов:

  • материал (material),
  • оборудование (machine),
  • измерение (measurement),
  • метод (method),
  • люди (man),
  • менеджмент (management).

Рисунок 3-Диаграмма причин и факторов Исикавы

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

Далее представлен весь алгоритм расчета. Мы пригласили экспертов, которые оценили по пятибалльной шкале факторы, влияющие на минимизацию рисков. Результаты опроса  экспертов сводятся в матрицу размерности   (табл.1), которая называется матрицей опроса.

Таблица 1. Матрица опроса

Факторы
Эксперты Мониторинг Работники Метод Управление Материалы Сумма по строке

1

5

5

4

5

3

22

2

3

5

5

2

5

20

3

2

4

3

1

4

14

4

1

5

2

4

2

14

Рассчитаем относительный вес  каждого фактора. Проведем преобразование матрицы опроса:

  1.  Находим отношение ранга, выставленного экспертом 1 к сумме рангов данного эксперта  по всем факторам.
  2.  Проводим операцию преобразования по всем экспертам.
  3.  Находим все суммы по столбцам (преобразованный ранг).
  4.  Находим относительный вес фактора: преобразованный ранг делим на количество экспертов

Таблица 2. Преобразованная матрица опроса

Факторы
Эксперты Мониторинг Работники Метод Управление Материалы

1

0,23

0,23

0,18

0,23

0,14

2

0,14

0,23

0,23

0,09

0,23

3

0,09

0,18

0,14

0,05

0,18

4

0,05

0,23

0,09

0,18

0,09

Сумма по столбцам

0,5

0,86

0,64

0,55

0,64

Делим на количество экспертов

0,125

0,21

0,159

0,136

0,159

%

12,5%

21,6%

15,9%

13,6%

15,9%

После построения диаграммы и проведения экспертной оценки, мы выявили, что наиболее важной причиной первого уровня являются Работники (21,6%), далее следует Метод (15,9%), Материалы (15,9%), Управление (3,6%) и самая малозначимая причина первого уровня  Мониторинг (12,5%).

Проведем расчет относительного веса  по каждой причине первого уровня, начиная с наиболее значимой «Работники»:

  1. Результаты опроса  экспертов сводятся в матрицу размерности   (табл.3), которая называется матрицей опроса по факторам причины первого уровня “Работники”. Высчитываем сумму по строке.
  2. Проведем расчет относительных весов по причинам второго уровня: Квалификация, Здоровье, Опыт работы, Вежливое обращение.
  3. Берем баллы, проставленные экспертами и делим на сумму по строке, тоже самое проделаем со всеми причинами второго уровня.
  4. Рассчитываем сумму по столбцам.
  5. Сумму по столбцам делим на количество экспертов.
  6.  Завершаем расчет относительных весов по причинам второго уровня, учитывая относительный вес причины первого уровня (Например, «Работники» – 0,21*21,6%=4,5%) (табл. 4).

Таблица 3. Матрица опроса по факторам причины первого уровня «Работники»

Работники
Эксперты Квалификация Здоровье Опыт работы Вежливое обращение Сумма по строке

1

5

5

4

5

19

2

3

5

4

5

17

3

4

5

5

5

19

4

4

3

1

2

10

Таблица 4. Преобразованная матрица опроса по факторам причины первого уровня «Работники»

Работники
Эксперты Квалификация Здоровье Опыт работы Вежливое обращение

1

0,26

0,26

0,21

0,26

2

0,15

0,26

0,21

0,26

3

0,21

0,26

0,26

0,26

4

0,21

0,15

0,05

0,11
Сумма по столбцам

0,84

0,94

0,73

0,89
Делим на количество экспертов*

0,21

0,23

0,18

0,22

Перенос на Исикавы**

4,5%

5,1%

4,0%

4,8%

Аналогично по алгоритму, представленному выше,  проводим расчет относительного веса  по остальным  причинам первого уровня: Метод, Материалы, Управление и Мониторинг.

Представим полученные результаты:

Работники (21,6%):

  • квалификация (4,5%)
  • здоровье (5,1%)
  • опыт работы(4,0%)
  • вежливое обращение с клиентами (4,8%)

Метод (15,9%): 

  • гарантия (4,0%)
  • скидки постоянным клиентам (4,0%)
  • проведение акций (3,9%)

Материалы (15,9%): 

  • качественные детали (3,3%)
  • хранение на складе (2,8%)
  • приемлемые цены у поставщиков (2,8%)
  • новейшее оборудование (3,3%)
  • надлежащий уход (3,3%)

Управление (13,6%):

  • электронный документооборот (4,5%)
  • распределение нагрузки (5,7%)

  Мониторинг (12,5%):

  • региональный рейтинг (4,9%)
  • система диагностики (7,2%)
  • видеонаблюдение за процессом (5,7%)

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

Библиографический список

  1. Гаврилова И.В., Новикова Т.Б., Назарова О.Б., Петеляк В.Е., Агдавлетова А.М. Совершенствование методов построения причинно-следственных диаграмм для решения задач управления в организационных системах / И.В. Гаврилова, Т.Б. Новикова, О.Б. Назарова, В.Е. Петеляк, А.М. Агдавлетова. – Фундаментальные исследования, №8 (часть 2), 2015. – с. 247-251
  2. Новикова Т.Б., Лунцова Д.С., Меркурьев А.В., Махмутова М.В. Разработка модели описания и оценок эффективности решения задач управления на примере бизнес-процесса «Планирование и мониторинг выполнения заказа в планово-производственном отделе» // Современная техника и технологии. 2015. № 12 (52). С. 168-173.
  3. Масленникова, О.Е. Информационная система управления как ядро информационной инфраструктуры современного образовательного учреждения [Текст]/О.Е. Масленникова//Вестник компьютерных и информационных технологий. -М., 2010. -№ 8. -С. 47-51.
  4. Новикова Т.Б., Курзаева Л.В., Петеляк В.Е., Масленникова О.Е., Белоусова И.Д. Описание управления бизнес-процессами предприятия на основе методологии IDEF0: трудности разработки, рекомендации по совершенствованию построения диаграмм / Т.Б. Новикова, Л.В. Курзаева, В.Е. Петеляк, О.Е. Масленникова, И.Д. Белоусова. – Фундаментальные исследования, №8 (часть 2), 2015. – с. 318-322
  5. Седнева Д.А., Климов П.А., Гусева Т.Ф., Вахрушев В.И., Румянцев Е.П., Новикова Т.Б. Описание моделей по созданию собственного бизнеса // Современные научные исследования и инновации. 2015. № 11 [Электронный ресурс]. URL: http://web.snauka.ru/issues/2015/11/59171 (дата обращения: 18.11.2015).

Все статьи автора «Стебелев Павел»

Источник

Библиографическое описание:

Романова, О. О. Моделирование бизнес-процесса «Сервисное обслуживание автомобилей» / О. О. Романова, Е. В. Абросимова, А. С. Улеев. — Текст : непосредственный // Технические науки: теория и практика : материалы III Междунар. науч. конф. (г. Чита, апрель 2016 г.). — Чита : Издательство Молодой ученый, 2016. — С. 16-19. — URL: https://moluch.ru/conf/tech/archive/165/9918/ (дата обращения: 24.03.2023).



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

До начала 90-х годов автосервис в России характеризовался довольно малым количеством станций технического обслуживания и ремонта автомобилей индивидуальных владельцев. Большинство автомобилистов занимались самообслуживанием и ремонтом своих автомобилей в собственных гаражах и ремонтных зонах коллективных автостоянок.

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

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

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

Рис. 1. Бизнес-процесс «Сервисное обслуживание автомобилей»

Рис. 2. Бизнес-процесс «Сервисное обслуживание автомобилей» (продолжение)

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

 удостоверяющие личность клиента (паспорт, водительское удостоверение);

 паспорт транспортного средства (ПТС);

 свидетельство о регистрации ТС.

В ходе регистрации менеджер сервисного центра определяет цель обращения клиента: прохождение техобслуживания (ТО) или ремонт автомобиля.

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

Промежуточная диагностика во время прохождения технического обслуживания автомобиля включает в себя:

 ежемесячную проверку масла в двигателе и антифриза (тосола) в радиаторе;

 наличие трансмиссионной жидкости в рулевом управлении (гидроусилителе) и коробке передач;

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

 подкачка колес и измерение давления в них;

 обслуживание аккумулятора;

 визуальный осмотр, мойка кузова и чистка салона.

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

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

 двигатель;

 ходовая часть, тормоза, сцепление;

 сайленблоки, шаровые наконечники, пружины, стойки, рулевые тяги, колодки, корзины и дисков сцепления, ABS и Airbag;

 электрооборудование;

 системы охлаждения (кондиционер) и отопления (печка).

На основании проведенных диагностических работ механик сервисного центра составляет «Акт осмотра автомобиля» и передает его менеджеру автосалона.

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

Функция «Оформление заказ-наряда»

На основании «Акта осмотра» автомобиля менеджер формирует заказ-наряд на выполнение работ. В заказе-наряде обязательно указываются: полный объем работ, выполняемый исполнителем; данные о ремонтных запасных частях и расходных материалах; описание каждого этапа работы; стоимость услуг. Документ нужно оформлять исключительно в соответствии с правилами технического обслуживания и ремонта автомобилей, утвержденными законодательством РФ. В заказе-наряде необходимо указать следующие атрибуты:

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

 подробную контактную информацию о заказчике услуг;

 список услуг и работ, которые необходимо выполнить;

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

 предполагаемые сроки выполнения заказа;

 стоимость оказанных услуг;

 порядок оплаты.

Функции «Произведение ремонта автомобиля» и «Повторная диагностика»

Механик сервисного центра производит ремонт автомобиля на основании ранее сформированного «Заказ-наряда» и проводит повторную диагностику. Если данная диагностика показала, что все неисправности устранены, то клиенту выставляется счет на оплату.

Функция «Переоформляет заказ на ремонт автомобиля»

Если в ходе диагностики были выявлены новые неисправности, компания ставит об этом в известность клиента, который вправе переоформить заказ на повторный ремонт автомобиля.

Функция «Оплата заказа»

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

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

Литература:

  1. Войнов И. В., Пудовкина С. Г., Телегин А. И. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей: Монография. — Челябинск: Изд. ЮУрГУ, 2002. — 392 с.
  2. Волков О. Стандарты и методологии моделирования бизнес-процессов. Режим доступа: http://www.connect.ru/article.asp?id=5710. — Загл. с экрана.
  3. Григорьев Д. Моделирование бизнес-процессов предприятия. Режим доступа: http://www.valex.net/articles/process.html. — — Загл. с экрана.
  4. Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов // М.: Финансы и статистика, 2006.

Основные термины (генерируются автоматически): сервисный центр, обращение клиента, техническое обслуживание, ABS, ремонт автомобилей, ремонт автомобиля.

Похожие статьи

Разработка алгоритма обслуживания клиентов при кузовном…

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

Рис. 2. Бизнес-процесс «Сервисное обслуживание автомобилей» (продолжение). Входом бизнес-процесса является обращение.

Проблема математического моделирования сложных единиц…

сервисный центр, обращение клиента, техническое обслуживание, ABS, ремонт автомобилей, ремонт автомобиля.

Теоретические основы управления затратами на техническое…

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

Анализ методов технологического расчета предприятий…

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

Анализ и проектирование системы обработки заявок клиентов…

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

— повышение качества и скорости обслуживания клиентов сервисного центра за счет оперативной регистрации заявок, точной…

Оценка систем организации ТО и Р автомобилей

Существуют следующие системы технического обслуживания и ремонта автомобилей: планово-предупредительная и по фактическому техническому состоянию (рисунок 1). Рис. 1. Системы ТО и Р машин.

Эффективное предоставление услуг автомобильного сервиса…

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

Тенденции на рынке автосервисных услуг в 2017 г. Volkswagen…

На сегодняшний день более 50 тыс. компаний в России напрямую связаны с оказанием услуга по ремонту и сервисному обслуживанию автомобилей. Об этом говорят данные недавнего исследования компании «АВТОСТАТ»: Рис. 1. Весь этот, без преувеличения огромный рынок…

Автоматизированные системы управления техническим…

Автоматизированные системы управления техническим обслуживанием и ремонтом оборудования. Автор: Каримова Нозима Ойбековна. Рубрика: Технические науки.

Источник

Моделирование информационной системы ‘Автосервис’

Оглавление

ВВЕДЕНИЕ

1.      ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

2. Основные
теоретические положения

2.1
Case-средства

2.2 Сравнение
CASE-средств

2.3
Инструментальное средство BPwin

3. Разработка
модели

3.1 Принцип
построения модели IDEFO

3.2 Принцип
построения модели DFD

3.3 Принцип
построения модели IDEF3

4. Модель
автосервиса.

4.1 Навигатор
модели — Model Explorer

4.2 Диаграммы
функциональной декомпозиции

4.2.1
Контекстная диаграмма

4.2.2 Диаграмма
декомпозиции А0

4.2.3 Диаграмма
декомпозиции А1

4.2.4 Диаграмма
декомпозиции А2

4.3 Диаграммы
потоков данных

4.3.1 Диаграмма
потоков данных А12

4.4 Диаграммы
IDEF3

4.4.1 Диаграмма
А2

4.4.2 Диаграмма
А23.1

4.4.3 Диаграмма
А32.1

5.      Математическая модель системы.

Вывод по
проделанной работе.

ЛИТЕРАТУРА

ВВЕДЕНИЕ

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

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

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

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

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

·   представление деятельности предприятия и принятых в нем

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

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

·        упорядочивание информационных потоков (в том числе
документооборота) внутри предприятия;

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

·        анализ требований и проектирование спецификаций корпоративных
информационных систем.

При моделировании изучается влияние и действие одних элементов на другие
и последствия этих взаимодействий.

1.  
ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

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

Целью деятельности Автосервиса является непосредственно диагностика и
ремонт автомобилей.

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

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

2. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ

 

2.1
Case-средства

В современном мире практически любая организация, будь то
бизнес-предприятие или государственное учреждение, сталкивается с проблемой
структурирования получаемой информации, анализа и управления различными
информационными системами (ИС). С каждым годом разработка и внедрение таких ИС
заметно усложняются. При этом на первоначальном этапе разработки подобных
систем всегда осуществляется детальный анализ самой деятельности и ставящихся
перед ИС задач. Поэтому в настоящее время применяются специальные CASE-средства
(Computer Aided Software/System Engineering), помогающие в разработке и
поддержке сложных программных систем — от простого моделирования
бизнес-процессов на предприятии до полной поддержки всего жизненного цикла
создания и сопровождения информационных систем.

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

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

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

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

Ø локальные, поддерживающие один-два типа моделей и методов;

Ø  малые интегрированные средства моделирования, поддерживающие несколько типов
моделей и методов (ERwin, BPwin);

Ø  средние интегрированные средства моделирования, поддерживающие от 4 до 10-15
типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);

Ø  крупные интегрированные средства моделирования, поддерживающиеболее 15 типов
моделей и методов (ARIS Toolset).

 

2.2
Сравнение CASE-средств

Чтобы выбрать наилучшее CASE-средство
для построения своей модели я провел сравнительный анализ трех CASE-средств методом анализа иерархии
(МАИ). К этим средствам относятся:

Ø BPWin

Ø  ARIS Toolset

Ø  Rational Rose

В список критериев, по которым я сравнил CASE-средства, попали:

·    Количество поддерживаемых стандартов

·        Удобство работы по созданию моделей

·        Ограничение на количество объектов на диаграмме

Известные данные по каждому из средств я свел в таблицу

BPWin

ARIS Toolset

RationalRose

1.Количество поддерживаемых
стандартов

ü
IDEF0 ü DFD ü IDEF3

ü
Частично DFD ü ERM
ü
UML ü EPC

ü
UML

Простая панель управления

Сложная панель управления

Относительно простая панель
управления

3. Ограничение на
количество объектов на диаграмме

2-8

Нет ограничения

Ограничения есть, но они не
жесткие

1 шаг МАИ: Оценка критериев

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

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

Количество поддерживаемых
стандартов

Удобство работы по созданию
моделей

Ограничение на количество
объектов на диаграмме

Оценки компонент
собственного вектора

Нормализованные оценки
вектора приоритета

Удобство работы по созданию
моделей

1

9

5

3,512

0,904

Количество поддерживаемых
стандартов

1/9

1

1/7

0,254

0,065

Ограничение на количество
объектов на диаграмме

1/5

7

1

1,117

0,288

Сначала определяем оценки компонент собственного вектора.

Для критерия «Удобство работы по созданию моделей»:

( 9 * 1 * 5) = 451/3 = 3,512

Так для критерия » Количество поддерживаемых стандартов» это
будет:

(1* 1/9 * 1/7)1/3 = (0.01573)1/3 = 0,254

Для последнего критерия «Ограничение на количество объектов на диаграмме»
:

(7 * 1/5 * 1)1/3 = 1,117

Получив сумму оценок собственных векторов ( = 3,883), вычисляем
нормализованные оценки вектора приоритета для каждого критерия, разделив
значение оценки собственного вектора на эту сумму.

0,254 / 3,883= 0,065 (для критерия «Количество поддерживаемых
стандартов»)

,512 / 3,883= 0,904 (для критерия «Удобство работы по созданию
моделей»)

,117 / 3,883= 0,288 («Ограничение на количество объектов на
диаграмме»)

Сравнивая нормализованные оценки вектора приоритета можно сделать вывод,
что наибольшее значение при выборе CASE-средства я придаю критерию «Удобство работы по созданию моделей
«.

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

ИС = (λ max — n)/(n — 1)

λmax = (1+9+7)*0.065 + (1.9+1+1.5)*0,904 +
(1/7+5+1)*0,288 = 3,06

ИС = (λmax — 3) / 2 = 0,03.

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

OC =
2,6 % < 10%, т.е. пересматривать свои суждения нет нужды.

2 шаг: Оценка альтернатив

Теперь для выбора наилучшего CASE-средства я сравню выбранные мною 3 CASE-средства по каждому критерию.

Критерий: «Количество поддерживаемых стандартов»

BPWin

ARIS

RationalRose

Оценки компонент
собственного вектора

Нормализованные оценки
вектора приоритета

BPWin

1

3

5

2,444

0,6

ARIS

1/3

1

7

1,318

Rational Rose

1/5

1/7

1

0,309

0,08

Оценки компонент собственного вектора:

: (1*3*5)1/3 =2,444

ARIS: (1/3*1*7)1/3 = 1,318

Rational Rose: (1/5*1/7*1)1/3 = 0,309

Сумма оценок собственных векторов = 2,444+1,318+0,309 = 4,071

Вычислим нормализованные оценки:

: 2,444 / 4,071 = 0,6

ARIS: 1,318 / 4,071 = 0,323

Rational Rose: 0,309 / 4,071 = 0,08

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

Критерий «Удобство работы по созданию моделей»

BPWinARISRationalRoseОценки компонент собственного вектораНормализованные
оценки вектора приоритета

BPWin

1

9

5

3,512

0,809

ARIS

1/9

1

1/4

0,0275

0,006

Rational Rose

1/5

4

1

0,8

0,184

Оценки компонент собственного вектора:

: (1*9*5)1/3 =3,512

ARIS:
(1/9*1*1/4)1/3 = 0,0275

Rational Rose: (1/5*4*1)1/3 = 0,8

Сумма оценок собственных векторов = 2,444+1,318+0,309 = 4,3395

Вычислим нормализованные оценки:

:
3,512 / 4,3395 = 0,809

ARIS:
0,0275 / 4,3395 = 0,006

Rational Rose: 0,8 / 4,3395= 0,184

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

Критерий «Ограничение на количество объектов на диаграмме»

BPWinARISRational
RoseОценки компонент собственного
вектораНормализованные оценки вектора приоритета

BPWin

1

1/7

1/5

0,309

0,063

ARIS

7

1

8

3,77

0,764

Rational Rose

5

1/8

1

0,856

0,173

Оценки компонент собственного вектора:

ARIS:
(7*1*8)1/3 = 3,77

Rational Rose: (5*1/8*1)1/3 = 0,856

Сумма оценок собственных векторов = 0,309+3,77+0,856 = 4,935

Нормализованные оценки:

:
0,309 / 4,935 = 0,063

ARIS:
3,77 / 4,935 = 0,764

Rational Rose: 0,856 / 4,935 = 0,173

Сравнивая по критерию ограниченности объектов на диаграмме, видно, что ARIS является лидером, так как у него нет
ограничений на количество объектов на диаграмме.

Однако наиболее важным для меня критерием является прежде всего удобство
при создании модели, поэтому для построения своей модели я выбрал
инструментальное CASE-средство BPWin.

2.3
Инструментальное средство BPwin

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

BPwin — это CASE-средство
верхнего уровня, поддерживающее 3 методологии IDEF0 (функциональная модель),
IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Основной из трех методологий
является IDEF0. BPwin имеет достаточно простой и интуитивно понятный интерфейс
пользователя, дающий возможность аналитику создавать сложные модели при
минимальных усилиях.

BPwin автоматизирует задачи, связанные с построением моделей развития,
обеспечивая семантическую строгость, необходимую для гарантирования
правильности и непротиворечивости результатов. Это достигается применением в
BPwin следующих методологий: IDEF0, DFD и IDEF3.

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

В BPwin возможно построение смешанных моделей, т. е. модель может
содержать одновременно как диаграммы IDEFO, так и IDEF3 и DFD. Модель в BPwin
рассматривается как совокупность работ, каждая из которых оперирует с некоторым
набором данных. Работа изображается в виде прямоугольников, данные — в виде
стрелок.

Все работы модели нумеруются. Номер состоит из префикса и числа. Может
быть использован префикс любой длины, но обычно используют префикс А.
Контекстная (корневая) работа дерева имеет номер А0. Работа декомпозиции А0
имеет номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер
родительской работы и очередной порядковый номер, например работы декомпозиции
A3 будут иметь номера А3.1, А3.2, АЗ.З, А3.4 и т. д.

В результате дополнения диаграмм IDEFO диаграммами DFD и IDEF3 может быть
создана смешанная модель, которая наилучшим образом описывает все стороны
деятельности предприятия. Иерархию работ смешанной модели можно увидеть в окне
Model Explorer.

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


3.
Разработка модели

 

.1 Принцип
построения модели IDEFO

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

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

Модель может содержать четыре типа диаграмм:

Ø контекстную диаграмму (в каждой модели может быть только одна
контекстная диаграмма);

Ø  диаграммы декомпозиции;

Ø  диаграммы дерева узлов;

Ø  диаграммы только для экспозиции (FEO).

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

Ø верхняя сторона имеет значение «управления»;

Ø  левая — «входа»;

Ø  правая — «выхода»;

Ø  нижняя — «механизма».

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

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

3.2
Принцип построения модели DFD

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

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

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

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

Ø  процессы;

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

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

3.3 Принцип построения модели IDEF3

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

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

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

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

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со
стрелкой, перекрестком или работой. Официальная спецификация IDEF3 различает
три стиля объектов ссылок — безусловные (unconditional), синхронные
(synchronous) и асинхронные (asynchronous).

4.     
Модель автосервиса.

 

.1      Навигатор
модели — Model Explorer

Иерархия работ смешанной модели изображена в окне Model Explorer.
(рисунок 3)

Рисунок 3. Окно Model Explorer

4.2
Диаграммы функциональной декомпозиции

4.2.1
Контекстная диаграмма

На контекстной диаграмме мы видим самое общее описание системы и ее
взаимодействие с внешней средой (рисунок 4).

Рисунок 4. Контекстная диаграмма

4.2.2
Диаграмма декомпозиции А0

На данной диаграмме мы видим первый уровень декомпозиции нашей системы, а
именно 3 основные функции и их взаимодействие друг с другом и с внешней средой
(рисунок 5).

Рисунок 5. Диаграмма декомпозиции А0

4.2.3
Диаграмма декомпозиции А1

Первая функция «Принятие заявки» декомпозируется на 2 более мелкие
функции (рисунок 6):

Ø  Добавление заявки в Базу Данных

Ø  Введение статистики

Рисунок 6. Диаграммма декомпозиции А1

4.2.4
Диаграмма декомпозиции А2

Вторая функция «Обслуживание автомобиля» декомпозируется на 3 более
мелкие функции (рисунок 7):

Ø  Диагностика автомобиля

Ø  Замена масла

Ø  Ремонт двигателя

Рисунок 7. Диаграмма декомпозиции А2

.2.5 Диаграмма декомпозиции А3

Третья функция «Удаление заявки» декомпозируется на 2 более мелкие
функции (рисунок 8):

Ø  Удаление заявки из БД

Ø  Отчет о работе

4.3
Диаграммы потоков данных

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

 

.3.1
Диаграмма потоков данных А12

Данная диаграмма описывает процесс «Введение статистики» (рисунок 9).

Рисунок 9. Диаграмма потоков данных А12

 

.4
Диаграммы IDEF3

 

Диаграмма
А2

Эта диаграмма описывает сценарий бизнес-процесса «Замена масла» (рисунок
11).

Рисунок 11. Диаграмма А2

4.4.1  Диаграмма А23.1

Эта диаграмма описывает сценарий бизнес-процесса «Ремонт двигателя»
(рисунок 12)

Рисунок 12. Диаграмма А23.1

4.4.2  Диаграмма А32.1

Эта диаграмма описывает сценарий бизнес-процесса «Составление отчета о
работе» (рисунок 13)

Рисунок 13. Диаграмма А32.1

5 
Математическая модель системы

Математическая модель — это объективная схематизация основных аспектов
решений задачи или ее описание в математических терминах.

Реализация с помощью СМО (системы массового обслуживания).

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

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

Основными компонентами СМО любого вида являются:

1.      Входной поток поступающих требований

.        Дисциплина очереди

.        Механизм обслуживания

В автомастерской имеется один пост диагностики, два механика по ремонту
двигателя автомобиля и один механик по замене масла. В час в автомастерскую
поступает 4 автомобиля. Каждый поступивший автомобиль проходит диагностику.
Диагностика автомобиля длится 12 минут. После диагностики, 50% автомобилей
направляется на ремонт двигателя, 48% — на замену масла, 2% — покидают
автосервис. Ремонт двигателя длится 30 минут, замена масла — 20 минут. По
окончанию ремонта автомобиль покидает автомастерскую. Максимальное число машин
в очереди равно 3. Автомастерская работает 8 часов.

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

5.1    Реализация в среде AnyLogic

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

 

Рисунок 14. Построение модели в AnyLogic

Запустив AnyLogic, можно
наблюдать работу автосервиса.

Рисунок 15. Запуск модели

5.2    Реализация в среде Matlab

(сокращение от англ. «Matrix Laboratory») — термин, относящийся к
пакету прикладных программ для решения задач технических вычислений, а также к
используемому в этом пакете языку программирования.

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

Рисунок 16. Построение модели в Matlab

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

Рисунок 17. Длина очереди поста диагностики

Рисунок 18. Время ожидания поста диагностики

Решение:

Определение характеристик функционирования автосервиса.

·        Исходные значения:

Число поступающих клиентов (интенсивность потока заявок): λ=4 авт/час

Количество возможных обслуженных клиентов: n=5 авт/час

Количество окошек автомастерской (постов диагностики): S=1

·        Время обслуживания:

·        Интенсивность потока обслуживания:

·        Относительная пропускная способность автомастерской:

·        Абсолютная пропускная способность
регистратуры:

·        Финальная вероятность:

·        Cреднее число автомобилей в очереди:

·        Средняя продолжительность пребывания автомобиля в очереди:


Вывод по
проделанной работе

информационная система математическая модель

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

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

Рисунок 19. Модель автосервиса после реинжиниринга.

Это приведет к уменьшению длины очереди и время ожидания заявки в
очереди.

Рисунок 20. Длина очереди поста диагностики после реинжиниринга.

Рисунок 21. Время ожидания поста диагностики после реинжиниринга.

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


ЛИТЕРАТУРА

1.   Рогозов Ю. И., Стукотий Л. Н.,
Свиридов А. С. Моделирование систем, ТРТУ, 2004.

2.      С. В. Маклаков CASE-средства
разработки информационных систем. BPwin и Erwin -М.: ДиалогМифи, 2001.

3.   Карпов, Ю. Г. Имитационное моделирование систем. Введение в моделирование
с AnyLogic 5. — СПб: БХВ-Петербург, 2006.

.     Материалы сайта www.citforum.ru — классификация CASE-средств и их общая характеристика.

.     Материалы сайта www.citycg.ru — методы описания
бизнес-проектов

Источник

image description

disserCat — электронная библиотека диссертаций работаем для вас с 2009 года

  • Корзина пуста

Вход
|
Регистрация

Вы робот?

Мы заметили, что с вашего адреса поступает очень много запросов.

Подтвердите, что вы не робот

Источник

Понравилась статья? Поделить с друзьями:
  • Музей авиаторов во всеволожске часы работы
  • Моделирование бизнес процессов в логистике
  • Мосэнергосбыт южное медведково часы работы
  • Музей айвазовского в феодосии время работы
  • Мособлгаз братовщина часы работы в субботу