Метрики и KPI в операционном управлении SaaS стартапом

Для технологических компаний и стартапов способность измерять, анализировать и действовать на основе конкретных операционных данных играет ключевую роль. Если вы управляете растущим стартапом, вам, вероятно, уже сейчас необходимо задуматься о KPI и операциях. Они не только повысят ваши показатели эффективности, влияя на маржинальность, но и помогут завоевать конкурентное преимущество за счет меньшего time-to-market, выстроить репутацию надежного вендора, открывая огромные возможности для B2B рынка. Например, тщательное отслеживание времени реагирования на инциденты и MTTR со стороны Amazon сыграло решающую роль в поддержании ее репутации как надежного и быстрого сервиса. В этой статье я собрал несколько наиболее частых метрик, которые я использовал, внедрял и перенимал от компании к компании за свою карьеру в startup operations.

Доступность имеет решающее значение для SaaS-компаний или любого технологического бизнеса, зависящего от непрерывного использования. Эта первая к внедрению метрика для сервисов, к которым пользователям нужен доступ постоянно, а технические неполадки напрямую влияют на возможность функционирования их бизнесов. Salesforce, например, сделала Availability своей CRM ключевым ценностным предложением, понимая, что даже минимальное время простоя может привести к значительным потерям для их клиентов.

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

Пример: облачный сервис был недоступен 2 часа в течение месяца. (1−2/720)×100%=99.72%

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

Как считать: обычно с подсчетом этой метрики отлично справляется тикет система вроде Zendesk. Необходимо общее время ответа разделить на количество тикетов за период. Вам может потребоваться время ожидания первого ответа — эта метрика считается аналогично.

Пример: Допуcтим, ваша тикет система показывает 400 часов общее время ответа за последний месяц и 100 тикетов. Вашe среднее время ответа — 4 часа.

Среднее время реагирования (MTTR) — важнейший показатель для любой технологической компании. Как и доступность сервиса, он особенно важен для тех, кто работает в отраслях, где непрерывность обслуживания имеет первостепенное значение. MTTR количественно определяет среднее время, необходимое для устранения неисправности, что позволяет оценить эффективность своего реагирования на технические проблемы. Быстрое MTTR часто является ключевой целью для SaaS компаний.

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

Пример: в прошлом месяце у вас было 5 инцидентов и общий даунтайм — 10 часов. В этом случае MTTR составит 2 часа.

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

Как считать: общее время работы разделить на количество отказов за указанный период.

Пример: если сервис проработал 1000 часов и испытал 5 технических сбоев, среднее время безотказной работы составит 200 часов.

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

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

Пример: Затраты отдела поддержки составили 10 000 долларов за месяц, было решено 500 обращений. Стоимость каждого обращения составила 20 долларов.

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

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

Пример: инкремент продукта c суммарным количеством стори поинтов 100 выпустили за 2 спринта, velocity составит 50 стори поинтов за спринт.

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

1. Определите основные цели. Начните с определения того, чего ваша организация стремится достичь с точки зрения предоставления услуг, удовлетворенности клиентов и технического совершенства. Например, если сокращение оттока клиентов (churn) является приоритетом, имеет смысл выявить причины и сфокусироваться на них. Это может быть как низкая availability сервиса, так и скорость ответа команды поддержки.

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

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

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

5. Ставьте KPI осознанно. KPI может навредить стартапу, если ставить его неосознанно. Например, если вы еще не знаете, как достичь 100% availability, то и ставить такой показатель бесполезно. При этом, если ваш сервис обычно работает бесперебойно и это закреплено в SLA, то KPI может быть вполне уместен. Для целей с более высокой степенью неопределенности может лучше подойти система OKR, особенно когда речь идет о технологическом стартапе.

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