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

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

Работа является попыткой изучить и применить на практических задачах систему бизнес-моделирования Business Studio. В работе использованы опыт работы с инженерными системами моделирования: SIMULINK, МВТУ и инженерное образование.

Особенности работы по выпуску продукта

В модели рассматривается параллельный выпуск двух продуктов двумя отделами:

• Продукт для малого бизнеса.

• Корпоративный продукт.

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

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

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

Существует 3 уровня, на которых могут разрабатываться функции продукта:

1. Сам продукт.

2. Библиотеки.

3. Платформа.

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

Порядок разработки продукта, когда готов его прототип, следующий:

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

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

В связи с этим, количество реализованных требований зависит от работы нескольких отделов:

• Если какой-то функционал является общим, его реализация переносится на уровень библиотек.

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

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

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

Разработка ведётся с применением технологии SCRUM [2]. Она подразумевает, что сотрудники за определённый промежуток времени, называемый спринтом, выполняют то количество поставленных задач, которое успевают.

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

Оптимизация

Оптимизацию можем выполнять на трёх уровнях [3]:

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

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

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

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

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

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

В результате моделирования выполнено 95% требований и выпущена версия продукта для малого бизнеса.

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

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

Действия по оптимизации

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

Было:

Стало:

Для процесса А5.3.3 Тестирование и исправление, используемом для разработки библиотек, сделаем то же самое.

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

Было:

Стало:

Добавим одного дополнительного тестировщика.

Было:

Стало:

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

Было:

Стало:

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

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

В результате моделирования выполнено 94% требований и выпущена версия продукта для малого бизнеса.

Простой разработчиков продукта для малого бизнеса составил 2 дня. Время с начала работы над новой версией продукта до её выпуска составило 1 месяц и 3 недели.

Простой сократился на 1 неделю и 1 день (в 4 раза), по сравнению с неоптимизированным бизнес-процессом.

Промежуток с начала работы разработчиками продукта для малого бизнеса над продуктом до завершения сократился на это время (на 12%)

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

Проверка результатов в режиме регулярной работы

Для проверки того, как будет работать отдел разработки программ в режиме регулярной работы, выпуская каждый месяц по 1 версии продукта для малого бизнеса, по 1 версии корпоративного продукта и по 2 версии библиотек и платформы, проведём моделирование выпуска 4 версий продукта (по 2 версии продукта для малого бизнеса и по 2 – корпоративного).

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

Видим, что выпускается заданное количество версий продукта и выполняется 94-97% требований пользователей.

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

Экономический эффект

Уменьшение простоя разработчиков продукта для малого бизнеса при неизменности их количества составило на одну версию (2 месяца разработки) на одного сотрудника 12%. Что в расчёте на всех сотрудников отдела и в пересчёте на месяц при ФОТ сотрудника 200 000 рублей в месяц составило:

11 человек * 12% * 200 000 руб. = 264 000 рублей.

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

18 человек * 12% * 200 000 руб. = 432 000 рублей.

ФОТ добавленного тестировщика составит 160 000 руб.

Суммарная экономия в месяц:

264 000 + 432 000 – 160 000 = 536 000 руб.

Выражаться она будет в более частом (на 12% чаще: 1 месяц и 3 недели по сравнению с 2 месяцами) новых версий продуктов и снижении стоимости выпуска каждой новой версии.

Выводы

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

Литература

1. Структура модели бизнес-процессов [Электронный ресурс] // Business Studio Документация [сайт]. [2016]. URL: http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/struct (дата обращения 02.06.2016).

2. Книберг Х. С.М. Kanban и Scrum: выжимаем максимум. Agile Ukraine, C4Media, Издательство InfoQ.com, 2010. 78 с.

3. Бизнес-процессы. Оптимизация бизнес-процессов [Электронный ресурс] // Канал Открытые бизнес-методики TRIZ-RI на Youtube [сайт]. [2014]. URL: https://www.youtube.com/watch?v=67bk0gDFX1s (дата обращения 11.09.2016).

4. Джефф Кокс, Ди Джейкоб, Сьюзан Бергланд. Новая цель. Как объединить бережливое производство, шесть сигм и теорию ограничений; пер. с англ. П. Миронова. — М. : Манн, Иванов и Фербер, 2011. — 400 с.

5. Имитируемая модель деятельности по разработке программ [Электронный ресурс] // ZK Interactive [сайт]. [2016]. URL: http://zkinteractive.com/management/soft_co_bm/ru/ (дата обращения 29.12.2016).