Философия Кайдзен, BPM, и гибкие методологии разработки

Философия Кайдзен, BPM, и гибкие методологии разработки

Автор: Реза Шафи

Перевод: Гибкие технологии

Ссылка на оригинал: http://www.oracle.com/technetwork/articles/entarch/kaizen-bpm-agile-093198.html

Японская философия бизнеса – Кайдзен (непрерывное совершенствование процессов производства, разработки и вспомогательных бизнес-процессов) оказала глубокое влияние на способы повышения качества и эффективности работы.  В этой статье рассказано о том, каким образом BPM (Business Process Management – Управление бизнес-процессами) можно использовать в качестве реализации принципов философии Кайдзен и причины, по которым поставка такого решения оптимизирована с помощью некоторых понятий, лежащих в основе гибких методологий разработки.

BPM как реализация Кайдзен

В области управления бизнесом, термин Kaizen (что буквально означает "хорошее изменение") берет свое начало в 1950-х годах в Японии. Сейчас этот термин чаще всего переводится как "постоянное улучшение". Хотя детальный взгляд на философию непрерывного совершенствования выходит за рамки данной статьи, краткое описание приведено ниже. На самом деле, постоянное совершенствование объединяет ряд идей, которые поощряют постоянный цикл проверки и адаптации любой деятельности, с целью ликвидации недоработок и улучшения качества. Один из принципов непрерывного совершенствования в том, что пользователи процессов, будь то служащие или руководство компании - те, кому рекомендуется постоянно анализировать свою работу и предлагать улучшения. На высоком уровне, для непрерывного улучшения предлагаются следующие мероприятия:

  • Стандартизация работы
  • Измерение стандартизированных операций
  • Калибровка измерений с требованиями
  • Внедрение инноваций в соответствии с требованиями с последующим повышением производительности
  • Стандартизация новых улучшенных операций

BPM можно рассматривать как реализацию абстрактных понятий непрерывного усовершенствования на уровне бизнес-процессов: BPM представляет собой основу, где бизнес-процессы организации могут быть оптимизированы неоднократно. По словам Брюса Сильвера (специалист в области BPM) - "BPM основано на понятии «цикла непрерывного совершенствования процесса». Циклами мероприятий BPM являются: процесс анализа, моделирование процесса, процесса реализации и мониторинга процесса. Сравнительный взгляд на деятельность цикла непрерывного улучшения и BPM показан на рисунке 1."

 file/www.png

Рис.1 – Непрерывное совершенствование и циклы активности BPM.

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

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

Программное обеспечение BPMS – это программные продукты, которые предоставляют возможности для бизнес-аналитиков осуществлять свою деятельность с минимальным участием IT. Это позволяет бизнес-аналитикам использовать итерационный подход к циклам BPM для постоянного улучшения процессов. На выходе получаем всегда активные и непрерывные усилия для реализации процесса улучшения, которые напоминают о важном вопросе: какими должны быть масштабы одной итерации цикла BPM, в размерах и усилиях? Для более детальной проработки вопроса обратимся к гибким методологиям разработки.

BPM по пути гибких методологий разработки

Тема гибких методологий разработки программного обеспечения достаточно широка и ее рассмотрение выходит за рамки данной статьи. Тем не менее, принято считать, что гибкие методологии разработки программного обеспечения это те, которые следуют принципам, изложенным в Agile Manifesto (Манифест гибкой разработки). Этот документ был составлен в 2001 году лидерами разработки программного обеспечения, которые использовали методы, отличающиеся от традиционных all-in-one и модели waterfall, которые пытались придумать общий язык между этими подходами. Основной движущей силой принципов изложенных в Agile Manifesto является идея, что это слишком сложно (некоторые сказали бы невозможно) точно определить все требования заказчика и связанные с ними разработки программного продукта со сложностью, что выходит за рамки основных уровней. Эта трудность может привести к целому ряду проблем, включая задержки в доставке продукта, снижение качества программного обеспечения, а также неспособность реагировать на изменение требований. Чтобы исправить это, гибкие методологии предписывают, среди прочего, итеративный подход к созданию программного обеспечения – предоставление результатов за небольшой отрезок времени с получением обратной связи - оценкой работы, проделанной в каждом цикле с целью улучшения процесса и более полного удовлетворения ожиданий клиентов.

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

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

На сегодняшний день не существует стандартной или единой методологии BPM, соответственно нет единой гибкой методологии. Многие организации определили свои собственные методологии. Для оценки существующей методологии, важно понять ее соответствие с принципами Agile Manifesto:

  • Является ли методика итерационной? Гибкие методы должны включать в себя проверку и адаптацию итерации цикла с рабочей моделью, выданной в конце каждой итерации, что постепенно приближает разработчиков к финальному релизу
  • Насколько велика итерация (от нескольких недель до нескольких месяцев)? Чем больше длина итерации, тем больше методология приближается к методу waterfall, следовательно, хуже адаптируется к изменениям и способствует новым улучшениям
  • Есть ли методики, позволяющие значительные изменения на протяжении всей итерации? Гибкие методологии не позволяют изменять требования во время итерации т.к. это может привести к хаосу, с последующей нестабильной рабочей моделью
  • Существует ли обратная связь между бизнес-аналитиками и пользователями? Гибкие методологии приветствуют взаимодействия лицом к лицу с конечными потребителями поставляемого продукта. Это делается для того, чтобы понять требования и желания клиента с последующей доработкой в течение следующих итераций
  • Методика включает большое количество обязательных документов? Гибкие методологии подчеркивают простоту и практичность. Большое количество обязательных документов не поддается этим принципам

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

Синергия BPM и гибких методологий разработки программного продукта

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

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

AquaLogic BPMS, например, предоставляет такой единой модели процесса, и, как следствие, AquaLogic BPM Studio позволяет пользователям переключаться между профилями "Бизнес-аналитики", "Бизнес-архитектор" или "Разработчик" путем простого нажатия и без необходимости преобразования основного процесса. Каждый из этих профилей, в свою очередь предоставляет пользователю различные инструменты, которые подходят для моделирования и реализации потребностей

Наконец, стоит отметить, что возможность постоянного развертывания новых и улучшенных версий бизнес-процессов производства требует использования BPMS продуктов, обладающих мощным потенциалом версий. BPMS продукт должен иметь возможность работать с несколькими версиями процесса. Хороший продукт BPMS должен также предусматривать возможность непрерывного развертывания новых версий одного и того же процесса. Естественно, AquaLogic BPM Studio предлагает обе эти важные возможности для версий.

Заключение

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

Рассказать друзьям: