Существует три основных подхода к моделированию бизнес -систем: процессный, системный (структурно-функциональный) и ситуационный. Выбор подхода моделирования бизнес- системы определяет алгоритм (последовательность) и этапы ее моделирования.
Поскольку в соответствии с известными типами управления стратегическое изменение бизнес-системы относится к проектному управлению, при любых подходах к моделированию оно рассматривается как стадия общего проекта по реорганизации (реинжинирингу) бизнес-системы. Это влечет за собой включение данного проекта в обязательный перечень проектов проектного офиса бизнес-системы.
Процессный подход основан на понимании бизнес-системы как совокупности бизнес-процессов и в технологии моделирования различается методами. В первом случае процессное моделирование происходит от общего к частному, во втором — от частного к общему.
Ситуационный подход к моделированию отталкивается от неотвратимости ситуации изменения бизнес-системы.
Стандартный алгоритм (последовательность) процессного моделирования включает следующие этапы:
Решаемые задачи и преимущества системы бизнес-моделирования Бизнес-инженер
- 1) подготовительный;
- 2) моделирование и анализ бизнес-системы «как есть»;
- 3) моделирование бизнес-системы «как должно быть»;
- 4) подготовка проекта по изменению процессов, организационной структуры, системы управления организацией, инфраструктуры.
На первом (подготовительном) этапе проводятся следующие обязательные мероприятия:
- • выявление отклонений от целевых параметров бизнес- системы и диагностика патологий бизнес-системы;
- • определение основных и вспомогательных бизнес-процессов (дерева процессов);
- • стратификация целей проекта;
- • выбор (разработка) и утверждение методики реорганизации, реинжиниринга бизнес-системы, включая методику моделирования бизнес-процессов, структуру регламента выполнения бизнес-процесса и другие документы;
- • выбор необходимого инструментального обеспечения реинжиниринга;
- • формирование проектной группы ремоделирования и реинжиниринга;
- • методическая подготовка: обучение руководителей и специалистов, организации;
- • программирование персонала к системным инновациям;
- • формирование плана-графика проектных работ.
Основным итогом подготовительного этапа является создание проектной группы ремоделирования. Второй важнейший результат этапа — утвержденный регламент реинжиниринга бизнес-процессов.
На втором этапе проекта выполняется моделирование бизнес-процессов «как есть». Этап включает следующие мероприятия:
- • создание моделей организационной структуры;
- • создание вспомогательных моделей (деревья функций, документов, материальных ресурсов и т. д.);
- • разработка моделей бизнес-процессов верхнего уровня;
- • проверка адекватности моделей верхнего уровня;
- • разработка моделей детальных бизнес-процессов (несколько уровней декомпозиции);
- • проверка адекватности детальных моделей;
- • создание моделей документов, данных и т. д.;
- • проведение анализа моделей.
- • формирование отчетов.
Основным результатом второго этапа являются модели бизнес-процессов, построенные в соответствии с требованиями организации, и данные анализа этих моделей. Полученные модели процессов используются для дальнейшей работы по созданию регламентирующих документов и реорганизации бизнес- процессов.
Урок 1 BPMN 2.0 Введение: Как моделировать бизнес процессы для разработки ИТ систем? 18+
Третий этап предназначен для построения моделей бизнес- процессов «как должно быть». На этом этапе должны быть сформированы новые варианты моделей бизнес-процессов. Формировать новые варианты непросто. Как правило, это требует продолжительного времени, что связано с анализом процессов, выявлением дублирования, патологий (в том числе с помощью средств имитационного и сценарного моделирования).
Выбор модели «как должно быть» различается и с точки зрения подходов: 1) от общего к частному — проектная группа отталкивается от уже готовой модели, полученной как расчетным путем, так и с помощью бенчмаркинга; 2) от частного к общему — идеальная модель формируется путем выбраковки и оптимизации действующих процессов. При этом подходе проектная группа выбирает приоритетные направления реинжиниринга процессов, дифференцирует процессы на эффективные и неэффективные, находит способы повышения эффективности действующих процессов, которые не будут подвергаться реорганизации, составляет варианты реорганизации.
Четвертый этап заключается в конкретизации мероприятий по срокам и ответственным в виде плана-графика. В соответствии с правилами проектного управления составляется расписание по ресурсам, срокам, ограничениям. В некоторых случаях идет документационная подготовка процессных изменений: составляются новые регламенты процессной структуры бизнес- системы (положения о структурных единицах либо центрах ответственности, должностные инструкции, новая система KPI, бланки отчетов владельцев процессов и т. д.).
Системный (структурно-функциональный) подход моделирования бизнес-систем компании включает в себя следующий алгоритм и этапы моделирования:
- 1) системный анализ ресурсов бизнес-системы (финансовые, имущественные, человеческие, интеллектуальные);
- 2) определение перспективного продуктового портфеля во взаимоувязке с имеющимися активами и ресурсами;
- 3) выбор стратегической (включая маркетинговую) альтернативы и комплекса методов продвижения продуктового портфеля на выбранных рыночных сегментах;
- 4) моделирование цепочки создания ценности каждого вида, входящего в продуктовый портфель, включая описание всех ключевых элементов цепочки создания стоимости (см. параграф 2.2).
В основе системного (структурно-функционального) подхода лежит принцип «от общего к частному». Вначале идет макропроектирование основных стратегических элементов бизнес-системы во взаимосвязи (в стандарте SMART- технологии с выделением функции related), затем начинается проектирование отдельных стратегических элементов бизнес- системы, и наконец — микропроектирование на уровне процессной структуры.
Разделяя процессный и системный подход (в транскрипции ряда авторов — структурно-функциональный), тем не менее стоит помнить о том, что разделение носит формально-условный характер. На практике оба подхода применяются зачастую параллельно в отношении одного и того же объекта моделирования в разных пропорциях, что отмечает ряд авторов. Зачастую «процессный подход — это дополнение к структурно-функциональному подходу при организационном моделировании (оптимизации) бизнес-систем. Не нужно противопоставлять друг другу эти подходы, наоборот, следует объединять их в рамках общего системного подхода в управлении» [1] .
Третьим подходом к моделированию является ситуационный подход, в котором краеугольным является понятие бифуркации. Несмотря на то, что авторы используют его применительно к организационному проектированию бизнес-систем, очевидно, что в точке бифуркации изменяются все ключевые параметры бизнес-системы, а не только организационная структура.
Поэтому, воспользовавшись данным концептуальным подходом, в соответствии с общей логикой изменения будем переносить этот подход на все ключевые факторы бизнес-системы. Графическое изображение алгоритма (последовательности) и этапов моделирования бизнес-систем в соответствии с ситуационным (бифуркационным) подходом разработано Е. С. Гребенкиной (рис. 8.2). Так, она обращает внимание на тот факт, что «в ходе эволюционного развития предпринимательских бизнес-систем неизбежно наступают периоды, когда система “перерастает” рамки того состояния, которое считалось приемлемым для бизнес-системы в определенных условиях, поскольку обеспечивало системе необходимый баланс, поддерживающий ее устойчивое равновесие. И здесь возникает необходимость разработки алгоритма, не позволяющего допустить структурной деформации бизнес-системы, приводящей к прекращению ее существования» 1 .
Гребенкина Е. С. Аспекты разработки алгоритма диверсификации организационной структуры предпринимательских бизнес-систем // Управление экономическими системами. Электронный научный журнал. УЭкС. 2013. URL: http://www.uecs.ru/ logistika/ item/2384-2013-10-01-07-14-58.
Рис. 8.2. Бифуркационный алгоритм моделирования бизнес-системы
Указанные подходы к моделированию и алгоритму моделирования бизнес-систем равноприменимы на практике. Преимущества и недостатки всех вышеприведенных подходов приведены в табл. 8.1.
Таблица 8.7
Преимущества и недостатки подходов к моделированию
Источник: studme.org
Хронологически правильна последовательность приоритетов бизнес моделирования
Плюсы и минусы подхода
| Плюсы | Минусы |
| Простая в использовании модель. | С этой моделью слишком сложно и дорого адаптироваться к изменениям требований. |
| Каждый этап хорошо задокументирован. | Документирование каждой фазы проекта занимает много времени. |
| Результат проекта абсолютно предсказуем. | Вы не можете ничего предоставить заказчику, пока не завершите весь проект. |
| Этапы и роли четко определены с самого начала. | Различные команды (дизайн, разработка, контроль качества и т. д.) изолированы, а взаимодействие между ними ограничено. |
| Минимальное вмешательство клиента. | Без обратной связи клиента результат рискует не оправдать ожидания. |
Каким проектам подходит
Каскадная модель – хороший вариант, если выполняются эти условия:
- Проект короткий и с нулевым риском.
- Требования фиксированные.
- Технологии стабильны.
- Доступны все необходимые ресурсы.
Всего десять лет назад многие компании использовали каскадную модель для разработки корпоративного программного обеспечения, включая CRM, системы управления цепочками поставок и системы точек продаж. Но сегодня эта модель не может удовлетворить быстро меняющиеся технические потребности. Вот почему компании все чаще обращаются к более современным подходам.
V-образная модель SDLC
V-образная модель – это своего рода другая версия каскада, но в её основе лежит контроль качества каждой фазы. Например, когда группа разработчиков собирает требования к проекту, QA-специалисты пишут приемочные тесты на основе этих сценариев. Точно так же на этапе проектирования системы создаются сценарии тестирования и так далее. После написания кода команда QA проверяет продукт на соответствие заранее написанным тестам (правая часть буквы «V»).
| Плюсы | Минусы |
| Легко реализовывать. | В V-образной модели внести изменения в середине проекта крайне сложно. |
| Тест-кейсы создаются заранее. | При таком большом количестве процедур тестирования остается меньше времени на код. |
| Бюджет и продолжительность проекта предсказуемы. | По сравнению с каскадной эта модель требует больше специалистов. |
| У каждого этапа есть свои результаты, и все хорошо задокументировано. | Модель не подходит для проектов с быстро меняющимися требованиями. |
| Это структурированный подход с четко определенными ролями и функциями. | Не подходит для больших и сложных проектов. |
Каким проектам подходит
V-образная модель может быть чрезвычайно полезна в случаях, когда ошибки могут быть фатальными, и в проектах, где точность имеет решающее значение. Например, это решение, основанное на нормативных требованиях, таких как подача налоговых деклараций. Кроме того, эта модель подходит для проектов в сфере здравоохранения. Например, компания Roche Diagnostics однажды использовала его для разработки системы диагностики рака.
Модель эволюционного прототипирования
Это ещё одна вариация каскада. Пока проект проходит через традиционные фазы, прототип продукта пошагово дорабатывается на основе отзывов клиентов. Как правило, первый прототип не проходит приемочный тест, поэтому модель прототипирования включает в себя несколько прототипов. Только после того, как предложенный дизайн продукта будет полностью принят, команда разработчиков сможет перейти к следующим этапам.
| Плюсы | Минусы |
| Получение отзывов пользователей на ранних этапах. | Поскольку прототипы могут развиваться бесконечно, планирование проекта невозможно. |
| Высокие шансы на успех проекта. | Разрабатывать несколько прототипов – дорого. |
| Легко адаптироваться к быстро меняющимся требованиям. |
Каким проектам подходит
Модель эволюционного прототипирования может быть полезна для проектов, которые предполагают взаимодействие с пользователем, используют новые технологии, имеют сложную функциональность или должны учитывать быстро меняющиеся требования, которые трудно или невозможно предсказать.
Итеративная и инкрементальная модель
В инкрементальной и итеративной модели решение разрабатывается небольшими частями через серию циклов. Рабочий процесс выглядит следующим образом:
- Планирование. Собираются все требования к проекту и делятся на составляющие.
- Реализация модулей. Каждая итерация представляет собой «мини-каскад», который имеет такой же процесс: анализ требований модуля, проектирование, реализация и тестирование модулей, интеграция и тестирование всей системы, выпуск версии и оценка. Процесс повторяется до тех пор, пока не будут выполнены все требования.
| Плюсы | Минусы |
| Модель инкрементальной и итеративной разработки обеспечивает быструю и регулярную «доставку» работающего программного обеспечения клиентам. | Во время интеграции модуля могут возникнуть архитектурные проблемы. |
| Легче и дешевле учесть изменения в требованиях проекта. | Несмотря на некоторую гибкость, систему следует планировать с самого начала; в противном случае его нельзя разделить на модули. |
| Обратная связь от клиента на ранней стадии. | Участие клиентов может быть проблематичным. |
| Небольшие части программного обеспечения легче тестировать и исправлять. | Не всегда можно разбить систему на сегменты. |
| Экономия на издержках. | Хотя выпуск одного модуля дешевле, общие затраты на систему будут увеличиваться по мере интеграции новых модулей. |
Каким проектам подходит
Модель будет эффективна в следующих случаях:
- Если система состоит из нескольких сегментов с чёткими требованиями.
- Ограниченные ресурсы на проекте или есть ограничения по времени выхода решения на рынок.
- Для стартапов, проходящих инвестиционные раунды.
- Масштабные проекты.
- Проекты, в основе которых новые технологии.
- Проекты, которые потребуется развивать после выпуска.
По словам Алистера Скотта , каждый программный продукт, который хочет оставаться конкурентным на рынке, требует наращивания мощностей. Даже если вы будете использовать каскадную модель для разработки своего решения, к моменту завершения цикла решение уже устареет. Поэтому необходимы дополнительные итерации.
Спиральная модель
Этот подход основан на оценке риска, он сочетает в себе функции каскадной, прототипной, итеративной и инкрементной моделей. Модель похожа на спираль с несколькими кругами. Каждый круг – это фаза, состоящая из четырёх элементов:
- Сбор требований. Он включает выявление и анализ потребностей заинтересованных сторон и бизнес-целей.
- Анализ рисков и прототипирование. Команда оценивает все возможные способы удовлетворения потребностей клиентов и выбирает лучшее решение. Затем они выявляют и устраняют риски, связанные с решением, и создают прототип, который развивается с каждым последующим циклом.
- Инжиниринг. Команда инженеров продолжает разработку и тестирование того, что было запланировано на двух предыдущих этапах.
- Планирование следующего этапа. Готовый продукт отправляется заказчику для получения обратной связи. Кроме того, команда разработчиков анализирует весь цикл с точки зрения расписания, бюджета и других критериев.
Затем, на основе отзывов пользователей и заинтересованных сторон, планируется следующая итерация.
Как видите, продукт неоднократно проходит через эти этапы, и в конце каждого цикла создаётся и выпускается лучшая версия продукта. И, как и в итеративном подходе, продукт состоит из серии релизов.
| Плюсы | Минусы |
| Анализ рисков на каждой итерации увеличивает шансы проекта на успех. | Требуется опыт управления рисками. |
| Этот метод позволяет создавать стабильные и надёжные системы, поскольку они тщательно тестируются в каждом цикле. | Модель подразумевает работу с большим объёмом документации. |
| Можно менять требования между циклами. | Нельзя изменить требования в середине цикла. |
| Раннее вовлечение разработчиков помогает согласовать бизнес-требования и технические возможности. | Каждый кружок в спирали развития представляет собой «мини-каскад», а это значит, что вы не можете пропускать фазы. |
| Частые выпуски позволяют получать регулярную обратную связь от клиентов даже на ранних этапах цикла. | Поскольку ограничений на количество итераций нет, сложно предсказать, сколько кругов потребуется для создания окончательной версии продукта. |
Каким проектам подходит
Спиральная модель подходит для:
- Больших, сложных продуктов, состоящих из нескольких компонентов.
- Проектов с частыми релизами.
- Проектов средней и высокой степени риска.
- Проектов с неясными требованиями.
Microsoft, IBM и Tata Consultancy используют спиральную модель.
Модели гибкой разработки программного обеспечения
Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:
- Люди и взаимодействие важнее процессов и инструментов.
- Рабочее программное обеспечение над обширной документацией.
- Сотрудничество с клиентами вместо переговоров по контракту.
- Реагирование на изменения вместо следования плану.
Ценности Agile породили более 50 методологий , из которых Scrum является самой популярной .
Scrum
Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:
- Планирование спринта , когда заинтересованные стороны проекта и команда разработчиков встречаются, чтобы обсудить, что нужно сделать во время следующего спринта.
- Обзор спринта , когда команда разработчиков демонстрирует заинтересованным сторонам, что было сделано во время спринта, и анализируется прогресс в достижении цели проекта.
- Ретроспектива спринта , когда команда разработчиков анализирует спринт и обсуждает, как можно улучшить процессы во время следующих спринтов.
Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.
Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.
| Плюсы | Минусы |
| Не нужно ждать завершения проекта, чтобы внедрить основные функции продукта. | Гибкие методологии разработки ПО сложно внедрить. |
| Кросс-функциональные команды регулярно общаются и обмениваются знаниями между собой и владельцами проектов. | В Agile проектная документация очень быстро устаревает, поэтому понадобятся дополнительные навыки оперативной работы с ней. |
| Возможность адаптироваться к изменениям на любой стадии проекта. | В Agile проектах практически невозможно делать прогнозы и достаточно тяжело с высокой долей точности планировать бюджет. |
| Регулярная обратная связь от пользователей, что позволяет удовлетворить все потребности. | Сбор отзывов пользователей может быть сложной задачей. |
Примеры использования
Большинство современных проектов требуют определённого уровня «маневренности», особенно когда:
- Требования к проекту недостаточно ясны.
- Требования к проекту постоянно меняются.
- Проект включает в себя множество взаимодействий с пользователем.
- У проекта много заинтересованных сторон.
В общем, Agile кажется именно тем, что нужно большинству проектов во времена неопределённости. Неудивительно, что более 70% компаний применяют Agile , включая Microsoft, IBM, Procter https://proglib.io/p/sdlc-modeli-kak-vybrat-pravilnyy-podhod-k-razrabotke-i-ne-zavalit-proekt-2021-05-15″ target=»_blank»]proglib.io[/mask_link]
Этапы в истории моделирования и управления бизнес-процессами
Начало первого этапа относят к 1920-м гг. XX в. и связывают с именем Фредерика Тейлора и его книгой «Принципы научного управления». В этот период впервые была осознана необходимость исследовать бизнес-процессы, описывать их в различных документах и действовать в соответствии с этими описаниями. Описание бизнес-процессов производится в текстовом, табличном и графическом виде, причем последний все более формализуется.
В период «первой волны» для моделирования бизнес-процессов используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Блок-схемы на основе определенной в ГОСТ 19.701-90 нотации схем алгоритмов, программ, данных и систем (в англ. литературе — ANSI flowcharts) остаются и сегодня простейшим, но практически важным формальным графическим языком моделирования бизнес-процессов. Блок-схемы позволяют быстро и наглядно показать шаги бизнес-процесса в понятной каждому форме, однако их нотация не предусматривает формализованного описания многих деталей процесса, в частности исполнителей бизнес-функций.
Начало второго этапа ознаменовал выход книги М. Хаммера и Д. Чампи -Реинжиниринг корпорации: манифест революции в бизнесе», которая возродила в управленческой среде интерес к описанию и анализу бизнес-процессов с целью их радикальной перестройки — реинжиниринга. Реинжиниринг бизнес-процессов предполагает построение двух моделей бизнес-процесса: как есть (англ. as is) и как должно быть (англ. to be), а затем внедрение последней на предприятии.
Идея методологий и инструментов моделирования третьего поколения состоит в том, чтобы позволить руководству и сотрудникам компании создавать и самим внедрять новые процессы «на лету». Автоматизация процессов производится посредством так называемых систем управления бизнес-процессами BPMS (Business Process Management System), которые дают возможность непосредственно реализовывать бизнес-процессы в соответствии с построенной формальной моделью и не требуют разработки дополнительного программного обеспечения.
Основой методологий IDEF0 и IDEF3, широко используемых в настоящее время для моделирования бизнес-процессов, явились методология SADT и алгоритмические языки, использовавшиеся для разработкимпрограммного обеспечения. методология SADT была разработана частной американской корпорацией и затем в рамках программы Министерства обороны США была преобразована в методологию IDEF0, утвержденную как федеральный стандарт США. Появление методологии IDEF0 было предопределено тенденциями развития вычислительных средств – мощных машин (Mainframe) и появлением подходов MRP.
Планирование материальных ресурсов для обеспечения производства (подход MRP) требовал выполнения сложных, многовариантных расчетов по обеспечению организации материальными ресурсами для производства готовой продукции. Использование подхода MRP, попытки автоматизации производства при помощи вычислительных машин привели к необходимости описывать деятельность организаций еще на стадии проектирования систем.
Кроме того, задачи создания сложных систем управления (в том числе военного назначения) требовали соответствующих инструментов разработки. Необходимость создания методолгий моделирования процессов была обусловлена практической необходимостью. Для моделирования деятельности организаций на верхнем уровне использовалась методология SADT, затем IDEF0. С начала 70-х годов ничего принципиально лучшего, чем IDEF0 для описания процессов на верхнем уровне не было предложено. Исключение составляет подход UML (Unified Modeling Language – универсальный язык моделирования), но он предназначен для моделировния работы объектно-ориентированного программного обеспечения, а не бизнес-процессов организации.
После появления персональных компьютеров стали разрабатываться различные инструментальные средства (программные продукты) для моделирования бизнес-процессов. Кроме средств моделирования процессов, активно развивалось направление моделирования данных. Появлялись программные средства, в основном ориентированные на разработку моделей данных организаций и настройку промышленных баз данных. такие программные продукты получили название CASE-систем. Среди наиболее известных продуктов для моделирования бизнес-процессов можно назвать Design/IDEF, BPWin, CASE-аналитик (в России), Silverrun, Designer-2000 и т.д.
В настоящее время на рынке присутствуют несколько методолгий. Часть из них основана на государственных стандартах, часть – на корпоративных разработках компаний, часть – выдвинута отдельными авторами. Классификация существуюших методологий по трем категориям:
1. Методологии ведения проекта;
2. Методологии моделирования и анализа бизнес-процессов;
3. Методологии использования программных продуктов для моделирования бизнес-процессов в проекте.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru