Бизнес процессы в стоматологической клинике

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

С одной стороны верно, с другой — резко. Несём
деньги, надеясь на плавность подходов, но клиентоориентированности ждать не
приходится. Ошибка в требовательности избалованных или настойчивости негнущихся? Есть ли шанс перемен или всегда
будем трястись перед белыми халатами?

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

Начали с азов и основ:
разделили вопросы на фундаментальные — например, отсутствие зубов, и локальные — потёртости
эмали. По степени возможного ущерба выделили опасные и некритичные. Спроектировали
процесс слаженной командной работы клиники, рассмотрев визит гостя для комплексного
лечения.

Так родился универсальный алгоритм консультации-лечения-профилактики,
выявивший «смертные грехи»:


Далее заполнили таблицы в Google Sheets с
зонами ответственности и результатами. Ролям назначили цвет, чтобы оценивать
структуру активностей:



Итак,

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

Как выглядел: доктора
готовили планы лечения с опозданием, требовали напоминания.

Чем мешал: с
ростом количества гостей накапливалась неопределённость с предстоящими
процедурами.

Что сделали: нарисовали
схему действий, сконфигурировали CRM, помогли команде принять изменения.

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

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


Ввели канбан-доску со счётчиками, показывающими шаги
и количество пациентов на этапах:


Грех второй: стопки
необработанных документов у администраторов растут

Как выглядел: менеджеры не успевали вносить
информацию по пациентам, полагая анкеты формальностью.

Чем мешал: промедления и неточности в данных
посетителей; бумаги считались неприятной рутиной.

Что сделали:
переверстали анкету и договор, интегрировали формы в ИТ-систему.

К чему привело: параметры
гостей загружены сразу в CRM, перед приёмом остаётся распечатать и подписать.

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

Личное дело гостя
клиники преобразилось:



Информация о здоровье стала компактнее:


Грех третий:
бумажные документы заполняют перед процедурами, теряя время приёма

Как выглядел: клиенты
приходили на консультацию и нервозно тратили 15 минут на формальности.

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

Что сделали:
пересмотрели анкету пациента, «завязали на возраст», перенесли в CRМ и на форму сайта.

К чему привело: накануне
визита администратор подсказывает клиентам, как заполнять документы в Сети.

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

Для не достигших
совершеннолетия анкета сайта требует ввести представителя, взрослые заполняют
данные только по себе:


Грех четвертый: в
документы вносят правки, распечатывают, мешают с предыдущими редакциями

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

Чем мешал: даже после
правок пациентам несли на подпись старые формы, плодя ненужные риски.

Что сделали: переверстали
шаблоны, перенеся генерацию в CRM — единый источник правды.

К чему привело: клиенты
получают актуальные документы, администраторы не ищут последние версии.

Подробнее: словно
головы гидры плодились договоры разных лет. Как во втором подвиге Геракла
предстояло найти первопричину, оставив единый канал правдивых бумаг. Убрали
лишнее, запрограммировали Битрикс24, искоренили иные варианты печати, получив
компактную анкету:


Осталось вывести на бумагу, проверить и подписать:


Параллельно печатаем договор, не утруждая гостя расспросами:


Грех пятый: важная
информация посетителей тонет в архиве, приходится уточнять заново

Как выглядел: гости заполняли анкеты перед
консультацией, повторяя ответы на приёмах.

Чем мешал: возникали неосведомлённости о здоровье клиентов,
претензии, негативные последствия ошибок.

Что сделали: карточку пациента разбили на блоки,
важное разместили сверху — пропустить невозможно.

К чему привело: на приёме видны аллергии и
заболевания — врачи осведомлены, ошибки маловероятны.

Подробнее: приоритизировали
информацию, акцентируя внимание на человеке. Главное в карточке CRM переместили вверх:


Грех шестой: путаница с планами лечения — готовятся долго, навскидку и
накануне

Как выглядел:
клиенты запрашивали финансовый прогноз процедур, но кому формировать —
непонятно.

Чем мешал: росла
частота запросов и суета подготовки документации.

Что сделали:
проработали алгоритм, протестировали варианты, запрограммировали ИТ-систему.

К чему привело:
карточки пациентов движутся виртуальным конвейером — шаги пропустить
невозможно.

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


Грех седьмой: заказ
расходных материалов в режиме гонки — успей, найди, поймай ответственного

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

Чем мешал: опасность переноса операций, простоя
кабинетов и врачей, моральных и финансовых потерь.

Что сделали: переопределили
очерёдность, заложили в систему, устранили альтернативы.

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

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


Сводная таблица заказов приобрела строгий вид:


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

Читайте также:

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

Топ-5 сервисов слежки или как маркетологи шпионят за клиентами

Последний год каникул: шесть условий для законной неуплаты налогов

Как найти нишу для своего интернет-магазина

Как правильно структурировать компанию

Подписчик по 49 копеек: миф или реальность?

Источник
  1. Краткий анализ рынка
  2. Обязательно ли быть стоматологом
  3. Кабинет или клиника
  4. Документы и разрешения
  5. Помещение
  6. Оборудование
  7. Персонал
  8. Маркетинг
  9. Финансовый план с расчетами

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

Краткий анализ рынка

Бизнес план стоматологии

По данным РБК, объем рынка стоматологических услуг в России в 2019 г составил 271,1 млн приемов, из которых доля коммерческой стоматологии — 31,1% (84,4 млн приемов). Пандемия привела к снижению спроса, но уже в 2021 году некоторые регионы продемонстрировали динамику роста. В Санкт-Петербурге рынок вырос на 20%, и на данный момент его объём — около 13 млрд рублей. При этом средний чек увеличился на 8%. Однако клиентская база растет медленно. Число пациентов увеличивается за счет отложенного спроса. По прогнозам BusinesStat, в 2024 году объем рынка составит 248,9 млн приемов.

Кроме общей статистики, полезно изучить частную. Например:

  • портрет предполагаемой ЦА;
  • количество конкурентов, в том числе среди частных стоматологов;
  • среднюю стоимость услуг в регионе и т. д.

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

Обязательно ли быть стоматологом

Следует учитывать, что профильное образование и релевантный опыт дают более глубокое понимание отрасли. Однако в конечном счете все зависит от организационно-правовой формы бизнеса. Чтобы осуществлять деятельность в сфере стоматологических услуг, требуется соответствующая лицензия. Согласно постановлению Правительства РФ № 291 от 16.04.2012, для ее получения индивидуальному предпринимателю необходимо иметь медицинское образование и стаж не менее 3-5 лет. При открытии ООО иметь диплом специалиста по медицине необязательно. Но весь персонал должен соответствовать вышеуказанным критериям.

Кабинет или клиника

Бизнес план стоматологии

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

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

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

Документы и разрешения

В заявлении на регистрацию ИП или ООО необходимо указать ОКВЭД. Актуальный список кодов можно посмотреть в классификаторе. В нашем случае основным будет 86.23 — «Стоматологическая практика». В качестве дополнительных подойдут 86.21 — «Общая врачебная практика» или 86.90 — «Прочая деятельность в области медицины».

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

  • ИНН;
  • разрешение Роспотребнадзора;
  • медицинская лицензия;
  • регистрация в ПФ (Пенсионный фонд), ФСС (Фонд социального страхования) и ФОМС (Фонд обязательного медицинского страхования);
  • постановка на учет в ФНС;
  • номер расчетного счета;
  • оформление печати;
  • договор аренды;
  • регистрация ККТ;
  • разрешения СЭС и пожарной инспекции;
  • договоры на водоснабжение, водоотведение, электроснабжение, связь, системы безопасности, вывоз медицинских отходов, дезинфекцию;
  • трудовые договоры персонала;
  • книгу учета доходов и расходов.

Порядок оформления лицензии описан в Федеральном законе от 4 мая 2011 г. N 99-ФЗ «О лицензировании отдельных видов деятельности». Процедура занимает около 1-2 месяца.

Помещение

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

  • одна стоматологическая установка — 14 м²;
  • каждая следующая установка — +7 м²;
  • высота потолков — от 3 метров;
  • максимальная глубина комнаты — от 6 метров;
  • дневное освещение.

По итогу на один рабочий кабинет понадобится выделить около 30 м², включая холл (10 м²) и санузел (5 м²). При наличии 3-х и более установок нужно оборудовать стерилизационную (6 м²). Для прочих кабинетов, например детского или хирургического, понадобится не менее 15 м² на каждый. Также нужно учесть вспомогательные и подсобные помещения. Если вы планируйте держать рентген-кабинет, нужно согласовать такой проект с региональным рентгенологическим отделением.

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

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

Оборудование

Бизнес план стоматологии

Кроме профессиональных аппаратов и установок, понадобится закупить мебель, инструменты, расходники и многое другое. Примерный набор медоборудования на 2 кабинета (кресла) будет выглядеть следующим образом:

Наименование Цена
стоматологическая установка 450 000 ₽
набор наконечников 5 000 ₽ (ежемесячно)
медицинские инструменты 45 000 ₽
полимеризационные лампы 12 000 ₽
автоклав 75 000 ₽
стерилизатор 45 000 ₽
алекслокаторы  42 000 ₽
радиовизиограф 350 000 ₽
расходные материалы 5 000 ₽ (ежемесячно)
шкафы для материалов и инструментов 87 000 ₽
мебель 70 000 ₽
Итого 1 186 000 ₽

Не исключено, что на первых порах будет дешевле взять некоторые аппараты в аренду. Кроме того, часть расходов можно сократить, купив б/у мебель. При выборе и установке медоборудования необходимо руководствоваться СанПиН 2.6.1.1192-03. 

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

Персонал

Бизнес план стоматологии

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

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

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

  • два стоматолога;
  • двое ассистентов;
  • администратор;
  • одна уборщица.

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

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

Маркетинг

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

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

Финансовый план с расчетами

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

Календарный план открытия

Сроки Мероприятия
10-12 месяцев до открытия — определяем позиционирование и нишу;
— считаем бюджет и размер вложений;
— ищем возможного партнера.
7-9 месяцев  — ищем помещение;
— оцениваем необходимость ремонта;
— составляем список медоборудования и расходников;
— ищем CRM;
— получаем одобрение на кредит в банке (при необходимости);
— ищем подрядчика на строительные работы.
6-7 месяцев  — заключаем договор аренды или купли-продажи;
— составляем планировку кабинетов;
— советуемся с подрядчиками.
5-6 месяцев  — составляем руководство по внутренней политике;
— определяем график работы;
— заканчиваем внутреннюю отделку;
— подключаем CRM;
— определяем необходимое количество сотрудников.
4-5 месяцев  — начинаем планировать маркетинговую стратегию;
— устанавливаем стационарный телефон;
— тестируем CRM;
— знакомимся с нормативно-правовыми документами;
— ищем поставщиков расходников и медоборудования;
— создаем сайт.
3 месяца  — подаем заявку на лицензию;
— регистрируем ИНН;
— согласовываем сроки поставок;
— устанавливаем CRM;
— заключаем договоры со страховой компанией и коммунальными службами.
2 месяца  — размещаем объявления о поиске сотрудников;
— определяем политику начисления зарплаты;
— организовываем уборку помещений, техническое обслуживание и доставку униформы/постельного белья;
— открываем счет в банке.
1 месяц  — тестируем медоборудование и ПО;
— нанимаем сотрудников;
— определяемся с датой открытия;
— публикуем информацию на сайте и в соцсетях.

Теперь можно перейти к расчетам.

Первоначальные расходы:

Статья Цена
регистрация 60 тыс. руб.
уставной капитал 10 тыс. руб.
покупка помещения 1,9 млн руб.
ремонт 500 тыс. руб.
медоборудование и расходники 2,5 млн руб.
маркетинг 70 тыс. руб.
прочие расходы 55 тыс. руб.
Итого 5,85 млн руб.

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

Ежемесячные траты:

Статья Цена
заработная плата 270 тыс. руб.
отчисления в фонды 65 тыс. руб.
реклама 25 тыс. руб.
коммунальные платежи 10 тыс. руб.
закупка расходников 15 тыс. руб.
техобслуживание  7 тыс. руб.
наконечники 5 тыс. руб.
прочие расходы 55 тыс. руб.
Итого 452 тыс. руб.

Доходы и окупаемость:

Рассчитаем доход для стоматологии на 2 кабинета, учитывая следующие параметры:

  • время работы — 8 часов, 5 дней в неделю;
  • график работы стоматологов — 6 часов в день (в две смены);
  • время приема одного пациента — 40 минут;
  • средний чек за услуги — 2500 рублей.

При таких показателях выручка за день составит 45 000 ₽, в неделю — 225 000 ₽, в месяц — 900 000 ₽. Теперь можно рассчитать окупаемость проекта.

1. Прибыль до налогообложения (доходы – расходы): 900 000 – 452 000 = 448 000 ₽.

2. Налоги (налоговый процент х прибыль): 0,15 х 448 000 = 67 200 ₽.

3. Чистая прибыль (прибыль до налогообложения – налоги): 448 000 – 67 200 = 380 800 ₽. 

4. Сроки окупаемости (первоначальные затраты / чистая прибыль): 5 085 000 / 380 800 = 13,3 мес.

Следовательно, подобный проект окупит себя уже через 1-1,5 года. Рентабельность бизнеса составляет около 80%.

Риски

Среди рисков открытия стоит выделить следующие:

  • низкий спрос;
  • высокая конкуренция;
  • низкая квалификация стоматологов ;
  • увеличение расходов;
  • потеря лицензии.

Планирование рисков поможет избежать многих ошибок и позволит трезво оценить реальные перспективы бизнеса.

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

ПОЛУЧИТЬ КОНСУЛЬТАЦИЮ

Источник

Моделирование и оптимизация бизнес-процессов в стоматологической клинике ООО ‘Ахтанин’

Введение

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

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

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

В-третьих, современные потребители
становятся все более и более требовательными. Уровень поставок и их качество
все время растут.

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

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

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

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

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

Для выявления бизнес-процессов,
которые необходимо совершенствовать, в дипломной работе был выполнен анализ
причин возникновения ошибок при реализации бизнес-процессов компании и
определены проблемы их реализации.

Целью данного исследования является
разработка рекомендаций по совершенствованию и оптимизации бизнес-процесса на
основе их моделирования с использованием методологии ARIS.

Для достижения поставленной цели
требуется решить ряд задач:

. Изучить понятие и необходимость
моделирования и оптимизации бизнес-процессов на современных предприятиях;

. Изучить особенности процесса
моделирования бизнес-процессов;

. Рассмотреть классификацию
методологий моделирования и оптимизации бизнес-процессов;

. Изучить особенности ARIS как модели управления
бизнес-процессами на предприятии;

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

Объект исследования —
стоматологическая клиника ООО «Ахтанин».

Предмет исследования — моделирование
и оптимизация бизнес-процессов, возникающие в ходе функционирования
предприятия.

Теоретической основой для данного
исследования послужили научные труды отечественных авторов-ученых, изучавших
проблемы моделирования бизнес-процессов: М.Р. Дзагоевой, В.Г. Елиферова, Н.М.
Абдикеева, В.В. Кондратьева, В.А. Баринова, Ю.В. Ляндау.

Для достижения поставленной цели в
работе использовалась концепция моделирования бизнес-процессов АРИС (ARIS —
architecture of integrated information systems).

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

1. Теоретические аспекты
моделирования и оптимизации бизнес-процессов на современных предприятиях

.1 Понятие и необходимость
моделирования и оптимизации бизнес-процессов на современных предприятиях

В стандарте ISO 9000-2001 процесс
определен как «совокупность взаимосвязанных или взаимодействующих видов
деятельности, преобразующих входы в выходы».

Кроме того, в литературе встречается
также, по меньшей мере, несколько десятков определений бизнес-процесса, таких
как:

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

Бизнес-процесс — это любая
организованная и устойчивая деятельность внутри предприятия, которая
преобразует какие-либо объекты по каким-либо правилам.

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

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

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

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

Бизнес-процесс — это логически
упорядоченная последовательность операций, выполнение которой направлено на
достижение определенной цели бизнеса.

Бизнес-процессы разделяют на
основные, сопутствующие, вспомогательные, обеспечивающие, процессы управление и
процессы развития (см. рис. 1.1).

Рис. 1.1. Типы бизнес-процессов

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

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

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

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

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

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

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

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

подготовка компании к сертификации
по международной системе качества ISO;

создания новых подразделений или
направлений деятельности компании.

К основным преимуществам проведения
реинжиниринга относятся:

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

повышение качества взаимодействия
между сотрудниками и подразделениями компании;

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

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

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

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

Бизнес-моделирование — деятельность
по выявлению и описанию существующих бизнес-процессов (анализ
бизнес-процессов), а также проектированию новых (проектирование
бизнес-процессов).

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

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

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

В общем случае модель
бизнес-процесса должна давать ответы на следующие вопросы:

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

в какой последовательности
выполняются эти процедуры;

какие механизмы контроля и
управления существуют в рамках рассматриваемого бизнес-процесса;

кто выполняет процедуры процесса;

какие входящие документы/информацию
использует каждая процедура процесса;

какие исходящие документы/информацию
генерирует процедура процесса;

какие ресурсы необходимы для
выполнения каждой процедуры процесса;

какая документация/условия
регламентирует выполнение процедуры;

какие параметры характеризуют
выполнение процедур и процесса в целом.

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

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

. Бизнес-процесс становится
структурированным, наглядным и простым для понимания. Хорошо видна временная
(что делать дальше?) и логическая (что делать дальше, если…) последовательность
выполнения работ.

. Модель бизнес-процесса формирует
единую картину и видение ситуации сотрудников и руководства предприятия.

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

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

. Определяются области контроля и
исполнения.

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

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

. Упрощает обучение новых
сотрудников.

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

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

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

Таким образом, детальная
бизнес-модель позволит:

описать, увидеть и скорректировать
будущую систему до того, как она будет реализована физически;

уменьшить затраты на создание
системы;

оценить работы по времени и
результатам;

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

улучшить качество создаваемой
системы.

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

В настоящее время существует
множество подходов или стандартов описания бизнес-процессов. Однако на самом
деле классическая технология их описания состоит всего лишь из двух стандартов
— DFD (DataFlowDiagram) и WFD(WorkFlowDiagram).

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

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

важность бизнес-процесса;

проблемность бизнес-процесса;

возможность и стоимость проведения
изменений бизнес-процесса.

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

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

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

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

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

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

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

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

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

теоретическая база;

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

рекомендации по использованию как
отдельно, так и в составе группы методик.

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

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

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

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

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

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

моделирования бизнес-процессов
(Business Process Modeling);

описания потоков работ (Work Flow
Modeling);

описания потоков данных (Data Flow
Modeling).

2. Методология моделирования и
оптимизации бизнес-процессов

.1 Классификация методологий
моделирования и оптимизации бизнес-процессов

Представим различные методологии
бизнес-процессов в виде таблицы 2.1.

Таблица 2.1. Классификация
методологий бизнес-процессов

Название методологии бизнес-процессов

Характеристика методологии

BPEL
(Business Process Execution Language)

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

ARIS

методология и одноименный программный продукт компании IDS
Sheer.

IDEF0

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

IDEF1

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

IDEF1X (IDEF1 Extended)

методология построения реляционных структур по принципу
“Сущность-взаимосвязь” (ER — Entity-Relationship), используется для
моделирования реляционных баз данных;

IDEF2

методология динамического моделирования развития систем.
Используется как расширение IDEF0 для описания динамических систем;

IDEF3

методология документирования процессов, происходящих в системе.
Позволяет описывать сценарий и последовательность операций для каждого
процесса. Средствами IDEF3 каждый функциональный блок IDEF0 может быть
представлен в виде отдельного процесса;

IDEF4

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

IDEF5

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

Таблица 2.2 —
Сравнительный анализ методологий процессного моделирования

№ п/п

Критерии

IDEF 0

DFD

ARIS

1

Язык представления

графический

графический

графический

2

исходные понятия

— Работа (для обозначения, собственно, действия); — Вход, Выход,
Управление и Механизм (для обозначения интерфейсов)

-Функция (действие, выполняемое моделируемой системой); — Поток
данных (объект, над которым выполняется действие. Может быть информационным
(логическим) или управляющим); — Хранилище данных (структура для хранения
информационных объектов); — Внешняя сущность (внешний по отношению к системе
объект, обменивающийся с нею потоками данных)

— Функция (служит для описания функций, процедур, работ); —
Событие (служит для описания реальных событий, воздействующих на выполнение
функций); — Организационная единица (представляет различные организационные
звенья предприятия (например, управление или отдел); — Документ (отражает
реальные носители); — Кластер информации (характеризует данные (набор
сущностей и связей между ними)); — Связь между объектами (описывает тип
отношений между некоторыми объектами); — Логический оператор (оператор,
определяющий связи между событиями и функциями в рамках процесса. Позволяет
описать ветвление процесса)

3

принцип построения

принцип доминирования процессов

иерархия функциональных процессов, связанных потоками данных

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

4

описание системы

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

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

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

5

описание процедуры процесса

объект на диаграмме

объект на диаграмме

объект на диаграмме

6

динамическое моделирование

нет

да

да

7

наглядность модели

модель нечитабельна неспециалистами

модель нечитабельна неспециалистами

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

8

основные преимущества

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

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

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

9

ограничения

·ограничение количества блоков на каждом уровне декомпозиции
(правило 3-6 блоков); · ограничение количества подходящих к одному
функциональному блоку (выходящих из одного функционального блока)
интерфейсных дуг четырьмя

·ограничение количества процессов / подсистем на диаграмме (не
меньше двух и не больше шести); · материальные процессы, потоки и хранилища
на диаграммах не отображаются (только процессы обработки информации, потоки
данных и хранилища данных); · не должно быть изолированных (несвязанных)
объектов (внешних сущностей, подсистем, процессов, хранилищ данных)

· в каждую функцию не может входить более одной стрелки,
«запускающей» выполнение функции, и выходить не более одной стрелки,
описывающей завершение выполнения функции

10

недостатки

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

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

· нет четко описанных регламентов действий; · не предлагается
уникального подхода к проблеме моделирования архитектуры предприятия; ·
инструментальная поддержка осуществляется продуктом той же компании —
разработчика методологии; · вследствие чрезмерного количества настроек работа
по созданию модели должна регламентироваться сложной, многоаспектной документацией;
· расходы на внедрение ARIS достаточно высоки — $1500 за одно рабочее место;
· высокие затраты на эксплуатацию программ; · высокие трудозатраты на
разработку

В настоящее время наиболее часто
используемыми являются методологии IDEF0 и IDEF1.

В рекомендациях по стандартизации
методологии функционального моделирования Госстандарта России от 2 июля 2001
года Р.50.1.028-2001 приводятся основные сведения о методологии IDEF0 и языке
описания моделей, а также указания по разработке моделей.основана на подходе
SADT (Structured Analysis & Design Technique /Development Technology) и
используется для создания функциональной модели системы или процесса,
отображающей его структуру, функции, а также информационные и материальные
потоки, преобразуемые данными функциями.

Концепция IDEF0 основывается на
следующих положениях:

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

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

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

Передача информации. К средствам
передачи информации в IDEF0 относятся:

Легко читаемые и понимаемые
диаграммы.

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

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

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

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

Итеративное моделирование.
Разработка модели в IDEF0 — это пошаговая процедура. На каждом шаге модель
обсуждается аналитиками и экспертами в изучаемой области, затем корректируется,
после чего цикл повторяется.

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

В качестве программного обеспечения,
поддерживающего стандарт IDEF0, можно использовать Design IDEF (Meta Software) или
BP-Win (CA).

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

.2 ARIS как модель управления
бизнес-процессом на предприятии

Моделирование реальных ситуаций в
работе компании и отработка комплексных бизнес-процессов стали темой все более
широких обсуждений.

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

Одной из таких концепций является —
Архитектура Интегрированных Информационных Систем — ARIS (Architecture of Integrated Information Systems), разработанная проф.
Шеером.

Эта концепция имеет два основных
преимущества:

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

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

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

Для оптимизации и моделирования
бизнес-процессов в настоящее время существует несколько методов моделирования
бизнес-процессов, которые используются дилерскими компаниями в сфере продаж
КСБ, но и во всем мире, такие как: ARIS, UML, BPMN.

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

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

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

Достоинствами использования
методологии ARIS для дилерских компаний в сфере продаж КСБ является:

организационную структуру компании
можно легко перенести на ARIS;

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

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

позволяет проанализировать поведение
разработанных моделей (имеется модуль имитационного моделирования);

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

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

Недостатками использования
методологии ARIS для компаний являются:

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

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

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

При помощи методологии и
инструментов ARIS можно управлять не только бизнес-процессами компании, но и
процессом «управление бизнес -процессами».

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

Решения ARIS включают в себя
отдельные программные продукты платформы ARIS и методологию выполнения проектов
ARIS Value Engineering (AVE), представляющую собой ноу-хау компании IDS Scheer.
Все эти специализированные решения прошли проверку на широком спектре реальных
проектов и на основе накопленного опыта обеспечивают быстрое и эффективное
решение бизнес — задач заказчиков.

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

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

В зависимости от задач и целей
внедрения решение ARIS Solution for Enterprise BPM поддерживает сценарии
преобразования бизнес — процессов и управления бизнес-процессами.

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

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

Управление бизнес-процессами (BPM) в
рамках решения ARIS Solution for Enterprise BPM охватывает процессы анализа,
оптимизации, коммуникации и внедрения. Интегрированная процедурная модель ARIS
Value Engineering for Enterprise BPM предоставляет специальные рабочие пакеты
для определения стратегий, потенциала к улучшению и сопряженных с этим
изменений.

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

Благодаря наличию испытанной
процедурной модели ARIS Value Engineering for EA это решение сочетает
лидирующие на рынке технологии управления бизнес-процессами (BPM) и глобальные
стандарты архитектуры предприятия. Решение позволяет осуществлять планирование,
визуализацию и оценку технологий, процессов, данных и организационных структур
без привлечения каких — либо дополнительных резервов.

Программное обеспечение SAP помогает
предприятиям внедрять бизнес-процессы. Решение ARIS для
процессно-ориентированного внедрения продуктов SAP обеспечивает необходимую
поддержку на всех этапах проекта — от анализа стратегии и требований,
проектирования и до конфигурации, тестирования, обучения и запуска решений SAP.
Бизнес-процессы документируются при помощи решения ARIS для SAP NetWeaver и
анализируются в контексте новых систем SAP.

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

Стратегическая платформа ARIS от IDS
Scheer предлагает целый ряд инструментов для поддержки проектов внедрения ССП
на различных этапах выполнения.

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

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

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

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

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

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

Если деятельность предприятия
поддержана системой управления предприятием R/3 фирмы SAP, то использование
комплекса ARIS позволит постоянно поддерживать систему R/3 в актуальном
состоянии, соответствующем существующим на предприятии бизнес-процессам.
Подобного рода интеграция существует и с некоторыми другими системами
управления предприятием.

Направленность данного продукта на
управление качеством по стандарту ISO9000 позволит обеспечить деятельность
предприятия на уровне, соответствующем общепринятым требованиям к организации
процессов. Кроме того, данная система обеспечит поддержку процесса подготовки и
непосредственной сертификации по данному стандарту. Для этого в системе
предусмотрено создание специальных отчетов, отвечающих требованиям ISO9000, а
также существуют модели, отражающие полную методологию процесса сертификации по
стандарту ISO 9000 — анализ существующей системы управления на предприятии,
реорганизация бизнес-процессов, обучение персонала и непосредственно сама
сертификация. Правильное проведение всех необходимых мероприятий позволит
предприятию успешно выйти на европейский рынок и быть признанным большинством
компаний Европы.

Система ARIS в настоящее время уже
успешно используется множеством известных компаний различного профиля как в
России, Европе, так и по всему миру.

Фирма Mercedes-Benz использует ARIS
Toolset с 1995 года для анализа и совершенствования своей деятельности в
области производства легковых автомобилей. Поводом для приобретения послужила
возрастающая в то время конкуренция на рынке легковых автомобилей и острая
необходимость в повышении конкурентоспособности предприятия. Использование
данной системы позволило перейти на качественно новый уровень в организации
производства. По словам самих сотрудников фирмы Mercedes-Benz, работающих в
подразделении планирования, ARIS помог им более глубоко понять принципы
стратегического планирования развития производства, а также технологию перехода
от стратегических планов к их эффективной реализации. В настоящее время это
подразделение успешно разрабатывает стратегические планы и консультирует
большинство заводов фирмы, занимающихся производством легковых автомобилей как
в самой Германии, так и за ее пределами.

Другая автомобилестроительная
компания Volkswagen, успешно использовала систему ARIS для реализации
эффективной программы лизинга, осуществляемой ее двумя дочерними
подразделениями — Volkswagen Leasing и Volkswagen Bank. Разработанная программа
лизинга, названная “LEASIS” в настоящий момент контролирует порядка 99
процентов всего лизингового рынка Германии. Весь процесс разработки данной
программы был полностью осуществлен в системе ARIS Toolset и продолжался
порядка 5 месяцев с участием от 6 до 20 специалистов на разных этапах
составления проекта. Окончательным этапом разработки стал расчет экономических
показателей реализации программы и презентация проекта и обучение для всех
будущих участников данной программы, что также было организовано с
использованием инструментов комплекса ARIS.

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

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

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

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

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

. Процессные модели — динамические
модели, которые показывают поведение процессов и их зависимость от ресурсов,
данных и функций окружения бизнеса. Включают в себя событийно-управляемые
модели (еЕРС), модели окружения функции (FAD), модель добавленной стоимости
(VAD).

Первые четыре категории
концентрируются на структуре организации, процессные модели концентрируются на
поведении процессов во времени.

При моделировании следует придерживаться
следующих основополагающих принципов, разработанные профессором Шеером:

) Принцип корректности — корректная
модель должна соответствовать принятым синтаксическим и семантическим правилам.
Метод должен быть полным и логичным, модель должна соответствовать методу.
Только тогда модель может быть адекватна реальности и использоваться разными
пользователями. «Придерживайтесь методологии АРИС».

) Принцип релевантности — объекты,
используемые при моделировании должны соответствовать целям моделирования. Чрезмерно
детализированное моделирование приводит к неоправданным потерям средств. «Не
пытайтесь замоделироватъ ВСЕ».

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

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

) Принцип сравнимости — АРИС —
инструмент неограниченных возможностей для достижения одного и того же
результата. Реальные выгоды от моделирования могут быть получены при
ограничении возможностей в разумных пределах — использовании собственных стандартов,
базирующихся на методологии АРИС. «Разработайте стандарты моделирования и
следуйте им».

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

АРИС имеет более чем 200 типов
объектов и множество типов отношений, упрощения моделирования при одновременном
достижении целей, согласно «Соглашению по моделированию бизнес-процессов
предприятий УП ЯБП в нотации системы ARIS», число объектов и отношений
сокращено. Число используемых моделей сокращено до семи (в АРИС доступно более
100 моделей).

Самих по себе объектов недостаточно,
важны отношения между ними. Отношения между объектами описываются путем соединений
между ними на диаграммах. Соединения может создаваться как между объектами
одинакового типа, так и между объектами различного типа. При этом не все
возможные отношения между двумя объектами имеют смысл — возможные типы
отношений между объектами описаны в модельном соглашении и могут быть
установлены так называемым «методическим фильтром» АРИС.

3. Моделирование и оптимизация
бизнес-процессов на примере стоматологической клиники ООО «Ахтанин»

.1 Построение модели бизнес —
процессов в ООО Стоматологическая клиника «Ахтанин»

ООО Стоматологическая клиника
«Ахтанин» — частное медицинское предприятие, специализирующееся на оказании
стоматологических услуг различного профиля.

Клиника начала свою деятельность в
2016 году. Предприятие является семейным. С момента открытия данной клиники ее
работниками являются два поколения Ахтаниных.

Принципы работы специалистов ООО
Стоматологическая клиника «Ахтанин»:

. Инфоримрованность клиентов обо
всех этапах лечения;

. Совместное принятие решений с
пациентом в отношении проводимого лечения;

. Достижение эстетичного результата
в своей работе.

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

ООО Стоматологическая клиника
«Ахтанин» предоставляет исключительно персонализированную медицинскую помощь.

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

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

ООО Стоматологическая клиника
«Ахтанин» расположена по адресу: Москва, ул. Маршала Рыбалко д.2 к.3.

ООО Стоматологическая клиника
«Ахтанин» является предприятием малой сферы бизнеса. Общая численность
персонала клиники составляет 12 человек.

ООО Стоматологическая клиника
«Ахтанин» имеет весьма неплохие показатели в своем индустриальном секторе, а
так же большое количество постоянных клиентов и постоянный приток новых
клиентов.

Используемые ИТ технологии:
«Имплантант — Ассистент», IDent, MS Office, MS Windows.

Основные бизнес-процессы: лечение
зубов, протезирование, лечение патологии прикуса, ортопедическое лечение.

На рис. 3.1 представлена
организационная структура ООО Стоматологическая клиника «Ахтанин».

Рис. 3.1.
Организационная структура ООО Стоматологическая клиника «Ахтанин»

Описание
бизнес-процесса: Заявку в ООО Стоматологическая клиника «Ахтанин» клиент может
оформить через телефон либо в режиме онлайн через официальный сайт клиники.

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

Описание процесса в
табличной форме представлено в табл. 3.1.

Таблица 3.1.
Описание бизнес-процесса в ООО Стоматологическая клиника «Ахтанин»

№

Наименование функции

Исполнитель

Ресурсы (в т.ч. документы, программы)

Регламенты

Входящие

Исходящие

1

Оформление заявки

Регистратор

Заявка на посещение врача

Запись в журнале заявок

Инструкция по оформлению заявок, регламент работы с клиентом

2

Оформление договора на оказание услуг

Регистратор

Запись в журнале заявок

Договор на оказание стоматологических услуг

Форма договора

3

Передача заявки на оказание услуг

Регистратор

Договор на оказание стоматологических услуг

Талон на посещение

Форма талона

4

Оказание услуг

Врач-стоматолог

Талон на посещение

Акт оказания платной стоматологической помощи

Регламент работы с клиентом

5

Расчет стоимости услуг

Бухгалтер

Акт оказания платной стоматологической помощи, прайс-лист

Квитанция на оплату

Бухгалтерская инструкция

6

Проверка оплаты услуг

Бухгалтер

Квитанция на оплату

Отметка об оплате

Бухгалтерская инструкция

Графическое
описание бизнес-процесса «Оказание услуги» представлено на рис. 3.2.

Рис. 3.2.
Бизнес-процесс «Оказание услуги»

В проекте
используются основные модели и расширения основных моделей (в скобках указано
оригинальное имя типа модели, а также проектная аббревиатура для
документирования):

. Диаграмма
организационной структуры (Organizational chart, OC).

. Диаграмма цепочки
добавленного качества (Value-added chain diagram, VAD).

. Диаграмма
событийно-управляемого процесса (extended Event-driven Process Chain, eEPC).

5. Диаграмма
носителей информации (Information carrier diagram, ICD)

. Диаграмма
операционных ресурсов (Techinical resources, TR)

6. Карта знаний (Knowledge map,
KM)

. Диаграмма структуры знаний (Knowledge
structure diagram, KSD)

. Карта полномочий
(Authorization map, AM)

. Диаграмма прикладных систем (Application
system diagram, ASD)

Данное соглашение
определяет трактовку следующих терминов, используемых в проекте (Таб. 3.2):

Таблица 3.2.
Термины проекта моделирования

Термин (рус.)

Термин (англ.)

Определение

Функция

Function

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

Событие

Event

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

Бизнес-процесс

Business process

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

Продукт

Product

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

Application system

Application system

Отражает обобщение отдельных прикладных систем, обладающих
одинаковыми техническими и функциональными характеристиками

Носитель информации

Information carrier

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

Тип операционного ресурса

Operating resource type

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

Организационная схема

Organizational chat

Организационная схема отражает совокупность организационных
взаимосвязей, рассматриваемых на верхнем уровне абстракции

Организационная единица

Organizational unit

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

Должность

Position

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

Технический термин

Technical term

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

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

Основными понятиями являются:

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

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

) Объекты — это составляющие части
системы, причем, система имеет конечное число объектов.

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

) Связи — это то, что соединяет
объекты и свойства системы в единое целое.

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

) Подпроцесс — это бизнес-процесс,
являющийся структурным элементом некоторого бизнес-процесса, который
представляет ценность для потребителя.

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

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

В настоящем документе перечислены
объекты, символы, связи между объектами и моделями, которые будут использованы
для описания бизнес-деятельности организации. При создании диаграмм
используется CASE система MS Visio.

Таблица 3.3. Допустимые объекты
диаграмм

Тип объекта рус. (англ.)

Символ с именем по умолчанию (рус. или англ.)

Целевое использование

Правила именования

Организационная схема (Organizational Chart)

Сотрудник (Person)

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

Сотрудник указывается фамилией и инициалами (дополнительно,
может указываться персональный номер)

Должность (Position)

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

Имя должности должно начинаться с имени существительного

Диаграмма технических ресурсов (Technical Recourses)

Класс операционного ресурса (Operating recourse class)

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

Имя класса должно начинаться с имени существительного или имени
прилагательного

Операционный ресурс (Operating resource)

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

Имя содержит название ресурса

Диаграмма носителей информации (Information Carrier Diagram)

Информационный носитель (Information carrier)

Используется для обозначения картотеки документов

Имя носителя должно начинаться с имени существительного во
множественном числе

Информационный носитель (Information carrier)

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

Имя носителя должно начинаться с имени существительного в
единственном числе

Носитель информации (Information carrier)

Используется для обозначения информационных носителей, тип
которых не определен

Имя носителя должно начинаться с имени существительного в
множественном числе

Носитель информации (Information carrier)

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

Именуется названием файла или именем информационной базы данных

Диаграмма карты полномочий (Authorization map)

Полномочие (Authorization condition)

Используется для структуризации полномочий

Имя носителя должно начинаться с имени существительного

Диаграмма событийно-управляемой цепочки процесса (Even-driven
Process Chain)

Событие (Event)

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

Имя события должно начинаться с глагола в прошедшем времени

Функция (Function)

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

Имя функции должно начинаться с отглагольного существительного

Технический термин (Technical term)

Используется для обозначения статуса документов

Называется согласно текущему статусу документа

Диаграмма типа прикладной системы (Application system type
diagram)

Тип прикладной системы (Application system
type)

Отражает типификацию отдельных прикладных систем, обладающих
одинаковыми техническими характеристиками

Имя типа прикладной системы должно начинаться с имени
существительного или имени прилагательного

Класс прикладной системы (Application system class)

Используется для обозначения класса прикладной системы

Называется согласно названию класса прикладной системы

Диаграмма карты знаний (Knowledge map)

Документированное знание (Documented knowledge)

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

Полное название документа, содержащего информацию

Knowledge category

Используется для обозначения категории знаний

Соответственно названию категории знаний

Диаграмма цепочки добавленного качества Value Added chain
Diagram)

Функция (Function)

Используется для наименования функции

Используется его реальное значение, описывающее реальный процесс

Допустимые связи диаграмм.

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

Таблица 3.4. Допустимые типы связей

Тип объекта источника связи

Тип связи рус. (англ.)

Целевое использование

Тип объекта приемника связи

Организационная схема (Organizational Chart)

Должность (Position)

является организационным управляющим (is organizational manager
for)

Предназначена для указания управляющего организационной единицы

Организационная единица (Organizational unit)

Организационная единица (Organizational unit)

Состоит из (Is composed of)

предназначена для описания состава организационной единицы

Организационная единица (Organizational unit)

Сотрудник (Internal person)

Занимает (occupies)

Используется для обозначения принадлежности штатного сотрудника
должности

Должность (Position)

Должность (Position)

Is superior Является вышестоящим

Используется для обозначения подчиненности в организационной
диаграмме

Должность (Position)

Технические ресурсы (Technical resource)

Operating resource

Принадлежит (Belongs to)

Описание принадлежности к виду

Operating resource type

Носители информации (information carrier
diagram)

Носитель информации (Information carrier)

Включает в себя (encompasses)

Предназначена для структурирования документов организации

Носитель информации (Information carrier)

Диаграмма событийно-управляемой цепочки процесса (eEPC)

Событие (Event)

Активизирует (activates)

Предназначена для того, чтобы показать, что событие инициирует
функцию

Функция (Function)

Функция (Function)

Порождает (creates)

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

Событие (Event)

Информационный носитель (Information carrier)

поступает на вход (provides input for)

Предназначена для представления документов, которые поступают на
вход

Функция (Function)

Функция (Function)

создает на выходе (creates output to)

Предназначена для представления документов, которые создаются на
выходе

Информационный носитель (Information carrier)

Тип прикладной системы (Application system
type)

может поддерживать (can support)

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

Функция (Function)

Тип операционного ресурса (Operating recourse type)

является операционным ресурсом (is operating recourse of)

Предназначения для представления типов операционных ресурсов,
посредством которых выполняется конкретная функция

Функция (Function)

Должность (Position)

Выполняет (executes)

Предназначения для представления должностей, которые
ответственны за выполнение конкретной функции

Функция (Function)

Технический термин (Technical term)

отображается на (lies on)

Предназначена для описания статуса документа

Информационный носитель (Information career)

Функция (Function)

порождает событие через (leads to)

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

Правило (Rule)

Должность (Position)

 (Accepts)

Показывает какой должностное лицо участвует в согласовании

Функция (Function)

Карта полномочий (Authorization map)

Должность (Position)

Располагает (Disposes of)

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

Полномочие (Authorization condition)

Дерево функций (Function tree)

Функция (Function)

подчиняется по
процессу (is process-oriented
superior)

Показывает, что объект «процесс», от которого направлено
соединение, связан с объектом-приемником «процесс»

Функция (Function)

Диаграмма прикладной системы (Application system diagram)

Тип прикладной системы (Application system
type)

Принадлежит (Belongs to class)

Используется для обозначение принадлежности информационных
систем

Класс прикладной системы (Application system class)

Тип прикладной системы (Application system
type)

Содержит (Subsumes)

Используется для обозначения вхождение набора данных в группу

Тип прикладной системы (Application system
type)

Карта знаний (Knowledge map)

Должность (Position)

Требует (requires)

Предназначена для связи между должностью и категорией знаний

Knowledge category

Диаграмма цепочки добавленного качества (Value Added chain
Diagram)

Функция (Function)

Поддерживает (Supports)

Предназначена для подчинения бизнес-функций

Функция (Function)

Разработка диаграмм модели
бизнес-процесса в среде ARISю

Архитектура (здание) ARIS — пять
типов представлений, отражающих основные аспекты деятельности организации.

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

Модель ресурсов в ARIS
структурируется в соответствии с концепцией жизненного цикла на уровне
представления моделей информационных систем.

Модель жизненного цикла,
представляемая в виде последовательности уровней или этапов, предназначена для
описания жизненного цикла информационной системы (ИС). Однако модель жизненного
цикла ARIS не может рассматриваться как процедурная модель для разработки
некоторого независимого объекта на каждом уровне представления. Различные
уровни представления выделены в модели в зависимости от степени их близости к
информационным технологиям (ИТ).

Это различие выражено в трехярусной
модели ARIS.

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

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

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

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

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

Организационное моделирование.

Диаграмма организационной структуры
— Organizational chart.

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

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

Рис. 3.3. Функциональные возможности
отраслевого решения «Запись на прием»

В задачи и функции Администратора
входит:

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

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

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

В соответствии с поставленными
задачами регистратура осуществляет:

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

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

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

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

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

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

При выполнении работы по составлению
отчетности специалисты ЦТО используют технические ресурсы.

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

При выполнении работы по регистрации
заявок специалисты используют технические ресурсы.carrier diagram — Диаграмма
носителей информации.

Диаграмма носителей информации
предназначена для структурированного описания документов организации.

Рис. 3.4. Диаграммы носителей
информации регистратуры ООО «Ахтанин» в нотации Information Carrier Diagram

Процессное моделирование.map — Карта
знаний.

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

Таблица 3.5. Детализирующие связи
для диаграммы КМ

Наименование детализируемого объекта

Тип объекта

Детализирующая модель

Тип моделей

Знание ПК

Knowledge category

Диаграмма структуры знаний ПК регистратора

Knowledge structure diagram

Нормативные знания

Knowledge category

Диаграмма структуры нормативных знаний регистратора

Knowledge structure diagram

Административно-управленческие знания

Knowledge category

Диаграмма структуры административно-управленческих знаний
регистратора

Knowledge structure diagram

Диаграмма структуры знаний — Knowledge structure diagram.

Authorization map — Карта полномочий.

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

Extended event driven
process chain (eEPC) — Событийная цепочка процесса.

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

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

Рис. 3.5.-Процесс регистрации
клиента в нотации Extended event driven process chain

«Диаграмма цепочки добавленного
качества» — Value Added chain Diagram.

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

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

Таблица 3.6. Детализирующие связи
для диаграммы VAD

Наименование детализируемого объекта

Тип объекта

Детализирующая модель

Тип моделей

Предоставление услуг ЦТО

function

Процессы предоставление услуг ЦТО

Value Added-Chain Diagram

Функциональное моделирование.

Application system type diagram (ASTD) — диаграмма типа прикладной системы.

Данная диаграмма предназначена для
моделирования прикладных информационных систем, используемых в организации.

Документирование бизнес процесса.

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

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

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

Наименование сотрудника

Полномочия

Регистратор

1. Прием заявок по телефону или через интернет 2. Запись заявки
в Журнал заявок 3. Запись клиента на прием к врачу 4. Составление договора на
оказание стоматологических услуг 5. Оформление медицинской книжки

Таблица 3.8. «Документация
регистратуры ООО Стоматологическая клиника «Ахтанин»

Наименование сотрудника

Полномочия

Регистратор

Законодательные и иные правовые акты Заявки (Журнал заявок)
Прайс-лист стоматологических услуг Внутренние распорядительные документы и
приказы Должностные инструкции Договоры с клиентами Медицинской книжки

.2 Анализ модели бизнес — процессов
в ООО Стоматологическая клиника «Ахтанин»

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

Таблица 3.9. Анализ разрывов в
информационных носителях

Наименование показателя

Значение показателя

Number of functions Количество
функций

5

Collectively associated information carriers Общее количество
задействованных носителей информации

3

Input information carrier В том числе количество носителей
информации, обеспечивающих вход функций

3

Output information carrier В том числе количество носителей
информации, фиксирующих выход функций

2

Functions with
at least
1 input information carrier
Количество функций, обладающих хотя бы 1 носителем информации, обеспечивающим
вход

3

Functions with
at least
1 output information carrier Количество функций, обладающих хотя бы 1 носителем информации,
фиксирующим выход

2

Functions with
at least
1 input information carrier
and 1 output
information carrier Количество функций, вход которых обеспечен хотя бы 1 носителем
информации, и выход также фиксируется хотя бы на 1 носителе информации

1

Functions with
different input and output information carriers

2

Number of function transitions Количество переходов функций (пар
функций, каждая из которых обладает хотя бы 1 носителем информации,
обеспечивающим вход, или хотя бы 1 носителем, фиксирующим выход)

1

Function transitions with media breaks Количество переходов
функций с разрывами носителей информации

2

Relationship between
media breaks and function transitions Коэффициент, отражающий степень информационных разрывов (0…1 min)

2

Для достижения поставленной цели
использовались нотация описания бизнес-процессов ARIS и инструментальный пакет
Microsoft Visio.

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

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

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

.3 Построение модели бизнес —
процессов в ООО Стоматологическая клиника «Ахтанин»

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

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

Оптимизационная модель управления
приемом заявок с использованием архитектурных возможностей ARIS приведена на рис. 3.6.

Рис. 3.6. Оптимизационная модель
управления приемом заявок с использованием архитектурных возможностей ARIS в
стоматологическая клиника «Ахтанин»

Заключение

бизнес информационный процессный

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

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

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

Моделирование реальных ситуаций в
работе компании и отработка комплексных бизнес-процессов стали темой все более
широких обсуждений.

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

Одной из таких концепций является —
Архитектура Интегрированных Информационных Систем — ARIS (Architecture of
Integrated Information Systems), разработанная проф. Шеером.

Эта концепция имеет два основных
преимущества:

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

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

ООО Стоматологическая клиника
«Ахтанин» — частное медицинское предприятие, специализирующееся на оказании
стоматологических услуг различного профиля.

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

Используемые ИТ технологии:
«Имплантант — Ассистент», IDent, MS Office, MS Windows.

Описание бизнес-процесса: Заявку в
ООО Стоматологическая клиника «Ахтанин» клиент может оформить через телефон
либо в режиме онлайн через официальный сайт клиники.

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

В рамках данного рассматриваемая
процедура «Приема и обработки заявок» была проанализирована по позиции: анализ
разрывов в информационных носителях. Для достижения поставленной цели
использовались нотация описания бизнес-процессов ARIS и инструментальный пакет
Microsoft Visio.

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

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

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

Литература

1.      Аакер Д. Стратегическое рыночное управление. — СПб: Питер,
2011. — 296с.

.        Абдикеев Н.М.; Данько, Т.П. и др. Реинжиниринг
бизнес-процессов; Эксмо; Издание 2-е, испр. — Москва, 2014. — 590c.

.        Агиевич Т.Г. Оптимизация бизнес-процессов: концептуальный
подход // Теория и практика общественного развития, №4. — 2013. — с.224-227.

.        Алоев Т.Б. Оптимизация бизнес-процессов и управления
персоналом как основа эффективности функционирования организации //
Гуманитарные, социально-экономические и общественные науки, №3. — 2016. —
с.123-127.

.        Блинов А.О., Рудакова О.С. Реинжиниринг бизнес-процессов.
— М.: Юнити-Дана, 2010. — 344с.

.        Бородулин А.Н. Основные объекты применения информационных
технологий к оптимизации бизнес-процессов // Управление большими системами:
сборник трудов, №17. — 2007. — с.40-61.

.        Варзунов А.В., Торосян Е.К., Сажнева Л.П. Анализ и
управление бизнес-процессами // Учебное пособие. — СПб: Университет ИТМО, 2016.
— 112с.

.        Галямина И.Г. Управление процессами. — СПб.: Питер, 2013.
— 304с.

.        Громов А.И. и др. Учебно-методический комплекс Анализ и
моделирование бизнес-процессов / Учебное пособие/Громов А.И., Чеботарев В.Г.,
Горчаков Я.В., Бойко О.И. — М., 2011. — 157с.

.        Громов А.И. Управление бизнес-процессами: современные
методы. монография / А.И. Громов, А. Фляйшман, В. Шмидт. — Люберцы: Юрайт,
2016. — 367c.

Источник

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

Подробности
Опубликовано: 10.07.2018 11:29
Автор: Худяков Сергей Дмитриевич
Просмотров: 6027

Аннотация: в работе реализуется автоматизация процессов стоматологической клиники по всем видам её деятельности, а также обеспечение врачу-стоматологу доступа к информации о ходе лечения конкретного пациента непосредственно на рабочем месте у стоматологического кресла. Актуальность выбранного направления объясняется ежегодно увеличивающимся количеством стоматологических клиник и не снижающимся количеством обращений в них, что приводит к росту очередей и высокой нагрузке менеджеров и медицинского персонала стоматологии.
Скачать: PDF, PPT, AVI.
Ключевые слова: опрос стейкхолдеров, стейкхолдер, ранжирование требований, ARIS eEPC, билд, builds, бизнес-ресурс, оценка рисков Боэма, квадрант, метод MoSCoW, метод QFD, user story mapping, lean prioritization, график ценности и усилий требований, реинжениринг, непервичные атрибуты.

Введение

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

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

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

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

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

Раздел 1. Цель и задачи практической работы

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

  • Выполнить детальный анализ спиралевидной модели.
  • Провести анализ предметной области.
  • Провести опрос стейкхолдеров.
  • Определить бизнес-процессы стоматологии и выявить из них ключевой бизнес-процесс.
  • Составить список требований.
  • Провести ранжирование требований по их значимости.
  • Проектирование процессов и оргструктуры в моделях AS-IS и TO-BE нотации ARIS VACD и eEPC до 3-4 уровней детализации.
  • Определение очерёдности выполнения требований по спиралям.
  •  Разработка ПО обеспечения (для каждого витка спирали):
    • моделирование разрабатываемых пользовательских интерфейсов;
    • проектирование структуры данных и нормализация таблиц данных;
    • реализация операции ключевого процесса в среде MS Access;
    • тестирование и количественная оценка результатов тестирования;
    • качественный и количественный анализ рисков. 

Раздел 2. Детальный анализ спиралевидной методологии внедрения систем 

2.1. Понятие жизненного цикла

Процесс создания ПО является сложным из-за количества необходимых действий. ПО претерпевает ряд процессов, которые в совокупности называются жизненным циклом [2]. На данный момент существует множество моделей ЖЦ, позволяющих наладить и структурировать процесс создания ПО от начала задумки до этапа ввода в эксплуатацию. Все эти модели схожи по наличию следующих действий [3]:

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

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

  • необходима возможность вносить изменения в продукт в ходе его реализации;
  • данное ПО создаётся для частной стоматологии, в силу чего необходимо учесть возникновение возможных рисков и их значимость во время проекта;
  • необходимо иметь промежуточные результаты продукта. 

2.2. Общее описание принципа спиралевидной модели

Суть спиралевидной модели заключается в том, что процесс создания итогового продукта можно условно разбить на 4 квадранта, через которые будет проходить каждый виток спирали, количество которых определяется в ходе жизненного цикла самого проекта, в зависимости от удовлетворения требований заказчика. Данными квадрантами являются (рисунок 2.1):

  • Формирование цели и требований.
  • Оценка и расчёт рисков.
  • Конструирование (разработка, кодирование, тестирование).
  • Оценка заказчика (внедрение и сопровождение).

Спиралевидная модель

Рис. 2.1. Спиралевидная модель

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

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

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

Квадрант 2: оценка и расчёт рисков. На данном этапе оценивается вся полученная информация из первого квадранта и используется метод оценки рисков Боэма или другой метод, более подходящей для конкретного проекта (модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году) [4].

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

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

  • создание прототипа и переход к следующему этапу;
  • остановка дальнейшего усовершенствования продукта и передача заказчику имеющейся работы (начиная со второго витка спирали);
  • возврат к предыдущей стадии разработки проекта;
  • прекращение разработки в силу неоправданности проекта.

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

Квадрант 3: конструирование (разработка, кодирование, интегрирование, тестирование). Происходит непосредственная разработка и написание кода продукта, в том числе и пользовательского интерфейса. При первой итерации создаётся концепция продукта (Proof Of Concept) [5], необходимая для первоначальной оценки заказчиком, после чего при последующих витках спирали создаются билды (builds) – готовые версии продукта, которые позволяют заказчику видеть ход работы над проектом и точнее формировать требования, дополнения и необходимые исправления билдов на пути к готовому продукту. По завершении создания производится тестирование билда и исправление ошибок.

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

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

2.3. Преимущества и недостатки

Спиральная модель обладает следующими преимуществами:

  • Возможность заказчику «видеть» развитие системы на ранних стадиях.
  • Частая обратная связь с заказчиком в процессе всего жизненного цикла проекта.
  • Изменения могут быть внесены на поздних стадиях разработки.
  • Учёт и проработка рисков до того, как они могут настать.
  • Большой потенциальный объём над проектом «разбивается» на малые задачи, которые оцениваются и воплощаются, при этом с учётом возможных последующих рисков.
  • Наличие преимущества инкрементной модели: билды различных версий продукта.
  • Высокий уровень административного управления, так как в конце каждой итерации проводиться анализ проведённых работ и расчёт необходимости дальнейшего продолжения проекта.
  • Повышается предсказуемость поведения система из-за частой корректировки поставленных требований к продукту.

Спиральная модель обладает следующими недостатками:

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

2.4. Последовательность шагов реализации приложения

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

Таблица 2.1. Предварительное содержание витков спирали 

Этап спирали

Номер спирали

Предполагаемые действия
Поиск решения задач, поставленных в требованиях I Общая структура
II Взаимосвязи данных
III Интерфейс
IV Доработка дополнительных функций и дизайна приложения
Оценка возможных рисков и их влияния I, II, III, IV Рассмотрение рисков и вариантов взаимодействия с ними
Разработка и кодирование этой части проекта I, II, III, IV Реализация требований в программной среде Microsoft Access 2016
Тестирование приложения IV Проведение тестирования приложения

Раздел 3. Идентификация требований и формирование списка требований 

3.1. Анализ требований

Требования – это описание тех пожеланий, которые необходимо выполнить при реализации продукта. Требования лишь описывают желаемый результат, но никак не учитывают технический аспект осуществления проекта [6]. Для упрощения работы, требования должны соответствовать следующим критериям:

  • однозначность;
  • непротиворечивость друг другу;
  • понятность;
  • корректность.

Требования заказчика к продукту фиксируется исходя из опроса-интервью. Для корректности и точности собранной информации необходимо выполнить следующие 4 этапа [6]:

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

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

3.2. Пользовательские требования

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

  • Наличие личной карточки пациента с основными данными:
    • ФИО;
    • дата рождения;
    • возраст;
    • пол;
    • номер ОМС;
    • паспортные данные (серия, номер, кем выдан);
    • номер телефона.
  • Описание всего лечения пациента:
    • перечень сопутствующих заболеваний;
    • анамнез пациента;
    • фиксация результата осмотра ротовой полости в «зубной карте»;
    • описание проведённого лечения;
    • возможность добавления рентген-снимков.
  • Возможность описания состояния зуба:
    • состояние зуба;
    • проведённые на нём процедуры;
    • использованные препараты;
    • отметка о необходимости дальнейшего лечения.
  • Информация о специалистах стоматологии:
    • ФИО специалиста;
    • специальность;
    • рабочий телефон.
  • Информация об оказываемых в стоматологии услугах:
    • наименование услуги;
    • стоимость услуги.
  • Возможность вывода следующей информации:
    • личной карточки пациента;
    • «зубной карты» определённого пациента;
    • внесённой информации по зубу пациента;
    • списка всех специалистов;
    • перечня услуг и их стоимости.
  • Возможность вносить в программу информацию о новом пациенте и описывать детали его лечения.
  • Отдельный доступ для:
    • врача, с возможностью внесения и изменения информации о проведенном лечении;
    • пациента только просмотр описания проведённого лечения.
  • «Зубная карта» схематично должна показывать ротовую область.
  • При запросе информация не должна быть показана вся сразу.
  • Незагруженный простой интерфейс. 

3.3. Функциональные требования

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

  • База данных должна содержать следующие таблицы:
    • «Пациент» (с содержанием полей «ФИО», «Дата рождения», «Возраст», «Пол», «Номер ОМС», «Паспортные данные», «Телефон»).
    • «Анамнез» (с содержанием полей «Дата посещения», «Описание»).
    • «Сопутствующие заболевания и противопоказания» (с содержанием полей «Соп.заболевания» и «Противопоказания»).
    • «Карта зубов» (с содержанием графы «номер зуба»).
    • «Описание зуба» (с содержанием полей «Состояние», «Процедуры», «Исп. препараты», «Завершённость лечения»).
    • «Персонал» (с содержанием графов «ФИО», «специализация»).
    • «Услуги» (с содержанием графов «Название», «Стоимость»).
  • Обеспечение возможности вывода на экран:
    • информации из таблицы «Пациенты»;
    • информации из таблицы «Зубная карта»;
    • информации из таблицы «Описание зуба»;
    • информации из таблицы «Персонал»;
    • информации из таблицы «Услуги».
  • Возможность вносить в программу информацию о новом пациенте и описывать детали его лечения.
  • Реализация отдельного доступа:
    • для врача, с возможностью внесения и изменения информации о проведенном лечении;
    • для пациента только просмотр описания проведённого лечения.
  • Информация показывается в свёрнутых списках.
  • Каждый зуб является отдельной кнопкой, нажатие на которую выводит информацию о выбранном зубе из таблицы «Описание зуба».
  • Незагруженный простой интерфейс. 

3.4. Приоритезация требований и матрица их отслеживания

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

  • Метод Кано – позволяет определить удовлетворённость клиентов функциями программного обеспечения.
  • Метод MoSCoW.
  • Метод QFD (Quality Function Deployment) – сопоставление желаний клиента и компании.
  • User Story Mapping – построение карты пользовательских событий использования.
  • Lean Prioritization с универсальной матрицей Value and Effort (график ценности и усилий требований).

Наиболее наглядным и подходящим для нашей цели является метод MoSCoW, суть которого заключается в присваивание к каждому требованию одной из четырёх категорий [8]:

  • Must – наиболее важное и срочное.
  • Should – важное.
  • Could – может быть отложено на некоторое время.
  • Would – не является приоритетным вообще (возможно   осуществление в следующем релизе).

Совокупность всех требований и их приоритетов находится в табл. 3.1. 

Таблица 3.1. Матрица отслеживания и приоритетов требований

№

Пользовательские требования

Функциональные требования

Компонент программы

Уровень приоритета 
 1 Наличие личной карточки пациента с основными данными Таблица «Пациент» с необходимыми полями для внесения данных из анкеты и документов Программа по ведению данных о пациенте Must
 2 Наличие перечня сопутствующих заболеваний и противопоказаний Таблица «Сопутствующие заболевания» и таблица «Противопоказания» Программа по ведению данных сопутствующих заболеваниях и противопоказаниях Must
 3 Наличие анамнеза пациента Таблица «Анамнез» с полями для данных из опроса пациента с датой обращения Программа по ведению данных об анамнезе пациента Must
 4  Возможность фиксация результатов осмотра ротовой полости в «зубной карте» Таблицы «Карта зубов» и «Описание зуба» Программа по ведению записи результатов осмотра Must
5 Наличие информация о специалистах стоматологии Таблица «Персонал», с необходимым данными о специалистах Программа по ведению данных о специалистах стоматологии Must
6 Наличие информации об оказываемых в стоматологии услугах Таблица «Услуги и цены» содержащая оказываемые процедуры и их стоимость Программа по ведению данных об услугах Should
7 Возможность записи и изменения информации в таблицах Возможность редактирование полей программ Средство для ввода информации Should
8 Показ информации по таблицам Вывод на экран запрашиваемой информации из таблиц Программа по выводу на экран запрашиваемых таблиц Should
9 При запросе информация не должна быть показана вся сразу Диалоговая форма и разворачивающиеся списки Диалоговая форма и разворачивающиеся списки Should
10 Возможность хранения рентген снимков Таблица «Рентген снимки» с сохранёнными фотографиями Средство работы с ссылками на изображения Could
11 Возможность отдельного доступа для врача и пациента с различным уровнем доступа к просмотру и изменению информации

Возможность авторизации пользователей

 Программное разделение информации по уровню доступа Could

3.5. Последовательность шагов спиралей при разработке приложения

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

  • Предварительные действия:
    • Определение предметной области.
    • Опрос стейкхолдеров с фиксацией их требований (см. таблицу 3.1).
    • Разработка бизнес-модели с использованием нотаций ARIS VACD и eEPC.
  • I виток спирали:
    • Поиск решения для реализации хранения информации в базе данных (пункты № 1-6 требований из таблицы 3.1).
    • Оценка возможных рисков и их влияния.
    • Разработка и кодирование этой части проекта.
    • Предоставление заказчику билда продукции и фиксация его оценки.
  • II виток спирали:
    • Принятие во внимание оценки предыдущего билда от заказчика. Поиск решения для реализации работы с данными для пользователя (пункт № 7 из таблицы 3.1).
    • Оценка возможных рисков и их влияния.
    • Разработка и кодирование этой части проекта.
    • Предоставление заказчику билда продукции и фиксация его оценки.
  • III виток спирали:
    • Принятие во внимание оценки предыдущего билда от заказчика. Поиск решения для реализации рабочего интерфейса (пункт № 8 из таблицы 3.1).
    • Оценка возможных рисков и их влияния.
    • Разработка и кодирование этой части проекта.
    • Предоставление заказчику билда продукции и фиксация его оценки.
  • IV виток спирали:
    • Принятие во внимание оценки предыдущего билда от заказчика. Поиск решения для реализации дополнительных функций приложения и усовершенствование пользовательского интерфейса (пункты № 9-11 из таблицы 3.1).
    • Оценка возможных рисков и их влияния.
    • Разработка, кодирование этой части проекта.
    • Тестирование и отладка готового приложения.
    • Предоставление заказчику готового продукта.

Раздел 4. Проектирование приложения 

4.1. Проектирование ключевых бизнес-процессов

Для создания ПО обеспечения, целью которого является автоматизация определённых действий, необходимо понять и описать, как происходит работа объекта сейчас и как мы хотим, чтобы как  это было. Для начала рассматривают бизнес-модель объекта, которая  в свою очередь  состоит из отдельных бизнес-процессов. Бизнес-модель – это совокупность бизнес-процессов и их взаимосвязей между собой, показывающая внутреннюю деятельность объекта в целом, направленная на достижение цели работы компании (в нашем случае оказание медицинских услуг в стоматологии) [8].

Бизнес-процесс – непосредственный набор действий (подпроцессов), который необходим для достижения конечной цели объекта. Задачей практической работы является автоматизация не всех протекающих в стоматологии бизнес-процессов, а лишь определённого, называемого ключевым бизнес-процессом.

Ключевым бизнес-процессом данной работы является фиксирование в электронном виде процесса лечения в формате «зубной карты». Для того, чтобы осуществить ключевой бизнес-процесс, рассмотрим деятельность стоматологии и проведём проектирование при помощи моделей «AS-IS» и «TO-BE» до 3-4 уровня, используя нотации ARIS VACD и eEPC.

Функциональная модель «AS-IS» описывает деятельность организации «как есть», то есть именно те действия, которые осуществляются на данный момент. Данная модель составляется из анализа существующих положений организации, опроса сотрудников о роде их деятельности, при непосредственном личном наблюдении эксперта за ходом работы. После построения модели «AS-IS» выявляются слабые места, действия, которые можно ускорить за счёт их автоматизации  и проводится реинжиниринг бизнеса – построение модели «TO-BE» (модель «как будет»). В этой модели учитываются необходимые изменения и тем самым описывается усовершенствованный бизнес-процесс [9]. Для проектирования процессов были выбраны две нотации ARIS VACD и ARIS eEPC.

Методология Architecture of Integrated Information Systems (ARIS) – проектирование интегрированных информационных систем – на данный момент является одной из самых распространённых и широко используемых. Она содержит около 100 нотаций, позволяющих отразить процессы на разных уровнях детализации. В целом, методология ARIS делит процессы на четыре группы [10]:

  • Группа «Оргструктура»: описание  организационной структуры и внутренней инфраструктуры компании.
  • Группа «Функции»: описание стратегических целей компании, функций и прочих элементов функциональной деятельности организации.
  • Группа «Информация»: описание информации, которая используется в деятельности организации.
  • Группа «Процессы»: описание взаимосвязей между структурой, функциями и информацией.

Для верхнего уровня проектирования будем использовать нотацию ARIS VACD (Value Added Chain), отличительной чертой которой является то, что информационные и материальные потоки на схеме отображаются объектами. При помощи данной нотации сможем отобразить логические связи между работами и их последовательность. Основное достоинство – это наличие обозначения для некоторой группы функций организации, которая служит для получения добавленной ценности [11]. Используемые элементы в данной нотации [12] приведены в таблице 4.1. 

Таблица 4.1. Графические элементы нотации ARIS VACD

Наименование

Описание

Графический элемент
 Процесс Обозначение процессов, происходящих в организации
 Объект Обозначение переходов носителей с информацией
Ответственный Обозначение организационных взаимосвязей и полномочий, обеспечивающих выполнение процесса

Для описания нижних уровней необходима нотация с большим количеством графических элементов, которые позволят детальнее отобразить происходящие бизнес-процессы в организации. Используем нотацию ARIS eEPC, отличительной чертой которой является наличие объектов «события», при помощи которого фиксируются факт, время или условие, инициирующих начало/окончание выполнения работ бизнес-процесса [11]. Используемые элементы в данной нотации [12] приведены в таблице 4.2.

Таблица 4.2. Графические элементы нотации ARIS eEPC 

Наименование

Описание

Графический элемент
Инициирующий/последующий процесс Обозначение процесса, который влияет на данный этап
Инициирующее/последующее событие Обозначение события, которое оказывает влияние на бизнес-процесс(-ы)
Процесс Обозначение выполняемого процесса
Ответственный Обозначение организационных взаимосвязей и полномочий, обеспечивающих выполнение процесса
Входящий/исходящий документ Обозначение необходимых бумажных документов при выполнении функции
Прикладная система Обозначение используемой программы для осуществления процесса
Логический элемент «И» Ставится в том случае, если для осуществления функции необходима одновременная инициация нескольких событий
Логический элемент «ИЛИ» Ставится в том случае, если для осуществления функции необходимо выполнение хотя бы одного из событий
Исключающий логический элемент «ИЛИ» Ставится в том случае, если для осуществления функции необходимо одно и только одно из событий в зависимости от условий

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

4.2. Диаграммы бизнес-процессов в моделях «AS-IS» и «TO-BE»

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

Первый уровень: процесс  «Накопление информации»

Рис. 4.1. Первый уровень: процесс  «Накопление информации»

Первый уровень бизнес модели включает в себя 4 основных бизнес-процесса, а именно «Обращение пациента», «Регистрация пациента», «Лечение пациента», «Оплата услуг» (рисунок 4.1). Как можно заметить, что уже начиная с первого уровня идёт накопление информации, в частности о пациенте. Разрабатываемое приложение обеспечит удобный её поиск и предоставление в более удобном формате, по сравнению с бумажным носителем.

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

Второй уровень: процесс «Лечение пациента» в модели «AS-IS»

Рис. 4.2. Второй уровень: процесс «Лечение пациента» в модели «AS-IS»

Второй уровень отражает конкретику действий врача-стоматолога. Основным бизнес-процессами были отмечены процессы проведения «Анамнеза», «Осмотра ротовой полости», «Анализа рентген-снимков», «Оказания медицинских услуг», «Фиксации результатов лечения» и «Передача администратору перечня проведённых услуг». Достоинством нотации ARIS eEPC, как уже было отмечено выше, является отображения объекта, совершающего процесс, а также их событийность. Благодаря этому видно, что стоматолог в ряде случаев вынужден обращаться к администратору с целью получения необходимой информации по пациенту, что приводит к следующему:

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

Разрабатываемое приложение устранит вышеперечисленные проблемы. Тогда после реинжениринга деятельность стоматологии на этом уровне примет вид, отражённый в модели «TO-BE» на рисунке 4.3.

Второй уровень: процесс «Лечение пациента» в модели «TO-BE»

Рис. 4.3. Второй уровень: процесс «Лечение пациента» в модели «TO-BE»

Одним из основных требований к разрабатываемому приложению являлось наличие «зубной карты» – формы, которая позволяла бы вести подробный учёт состояния каждого зуба пациента. Для понимания необходимых действий проведём декомпозицию процесса «Фиксация результатов лечения» (рисунок 4.4). 

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

Бизнес-процесс «Регистрация» заключает основное событие, а именно «наличие пациента в БД», так как от этого действия зависят дальнейшие действия администратора. При наличии пациента в БД, администратор переходит к записи на приём, при отсутствии – заводит новую ЛК. 

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

Третий уровень: процесс «Фиксация результатов лечения» в модели «AS-IS»

Рис. 4.4. Третий уровень: процесс «Фиксация результатов лечения» в модели «AS-IS»

Третий уровень: процесс «Фиксация результатов лечения» в модели «TO-BE»

Рис. 4.5. Третий уровень: процесс «Фиксация результатов лечения» в модели «TO-BE»

Бизнес-процесс «Оплата» включает в себя определение оплачиваемого лица (юридическое лицо, физическое лицо, оплата по ОМС). В зависимости от этого происходит создание различных листов оплаты. В частности при выборе юридического лица, нет возможности оплатить наличными средствами (в соответствии с  законодательством  РФ). Таким образом, для реализации поставленной задачи деятельность стоматологии была расписана до 3 уровня детализации. 

4.3. Архитектура данных разрабатываемого приложения

Проанализировав процессы бизнес-модели и необходимые требования к приложению, сделаем вывод о данных, которые будут храниться в базе. Эти данные распределим в таблице 3.1 по классам.

Таблица 4.3. Классы данных (до нормализации) 

Название класса

Поля данных
Пациент ФИО
Дата рождения
Паспортные данные (серия и номер)
Номер телефона
Пол
Анамнез Жалобы
Дата обращения
Сопутствующие заболевания и противопоказания Соп заболевания
Противопоказания
Карта зубов Зуб №1-№32
Состояние зуба Состояние
Проведенные процедуры
Использованные препараты
Необходимость дальнейшего лечения
Лечащий врач
Рентген снимки Дата снимка
Приложенный снимок
Услуги Название услуги
Цена
Специалисты ФИО
Специализация
Номер телефона

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

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

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

Данные находится во 2 НФ, если они соответствуют 1НФ и каждый атрибут полностью функционально зависит от первичного ключа. Для этого в каждый класс данных добавляем поле для записи первичного ключа, например, «Код пациента», «Код услуги», «Код специалиста» и т.д., а также добавляются соответствующие внешние ключи. Перейдём к 3 НФ.

Данные находится в 3 НФ, если оно соответствует 2 НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. Для выполнения последнего условия необходимо изменить структуру «карты зубов», так как «описание зуба» зависит от «пациента» через «номер зуба». В данной работе используется стандартная нумерация зубов, которая представляет  последовательное присвоение номера каждому зубу, начиная с верхней челюсти по часовой стрелке (рисунок 4.6). 

Нумерация зубов

Рис. 4.6. Нумерация зубов

В условиях данной практической работы «зубная карта» будет вестись без учёта аномалий количества зубов. Нумерации зубов одного пациента не отличается от нумерации другого пациента, хотя при этом сами зубы будут иметь различные описания. Для того, чтобы система могла различать каждый зуб, введём регистрацию отдельных лечений, т.е. каждый совершенный приём врача будет являться отдельной операцией над конкретным зубом у конкретного пациента. Тогда у класса данных «состояние зуба» ключевым полем станет «Код проведённого лечения» и он будет зависеть от «Кода пациента» и «Номера зуба». Тем самым, денные примут вид 3 НФ. Отобразим их в таблице 4.4 с указанием типов данных, размерности данных и ключевых полей (подчёркнутый текст в полях).

Таблица 4.4. Данные после нормализации 

Название класса

Поля данных

Тип данных

Размерность
Пациент Код пациента Числовой До 5 символов
Фамилия Краткий текст До 30 символов
Имя Краткий текст До 30 символов
Отчество Краткий текст До 30 символов
Дата рождения Дата и время До 10 символов
Паспортные данные (серия и номер) Числовой 10 символов
Номер телефона Числовой 11 символов
Пол Подстановка До 255 символов
Анамнез Код анамнеза Числовой До 5 символов
Код пациента Числовой До 5 символов
Жалобы Длинный текст До 64000 символов
Дата обращения Дата и время До 20 символов
Сопутствующие заболевания и противопоказания Код записи Числовой До 5 символов
Код пациента Числовой До 5 символов
Соп заболевания Текстовый До 255 символов
Противопоказания Текстовый До 255 символов
Состояние зуба Код проведённого лечения Числовой До 5 символов
Код пациента Числовой До 5 символов
Дата лечения Дата и время До 20 символов
Состояние Текстовый До 255 символов
Проведенные процедуры Длинный текст До 64000 символов
Использованные препараты Текстовый До 255 символов
Необходимость дальнейшего лечения Текстовый До 255 символов
Лечащий врач Подстановка До 255 символов
Рентген снимки Код снимка Числовой До 5 символов
Код пациента Числовой До 5 символов
Дата снимка Дата и время До 20 символов
Приложенный снимок Вложение До 255 символов
Услуги Код услуги Числовой До 5 символов
Название услуги Текстовый До 255 символов
Цена Числовой До 255 символов
Специалисты Код специалиста Числовой До 5 символов
ФИО Текстовый До 255 символов
Специализация Текстовый До 255 символов
Номер телефона Числовой 11 символов

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

 Архитектура данных

Рис. 4.7. Архитектура данных 

4.4. Проектирование интерфейсов  приложения

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

  • простота и наглядность рабочих окон;
  • отсутствие нагромождения кнопок и полей для ввода информации;
  • разделение функционала приложения по категориям.

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

 Начальный экран

Рис. 4.8. Начальный экран

Окно «Регистрация пациента»

Рис. 4.9. Окно «Регистрация пациента»

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

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

Окно «Работа с пациентом»

 Рис. 4.10. Окно «Работа с пациентом»

Отдельным функционалом приложения является работа с «зубной картой». Для поиска необходимого зуба пациента реализуется оконная форма «Поиск информации по зубу» (рисунок 4.11).

Окно «Поиск информации о зубе»

 Рис. 4.11. Окно «Поиск информации о зубе»

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

Окно «Все таблицы данных»

Рис. 4.12. Окно «Все таблицы данных»

Работа с данными, хранящимися в таблице, будет заключаться в поиске нужных записей, их просмотре и изменении. Например, будет требоваться такая работа с таблицами по специалистам и по услугам стоматологии. Для выполнения этих действий реализуются окна «Специалисты» (рисунок 4.13) и «Услуги» (рисунок 4.14).

 Окно «Услуги»

Рис. 4.13. Окно «Услуги»

 Окно «Специалисты»

Рис. 4.14. Окно «Специалисты»

Благодаря разработанному интерфейсу, приложение сможет быть доступным для  пользователя и обеспечит доступ к своему функционалу. Для наглядности и понимания, что будет отображаться на экране и какова последовательность открытия окон при различных нажатиях на кнопки, составлена схема приложения (рисунок 4.15.1 и 4.15.2).

 Схема приложения (часть 1)

Рис. 4.15.1. Схема приложения (часть 1)

 Схема приложения (часть 2)

Рис. 4.15.2. Схема приложения (часть 2)

Раздел 5. Реализация приложения 

5.1. Первый виток спирали (1 билд приложения)

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

На рисунке 5.1 представлен скриншот, демонстрирующий организованные таблицы с имеющимися в них атрибутами, а также связи между этими таблицами. На рисунке 5.2, для примера, изображена таблица «Пациенты».

Схема данных

Рис. 5.1. Схема данных

Таблица «Пациенты»

Рис. 5.2. Таблица «Пациенты» 

5.2. Второй виток спирали (2 билд приложения)

Таблицы Microsoft Access позволяют добавлять, удалять и редактировать хранящуюся в них информацию. Однако, это является неудобным для пользователя  когда есть необходимость внести лишь конкретную информацию о единичном пациенте или лечении. Для обеспечения удобного добавления информации создадим ряд форм, которые позволят добавлять данные в таблицу (рисунки 5.3 – 5.7).

Форма «Регистрация пациента»

Рис. 5.3. Форма «Регистрация пациента»

Форма «Добавление анамнеза»

Рис. 5.4. Форма «Добавление анамнеза»

Форма «Добавление информации о проведённом лечении»

Рис. 5.5. Форма «Добавление информации о проведённом лечении» 

5.3. Третий виток спирали (3 билд приложения)

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

Для поиска личной карточки организуется запрос (рисунок 5.6), в условиях отбора которого прописаны команды, предоставляющие возможность внести критерии отбора по отдельности (например, «Like «*» & [Введите код пациента] & «*»»). Данные команды позволяют вывести на экран диалоговое окно, в поле которого пользователь вводит интересующие его данные (рисунок 5.7). При необходимости поля могу быть оставлены пустыми, тогда выборка пройдёт без учёта этого критерия.

Запрос «Поиск пациента»

Рис. 5.6. Запрос «Поиск пациента»

Диалоговое окно для ввода параметра выборки «Фамилия»

Рис. 5.7. Диалоговое окно для ввода параметра выборки «Фамилия»

Аналогичным образом реализованы и другие выборки. Скриншоты, демонстрирующие конструкционную организацию остальных запросов, отображены на рисунках 5.8 – 5.12.

Запрос «Поиск анамнез»

Рис. 5.8. Запрос «Поиск анамнез»

Запрос «Поиск информации по зубу»

Рис. 5.9. Запрос «Поиск информации по зубу»

Запрос «Поиск специалиста»

Рис. 5.10. Запрос «Поиск специалиста»

Запрос «Поиск услуги»

Рис. 5.11. Запрос «Поиск услуги»

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

Интерфейс главного окна

Рис. 5.12. Интерфейс главного окна 

Форма «Зубная карта»

Рис. 5.13. Форма «Зубная карта»

«Зубная карта» имеет вид общей таблицы со всеми зубами, обслуживаемыми в стоматологии. Запрос на поиск необходимого зуба состоит из выбора пациента и номера необходимого зуба. Для удобства выборы этих критериев реализованы выпадающими списками на форме (рисунок 5.13).

Доступ управления данных о специалистах и услугах осуществляется через кнопочные формы, изображённые на рисунках 5.14 и 5.15 соответственно.

Форма «Услуги»

Рис. 5.14. Форма «Услуги» 

Форма «Специалисты»

Рис. 5.15. Форма «Специалисты» 

5.4. Четвертый виток спирали (4 билд приложения)

Отчёт «Услуги»

Рис. 5.16. Отчёт «Услуги»

Представление информации из таблиц выполним, используя инструмент «отчёты». В таком виде информация представляется нагляднее, не подлежит изменению и, при необходимости, может быть распечатана. На рисунках 5.16 – 5.19 изображены примеры скриншотов отчётов различных запросов.

Отчёт «Анамнез»

Рис. 5.17. Отчёт «Анамнез»

Отчёт «Поиск информации по зубу»

Рис. 5.18. Отчёт «Поиск информации по зубу»

Отчёт «Поиск специалиста»

Рис. 5.19. Отчёт «Поиск специалиста» 

Раздел 6. Тестирование приложения

После создания приложения проводится его тестирование,  для  выявления проблем в работе, исправление ошибок, а также проверку соответствия изначальных требований. Тестирование ПО проводится до передачи готового продукта заказчику. Условно виды тестирования можно подразделить на три группы [13]:

  • Функциональные.
  • Нефункциональные.
  • Связанные с изменениями.

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

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

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

6.1. Функциональное тестирование

В рамках функционального тестирования проведём два теста: на модульном уровне и на интеграционном уровне [7]. Модульное тестирование будет заключаться в постановке определённой задачи и проверке её надлежащего исполнения. Поставим задачи, охватывающие ключевой бизнес-процесс практической работы, после чего отразим пошаговые действия в приложении по их выполнению. Задача 1. Регистрация личной карточки пациента с известными данными:

  • ФИО – Измайлов Пётр Викторович.
  • Дата рождения – 17.05.1987.
  • Паспортные данные – 4617321123.
  • Номер телефона – 495345543.
  • Пол – муж.

Реализация задачи требует выполнения следующих шагов:

  • Открытие приложения (рисунок 6.1).

Главное окно

Рис. 6.1. Главное окно

  • После нажатия клавиши «Зарегистрировать пациента» открывается форма для внесения личных данных нового пациента. Заполняем поля (рисунок 6.2).

Занесение данных о пациенте

Рис. 6.2. Занесение данных о пациенте

  • После через главное форму ищем пациента через «Работу с пациентами» и заполняем поля «Фамилия» и «Имя» (рисунок 6.3).

Поиск пациента Измайлова Петра

Рис. 6.3. Поиск пациента Измайлова Петра

  • После нажатия кнопки «Вызов ЛК» была выведена информация по необходимому пациенту (рисунок 6.4).

Личная карточка необходимого пациента

Рис. 6.4. Личная карточка необходимого пациента

Задача 2. Занесение информации о проведённом лечении:

  • Пациент – Измайлов Пётр Викторович.
  • Дата лечения – 11.11.2018.
  • Номера зубов – 6,7.
  • Услуга – чистка, лечение кариеса.
  • Код специалиста – 2.
  • Использованные материалы – фреза, пломба.

Реализация задачи требует выполнения следующих шагов:

  • Открытие приложение с главным окном (рисунок 6.1) и последовательное нажатие кнопок: «Работа с пациентом» -> кнопка «Добавить», напротив кнопки «Зубная карта», (рисунок 6.5).

Окно «Работа с пациентом»

Рис. 6.5. Окно «Работа с пациентом»

  • В открывшееся окно добавления информации о проведённом лечении вносим данные (рисунок 6.6).

 Внесение данных о проведённом лечении

Рис. 6.6. Внесение данных о проведённом лечении

  • После добавления лечения найдём информацию по проведённому лечению зуба №7 пациента Измайлова. Откроем приложение с главным окном (рисунок 6.1) и последовательное нажатие кнопок: «Работа с пациентом», «Зубная карта». В открывшееся окно введем данные (рисунок 6.7).

Поиск данных по искомому зубу

Рис. 6.7. Поиск данных по искомому зубу

  • После нажатия кнопки поиска приложение вывело отчёт, содержащий информацию о необходимом зубе (рисунок 6.8).

Отчёт по искомому зубу

Рис. 6.8. Отчёт по искомому зубу

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

6.2. Нефункциональное тестирование

В нефункциональном тестировании выберем тест на производительность системы, а именно нагрузочный тест [7]. Данный тест позволяет проверить, как будет вести себя разработанное приложение при наличии различного числа хранящихся данных. Выбор обусловлен так же тем, что основной задачей программного обеспечения является поиск и выведение искомой информации из области хранения данных. Быстрота действия системы на прямую влияет на скорость обслуживание пациента. Основные действия программы – это запись и поиск информации (с выводом отчёта). Количество записей выбрано следующее: 1, 10, 100. Расчёт проводится по среднеквадратичному отклонению [14]. Для этого замеряются временные промежутки выполняющегося действия, а далее находится время отклика по среднему арифметическому по формуле (1), где tср – среднее время, ti – время одного замера, n – количество замеров. Полученные результаты занесём в таблицу 6.1.

                                                   (1)

Для расчёта среднеквадратичного отклонения необходимо рассчитать дисперсию, для чего воспользуемся формулой (2). (Рассчитанная дисперсия оказалась в 10-4 степени, что во много раз меньше секунды, поэтому примем   

                          (2)

Конечная погрешность рассчитывается по формуле (3), в которой «P» – доверительный коэффициент Стьюдента (примем его равным 0,95), а «A» — абсолютная погрешность секундомера, равная 0.005.

                             (3)

Итоговое значение времени отклика примет вид, обозначенный в формуле (4).

                                      (4)

Таблица 6.1. Результаты нагрузочного тестирования 

Количество записей

Действие

t1, c.

t2, c.

t3, c.

t4, c.

t5, c.

Дисперсия, с.

Время отклика, с.
1 Запись 0,11 0,13 0,10 0,10 0,11 0  0,088±0,005
Поиск 0,20 0,21 0,19 0,19 0,20 0  0,198±0,005
10 Запись 0,13 0,12 0,12 0,12 0,13 0  0,124±0,005
Поиск 0,10 0,12 0,11 0,14 0,11 0 0,116±0,005
100 Запись 0,13 0,11 0,14 0,11 0,12 0 0,122±0,005
Поиск 0,16 0,12 0,13 0,11 0,14 0 0,132±0,005

Нагрузочное тестирование прошло успешно, так как время выполнения команды является комфортным для восприятия информации. 

Раздел 7. Риски в проекте приложения

В спиралевидной модели, как уже было отмечено в разделе «Общее описание принципа спиралевидной модели», отдельное внимание уделяется рискам, возникающим во время проектирования, разработки, эксплуатации приложения. Словарь русского языка С.И. Ожегова и Н.Ю. Шведовой даёт следующее определения риска: риск – это возможность опасности, неудачи. В ходе разработки приложения возможно возникновение таких ситуаций и факторов, которые могут замедлить процесс разработки, усложнить его, повысить необходимость некоторых ресурсов или вовсе привести к отказу от выпуска продукта.

Для минимизации влияния со стороны возможного риска проводится управление риском. Управление риском содержит в себе шесть действий [16]:

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

Действия 1-3 относятся к этапу оценивания риска, действия 4-6 – к этапу контроля риска. Рассмотрим некоторые действия более детально. Идентификация риска позволяет определить список элементов рисков, который возможен в условиях данного проекта. Определяют проектный (связанный с ресурсами, формированием требований, форматом взаимодействия с заказчиком), технический (связанный с трудностями проектирования и реализацией программного обеспечения), коммерческий (связанный с рыночной оценкой и необходимостью программного обеспечения) источник рисков. Для более точного определения рисков используют проверочные списки рисков, которые содержат в себе наиболее часто встречающиеся известные риски.

Анализ риска заключает в себе оценку риска по формуле 5, где RE – показатель риска, P(UO) – вероятность неудовлетворительного результата, L(UO) – потеря при неудовлетворительном риске [16].

                    (5)

Вероятность риска определяют с помощью экспертного мнения или же учитывая имеющуюся статистику. После чего данные сводятся в таблицу (таблица 7.1).

Таблица 7.1. Пример таблицы данных оценки элементов риска 

Элемент риска

 Вероятность, %

Потери

Влияние риска
Наименование риска 5-7 8 20-40

Ранжирование риска позволяет присвоить каждому риску свой уровень приоритета, который пропорционален влиянию элемента на весь проект в целом.  Для этого создаётся шкала степени воздействия рисков на проект [17], в которой определяются теоретически возможные изменения в проекте (например, степени влияния «10» соответствует полному провалу проекта, «4» –  превышение сроков на 40% от ранее установленных, «1» –  отсутствие влияния на проект). Разрешение риска включает в себя три варианта действия с риском:

  • принятие риска (риск принимается и никакие действия не предпринимаются);
  • понижение риска (риск берётся во внимание, осуществляется поиск решения задачи по снижению уровня его влияние на проект, после чего предпринимаются действия для достижения цели снижения влияния);
  • передача третьей стороне (риск принимается во внимание, но дальнейшие действия с ним возлагаются на другое ответственное лицо).

 Заключение

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

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

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

Деятельности стоматологической клиники  была подвержена анализу и фиксации её бизнес-процессов посредством модели «AS-IS» с последующим её реинженирингом в модель «TO-BE». Модели описаны с использованием нотаций ARIS VACD для верхнего уровня и ARIS eEPC для нижних уровней детализации.

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

Список литературы

  1. Программы для стоматологий – URL: http://www.livemedical.ru/tools/dental/ (дата обращения 12.12.2018)
  2. Карпович Е.Е. Жизненный цикл программного обеспечения — М.:Центр дистанционного обучения. НИТУ «МИСиС», 2016 г. – 131 с.
  3. Кумагина, Е.А., Неймарк, Е.А. Модели жизненного цикла и технологии проектирования программного обеспечения: учебно-методическое пособие / Е.А. Кумагина, Е.А. Неймарк. – Нижний Новгород: Изд-во ННГУ, 2016. – 41 с.
  4. Михайловский Н.Э. Конференция «Теория и практика управления предприятием». Доклад «Сравнение методов оценки стоимости проектов по разработке информационных систем». Дата публикации 20.02.2003
  5. Гурендо Д. Жизненный цикл разработки ПО – URL: https://xbsoftware.ru/blog/zhiznennyj-tsykl-razrabotki-spiral/ (дата обращения 12.12.2018)
  6. Требования. Анализ требований, виды требований – URL: https://intellect.ml/trebovaniya-analiz-trebovanij-vidy-trebovanij-5188 (дата обращения 12.12.2018)
  7. Куликов, С. C. К90 Тестирование программного обеспечения. Базовый курс / С. С. Куликов. – Минск: Четыре четверти, 2017. – 312 с.
  8. Методы приоритезации – URL: https://habr.com/company/hygger/blog/359208/ (дата обращения 12.12.2018)
  9. Учитель Ю. Г. Разработка управленческих решений / Ю. Г. Учитель, А. И. Терновой, К. И. Терновой. – 2-е изд., перераб. и доп. – М., 2007. – 383 с.
  10. Ковалёв С.М., Ковалёв В.М. Статья «Современные методологии описания бизнес-процессов – просто о сложном» – URL: http://www.betec.ru/index.php?id=6&sid=33 (дата обращения 12.12.2018)
  11. «Введение в описание бизнес-процессов. Часть 2», статья от 21.07.2014 – URL: http://becmology.ru/blog/business/bp02.htm (дата обращения 12.12.2018)
  12. Степанов Д. Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень бизнес-процессов / МИРЭА. — М., 2017. – URL: https://stepanovd.com/training_erp_1-7_ru.pdf (дата обращения 12.12.2018)
  13. Виды тестирования программного обеспечения – URL: http://www.protesting.ru/testing/testtypes.html (дата обращения 12.12.2018)
  14. Степанова, Е. А. Основы обработки результатов измерений : [учеб. пособие] / Е. А. Степанова, Н. А. Скулкина, А. С. Волегов ; [под общ. ред. Е. А. Степановой] ; Мин-во образования и науки Рос. Федерации, Урал. федер. ун-т. – Екатеринбург: Изд-во Урал. ун-та, 2014. – 95 с.
  15. Варзунов А. В., Торосян Е. К., Сажнева Л. П., Анализ и управление бизнес-процессами // Учебное пособие. – СПб: Университет ИТМО, 2016. –112 с.
  16. Орлов С.А., Цилькер Б.Я., Технологии разработки программного обеспечения. Учебник для вузов. 4-е издание. Стандарт третьего поколения // Учебник для вузов. — Издательский дом «Питер», 2012. – 608 с.
  17. Галкин Г. Управление рисками. Часть 3. Качественный анализ рисков // Intelligent enterprise – 2005. – №15

Выходные данные

Худяков С.Д. Автоматизация ключевых бизнес-процессов стоматологической клиники с использованием спиралевидной модели внедрения: диплом бакалавра / МИРЭА. – М., 2019. – 75 с. – URL: https://stepanovd.com/training/20-vkr/101-vkrb-2019-9-khudyakov.

Источник

Понравилась статья? Поделить с друзьями:
  • Видеосъемка работников управляющей компании
  • Бизнес с чего начать современные идеи форум
  • Буторина 10 травмпункт детский время работы
  • Бизнес процессы зуботехнической лаборатории
  • Виды бланков документов состав их реквизиты