Применение процессного подхода для оптимизации бизнес-процессов (Бизнес-процессы)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

Задачи курсовой работы:

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

1 ОСНОВНЫЕ ПОНЯТИЯ ПРОЦЕССНОГО ПОДХОДА

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

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

Согласно версии Европейской ассоциации BPM управление бизнес-процессами определяется следующим образом:

«Управление бизнес-процессами (BPM) представляет собой системный подход для отражения, проектирования, выполнения, документирования, измерения, мониторинга и контроля как автоматизированных, так и неавтоматизированных процессов, для достижения целей и бизнес-стратегий компании. BPM охватывает осознанное, всеобъемлющее и все более технологичное определение, совершенствование, инновации и поддержание сквозных процессов. Благодаря этому системному и сознательному управлению процессами компании добиваются лучших результатов быстрее и гибче».[21]

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

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

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

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

Графическое изображение бизнес-процесса представлено на рисунке 1.

Рисунок 1 – Графическое представление бизнес-процесса

Специалисты выделяют следующие виды бизнес-процессы в зависимости от их назначения:

• процессы развития;
• процессы управления
• обеспечивающие процессы;
• основные процессы.[17]

На рисунке 2 представлена классификация бизнес-процессов в зависимости от их назначения.

Рисунок 2 - Виды бизнес-процессов

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

Рисунок 3 – Взаимосвязь бизнес-процессов

Назначение разных типов бизнес-процессов представлено на рисунке 4.

Рисунок 4 - Назначение разных типов бизнес-процессов

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

Примеры отображения бизнес-процессов в наиболее популярных графических нотациях представлены на рисунках 5 – 8.

Для описания бизнес-процессов используются различные нотации (наборы правил):

• семейство IDEF0 (рисунок 3);
• BPMN 2.0 (рисунок 4);
• eEPC (рисунок 5) и другие нотации.

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

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

Рисунок 5 – Представление бизнес-процесса в нотации BPMN

Рисунок 6 - Представление бизнес-процесса в нотации DFD

Рисунок 7 - Представление бизнес-процесса в нотации IDEF0

Рисунок 8 - Представление бизнес-процесса в нотации eEPC

1.2 Жизненный цикл информационной системы

Технология в узком смысле понятия – это определенный технологический подход.

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

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

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

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

Рисунок 9 – Управление жизненным циклом изделия

Технологии базируются на понятии жизненного цикла.

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

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

• анализ и планирование;
• проектирование;
• разработка;
• тестирование;
• документирование;
• эксплуатация/сопровождение.

Основные фазы жизненного цикла программного продукта представлены на рисунке 10.

Рисунок 10 – Основные фазы жизненного цикла программного продукта

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

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

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

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

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

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

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

Процессом называется совокупность связанных между собой действий проекта, которые преобразуют заданные входные данные в выходные. [14]

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

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

Рисунок 11 – Иерархия понятий

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

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

• каскадная модель;
• поэтапная модель с промежуточным контролем;
• спиральная модель;
• инкрементная модель.[2]

1.3 Каскадная модель жизненного цикла программного средства

Каскадная модель жизненного цикла программного обеспечения была предложена в 1970 году экспертом в области программной разработки Уинстон Ройсом. В опубликованной статье, получившей широкую известность, он изложил свое мнение о методике, которая позже получила название «модель водопада» (waterfall model), или «каскадная модель».

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

Принцип модели основан на однократном осуществлении процессов в форме заблаговременно ограниченных и однозначно упорядоченных во времени стадий, осуществляемых в их естественных границах.[13]

Схема, иллюстрирующая каскадную модель, представлена на рисунке 12.

Рисунок 12 – Классическая каскадная модель

Позже каскадная модель неоднократно регламентировалась множеством разнообразных нормативных актов, в например, известным стандартом Министерства обороны и российскими стандартами серии ГОСТ 34.

Обязательными качествами классической каскадной модели являются:

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

Отмечают следующие преимущества использования каскадной модели:

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

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

Отмечают и другие недостатками каскадного подхода:

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

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

Позже появилась усовершенствованная модифицированная каскадная модель (рисунок 13).

Рисунок 13 – Модифицированная каскадная модель

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

1.4 Поэтапная модель с промежуточным контролем

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

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

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

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

Поэтапная модель с промежуточным контролем вошла в практику с 1987 года.

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

Поэтапная модель с промежуточным контролем представлена на рисунке 14.

Рисунок 14 - Поэтапная модель с промежуточным контролем

1.5 Спиральная модель жизненного цикла программного средства

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

В середине восьмидесятых годов двадцатого века инженером Барри Боэмом был предложен собственный вариант итерационной модели. Эту модель назвали спиральной моделью жизненного цикла программного средства.[22]

Спиральная модель в упрощенном виде представлена на рисунке 15.

Рисунок 15 – Спиральная модель в упрошенной форме

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

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

Рисунок 16 – Классическая спиральная модель жизненного цикла программных средств

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

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

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

Существенные свойства спиральной модели:

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

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

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

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

1.6 Инкрементная модель жизненного цикла программного средства

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

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

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

Инкрементная модель представлена на рисунке 17.

Рисунок 17 – Инкрементная модель жизненного цикла

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

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

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

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

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

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

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

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

2 ОПТИМИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ

2.1 Общая характеристика бизнес-процесса

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

Дадим общую характеристику бизнес-процесса разработки программного продукта на заказ.

Характеристика представлена в таблице 1.

Таблица 1 – Характеристика бизнес-процесса

Параметр	Описание
Название процесса	Разработка программного обеспечения под заказ
Тип процесса	Основной производственный процесс
Цель процесса	Проектирование, разработка и внедрение программного обеспечения, заказанного клиентом, «под ключ»
Периодичность проведения процесса	Периодически повторяющийся процесс (технология реализации процесса практически не меняется со сменой заказчика и содержания заказанного программного продукта)
Границы процесса	Начало процесса – переговоры с клиентом, обсуждение назначения программы и требований к ней, составление технического задания Окончание процесса – изъятие разработанного программного обеспечения из эксплуатации Входы процесса – заключение договора о разработке программного продукта на основе технического задания Выходы процесса – приемка работы заказчиком, подписание акта выполненных работ
Ресурсы, необходимые для выполнения процесса	Разработчики (программисты, дизайнер, верстальщик), менеджер проекта, team менеджер, регламенты организации, оборудованное помещение, компьютеры и иное микропроцессорное оборудование, расходные материалы.

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

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

Рисунок 18 – Схема разработки заказного программного обеспечения

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

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

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

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

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

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

Организационная структура ООО «Интеллект» представлена на рисунке 19.

Рисунок 19 – Организационная структура ООО «Интеллект»

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

Потребителями бизнес-процесса разработки программного продукта на заказ являются:

• промышленные предприятия (заказывают как офисные, так и web-приложения);
• организации сферы обслуживания (заказывают как офисные, так и web-приложения);
• бюджетные организации (заказывают в основном web-приложения).

Все потребители процесса являются внешними по отношению к исполнителям организациями.[20]

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

• 61% - постоянные заказчики;
• 39 % - однократные заказчики.

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

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

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

При этом для обеспечения унифицированной оценки принята пятибалльная оценка метрик:

• время выполнения заказа
  • • 1 – критичное нарушение сроков сдачи проекта;
    • 2 – некритичная задержка сдачи проекта;
    • 3 – сдача готового проекта в срок с последующей доработкой;
    • 4 – сдача готового проекта и его доработка к принятому сроку;
    • 5 – досрочная сдача готового проекта;
• функциональность программы
  • • 1 – программа не решает поставленные задачи;
    • 2 – частичная реализация функций;
    • 3 – функции реализованы в целом;
    • 4 – функции реализованы полностью, но есть незначительные замечания;
    • 5 – функции реализованы полностью, без замечаний;
• качество пользовательского интерфейса
  • • 1 – пользовательский интерфейс неудобный и нефункциональный, нет сопроводительных комментарий для оператора;
    • 2 – интерфейс пользователя неудобный, нарушает общепринятые принципы реализации отдельных функций;
    • 3 – программа имеет неудобный, но функциональный интерфейс;
    • 4 – пользовательский интерфейс реализован качественно с некоторыми замечаниями заказчика;
    • 5 – пользовательский интерфейс реализован качественно, удобно для оператора;
• качество сопровождения продукта
  • • 1 – программный продукт не сопровождается после внедрения;
    • 2 – сопровождение программного продукта осуществляется разово за отдельную плату;
    • 3 – сопровождение программного продукта осуществляется разово без дополнительной оплаты;
    • 4 – сопровождение осуществляется системно в период гарантийного срока;
    • 5 – сопровождение осуществляется системно до изъятия разработанной программы из эксплуатации;
• стоимость работы (руб./час)
  • • 1 – очень высокая;
    • 2 – высокая;
    • 3 – выше среднего;
    • 4 – выше ожидаемой;
    • 5 – совпадает с ожиданиями заказчика.

Определим интегральные оценки бизнес-процесса разработки программного продукта на заказ методом аддитивной свертки.[5] Интегральные оценки по каждой метрики сведены в таблицу 2.

Таблица 2 – Оценка качества бизнес-процесса потребителями

Метрика	5	4	3	2	1	Интегральная оценка
Время выполнения заказа	82%	10%	6%	2%	0%	4,72
Функциональность программы	68%	22%	10%	0%	0%	4,58
Качество пользовательского интерфейса	22%	11%	5%	42%	2%	2,73
Качество сопровождения продукта	20%	21%	33%	20%	6%	3,29
Стоимость работы	9%	13%	18%	22%	38%	2,33

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

У ООО «Интеллект» имеется 3 организации – конкурента, которые оказывают аналогичные услуги и разрабатывают программные продукты под заказ.

Сравним исследуемый процесс с процессами конкурентов по двум измеримым метрикам:

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

Результаты сравнения представлены в таблице 3.

Таблица 3 – Сравнение исследуемого процесса с процессами конкурентов

Метрика	ООО «Интеллект»	Конкурент 1	Конкурент 2	Конкурент 3
Среднее время выполнения заказа (дн.)	14	15	14	17
Средняя стоимость часа работы (руб.)	2000	1200	1550	1370

На рисунках 20 – 21 представлены столбиковые диаграммы, демонстрирующие уровни значений метрик исследуемого процесса и аналогичных процессов конкурентов.

Рисунок 20 – Сравнение по времени выполнения заказа

Рисунок 21 – Сравнение по стоимости работы

2.2 Построение модели процесса

Бизнес-процесс описан в нотации IDEF0. Диаграмма первого уровня, а также детализация одного из узлов выполнена с помощью универсального векторного графического редактора MS Visio.[4]

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

Рисунок 22 – Диаграмма первого уровня

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

Детализация блока диаграммы Разработка программного продукта представлена на рисунке 23.

Рисунок 23 – Детализация узла Разработка программного продукта

Для представления действий каждого участника подпроцесса Разработка программного продукта в MS Visio разработана диаграмма прецедентов (рисунок 24).

Рисунок 24 – Диаграмма прецедентов процесса

Для модели процесса оценим отдельные шаги процесса для выявления их необходимости. Оценки поможет увидеть и осознать «тонкие» места процесса, в рамках которых он может быть улучшен.[10]

Используемые обозначения:

• УПЦ - действие, увеличивающее потребительскую ценность продукта;
• УОЦ - действие, увеличивающее организационную ценность продукта;
• УНЦ - действие, не увеличивающее ценность продукта.

Отдельные этапы бизнес-процесса разработки программного продукта на заказ:

• Заключение договора с заказчиком;
• Разработка программного продукта;
• Разработка регламентов и сопроводительных документов;
• Внедрение программного продукта;
• Сопровождение программного продукта.

Оценка шагов бизнес-процесса представлена в таблице 4.

Таблица 4 – Оценка шагов бизнес-процесса

Шаг процесса	Оценка	Возможность изменения
1. Заключение договора с заказчиком
1.1 Обсуждение с заказчиком требований к программному продукту	УОЦ
1.2 Формирование и утверждение ТЗ	УОЦ
1.3 Подписание договора с заказчиком	УПЦ	Совместить с 1.3
2. Разработка программного продукта
2.1 Распределение ролей в команде	УОЦ
2.2 Разработка дизайна проекта	УПЦ	Вынести на аутсорсинг
2.3 Верстка ресурса	УПЦ	Вынести на аутсорсинг
2.4 Разработка алгоритма решения задачи	УПЦ	Совместить в 2.2 и 2.3
2.5 Написание программного кода	УПЦ
2.6 Отладка программного кода	УПЦ
2.7 Тестирование программного кода	УПЦ
3. Разработка регламентов и сопроводительных документов
3.1 Описание программного продукта	УОЦ	Совместить с 2.6 по времени выполнения
3.2 Составление функциональной схемы программы	УОЦ	Совместить с 2.6 по времени выполнения
3.3 Разработка руководства пользователя; руководства оператора; руководства системного оператора.	УОЦ	Совместить с 2.7 по времени выполнения
3.4 Печать документации и направление копий документации всем заинтересованным лицам	УНЦ	Заменить на электронные копии, направляемые по рассылке
4. Внедрение программного продукта
4.1 Разворачивание программы на платформе заказчика	УПЦ
4.2 Запуск и тестирование функционала	УПЦ
4.3 Приемка программного продукта заказчиком	УПЦ
4.4 Подписание акта выполненных работ	УОЦ
4.5 Передача копий акта бухгалтеру и в налоговую службу	УНЦ	Выполнять, используя электронный документооборот
4.6 Оценка продукта заказчиком	УОЦ
5. Сопровождение программного продукта
5.1 Обучение персонала	УПЦ	Использовать дистанционные технологии обучения
5.2 Оперативное реагирование на выявленные случаи некорректной работы программы	УПЦ	Заменить электронной копией
5.3 Удаление программного продукта и изъятие его из использования	УОЦ

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

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

Измерим отдельные шаги бизнес-процесса по метрикам, которые использовались для сравнения с конкурентами:

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

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

Оценка стоимости действий по реализации проекта выполнена не в почасовой, а в абсолютной оценке.

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

Таблица 5 – Измерение шагов бизнес-процесса по стоимости

Шаг процесса	Стоимость по центрам затрат, руб.		Общая стоимость, руб.
	Оплата работы	Амортизация оборудования, аренда помещения, расходные материалы
1. Заключение договора с заказчиком	4000	200	4200
2. Разработка программного продукта	27000	3000	30000
3. Разработка регламентов и сопроводительных документов	3100	300	3400
4. Внедрение программного продукта	4300	1500	5800
5. Сопровождение программного продукта	12000	500	12500
ИТОГО:	50400	5500	55900

Таблица 6 – Измерение шагов бизнес-процесса по времени

Шаг процесса	Общая продолжительность, дней
1. Заключение договора с заказчиком	1
2. Разработка программного продукта	9
3. Разработка регламентов и сопроводительных документов	2
4. Внедрение программного продукта	2
5. Сопровождение программного продукта	До окончания эксплуатации продукта
ИТОГО:	14

Оценим шаги по метрикам качества в виде качественных оценок (таблица 7).

Таблица 7 – Качественная оценка шагов по метрикам

Шаг процесса	Средняя стоимость	Средняя продолжительность
1. Заключение договора с заказчиком	Удовлетворительно	Удовлетворительно
2. Разработка программного продукта	Неудовлетворительно	Удовлетворительно
3. Разработка регламентов и сопроводительных документов	Удовлетворительно	Удовлетворительно
4. Внедрение программного продукта	Неудовлетворительно	Удовлетворительно
5. Сопровождение программного продукта	Удовлетворительно	Удовлетворительно

2.3 Анализ рисков проекта

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

Возможные риски процесса представлены в таблице 8.

Таблица 8 – Риски процесса

№	Шаг процесса	Риск	Последствия	Вероятность
1	1.2 Формирование и утверждение ТЗ	Заказчик и менеджер проекта не могут согласовать позиции	Существенные	Небольшая
2	2.1 Распределение ролей в команде	Team-менеджер некорректно распределил роли в команде	Критические	Небольшая
3	2.5 Написание программного кода	Программист не имеет достаточной квалификации для разработки проекта	Катастрофические	Высокая
4	4.2 Запуск и тестирование функционала	Развертывание продукта невозможно на оборудовании заказчика по техническим причинам	Критические	Умеренная
5	5.1 Обучение персонала	Заказчик в целях экономии отказался от обучения персонала	Существенные	Умеренная

Карта рисков бизнес-процесса представлена в таблице 9.

Таблица 9 - Карта рисков бизнес-процесса

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

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

План возможных мероприятий по устранению невыносимых рисков:

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

2.4 Оптимизация бизнес-процесса

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

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

Дерево целей совершенствования бизнес-процесса представлено на рисунке 25.

В качестве наиболее проблемных точек бизнес-процесса на основе анализа были отмечены:

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

Рисунок 25 – Дерево целей

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

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

Диаграмма бизнес-процесса разработки программного продукта на заказ TO-BE представлена на рисунке 26.

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

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

Рисунок 26 – Модель бизнес - процесса TO-BE

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

Задачи курсовой работы выполнены, цель реализована.

СПИСОК ЛИТЕРАТУРЫ

1. Абдикеев Н. М./Управление знаниями корпорации и реинжиниринг бизнеса: Учебник / Н.М. Абдикеев, А.Д. Киселев; Под науч. ред. Н.М. Абдикеева. - М.: ИНФРА-М, 2013 - 382с.
2. Адизес И. Управление жизненным циклом корпорации. - СПб: Питер, 2017. - 384 с.
3. Вачугов Д.Д./ Курс менеджмента: Учебное пособие для студентов./ Д.Д. Вачугов. - Ростов-на-Дону:Феникс, 2013 - 512с.
4. Вендров, А. М. Практикум по проектированию программного обеспечения экономических информационных систем. - М.: Финансы и Статистика, 2016. - 192 c.
5. Гаврилов Л. П./Информационные технологии в коммерции: Учебное пособие / Л.П. Гаврилов. - М.: НИЦ Инфра-М, 2013. - 238 с
6. Гецци, Карло Основы инженерии программного обеспечения. - СПб.: БХВ-Петербург, 2015. - 832 c.
7. Глухов И.А. Стоимостно-ориентированный реинжиниринг бизнес-процессов // Вестник Финансовой академии. - 2008. - № 2.
8. Губич, Л. В. Внедрение на промышленных предприятиях информационных технологий поддержки жизненного цикла продукции. - Минск.: Белорусская наука, 2013. - 190 c.
9. Гэртнер, Маркус ATDD. Разработка программного обеспечения через приемочные тесты. - М.: ДМК Пресс, 2013. - 232 c.
10. Демчук О.Н. Теория организации. - М.: Флинта.МПСИ, 2014. - 264 с.
11. Дж. Харрингтон. /Оптимизация бизнес-процессов: Учебник / Дж. Харрингтон, Э. Эсселинг, Х. Нимвеген; - М.: Издательство Бизнес-микр , 2015 - 478 с.
12. Дорофеев В.Д. Инновационный менеджмент. - Пенза: Изд-во Пенз. гос. ун-та, 2013. – 24 с.
13. Жизненный цикл малого предприятия. - М.: Фонд «Либеральная миссия», 2015. - 244 с.
14. Иванов Д.Е. Жизненные стадии и циклы организации. - М.: Парта, 2015. - 75 с.
15. Ивашковская И. В./Моделирование стоимости компании. Стратегическая ответственность совета директоров / И.В. Ивашковская. - М.: ИНФРА-М, 2014. - 430 с.
16. Коберн А. Быстрая разработка программного обеспечения. - М.: ЛОРИ, 2013. - 336 c.
17. Логинов П.П. Процессный подход к управлению стратегической позицией предприятия //Менеджмент в России и за рубежом. - 2008.-№4.
18. Маранова Н.А. Управление человеческим капиталом на основе модели жизненных циклов в интересах инновационного развития. - Нижний Новгород: НГТУ им. Р.Е. Алексеева, 2014. - 158 с.
19. Незнахина Е.Л. Управление развитием предприятия на основе модели жизненных циклов. - Нижний Новгород: НГТУ, 2009. - 142 с.
20. Ойхман Е.Г/ Реинжиниринг бизнеса: реинжиниринг организаций и информационные технологии:Учебник/ Е.Г. Ойхман, Э.М. Попов - М.: Финансы и статистика, 2013. - 210с.
21. Рассел Д. Жизненный цикл программного обеспечения. - М.: Книга по Требованию, 2012. - 89 c.
22. Синицын С. В. Верификация программного обеспечения. - М.: Бином. Лаборатория знаний, 2017. - 368 c.