Кейс PashaPay часть 2: проектирование организации

Взвешенный SWOT-анализ и конфронтационная матрица

Кейс PashaPay часть 1: организационный дизайн и обучение менеджмента
Кейс PashaPay часть 3: развитие способностей и итоги

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

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

Конфронтационная диаграмма

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

Системное проектирование организации

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

Срочность изменений

Определения причин измениться создает топливо для трансформации. Поэтому мы открыли сессию с объяснения, почему компания будет меняться. Это сообщение затем донесли на Town Hall, встрече всех сотрудников компании.

Объяснение срочности изменений для сотрудников

Организационные способности

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

Список организационных способностей

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

Определение границ продукта

Самые горячие дискуссии разгорелись вокруг определения границ продукта. Прежде всего мы приняли основные критерии:

клиент находится за пределами организации;
продукт закрывает потребности и обладает уникальной функциональностью;
есть бизнес-модель и поток доходов (PnL).

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

DailyPay — часть приложения m10;
BillsPay — тоже часть приложения m10;
приложение m10 целиком;
приложение m10 и платежные терминалы million;
платежные терминалы million.

После долгих дебатов группа решила считать million и m10 самостоятельными продуктами. Во-первых, они практически автономны. Во-вторых, DailyPay и BillsPay, несмотря на Pnl, не самостоятельные продукты, а его области, так как не могут существовать в отрыве друг от друга. Объединение же million и m10 было непрактично из-за слишком большого объема изменений.

В качестве продукта группа выбрала m10 и начала собирать вокруг него продуктовую группу.

Проектирование продуктовой группы

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

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

Дальше группа приступила к поиску основных частей продуктовой группы. Для этого миссию декомпозировали.

Первый уровень декомпозиции миссии

Фрагмент второго уровня декомпозиции миссии

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

Запуск группы трансформации

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

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

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

Создание группы трансформации и голосование

Состав представлял компанию как систему. Это были топ- и мидл-менеджмент, отдельные разработчики, Скрам-мастера и представитель HR.