Гибкость и надежность

Автор: Рудольф Буркхард (Rudi Burkhard)

Важное конкурентное преимущество компании — гибкость — это немедленная реакция на новые потребительские запросы (от существующих и новых клиентов). Однако, надежность проектов, находящихся в процессе реализации, при этом страдает. [В статье разбираются 3 Грозовых тучи.]

Гибкость и надежность

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

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

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

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

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

Конфликт: гибкость против надежности

Ниже мы покажем Грозовую тучу конфликта гибкость против надежности. Если поставка задерживается (или делается не в полном объеме), бизнесу клиентов наносится значительный ущерб. Но отсутствие немедленного ответа на срочные требования столь же разрушительно для клиентов. Тогда конфликт очень реален. Компания попадает в безвыходное положение. Достигнуть и гибкости и надежности в необходимой степени ни один серьезный конкурент не может; что дает возможность получить значительное конкурентное преимущество.

Описание конфликта

Верхняя ветвь:

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы должны «находить новых и поддерживать существующих клиентов» (B), ПОСКОЛЬКУ (A-B):

  1. «В нашем бизнесе успех означает, что мы достигаем роста прибыли» и/или
  2. «Новый бизнес — жизненная основа нашей компании».

• Чтобы «находить новых и поддерживать существующих клиентов» (B), мы должны «немедленно реагировать на клиентские запросы» (D), ПОСКОЛЬКУ (B-D):

  1. «Срочные запросы не редки».
  2. «Клиенты работают с поставщикам, которые реагируют быстро».
  3. «Задержки, вызванные реакцией на срочные запросы, не подвергают опасности существующий бизнес».
  4. «Клиенты привыкли к задержкам».
  5. «Заканчивать проекты позже (или не в полном объеме) — установившаяся практика в нашей отрасли».

Туча конфликта - гибкость против надежности (tocpeople.com)

Рис. 1

Нижняя ветвь:

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы «не должны подвергать опасности наши взаимоотношения с существующими клиентами» (C), ПОСКОЛЬКУ (A-C):

  1. «У клиентов хорошая память»;
  2. «Клиенты «наказывают» нас за невыполнение сроков прекращением сотрудничества».

• Чтобы «не подвергать опасности взаимоотношения с существующими клиентами» (C), мы «не должны немедленно реагировать на клиентские запросы» (D’), ПОСКОЛЬКУ (C-D`):

  1. «Немедленная реакция задерживает другие активные проекты».
  2. «Немедленная реакция приводит к многозадачности».
  3. «Многозадачность приводит к потере мощностей».
  4. «Потеря мощностей вызывает еще большие задержки».

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

Некоторые компании «создали» 50-100% защитные мощности (с существующими ресурсами) в своих проектных организациях и используют эти мощности, чтобы реагировать быстрее и производить больше.

Конфликт: гибкость против эффективности

Текущая задача должна быть завершена, прежде чем новая задача будет запущена, гласит правило Управления проектами по методу Критической цепи. Возникает впечатление, что это правило ставит под угрозу гибкость. Если гибкость нам необходима, тогда кажется, что Критическая цепь менее гибка, чем стандартное управление проектами. Давайте рассмотрим этот конфликт ниже. Мы видим, что цепь A-B-D осталась такой же, изменились блоки C и D’.

Описание конфликта

Туча конфликта: гибкость против эффективности (tocpeople.com)

Рис. 2

Нижняя ветвь:

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы должны «эффективно использовать ресурсы» (C), ПОСКОЛЬКУ (A-C):

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

• Чтобы «эффективно использовать ресурсы» (C), мы «не должны допускать вредную многозадачность» (D’), ПОСКОЛЬКУ (C-D`):

  1. «Многозадачность уменьшает наши мощности на 25% и более».
  2. «Многозадачность задерживает проекты на 25% и более».
  3. «Потерянные мощности нарушают гибкость и надежность».

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

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

Еще рекомендуем:  Использование канбан в разработке программного обеспечения: от Agile к Lean. Окончание

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

Необходимо проверить, нужна ли незамедлительная реакция в действительности. В большинстве сред немедленная (в ту же секунду) реакция не требуется, небольшая задержка вполне приемлема.

Критическая цепь рекомендует минимизировать многозадачность (устранить «плохую» многозадачность, если быть точным), но явно утверждает, что «ХОРОШАЯ» многозадачность допустима и имеет право на жизнь.

Конфликт: внедрять ли «сделанные на скорую руку» решения или нет

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

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

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

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

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

Описание конфликта

Верхняя ветвь:

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы «не должны подвергать опасности сроки завершения наших проектов» (B), ПОСКОЛЬКУ (A-B):

  1. «Своевременное завершение важно для лояльности клиентов».
  2. «Немедленная быстрая реакция важна для поддержания или развития бизнеса».

• Чтобы «не подвергать опасности сроки завершения наших проектов» (B), мы «должны принимать решения на скорую руку» (D), ПОСКОЛЬКУ (B-D):

  1. «Часто у нас недостаточно времени, чтобы принять качественное решение».
  2. «Мы должны немедленно реагировать на срочные клиентские запросы».
  3. «Ресурсы проекта оцениваются с позиции их гибкости: способности быстро отреагировать и вовремя завершить проект».
  4. «Недостатки решения на скорую руку могут быть исправлены позже».

Туча конфликта - внедрять ли «сделанные на скорую руку» решения или нет (tocpeople.com)

Рис. 3

Нижняя ветвь:

• Чтобы «управлять нашим проектным бизнесом успешно» (A), мы «должны гарантировать качество продукта» (C), ПОСКОЛЬКУ (A-C):

  1. «Качество продукта гарантирует более простые будущие обновления и дополнения продукта».
  2. «Низкое качество продукта замедляет его будущие обновления».
  3. «Низкое качество продукта означает, что клиенты часто страдают и жалуются».

• Чтобы «гарантировать качество продукта» (C), мы «не должны принимать решения на скорую руку» (D), ПОСКОЛЬКУ (B-D):

  1. «Качественное решение обеспечивает разработку задуманного программного обеспечения».
  2. «Решения на скорую руку в конечном счете приводят к нестабильности продукта».
  3. «Решения на скорую руку имеют тенденцию содержать больше ошибок».
  4. «Решения на скорую руку могут поставить под угрозу спецификации продукта».
  5. «Решения на скорую руку ставят под угрозу будущее продуктов, которые часто не исправляются».

Критическая цепь

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

Путь вперед

  1. Высшее руководство должно понять, что в то время как Критическая цепь ограничивает многозадачность в целом, она не отвергает «хорошую» многозадачность.
  2. Компания и клиент вместе выполняют анализ ситуации, в которой находится клиент, и разрабатывают концепцию решения. Необходимые условия, которым должно удовлетворять решение:
    — гибкость;
    — надежность;
    — качество продукта (никаких решений на скорую руку);
    — наличие мощностей, которые позволят обеспечить первые три приоритета и сохранить возможность для увеличения количества проектов — без общепринятых компромиссов.
  3. Концепция представляется руководству проектной организации вместе с проектным предложением. Оно должно быть оформлено в виде не более чем 2-часовой презентации.
  4. Проектное предложение представляется высшему руководству для одобрения.
  5. Внедрение подхода — значительные результаты можно ожидать в течение 6-9 месяцев.
Руди Буркхард
(Rudi Burkhard)
Business Development Director, VISTEM GmbH & Co.

1 комментарий “Гибкость и надежность

  1. Владимир Речкалов
    Владимир Речкалов

    В статье показано, как использовать инструмент Мыслительных процессов — Грозовые тучи — в управлении проектами.

      Цитировать  Ответить

А что вы думаете?

Ваш e-mail не будет опубликован. Обязательные поля помечены *