Екатерина Смирнова

Лид продуктового кластера в Samokat.tech

Эксперт по внутренним продуктам, 10+ лет опыта внедрения, развития и управления продуктами. Выстраивает и трансформирует продуктовые направления. Практикующий психолог, занимается командообразованием и менторингом.

Кто же ты такой, Внутренний продукт? Шпаргалка для осмысления

Дата: 24.11.2023

Что делать, если перед вами стоит задача нанять на работу не людей, а информационные системы? О чем стоит подумать, чтобы запустить внутренние системы по продуктовому маршруту? Внутри 5 шагов, 19 вопросов-помощников и примеры применения на реальном продукте.

Что делать с этими системами, они же внутренние. Вот с продуктами для клиентов понятно, а всякие там 1С и CRM куда? Туда же? А если у нас еще проект миграции на новую внутреннюю платформу, тоже туда же, в продуктовый офис? Так это же проект, не понятно, как он туда стыкуется.

Не вижу абсолютно никакой разницы между коммерческими и внутренними продуктами.

Почему внутренние продукты – ПРОДУКТЫ? Где там ПРОДУКТОВАЯ составляющая?

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

Внутренние продукты – любые информационные системы, в которых настроена работа бизнес-процессов компании. Вне зависимости от того, ведете вы доработку этого продукта или просто купили его, настроили и «он просто работает», тут определенно идет речь о внутреннем продукте.

Я занимаюсь внутренними продуктами более 13 лет и сегодня хочу поделиться своей точкой зрения и своим опытом с теми, кто впервые запускает/реанимирует внутренние продукты и стоит перед выбором, какую же сборку запустить, чтобы «оно работало».

Я точно знаю, что нет большого количества материалов по этой теме, ровно как нет единой точки зрения о том, насколько внутренние продукты на самом деле Продукты: кто-то видит работу вокруг внутренних продуктов как классическую продуктовую, кто-то – как проектную деятельность, кто-то – как стратегически значимую часть бизнеса, кто-то как исполнительскую дисциплину.

Единственно правильного ответа нет, но давайте разбираться, что же делать, если перед вами стоит такая задача как обеспечение результативности внутренних информационных систем, таких как CRM, WMS, 1С и так далее.

Начнем с примера Во многих компаниях бухучет ведется в 1С какой-либо конфигурации. Компания растет, клиентов становится все больше, объем бухгалтерских операций множится, бухгалтерия в текущем составе перестает справляться с работой в нужные сроки, и встает вопрос: «Что сделать, чтобы не нанимать людей снова и снова при росте компании?». Естественное желание – автоматизировать операции и «нанять на работу» в большей степени продукт 1С и в меньшей степени ручной труд бухгалтера. То есть нужно разработать что-то такое, что будет использовать бухгалтер, чтобы успевать делать больше работы все в те же 8 рабочих часов.

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

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

Мы же с вами посмотрим на решение под углом продуктового подхода…

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

Шаг 1. Определяем целевую аудиторию и какие возможности должен обеспечить продукт

Вопросы-шпаргалки, которые помогут найти ответы:

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

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

Наш пример: В нашем примере с 1С «бытовым языком» получаем следующее. Продукт нужен для закрытия рутинных бухгалтерских операций. Мы понимаем, что 1 бухгалтер обслуживает 5К клиентов, компания растет на 5К клиентов каждые 3 месяца, то есть только за год нам в таком случае потребуется нанять дополнительно 4 бухгалтера, что не выгодно. Кроме того, когда будет решена проблема с бухгалтерскими операциями, аналогичные вопросы следует решить с казначеством, а далее – с командой клиентского сервиса. А потом, скорее всего, и до других отделов доберемся. Итого мы получаем экономию по году на бухгалтерах, нанимая +1 бухгалтера каждый 3 месяса: 1 бухгалтер – 12 мес, еще 1 бухгалтер – 9 месяцев, еще 1 бухгалтер – 6 месяцев, еще 1 бухгалтер – 3 месяцев. Итого всего 30 бух-месяцев за год, даже при минимальной зарплате бухгалтера в 60к получаем 1,8 млн экономии в год. И так далее…

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

Если на этом этапе вы уже нашли деньги, которые компания не потратит/заработает благодаря «найму продукта на работу», есть уже от чего оттолкнуться для формирования условно доходной части (а тут и до P&L дотащить можно), значит, можем ставить двойную галку в пользу разворачивания продуктового офиса.

Если же ответов на эти вопросы нет, то перед наймом владельца продукта и/или продуктовой команды все же стоит поработать с собственными ожиданиями.

Шаг 2. Определяем роль и критичность продукта в обеспечении процессов компании

Вопросы-шпаргалки, которые помогут найти ответы:

Какова роль данного продукта в процессах компании?
Что будет, если выключить данный продукт, случится ли бизнес-проблема, каковы будут издержки?
Насколько продукт должен быть стабилен и надежен, нужно ли будет задуматься о том, как именно обеспечить эту надежность?

Наш пример: В нашем примере Продукт 1С становится полноценным участником бизнес- процессов компании, без него выполнение процессов становится невозможным, соответственно в случае выключения продукта 1С компания однозначно столкнется с бизнес-проблемой, при чем в случае с бухгалтерией и казначейством продукт должен быть доступен в рабочее время по будням, а вот клиентский сервис в компании оказывается 24 на 7, соответственно, и продукт в этой части должен работать круглые сутки и круглый год. То есть крайне важна задача постоянного отслеживания здоровья продукта, и следует понять, кто и как будет это делать.

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

Шаг 3. Определяем объем бизнес-задач, которые должен закрыть продукт, а также уровень проработанности этих задач

Вопросы-шпаргалки, которые помогут найти ответы:

Видится ли, что задач для продукта столько, что он должен разрабатываться постоянно и непрерывно?
Сколько уже сейчас задач для этого продукта есть?
Уже есть четкое понимание, что нужно делать и зачем? Или есть понимание, что там «непаханное поле», и нужен человек, который сможет «это поле вспахать»?

Наш пример: В нашем случае с 1С предположим, что бухгалтерские и казначеские задачи нам ясны, их останется только проработать и приоритизировать, а клиентские – нет, в них есть только цель «не разращивать количество клиентских менеджеров». И например, бухгалтерские и казначейские задачи проработают методологи соответствующих отделов, от команды 1С ожидается только исполнение четко и точно, а клиентские задачи – нужно полностью исследовать, моделировать, проверять и после – разрабатывать.

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

Шаг 4. Определяем зоны ответственности между бизнес/функциональными- подразделениями и продуктовой командой

Вопросы-шпаргалки, которые помогут найти ответы:

Кого мы видим лидером в разработке этого продукта?
Кто будет валидировать проблемы и решать задачи, под которые есть идеи на разработку?
Кто будет исследовать зоны изменения, искать решения, трансформировать процессы, прочитывать выгоды?
Будет ли это человек от бизнеса или человек из команды продукта?
Если это будет человек из команды продукта, какими полномочиями мы готовы его наделить в области трансформации процессов, под которые будет разворачиваться продукт?

Наш пример: Из предыдущих ответов нам уже известно, что бухгалтерские и казначейские задачи планируется решать силами методологов, в них задача от команды 1С – вовремя и безошибочно сделать разработку в соответствии с методологией. В случае с клиентским сервисом все не настолько однозначно, и встает вопрос, какого уровня абстракции придет запрос в продуктовую команду?

Рассмотрим два крайних варианта:
1. В команду поступает вопрос, как сделать так, чтобы не нанимать дополнительную единицу сотрудников внутри конкретного клиентского сервиса при росте клиентской базы, чтобы решение этой задачи было экономически более целесообразно, чем найм дополнительных людей в перспективе Х лет. При такой постановке вопроса «бизнес» нанимает «продукт» не просто реализовать что-то, а найти решение конкретной бизнес-задачи, используя продукт как инструмент. И это в нашем примере кейс клиентского сервиса.
2. «Бизнес» выделяет сотрудников внутри коммерческих структур, те изучают процессы клиентского сервиса, придумывают точки оптимизации и приносят в команду 1С запрос найти решение по реализации в продукте конкретных вещей. В этом случае трансформация процесса остается на стороне бизнеса целиком и полностью, команда придумывает решение на продукте. В нашем примере такие кейсы у бухгалтерии и казначества.

Вывод: вам следует четко определиться, какого уровня задачи будет решать ваш владелец продукта и продуктовая команда, делегируете ли вы им решение бизнес- задачи или только разработку продукта. В обоих вариантах команда будет и должна проработать варианты решения с бизнесом и отвалидировать их пригодность, но масштаб задачи в 1 и 2 вариантах принципиально разный. В любом случае вам нужен кто-то, кто заточит продукт под бизнес, а значит, речь идет минимум о Владельце Продукта, максимум – о разделении роли на Менеджера Продукта (который будет смотреть в сторону бизнеса) и Владельца Продукта (который будет смотреть в стороны продукта).

Шаг 5. Определяем критерии, как мы измерим успешность работы продукта и продуктовой команды

Вопросы-шпаргалки, которые помогут найти ответы:

Допустим, мы наняли команду, которая разрабатывает продукт, как мы поймем, что команда делает свою работу на отлично?
Что именно мы ожидаем от такой команды?
Как мы сможем измерить полученные результаты? Есть ли варианты внедрения качественных и количественных оценок?

Наш пример: По задачам бухгалтерии и казначейства вполне допустимо поставить задачи в формате KPI (что именно, когда именно и как должно быть сделано). Здесь мы должны поставить явные задачи в виде функционала и явные сроки. По задачам клиентского сервиса отлично подойдет подход OKR, ведь мы ставим перед командой вполне себе амбициозную цель и можем сформулировать конкретные ключевые результаты. И мы уже знаем, что в конечном итоге можем измерить ту самую экономию на найме, первые результаты которой мы получим уже в ближайшие три месяца.

При желании оба кейсы мы можем подкрепить CSI-опросом и получить в том числе качественную оценку работы продуктовой команды.

Вывод: думайте сразу о том, как и посредством чего вы измерите результаты работы (как бы это ни звучало банально), умеете ли вы измерять то, что хотите поставить как основные метрики, отдаете ли вы предпочтение получению бизнес- результата или также хотите измерить удовлетворенность пользователей. Задайте метрики и критерии успеха до момента старта работ.

Итого:

Подытожим, какие шаги обязательно нужно пройти перед запуском любой работы с внутренними продуктами:

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

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

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

Если нужна плотная сборка бизнеса и нескольких продуктовых команд, чтобы обеспечить решение ваших задач «под ключ» и получить ту самую заветную ценность, как в нашем примере с клиентским сервисом, то вполне можно примерить на себя сборку SAFe® (Scaled Agile Framework®).

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

Анализируйте вашу ситуацию, критично подойдите к ответам на базовые вопросы, пробуйте, тестируйте и все точно получится!

И приходите с вопросами!

Курс Product Owner

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

Зарегистрироваться

Метки: Продукт

Автор:

Екатерина Смирнова

Поделиться