Как быть гибким в бизнесе

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

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

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

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

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

ГИБКОЕ VS ФИКСИРОВАННОЕ МЫШЛЕНИЕ. Как добиваются успеха

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

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

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

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

Достигнуть и гибкости и надежности в необходимой степени ни один серьезный конкурент не может; что дает возможность получить значительное конкурентное преимущество.

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

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

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

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

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

5 СПОСОБОВ РАЗВИТЬ ГИБКОСТЬ МЫШЛЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Путь вперед

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

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями.

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

Источник: tocpeople.com

Как быть гибким в бизнесе

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

Согласно определению Business Agility Institute, гибкость бизнеса — это набор организационных возможностей, моделей поведения и способов работы, которые обеспечивают компании свободу, маневренность и устойчивость для достижения ее цели. И все это возможно только в том случае, если организация предоставляет комфортную среду, чтобы развивать идеи, альтернативы и возможности, о которых говорит Франкен.

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

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

Операции. Системы управления и политики должны ценить новые идеи и возможности, а не устоявшуюся структуру. Настало время переосмыслить командную деятельность, встречи, семинары и дискуссионные форумы.

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

Люди. Компании стоит инвестировать в решения и практики, которые позволяют каждому сотруднику по-своему проявлять креативность. Так, Lucid Software подарила своему персоналу подписку на сервис мастер-классов MasterClass. Каждый может выбрать занятие на свой вкус, например по кулинарии. Это заряжает людей на повседневную деятельность на долгие месяцы.

Групповые упражнения

Снижение рисков

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

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

Парные и групповые разработки

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

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

Фото на обложке: Trismegist san / Shutterstock

Источник: rb.ru

Секрет успеха. 4 принципа гибкого подхода на примере Skipp

Начинающие ИТ-предприниматели часто думают, что главное — запустить продукт. Но практика показывает, что запуск — это только начало, а всё самое сложное и интересное происходит потом.

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

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

Интерфейс платформы для менеджера Skipp: он может посмотреть статус каждой конкретной фичи в любом проекте

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

1. Начинать с малого

Делать сразу большую систему рискованно:

❌ Нет гарантии, что она окупится.

❌ Рынок может измениться и она потеряет актуальность.

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

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

Как это было в Skipp

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

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

Небольшая первая версия — только начало пути. Как применять гибкий подход в бизнесе после запуска?

2. Думать гипотезами, а не большими планами

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

«Если мы сделаем конкретный оффер на узкую аудиторию, сможем снизить стоимость привлечения на 10%».

«Если в продукте появится возможность приглашать друзей, мы сможем привлекать на 5% больше новых пользователей в месяц за счёт рекомендаций».

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

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

Как это было в Skipp

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

Вот такая гипотеза показала положительный результат:

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

А вот две, которые не оправдались:

❌ «Если сразу скажем клиенту стоимость проекта, исходя из нашей грубой оценки, то повысим конверсию заявка → покупка».

❌ «Если отдадим менеджмент на аутсорс, и не будем подключать продакта Skipp на каждый заказ, повысим маржинальность».

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

Движение через гипотезы — основа гибкости. Но как проверить их результативность?

3. Опираться на метрики

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

Метрики помогают принимать решения. Например:

Метрика — конверсия. Гипотеза — меняем позиционирование продукта на лендинге. Проверили гипотезу и увидели, что конверсия упала — отказываемся от идеи.

Метрика — конверсия. Гипотеза — упрощаем форму регистрации. Проверили гипотезу и конверсия, наоборот, выросла — отлично, идём в нужную сторону.

Метрика — средний чек. Гипотеза — переработать тарифы. Ввели новые тарифы, вырос средний чек — здорово, гипотеза сработала.

Часто молодые проекты смотрят только на выручку. Это нормально на самом первом этапе, когда ещё непонятно, востребована ли модель. Но от этого подхода со временем стоит уходить. Выручка — верхнеуровневая метрика, которая опирается на много других.

Как это было в Skipp

Например, мы обращали внимание на количество полностью успешных проектов. В самом начале их было около 60%. Мы начали подключать менеджера Skipp на все проекты, после чего процент успешно выполненных проектов вырос до 90%.

Другая важная метрика — стоимость привлечения клиента. Чтобы её оптимизировать, мы сменили позиционирование, сделали конкретные нишевые офферы, расширили список каналов, в которых продвигаемся. Раньше общие расходы на привлечение клиента, включая оплату сейлзу, выходили в 150 000₽, сейчас — 85 000₽.