Как исследовать внутренний корпоративный продукт: методы, метрики и типичные ошибки

Год назад компания внедрила корпоративный портал за одиннадцать миллионов рублей, и на отчётном слайде всё выглядит прекрасно: учётные записи заведены у всех 2400 сотрудников, то есть охват стопроцентный. Проблема в том, что заходит туда каждый третий, заявки в HR по-прежнему приходят письмами, а документы коллеги пересылают друг другу в корпоративном мессенджере, потому что найти их в базе знаний быстрее не получается. Формально продукт внедрён, фактически люди работают мимо него, и никто в компании не может объяснить почему.

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

Содержание статьи

• Главное за 30 секунд
• Что такое внутренний продукт и чем он отличается от рыночного
• Почему стандартные продуктовые метрики не работают для внутренних сервисов
• Шаг 1. Отделите проблему заказчика от проблемы пользователя
• Шаг 2. Найдите обходные пути: где сотрудники работают мимо системы
• Шаг 3. Наблюдение за рабочим местом: главный метод для внутренних продуктов
• Шаг 4. Интервью с внутренним пользователем: как получить честные ответы
• Шаг 5. Какие метрики измерять после исследования
• Шаг 6. Как посчитать пользу внутреннего продукта в деньгах
• Как приоритизировать бэклог, когда заказчик один и он же руководитель
• Ограничения: что не получится исследовать внутри компании
• План действий на ближайшую неделю
• Часто задаваемые вопросы

Внутренний продукт это сервис, которым пользуются сотрудники компании, а не её клиенты: корпоративный портал, база знаний, система заявок, внутренняя CRM, ERP, инструменты для совместной работы и платформы адаптации новых сотрудников. Продуктовый подход к ним применяется тот же самый, но три условия меняются радикально, и именно из-за них исследование строится иначе.

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

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

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

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

Конверсия и удержание тоже теряют смысл. Пользователь не конвертируется, он получает доступ по должности, и он не уходит, потому что уходить некуда. Метрики, привычные по коммерческим продуктам, здесь показывают не поведение, а штатное расписание.

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


В сквозном примере картина по этим метрикам оказалась совсем не такой, как на отчётном слайде. Из 2400 сотрудников за месяц в портал заходили 912 человек, то есть 38%, из примерно 1900 заявок в HR через портал проходили 42%, а остальные 58% приходили письмами и сообщениями в мессенджере. Среднее время оформления заявки на отпуск составляло 12 минут против трёх, которые уходили на письмо руководителю..

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

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

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

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

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

Искать обходы стоит в четырёх местах, и все они доступны без специальной аналитики. Первое это входящая почта смежных подразделений: попросите HR или бухгалтерию посчитать за неделю, сколько запросов пришло не через систему. Второе это корпоративный мессенджер, где обычно живут пересылки документов и просьбы прислать актуальную версию файла. Третье это файловые хранилища с таблицами, дублирующими функционал платформы. Четвёртое это обращения в поддержку с формулировкой «как сделать», которые означают, что сценарий в интерфейсе не читается.

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

Такая картина совпадает с отраслевыми данными по корпоративным системам. Исследование Interact показывает, что 19,8% рабочего времени, то есть примерно один полный день в неделю, сотрудники тратят на поиск информации для работы, а корпоративный поиск даёт результат с первой попытки лишь в 10% случаев против 95% у Google, из-за чего люди перестают доверять внутренним системам и спрашивают коллег или заново делают работу, которую не смогли найти.

Отдельно посчитайте стоимость обхода для компании, а не для сотрудника. Письмо экономит девять минут оператору, но создаёт ручной перенос данных в HR, и в примере три специалиста тратили на эту рутину около 40% рабочего времени.

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

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

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

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

Классический CustDev внутри компании упирается в иерархию. Сотрудник знает, что продукт внедрял его руководитель или соседний департамент, знает, что продакт сидит этажом выше, и вполне резонно опасается, что критика системы прозвучит как критика начальства. Ответ по умолчанию в такой ситуации это «всё нормально, привыкли».

Снимается это несколькими приёмами, которые стоит применять вместе. Разговаривайте о процессе, а не о системе: вопрос «как вы оформляете отпуск» даёт факты, а вопрос «нравится ли вам портал» даёт вежливую оценку. Просите рассказать про последний конкретный случай с датой, потому что воспоминание о реальном эпизоде труднее пригладить, чем общее мнение. Обещайте агрегированные выводы и выполняйте обещание, не пересказывая руководителю, кто именно что сказал. По возможности подбирайте респондентов вне прямой цепочки подчинения заказчику исследования.

Рамка Jobs To Be Done работает здесь особенно хорошо, потому что переводит разговор с оценки интерфейса на работу, которую человек нанимает инструмент выполнять. Вопросы про то, что происходило до появления системы, как задача решалась раньше и в какой момент сотрудник возвращается к старому способу, дают больше, чем любые вопросы о функционале. Подробный разбор подхода есть в статье Концепция Jobs To Be Done.

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

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

Для сквозного примера набор получился такой.


Изменений потребовалось немного: автоматическая подстановка кода затрат из штатного расписания, сохранение черновика, интеграция портала с учётной системой и переписанный сценарий адаптации новых сотрудников с короткими подсказками вместо общего курса на два часа. Обучение сотрудников при этом сократилось, а не выросло, потому что часть шагов из процесса просто исчезла.

Отдельно стоит завести опережающий показатель, по которому вы поймёте ухудшение раньше, чем оно дойдёт до отчёта. В примере таким индикатором стала доля заявок, брошенных на середине заполнения: она реагировала на любые изменения формы в течение недели. Логика выбора главного показателя и дерева метрик под ним разобрана в статье OKR, дерево метрик и North Star Metric.c.

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

Считаем на примере. Заявок в месяц около 1900, экономия на каждой составила 8 минут, итого 15 200 минут или примерно 253 часа ежемесячно. При средней стоимости часа сотрудника в 780 рублей это 197 тысяч рублей в месяц, то есть около 2,4 млн рублей в год только на одной операции.

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

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

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

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

Работает здесь не спор, а перевод обеих сторон в единую систему координат. Когда каждая задача оценена через охват затронутых сотрудников, влияние на время операции, уверенность в оценке и трудозатраты, разговор перестаёт быть столкновением мнений. В примере доработка карточек сотрудников, которую HR считал первоочередной, затрагивала 2400 человек примерно раз в год, а исправление формы заявки касалось 1900 операций ежемесячно, и разрыв в приоритете стал очевиден без единого эмоционального аргумента. Механика оценки разобрана в статье Приоритизация по RICE.

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

Метод честнее работает, когда вы заранее знаете его слабые места.

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

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

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

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

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

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

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