Перейти к основному содержимому

Диагностика качества бизнес-процесса

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

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

Рисунок: Сводная круговая диаграмма по всему проекту или программе

Рисунок: График на основе исторических данных

Исходные данные для оценки метрик качества процесса

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

Рассмотрим на примере активностей в типовом ИТ-проекте. В этом примере фаза «анализ» не включена в производственный цикл ресурса ограничения.

Расшифровка нотации:

  • Н --- активность новая
  • П --- активность запланирована
  • Р --- активность в работе
  • З --- активность завершена
  • Цикл --- производственный цикл

Диагностика «Превышение затрат»

Если участок «Разработка» потребовал для выполнения больше чем одного исполнителя --- то у нас количество активностей будет больше запланированных.

Чем плохо:

  1. При каждой передаче задачи другому исполнителю теряется скорость решения и сфокусированость на результате.
  2. Появляется «неожиданная» работа которая не включена в план, что снижает предсказуемость проекта.
  3. Для ИТ-проектов архитектурные решения прорабатываются «на ходу» без должного обдумывания.

Рекомендация:

  1. Выявите причины такого поведения.
  2. Для ИТ-проектов: выполняйте среднесрочное проектирование.
  3. Для ИТ-проектов: выполняйте разбивку на задачи завершаемые автоматическими тестами покрывающими сценарии.

Диагностика «Превышение затрат (цикл)»

Если по какой либо причине работы на производственных участках выполняются несколько раз.

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

Чем плохо:

  1. Низкое качество исполнения приводит к перерасходу ресурсов на переделку.

Рекомендация:

  1. Выявите причины такого поведения.
  2. Определите и запишите критерии качества реализации.
  3. Убедитесь, что исполнитель правильно понял, что нужно сделать.
  4. Проведите необходимое обучение.

Диагностика «Превышение затрат критичное»

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

Тут пара «Разработка 2 --- Рецензирование 2» это нормальное поведение, а вот «Разработка 3 --- Рецензирование 3» уже не нормальное поведение.

Чем плохо:

  1. Переделки реализации приводят к перерасходу ресурсов и снижению скорости реализации проекта.

Рекомендация:

  1. Выявите причины такого поведения.
  2. Определите и запишите критерии качества реализации.
  3. Убедитесь, что исполнитель правильно понял, что нужно сделать.
  4. Найдите способы более дешёвого протипирования и проверки прототипа.
  5. Проведите необходимое обучение.

Диагностика «Нарушение процесса»

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

Чем плохо:

  1. Выявление дефектов на последней фазе производственного цикла приводят к перерасходу ресурсов и снижению скорости реализации проекта.

Рекомендация:

  1. Выявите причины такого поведения.
  2. Определите и запишите критерии качества реализации.
  3. Убедитесь, что исполнитель правильно понял, что нужно сделать.
  4. Найдите способы более дешёвого протипирования и проверки прототипа.
  5. Проведите необходимое обучение.
  6. Разработайте сценарии проверки до реализации.
  7. Для ИТ-проекта: используйте подход «тесты первыми» и автоматизацию тестирования

Диагностика «Провал активностей»

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

Тут активность «рецензирование» просто пропущен и сразу перешёл из «запланирован» в «завершено», а активность «тестирование» не выполнена, так как активность «разработка» сразу завершилась в последнее состояние.

Чем плохо:

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

Рекомендация:

  1. Выявите причины такого поведения.
  2. Если какие-то активности не требуются, договоритесь о новых правилах работы.
  3. Проверьте причины появления «внеплановых задач» в проекте. (см. Диаграмма сгорания)