Жизненный цикл модели бизнес процесса

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

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

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

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

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

Платформа ELMA BPM обладает огромным количеством возможностей для управления бизнес-процессами, однако все функции системы легко могут быть поделены на четыре группы в соответствии со стадиями жизненного цикла (цикл Деминга) процесса PDCA (Plan, Do, Check, Act):

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

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

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

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

Рис. 1. Пример графической модели процесса

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

Что бы избежать путаницы бизнес-процесс, создаваемый в Дизайнере ELMA, называется моделью бизнес-процесса, бизнес-процессом или просто процессом. Запущенный в веб-приложении бизнес-процесс называется экземпляром бизнес-процесса или просто экземпляром процесса.

Основы маркетинга. Урок 3 из 10. Жизненный цикл товара

Источник: www.elma-bpm.ru

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

Эффективное управление бизнес-процессами предполагает адаптацию к изменяющимся условиям бизнеса, нормативным требованиям законодательства и давлению конкуренции, что привело к разработке систем управления бизнес-процессами полного цикла (Closed loop Business Process Management (BPM) systems) (рис. 5.15) [30]. [1]

Рис. 5.15. ВРМ-решение полного цикла

Жизненный цикл процесса состоит из следующих шагов или задач.

• 1. Моделирование процесса (Model the process) — во время этого шага владельцы бизнес-процессов создают высокоуровневую модель, состоящую из задач, которые должны выполняться, и нужных для этого ресурсов. Кроме того, делаются некоторые предположения о времени выполнения и стоимости каждой задачи;
• 2. Имитация и анализ (Simulate and Analyze) — полученная высокоуровневая модель используется для «прогона» некоторых гипотетических сценариев с целью обнаружения критических участков (paths) и «узких горлышек» (bottle necks). Полученная информация применяется для тонкой настройки процесса перед его развертыванием;
• 3. Внедрение и документирование (Implement and document) — во время этого шага высокоуровневый бизнес-процесс, точнее его описание высокого уровня, преобразуется в модель исполняемого процесса. Сам же процесс документируется для того, чтобы он мог использоваться для обучения и сопровождения в будущем;
• 4. Развертывание и исполнение (Deploy and Execute) — этот шаг включает развертывание процесса для ВРМ-«движка» (BPM-engine) и его исполнение для реализации сквозных (endtoend) потоков [управления и данных] между системами и людьми;
• 5. Мониторинг (Monitor) — во время этого шага происходит мониторинг бизнес-процессов с целью получения ключевых индикаторов эффективности и других метрик. Это шаг выполняется, как правило, с применением средства мониторинга бизнес-активности (Business Activity monitoring tool) совместно с ВРМ-«движком»;
• 6. Оптимизация и перепроектирование ( Optimize and Redesign) — после того как над системой в течение некоторого времени проведен мониторинг, полученные за это время метрики (historical metrics) могут быть использованы для дальнейшей оптимизации процесса. Реальная пропускная способность процесса и метрики использования могут быть введены в инструмент имитации, чтобы получить оптимальную исполнительную модель.

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

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

Кривая жизненного цикла системы отображает взаимодействие S-образной кривой и конкурентной позиции производимых товаров на рынке — по аналогии с моделью ADL/LG. Все многообразие состояний бизнес-процессов предприятия можно представить матрицей, где по строкам отражается конкурентная позиция товара на рынке (результаты маркетинговых исследований), а по столбцам — стадия развития бизнес-процессов в соответствии с кривой жизненного цикла (рис. 5.16).

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

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

Рис. 5.16. Матрица показателей, характеризующих бизнес-процессы

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

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

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

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

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

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

Источник: bstudy.net

Жизненный цикл модели бизнес процесса

Студентам > Дипломные работы > Применение спиралевидной модели внедрения информационных систем в городской поликлинике

Применение спиралевидной модели внедрения информационных систем в городской поликлинике

Аннотация: в работе реализуется программа в среде MS FoxPro для автоматизации работы городской больницы на основе спиралевидной модели внедрения информационных систем. Выполняется идентификация требований, их приоритизация и разбиение на циклы разработки. Выявленные ключевые бизнес-процессы городской больницы моделируются в нотациях IDEF0 и DFD с разным уровнем детализации, кроме того, ведется проектирование архитектуры данных. Смоделированные процессы и данные городской больницы разрабатываются в среде MS FoxPro в разрезе ранее определенных циклов (витков спирали). Проводится функциональное и интеграционное тестирование реализованного приложения.
Скачать: PDF, PPT.
Ключевые слова: спиральная модель жизненного цикла, спиральная модель жизненного цикла программного обеспечения, спиральная модель жизненного цикла программного продукта, модели жизненного цикла аис, модели жизненного цикла информационных систем, модели жизненного цикла программного обеспечения, v образная модель жизненного цикла, эволюционная модель жизненного цикла, прототипная модель жизненного цикла, сравнительный анализ моделей жизненного цикла, IDEF0 декомпозиция пример, DFD диаграмма, методы обследования пациента, спиральная модель жизненного цикла пример, spiral model, база данных пациенты, база данных пациентов поликлиники, база данных анамнеза, сбор жалоб и анамнеза прием больных, база данных протокол осмотра пациента.

Введение

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

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

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

Поэтому будет целесообразно некоторым образом автоматизировать деятельность поликлиник. Этого можно достигнуть за счет разработки приложения с помощью систем управления базами данных (СУБД), например, MS FoxPro. Разрабатываемая программа упростит процесс обработки информации, сделает его куда более быстрым и удобным; приложение совместимо с операционной системой Microsoft Windows, которая используется на большинстве компьютеров медицинских учреждений. Кроме того, с программой могут работать пользователи без специальных знаний, навыков и подготовки.

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

• учтены не все аспекты деятельности поликлиник;
• сложность в освоении;
• неудобство в эксплуатации.

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

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

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

Раздел 1. Спиралевидная модель внедрения программных продуктов

1.1. Понятие жизненного цикла и его модели

Информационные системы (ИС) должны удовлетворять интересам бизнеса, а также быть легко модифицируемыми и недорогими. Плохо спроектированная система, в конечном счете, требует больших затрат и времени для ее содержания и обновления. Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). Жизненный цикл (Life Cycle) определяется как развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. Модель жизненного цикла (Life Cycle Model) – структура процессов и действий, связанных с жизненным циклом, организуемых в стадии, которые также служат в качестве общей ссылки для установления связей и взаимопонимания сторон [3].

1.2. Спиралевидная модель и ее особенности

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

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

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

Рис. 1.1. Спиралевидная модель: 1 – начальный сбор требований проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – планирование проекта и анализ риска с использованием начальных требований; 4 – планирование и анализ риска реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – версия системы следующего уровня; 8 – разработанная система; 9 – оценивание заказчиком

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

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

Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Барри Боэм – автор модели – в своей работе [7] формулирует десять наиболее распространённых (по приоритетам) рисков:

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

Достоинства спиральной модели:

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

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

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

2.1. Этапы сбора и анализа требований

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

• определение концепции продукта;
• сбор требований;
• анализ требований;
• проектирование системы.

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

На этапе сбора требований основная работа ведется с заказчиком системы и ее будущими пользователями. Цель этапа — точно определить функции продукта и способы его интеграции в существующие процессы. Качественное выполнение работ на этом этапе гарантирует то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет и сроки [9].

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

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

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

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

2.2. Результаты сбора и анализа требований

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

• Хранение данных различных категорий:

• пациенты;
• врачи (персонал);
• запись на прием;
• анамнез пациентов.

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

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

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

• Must have (обязательные) – требования с наибольшим приоритетом, без выполнения которых релиз продукта невозможен;
• Should have (желательные) – высокоприоритетные требования, которые критичны для функционала;
• Could have (возможные) – требования, которые можно включить в текущий релиз, но которые не влияют существенно на его успех;
• Won’t have (отсутствующие) – требования, которые не являются необходимыми в текущем релизе, но которые можно включить в следующие [9].

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

• Требование 1 – Must have. Это требование является основой всей разрабатываемой программы, и без его выполнения нельзя говорить о релизе продукта.
• Требование 2 – Should have. В среде MS FoxPro возможна работа с записями (создание, редактирование, удаление, поиск, сортировка) посредством панели управления самой программы, т.е. нет прямой необходимости реализации данного требования. Вместе с тем, его реализация значительно упрощает интерфейс, вследствие чего работать с программой может любой пользователь без специальной подготовки.
• Требования 3-6 – Could have. Требования не являются ключевыми для полноценного функционирования самой программы, но их было бы неплохо включить в текущий релиз.

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

• Таблицы, содержащие данные различных категорий:

• данные о пациентах – таблица «Пациенты»;
• данные о врачах и работниках регистратуры – таблица «Персонал»;
• данные о записи на прием – таблица «Запись на прием»;
• анамнез пациентов – таблица «Анамнез»;

• создание записей;
• редактирование записей;
• просмотр записей без изменения (для таблиц «Пациенты» «Анамнез»);
• удаление записей;
• отбор записей по ключевым параметрам;
• сортировка записей по возрастанию/убыванию (в прямом/обратном алфавитном порядке) параметров.

2.3. Список требований

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

Источник: stepanovd.com