Предприниматели без опыта часто думают, что самое сложное и важное в ИТ-бизнесе — запустить продукт. Как будто бы это единовременное большое усилие, после которого всё пойдёт как по маслу, останется просто поддерживать систему и иногда докупать сервера. Но практика подсказывает, что всё наоборот: выживание продукта зависит от действий, которые команда предпримет после, а не до первого релиза.
1142 просмотров
У проекта будет намного больше шансов выжить, если не пытаться сразу написать миллион строк кода и сотню функций, а начать с прототипа и постепенно развивать его на основе обратной связи от пользователей и ситуации на рынке. Эту идеологию мы в Skipp используем и на клиентских проектах, и для решения внутренних задач. Она помогает нам избегать ошибок и постоянно расти.
Для начала: а вы вообще кто?
Skipp — сервис для разработки ИТ-продуктов. К нам обращаются клиенты с идеями или ТЗ, а мы подбираем команды исполнителей — проверенные студии дизайна или разработки.
Саймон Хейворд – Agile-трансформация. Готовый план перехода к гибкой бизнес-модели организации.
Для каждого клиента мы выделяем менеджера по продукту. Он помогает конкретизировать цель, составить подробное задание, принимать продуктовые решения. С одной стороны, его работа в том, чтобы заказчик и разработчики смогли говорить на одном языке. С другой — чтобы клиент решил свои задачи, а не просто получил на выходе какой-то код.
У нас есть платформа, где заказчики, менеджеры Skipp и команды исполнителей вместе работают над проектом. Клиенты ставят задачи, разработчики принимают их, оценивают и сдают, менеджеры следят за процессом, помогают клиенту и обеспечивают коммуникацию. Платформа — сердце нашего бизнеса, она автоматизирует множество внутренних процессов. В ней можно собрать команду, построить роадмэп разработки и отслеживать прогресс по проекту.
Интерфейс платформы для менеджера Skipp: он может посмотреть статус каждой конкретной фичи в любом проекте
Интерфейс платформы для клиента: здесь он может сравнить оценки команд и выбрать исполнителя для задачи
Но так было не всегда. Расскажем, как с помощью гибкого подхода мы прошли путь от простого лендинга с оффером до платформы с собственной методологией продуктовой разработки.
1. Начинать с малого
У строительства большой системы много рисков. Во-первых, у основателя ещё нет оснований полагать, что она окупится: если вложить значительные средства сразу, их легко потерять. Во-вторых, на большую систему может уйти много времени. Это опасно: рынок может поменяться, и продукт не будет ему соответствовать; предприниматель не будет получать обратной связи от клиентов; компания не начнёт зарабатывать.
Когда разработка начинается с чего-то небольшого, ситуация становится противоположной, предприниматель успеет среагировать на изменения во внешней среде. Такой подход поможет собрать обратную связь и повысить ценность продукта. А ещё — быстрее начать зарабатывать.
Вместо того чтобы сразу запускать полномасштабную разработку, выберите самую важную функцию для пользователя и выпустите её. Чем быстрее вы сможете запустить первую версию, тем лучше. Часто для этого даже не нужны ресурсы разработки: можно найти no-code решение. Соберите обратную связь и запланируйте следующий шаг.
Гибкая бизнес-модель. Опыт внедрения | Марианна Данилина, Иван Самолов | Подкаст#76
Как это было в Skipp
В первой версии Skipp платформы для клиента и исполнителей вообще не было: мы запустили лендинг, всю работу делали вручную. Это отнимало больше времени, но мы проверили, востребована ли услуга на рынке.
В первой итерации у бизнес-модели были недостаки. Мы часто брали с клиентов фиксированную стоимость, а с исполнителями работали по часовой ставке. Из-за этого некоторые проекты уходили в минус, если разработка длилась дольше, чем мы оценили в начале. Например, на одном проекте мы потеряли так миллион рублей.
Но первая версия — не значит плохая. Даже с лендингом и ручным подходом мы смогли успешно закрыть несколько проектов. В некоторых проектах экономика была на грани, но чаще мы выходили в небольшой плюс: в среднем с проекта зарабатывали 15%. Это было достаточным подтверждением жизнеспособности модели.
Небольшая первая версия — только начало пути. Как применять гибкий подход в бизнесе после запуска?
2. Думать гипотезами, а не большими планами
Гибкий подход — постоянное итеративное развитие: делаем шаг, осматриваемся, принимаем решение, делаем следующий шаг. Но как понять, как именно нужно развивать продукт, какие функции добавлять, как дорабатывать модель?
Даже если на старте у предпринимателя в голове есть дорожная карта, он не знает наверняка, что именно сработает и принесёт деньги. Следовать поэтапному, но неизменному плану — неустойчивый подход.
Например, после запуска может оказаться, что экономика проекта отрицательная — за привлечение клиента приходится платить больше, чем бизнес зарабатывает с него. Если продолжать двигаться по изначальному плану, компания будет терять деньги на каждом клиенте и масштабировать минуса
Чтобы сохранить гибкость, предприниматель делает небольшие шаги на основе гипотез: ищет, какое решение может быть востребовано на рынке и как его можно реализовать. Гипотеза может касаться нового модуля в продукте, нового канала продвижения или сегмента, нового подхода к процессу.
Важно, чтобы в гипотезе было конкретное предположение: как действие повлияет на продукт или компанию. Гипотеза состоит из двух частей: Если [сделать что-то], то [мы получим такое-то изменение в продукте или процессах].
- «Если мы сделаем конкретный оффер на узкую аудиторию, сможем снизить стоимость привлечения на 10%».
- «Если в продукте появится возможность приглашать друзей, мы сможем привлекать на 5% больше новых пользователей в месяц за счёт рекомендаций».
- «Если мы добавим ежедневные пуш-уведомления, то сможем повысить частоту использования продукта и удержание пользователей».
Гипотезу можно быстро проверить. Не придётся разрабатывать что-то месяцами: на запуск хватит нескольких дней или даже часов, останется только оценить результат и принять решение о следующем шаге. Если гипотеза оправдает себя и принесёт положительный результат, её можно взять в работу и развивать. Если результата не будет или он будет отрицательным, откатитесь назад и проверяйте следующую гипотезу.
Как это было в Skipp
После запуска первой версии мы столкнулись с тем, что не могли с точностью прогнозировать прибыльность проектов. Мы могли как заработать, так и уйти в минус. Чтобы преодолеть проблемы, мы выдвинули много гипотез и начали их последовательно проверять.
Например, вот такая гипотеза показала положительный результат:
Если мы возьмём на себя предпроектную подготовку и подробно опишем технические требования, исполнители согласятся работать за фиксированную стоимость, и мы сможем повысить маржинальность до 30%.
Раньше мы сразу передавали командам ТЗ от клиентов, часто оно было несовершенным и оставляло много вопросов. Поэтому разработчики соглашались только на почасовую оплату. Когда мы сами начали проводить подготовку, помогали заказчику составить задание и готовили прототипы, исполнителям стало легче точно оценить проект на старте. Многие команды согласились работать по фиксированной ставке. Гипотеза помогла нам повысить маржинальность проектов с 15–20% до 30–35%.
Вот две гипотезы, которые не оправдались:
Если сразу скажем клиенту стоимость проекта, исходя из нашей грубой оценки, то повысим конверсию заявка → покупка.
Гипотеза не сработала, потому что большинство клиентов сразу запрашивали подробную смету.
Если отдадим менеджмент на аутсорс, и не будем подключать продакта Skipp на каждый заказ, повысим маржинальность.
Гипотеза не сработала, потому что качество управления всегда было ниже. Менеджер Skipp защищает интересы клиента, работает с ожиданиями и делает процесс разработки прозрачным: если его не подключать, результат был хуже.
Движение через гипотезы — основа гибкости. Но как проверить их результативность?
3. Опираться на метрики
В основе гибкости лежит здравый смысл. У предпринимателя нет задачи проверять все гипотезы, которые он сможет придумать. В первую очередь нужно работать над предположениями, которые смогут значительно усилить бизнес или продукт.
Для этого нужно определить список приоритетных метрик — количественных показателей, с помощью которых вы оцениваете состояние продукта или бизнеса. Например, конверсия и рентеншен, чтобы следить, улучшают ли нововведения пользовательский опыт. Или стоимость привлечения и средний чек, чтобы контролировать юнит-экономику.
Если предприниматель не выбрал метрики, он двигается вслепую: не знает, принесли ли предыдущие шаги положительные изменения, не может планировать следующие.
Метрики помогают принимать решения. Например:
- Метрика — конверсия. Гипотеза — меняем позиционирование продукта на лендинге. Проверили гипотезу и увидели, что конверсия упала — отказываемся от идеи.
- Метрика — конверсия. Гипотеза — упрощаем форму регистрации. Проверили гипотезу и конверсия, наоборот, выросла — отлично, идём в нужную сторону.
- Метрика — средний чек. Гипотеза — переработать тарифы. Ввели новые тарифы, вырос средний чек — здорово, гипотеза сработала.
Часто молодые проекты смотрят только на выручку. Это нормально на самом первом этапе, когда ещё непонятно, востребована ли модель. Но от этого подхода со временем стоит уходить. Выручка — верхнеуровневая метрика, которая опирается на много других. Из-за этого ей достаточно сложно управлять, она не показывает детали состояния продукта и бизнеса.
Например, можно разложить выручку на средний чек и количество клиентов. Количество клиентов — на конверсию и трафик на сайте. Получается, выручка зависит как минимум от трёх других показателей, каждым из которых бизнес может управлять. Если смотреть на одну выручку, то можно не заметить, что средний чек, например, растёт, а конверсия падает. И не понять, что отдел продаж работает хорошо, а маркетинг — хуже.
Чем раньше бизнес начинает смотреть на низкоуровневые метрики, тем больше рычагов управления бизнесом у него появляется. Тем проще предпринимателю принимать решения и сохранять гибкость.
Как это было в Skipp
Первое время мы тоже ориентировались в основном на выручку и количество клиентов, чтобы разобраться, есть ли вообще спрос на подобный формат работы. Но во время следующих этапов разработки мы ориентировались уже на более низкоуровневые метрики.
Один из показателей, которые для нас важны, — конверсия во второй заказ. Если проект прошёл хорошо, то выше вероятность, что клиент придёт к нам снова. В итоге мы заплатим за привлечение один раз, а заработаем несколько — вырастет LTV при неизменном CAC.
Ещё мы обращали внимание на количество полностью успешных проектов, то есть таких, в которых не возникало особых проблем с качеством и сроком. В самом начале их было около 60%. Мы видели, что проекты, в которых я участвую в качестве менеджера, чаще заканчиваются успехом, а когда менеджмент оставался на стороне исполнителя, сложности появлялись чаще.
Так мы решили ввести менеджера Skipp на все проекты. Он погружается в задачу клиента и полностью ведёт её, стыкует бизнес с разработкой, помогает принимать решения. После появления менеджеров по продукту процент успешно выполненных проектов вырос до 90% — из 50 проектов, которые мы сделали за последнее время, проблемы появились только в пяти.
выросла доля успешно выполненных проектов после появления менеджеров по продукту
Другая метрика, над которой мы работали, — стоимость привлечения клиента. Мы снова выдвинули несколько гипотез: сменили позиционирование, сделали конкретные нишевые офферы, расширили список каналов, в которых продвигаемся. Раньше общие расходы на привлечение клиента, включая оплату сейлзу, выходили в 150 000₽, сейчас — 85 000₽.
Итак, мы запустили первую версию, проверили серию гипотез, нащупали необходимые метрики, проект встал на стабильные рельсы. Как сохранять гибкость дальше?
4. Искать бутылочное горлышко
Со временем продукт и компания развиваются. Проявлять гибкость на глобальном уровне уже сложно: есть стабильное количество пользователей или клиентов, сложившаяся экономика, прогнозируемый денежный поток. Проверять модель в этом случае уже не нужно. Но это не значит, что следует отказаться от гибкого подхода.
На этом этапе гибкость переходит на более низкий уровень. Команда ищет способы оптимизировать работу, повысить эффективность, заработать больше. То есть, начинает искать узкие места в системе — бутылочные горлышки.
- Отдельно можно рассмотреть воронку привлечения клиентов — от первого касания до оплаты. Найти узкие места и исправить их, чтобы сэкономить на привлечении.
- Отдельно — процесс регистрации и онбординга в продукт, чтобы улучшить ретеншн.
- Отдельно — использование продукта и повторные оплаты, чтобы увеличить LTV.
- Отдельно — внутренние процессы вроде документооборота и найма, чтобы снизить издержки.
Как это происходит в Skipp
Сейчас мы сфокусированы на процессах — выявляем задачи, на которые уходит много ресурсов, и пытаемся их автоматизировать. Упрощаем документооборот, процесс коммуникации между клиентами и исполнителями. Для этого дорабатываем внутреннюю платформу, через которую это всё и работает.
Бутылочное горлышко. Раньше мы тратили десятки часов на оценку проекта. Нужно было получить задачу от клиента, отправить её в несколько подходящих команд, получить от них предварительную оценку. Обсудить с клиентом, подумать, что стоит оптимизировать, вернуться к исполнителям с обратной связью.
Процесс получался небыстрый. У исполнителей разный подход к составлению смет, приходилось тратить время, чтобы унифицировать их. Согласовать смету с первого раза практически невозможно, и время всегда уходило на несколько раундов обсуждения. По каждому клиенту накапливались десятки файлов, в которых немудрено запутаться.
Решение. Сейчас оценка проходит через платформу. Исполнители отправляют туда свои сметы, при этом все отклики в одном формате. Клиент может сразу на платформе дать комментарии и получить обратную связь. Мы экономим кучу времени и, соответственно, денег.
Бутылочное горлышко. Раньше у нас уходило несколько недель на поиск и найм разработчиков и менеджеров. Было сложно проверить компетенции на собеседовании, поэтому иногда мы брали людей на проекты, но по ходу работы понимали, что им не хватает навыков. Их приходилось менять, это затягивало разработку, рождало дополнительные издержки.
Решение. Мы внедрили стандарты компетенций для каждой роли. Например, составили списки хард и софт скиллов, которые должны быть у менеджеров по продукту в Skipp. Чтобы проверить, что кандидат владеет навыками, стандартизировали вопросы и задачи для собеседовений.
Чтобы попасть в воронку найма или откликнуться на конкретную вакансию, кандидату не обязательно связываться с нами, он может зарегистрироваться сразу на платформе Skipp. Во время регистрации с него уже соберут часть информации, которая поможет валидировать его компетенции.
Что в результате
Гибкий подход помогает предпринимателю пройти путь от идеи до прибыльного бизнеса. Ключевые принципы подхода:
- Не затевайте большую разработку сразу, начните с чего-то простого.
- Развивайтесь с помощью проверки гипотез.
- Опирайтесь на метрики, чтобы выбрать гипотезу и оценить, насколько она оправдалась.
- Ищите бутылочное горлышко — узкое место, которое тормозит процессы или отнимает деньги — и оптимизируйте его.
Проект, который развивается по гибкому подходу, постоянно остаётся на связи с рынком и пользователями. Плюс гибкость помогает экономить: шаги для развития небольшие и относительно дешёвые.
В Skipp мы прошли путь от лендинга и ручной работы до автоматизированной платформы, которая соединяет клиентов и разработчиков. Если бы мы сразу начали полноценную разработку, то не учли бы множество подводных камней, о которых не знали заранее: про менеджмент, привлечение клиентов, работу с исполнителями.
За счёт того, что мы шли поэтапно и постоянно адаптировались, у нас получилось преодолеть большинство проблем молодых компаний и реализовать больше 100 клиентских проектов за полтора года.
Источник: vc.ru
Бизнес: «жесткость» vs. «гибкость»?
Нормой стало представление о том, что бизнес может являться жесткой или гибкой системой, но никак не и той, и другой одновременно. Однозначно воспринимается, что жесткий бизнес- это плохо, а гибкий — хорошо. Данная статья написана в попытке разобраться: что стоит за понятием гибкости в бизнесе, и за счет чего она может достигаться. Практическое применение выявленных ситуаций — использование при проектировании архитектуры компании.
Бизнесу выгодна повторяемость деятельности, включая ее результат. Повторяемая деятельность — это деятельность, которая может воспроизводиться по одному и тому же шаблону. Например, деятельность «Заключение договора» или даже более глобальная — «Строительство дома».
Повторяемость дает возможность «один раз» детально продумать деятельность, подготовить необходимые для нее средства (оборудование, компьютеры, , здания ), людей, скомпоновать их в «жесткую машину деятельности», а потом многократно ее использовать. Это дает серьезную экономию, затраты на проектирование деятельности и подготовку средств осуществляются один раз, а сама деятельность — многократно. И чем больше ее повторений, тем значительнее эффект экономии. Поэтому бизнесу однозначно выгодна повторяемость деятельности. Он ее «хочет» и он к ней «стремится».
Проблема в том, что повторяемости деятельности «не хотят» клиенты, конкуренция и внешняя среда. Клиенты требуют уникального продукта «под себя» или новых продуктов «почаще», конкуренты и государство подкидывают свои «сюрпризы». Бизнес должен реагировать на это и реагировать быстро. Возникает парадокс: с одной стороны, бизнес «хочет» повторяемости деятельности, с другой — гибкости и быстрой реакции на ситуацию.
Поскольку бизнес «хочет» и того, и другого, то парадокс становится проблемой, которую необходимо решить. В зависимости от причин, «толкающих» бизнес к гибкости, и способов ее реализации видятся три типовых вида гибкости. Рассмотрим их через призму системного подхода, в котором место целевой системы отводится компании.
1. Создание гибкой системы, способной реагировать на широкий (но конечный) класс ситуаций
Контринтуитивно, но то, что внешнему наблюдателю может показаться «гибким поведением» компании, может являться… осознанным замыслом. Компания может специально создаваться, чтобы реагировать на широкий класс ситуаций. И это реагирование принимается за гибкое поведение, хотя изначально оно было «запрограммировано» в архитектуре компании.
Но класс ситуаций, на которые возможна реакция, на самом деле конечен, и при выходе за него компания не сможет отреагировать совсем или отреагировать в приемлемые сроки.
Типовым примером осознанной реализации гибкости в поведении компании является возможность создания уникального продукта для клиента. Степень этой гибкости может отличаться от достаточно низкой (серийное производство с ограниченным набором опций) до достаточной высокой (производство сложных продуктов на заказ по проектному принципу).
Примером низкой гибкости является автомобилестроение, особенно немецкое, когда клиент может выбрать опции автомобиля и автомобиль будет произведен для него «под заказ». Примером высокой гибкости, является строительство зданий и сооружений, когда под заказ клиента производится и проектирование здания, и компоновка «машины деятельности» из оборудования и персонала. Главным является то, что класс ситуаций, на которые может отреагировать компания, тем не менее остается конечным. Например, строительная компания не сможет произвести для клиента трактор.
2. Оперативная сборка «машины деятельности»
Внешняя среда часто требует от компании результата, технологии «производства» которого и, соответственно, «машины деятельности», в компании еще нет. Например, это могут быть нестандартные запросы внутренних подразделений, клиентов или партнеров компании.
— Степан! У гостя карета сломалась. — Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну… За… Сделаем и за два.
— А за пять дней?
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!
Кинофильм «Формула любви»
Реакция на такие запросы требует от организации как бы «минипроектов», в которых могут участвовать один или несколько сотрудников. Если проанализировать виды деятельности, которые возникают в таком минипроекте, то неизбежно среди них будет «придумывание» технологии деятельности, поиск необходимых средств, инструктаж участников «минипроекта» — словом, вся та классическая деятельность, которую можно наблюдать и в проекте, и при создании «жесткой машины деятельности». При этом совершенно неважно: будут ли фиксироваться разработанные решения «на бумаге» или «умрут» в головах участников вместе с окончанием минипроекта; один участник разрабатывает технологию или это происходит коллективно, кто является главным ответственным за выработку технологии и сборку «машины деятельности» — руководитель или сотрудник. Главное — что данные виды «инженерной» деятельности реально осуществляются.
Если нестандартные запросы начинают повторяться, то нормальным поведением компании является фиксация «на бумаге» способа реакции на них и подготовка средств деятельности «заранее». Степень фиксации и подготовки может быть разной, зависящей от прогнозируемой частоты повторения запросов или сложности деятельности — вплоть до создания со временем «жесткой машины деятельности». Нужно это сугубо по экономическим причинам: даже те же самые участники «минипроекта» через время уже могут забыть, как они решали эту же задачу в прошлый раз. А если «минипроект» будет поручен новой команде, то тратить время и, соответственно, деньги на придумывание того, что уже было придумано — расточительно для компании. Поэтому можно дать совет руководителям: если в вашей компании отсутствует практика фиксации технологии некоторой деятельности, которая стала повторяться — это повод для беспокойства.
3. Быстрая перестройка компании
Если случилось так, что вы (сугубо по экономическим соображениям, приведенным в начале статьи!) построили «жесткую машину деятельности», то рано или поздно возникнет вопрос о необходимости ее перестройки. Для создания эффекта гибкости в глазах внешних наблюдателей (например, собственников или клиентов) компании необходимо вовремя уловить «сигналы», способные вызвать изменения, быстро спроектировать и провести изменения по всей структуре компании или ее части.
Перестройка может быть вызвана, например:
- Необходимостью другого результата деятельности (новая продуктовая линейка);
- Появлением новых средств деятельности (знаний, технологий, оборудования), которые дают существенный экономический выигрыш;
- Требованиями государства (например, введением ЕГАИС для контроля оборота алкоголя).
В любом случае, главное не упустить момент и вовремя начать перестройку.
С того момента, когда установлена необходимость перестройки компании, начинается отсчет времени. Изменение даже большой компании не должно представлять проблему, если она УЖЕ обладает грамотно спроектированной архитектурой. Например, с использованием принципа модульности, когда связи между модулями минимизируются, а внутри компоненты модулей могут быть связаны сильно.
Реализацией этого принципа является и подход, пропагандируемый Тимуром Кадыевым — «Один процесс — одно подразделение», означающий, что один процесс целиком должен находиться в границах одного подразделения. За счет минимизации связей между подразделениями появляется возможность менять их достаточно независимо друг от друга. Но это в теории. На практике компании с такой архитектурой встречаются редко. Плюс, на возможность быстро спроектировать и провести изменения накладывают отпечаток межличностные отношения руководителей, которые не всегда способны договориться друг с другом.
Одним из решений этой проблемы является не создание одной крупной компании, а строительство системы взаимодействующих небольших компаний. При этом даже интуитивно минимизируются связи между компаниями, а сами компании получают «законную» возможность развиваться самостоятельно, независимо от мнения и влияния других руководителей. К такому же эффекту приводит и использование аутсорсинга: как и для использующей аутсорсинг компании, так и для .
В конце этого раздела хотелось бы подчеркнуть, что , гибкая компания — это не та компания, которая имеет небольшой размер, и не та, в которой отсутствуют жесткие связи между подразделениями, а, в первую очередь, та — которая способна не «проглядеть» необходимость изменений и быстро провести их. Такое часто встречающееся явление, как «заторможенное» развитие компании, в которой построена «жесткая машина деятельности», на мой взгляд, вызвано, в первую очередь не следствием жесткости и размера системы, а, скорее, отсутствием нужных компетенцией у менеджеров и неверно выбранной архитектурой компании.
В статье рассмотрено три вида гибкости компании:
- Гибкость, как возможность реакции на заранее известный широкий класс ситуаций;
- Гибкость, как возможность компании реагировать на непредусмотренные ситуации;
- Гибкость, как возможность быстрой перестройки компании.
Эти виды, как мы убедились выше, вполне мирно могут сосуществовать с жесткой структурой компании. Поэтому миф о невозможности гибкости в компаниях с жесткой структурой, надеюсь, развенчан.
Также хотелось бы отметить, что, наверняка, в этой статье учтены не все классы гибкости. Поэтому представляет интерес дальнейший поиск и систематизация таких способов.
Источник: www.businessstudio.ru
Что такое гибкая бизнес-модель и как сделать компанию легко масштабируемой
- View Larger Image
Что должна включать бизнес-модель, чтобы компания стала легко масштабируемой? Почему важно соблюдать баланс между тремя основными блоками бизнес-модели? Какие ошибки допускают руководители компаний в ходе стратегических преобразований? Ответы — в статье.
Дмитрий Лейкин Директор, руководитель направления организационного проектирования компании «КПМГ» в России и СНГ, Москва; кандидат экономических наук. Журнал “Генеральный Директор” №5-2011
Гибкость бизнес-модели означает способность компании быстро перестраивать внутреннюю среду в ответ на изменения в стратегии и внешней среде. Бизнес-модель любой компании можно представить в виде трех блоков (см. рисунок).
- Структура, процессы, информационные технологии. Недостаточно просто разработать структуру (то есть нарисовать квадратики и обозначить связи между ними), обязательно нужно описывать информационные и материальные потоки между подразделениями, а также автоматизированные участки процесса (операции).
- Оценка деятельности и мотивация. В блок входят целевые показатели, которые устанавливаются руководителям и сотрудникам подразделений, оценка результатов и система мотивации. В первую очередь речь идет о денежной мотивации (размере бонусов, премий) и о решениях продвигать сотрудников по итогам достижения целей.
- Персонал и корпоративная культура. К блоку относятся ценности сотрудников, их лояльность. Изменение этих элементов – очень длительный и сложный процесс, плохо поддающийся формализации.
От чего зависит гибкость бизнес-модели
Нужно соблюдать баланс между тремя блоками. Что это означает? Первое: уровень регламентации должен быть минимально необходимым и достаточным для определения полномочий сотрудников и порядка взаимодействия подразделений.
Второе: нужно, чтобы показатели сотрудников соответствовали их полномочиям, зарплата была на уровне среднерыночных параметров (или чуть выше), а бонусы увязаны с достижением показателей и приложенными усилиями. Третий фактор – благоприятная атмосфера и корпоративная культура, делающие компанию привлекательной для специалистов. Рассмотрю на примерах, к чему могут привести перекосы в сторону одного из блоков.
Пример 1. Акцент сделан на первом блоке. Введение должностных инструкций, регламентов и других документов вместе с автоматизацией делают систему управления менее подверженной человеческому фактору. Однако, если увлечься регламентацией, скорость принятия решений будет падать.
Например, в одной компании количество инструкций было столь велико, что их актуализацией занимался отдел из 15 человек. Даже небольшое предложение об изменении наталкивалось на ответ: «Я действую по утвержденному регламенту. Если хотите что-то поменять, согласуйте все изменения в установленном порядке. Только после этого я скорректирую свою часть процесса». «Согласование в установленном порядке» означало сбор примерно семи подписей. Эта процедура обычно длилась не меньше месяца.
Пример 2. Акцент сделан на втором блоке. Вы решили нанимать «звездных» менеджеров. Однако не всегда итоговые показатели зависят от их усилий (успехи могут быть связаны, например, с благоприятной рыночной конъюнктурой). Кроме того, такие менеджеры, как правило, спустя два-три года уходят из компании в погоне за большими бонусами.
Например, в одной компании директора окончили ведущие бизнес-школы и их зарплата и бонусы были существенно выше, чем среднерыночные. Каждый из них считал своим долгом давать Генеральному Директору рекомендации по выстраиванию деятельности других отделов и постоянно комментировать стратегию бизнеса. Все они были «звездами», но компания «звездных» результатов не показывала. Атмосфера в коллективе была пропитана нездоровой конкуренцией между топ-менеджерами; возникали конфликты, которые приходилось разрешать Генеральному Директору. Как только начался кризис, многие из директоров стали искать работу в надежде на лучшее вознаграждение.
Пример 3. Акцент на третьем блоке. В этом случае в компании создается атмосфера, комфортная для талантливых сотрудников. Денежная мотивация для них – не определяющий фактор: они готовы работать за идею. Минусы в том, что найти таких сотрудников сложно; кроме того, они не всегда могут грамотно реализовать идею. В одной компании костяк топ-менеджеров не менялся 15 лет.
Эти люди стояли у истоков бизнеса и понимали друг друга с полуслова. Вначале многие работали по 12–14 часов в сутки за идею. С течением времени финансовые показатели повысились, жизнь топ-менеджеров улучшилась, и темп работы снизился. Руководители стали приходить в офис к десяти, а уходить в пять-шесть вечера. То же самое происходило с их подчиненными.
В результате темпы роста уменьшились до 3–5% в год, и компания начала терять долю рынка. Почти семейные отношения, отличавшие корпоративную культуру, сыграли с акционерами злую шутку.
Как это работает
Рассмотрим пример: предприятие, находящееся в Москве, производит бытовые товары. Основные покупатели – оптовые дилеры, поставляющие продукцию в регионы и отдельные магазины, а также розничные сети. Бизнес-модель компании выглядит так.
Блок 1. Организационная структура выстроена по классическому принципу: Генеральному Директору подчиняются директора по продажам, по производству, по закупкам, финансовый директор, директор по персоналу и директор по IT.
Процессы стандартны: менеджеры по продажам принимают клиентские заказы и вводят их в информационную систему. Директор по производству отвечает за своевременное исполнение заказа и поддержание целевых остатков на складе готовой продукции.
Информационные системы используются в бухгалтерии (учетная система) и на производстве (система планирования и контроля исполнения заказов, разработанная IT-специалистами предприятия).
Блок 2. В вознаграждении топ-менеджеров преобладает постоянная часть (зарплата), также им выплачивается годовая премия, которая зависит от достижения целевого показателя прибыли (до уплаты процентов, налогов и амортизации). Бонусы директора по продажам зависят от исполнения плана по выручке и маржинальной прибыли. Переменная часть дохода – примерно 20% от постоянной части зарплаты.
Блок 3. Трансформацию корпоративной культуры я в этом примере рассматривать не буду, а сконцентрирую внимание на первых двух блоках (изменения в них более наглядны и могут быть формализованы).
Допустим, в Москву приходит крупный игрок. Он строит завод, мощности которого достаточно для удовлетворения спроса во всем Центральном регионе. У него передовые технологии, отлаженные логистические процессы и широкая линейка продуктов. Что делать в этой ситуации? Менять стратегию и перестраивать бизнес-модель. Предположим, что стратегия компании включает альтернативы:
- смещение фокуса на региональные продажи и их ускорение;
- сокращение издержек, уменьшение ассортиментного ряда и снижение цен.
Посмотрим, какие изменения могут произойти в бизнес-модели при реализации каждой альтернативы.
Стратегия 1. Региональные продажи
Блок 1. Для реализации этой стратегии нужно сместить фокус на региональные продажи. Это потребует открытия филиалов, которые находят клиентов и поставляют им продукцию в регионе. Возможно, будет полезным создать подразделение продаж на заводе (подразделение входит в структуру отдела продаж, но располагается на производственной площадке).
Работающие в нем менеджеры будут принимать заказы и следить за их своевременным исполнением на заводе. Также нужно изменить структуру дирекции по продажам, которая станет своего рода корпоративным центром по отношению к филиалам. В ней появятся такие функции, как разработка единой ценовой политики, условий расчетов с покупателями, маркетинг, реклама, управление брендом.
Появление нескольких точек продаж предъявляет новые требования к процессам. Нужно разработать механизм взаимодействия филиалов и производства, определить в том числе приоритеты заказов, установить сроки их исполнения и отгрузки продукции. Стоит внести изменения в IT: создать единую систему управления заказами, которая в режиме реального времени позволит принимать заказы от филиалов, а филиалам даст возможность следить за ходом исполнения заказа на производстве.
Блок 2. Система мотивации продавцов должна быть скорректирована с учетом задачи поиска и привлечения новых клиентов в регионах. Как известно, завоевать нового клиента сложнее, чем удержать уже имеющегося. Поэтому сотрудникам нового филиала нужно установить сравнительно небольшую фиксированную часть вознаграждения и значительную переменную.
Стратегия 2. Снижение затрат
Стратегия предполагает сокращение затрат, уменьшение продуктовой линейки и снижение цен. В результате компания станет лидером в издержках и сможет конкурировать с новым игроком за счет более низких цен.
Блок 1. Может быть создана рабочая группа для разработки и реализации программы сокращения издержек. В группу должны войти все функциональные руководители. Их задача – обеспечить достижение целевых показателей затрат по каждому функциональному блоку и по компании в целом.
Изменения в процессах и в IT также направлены на уменьшение затрат: устранение дублирующих функций, избыточных уровней управления, повышение скорости исполнения заказа, ускорение оборачиваемости запасов для снижения операционного цикла и высвобождения оборотных средств. При этом стратегия не предполагает никаких масштабных вложений в IT.
Блок 2. В основе системы мотивации ключевых топ-менеджеров – целевые показатели программы сокращения затрат. Бонусы выплачиваются после того, как будет виден эффект от экономии.
Что поможет достичь результата
Какой бы вариант стратегии ни был выбран, успех будет зависеть от способности довести все необходимые изменения до конца (см. Типичные ошибки при изменении бизнес-модели). Результативность изменений зависит от трех факторов.
1. Размер компании. Чем больше организация, тем больше людей участвует в изменениях и тем сложнее эти изменения довести до конца. В компаниях с оборотом около 10 млн долл. США изменения могут занять до полугода.
2. Отсутствие противоречий в текущей бизнес-модели. Например, если в компании система мотивации не связана со степенью ответственности структурных подразделений (премии распределяются исключительно по усмотрению первого лица независимо от ключевых показателей), то изменение системы натолкнется на противодействие тех топ-менеджеров, которые, не демонстрируя хороших результатов, регулярно получают большие бонусы, так как имеют сильное личное влияние на Генерального Директора.
3. Умение и воля Генерального Директора. Вам нужно четко следовать методологии и последовательно изменять каждый блок бизнес-модели. Изменения в структуре должны сопровождаться изменениями в процессах, за перестройкой процессов должны следовать новые требования к IT-системам и их перенастройка.
Изменившиеся в результате полномочия и ответственность должны привести к корректировке системы мотивации (в том числе принципов начисления бонусов). Воля руководства – это решимость довести изменения до конца, перестроить и по-новому сбалансировать все блоки бизнес-модели, несмотря на сопротивление топ-менеджеров и сотрудников.
Типичные ошибки при изменении бизнес-модели
1. Изменение только организационной структуры. Генеральный Директор утверждает приказом новую структуру – и считается, что изменения успешно проведены. При этом системы управления, IT и мотивации не корректируются, не устанавливаются и новые правила взаимодействия между отделами. Оценка деятельности и система мотивации либо отражают старые полномочия и ответственность топ-менеджеров, либо основываются на субъективной оценке Генеральным Директором результатов деятельности руководителей.
2. Изменение корпоративной культуры без решения проблем отделов, противоречий в процессах и мотивации. Видя, что сотрудники разных отделов не доверяют друг другу, Генеральный Директор решает улучшить корпоративную культуру: проводятся мероприятия по оценке лояльности персонала, тренинги по командообразованию.
Однако в дальнейшем Генеральный Директор сталкивается с прежними проблемами: дублирование функций, нежелание руководителей отделов делиться информацией и давать разъяснения, невозможность достичь поставленных целей из-за недостаточных полномочий. Командный дух пропадает в течение первой недели после тренинга. Причины: проблемы, накопившиеся в отделах, так и остались не решенными; то, что сотрудники слышат на тренингах, не соответствует происходящему в реальности.
3. Решение проблем при помощи регламентов и автоматизации. Улучшая бизнес-модель, некоторые руководители решают внедрять процессное управление, инвестировать в IT, но забывают изменить организационную структуру и систему мотивации. Проблем здесь две.
Во-первых, как бы подробно ни был описан процесс, руководители, не нацеленные на сотрудничество с другими отделами и воспринимающие их как конкурентов своих подразделений, всегда найдут оправдание собственному нежеланию взаимодействовать. Во-вторых, руководители не считают себя частью процесса, они лишь обращают внимание на оргструктуру (сколько людей у них в подчинении, за что отвечают и кому подчиняются их отделы). Процессы воспринимаются как производные от структуры, которая отражает принципиальное разделение полномочий и ответственности между подразделениями.
Источник: xn--h1adjbc1b9c.xn--p1ai
