Как вырастить корпоративный сервис в клиентский продукт

Наверное, история создания многих клиентских сервисов начиналась в пределах собственной компании. Сначала придумали костыль, чтобы решить свою проблему. Затем, когда все полетело, — решение отправили в мир. Так было со многими продуктами Контура и сервисами нашего Удостоверяющего центра в частности. Как понять, будет ли полезен ваш продукт другим клиентам, и стоит ли в это вообще ввязываться, расскажу я — Сергей Лапшин, менеджер проектов в Удостоверяющем центре Контура. В УЦ занимаюсь многими проектами. Но свой рассказ сегодня буду вести на примере сервиса Корпоративный центр регистрации. Если кратко: он позволяет компаниям получать сертификаты электронной подписи и идентифицировать личность будущих владельцев на рабочих местах.

Сначала введу в контекст

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

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

И делаем мы это разными способами:

• стандартный — это, конечно, веб-интерфейсы.

• если клиенту удобно работать в собственной информационной системе — предоставляем API-решения.

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

• среди клиентов у нас есть даже удостоверяющие центры — для них у нас есть on-prem решение.

Многие продукты появлялись как внутренние сервисы

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

Потом для взаимодействия продуктов Контура с удостоверяющим центром мы стали использовать API Корпоративного центра регистрации. На старте он был просто внутренним инструментом, а потом стал успешным коммерческим продуктом. Сейчас он позволяет нам взаимодействовать с другими разработчиками ПО и предоставлять им услуги УЦ как кусочек собственного сценария — особенно это хорошо работает в кЭДО.

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

Есть план, и его можно придерживаться

Обычно процесс превращения внутреннего сервиса в продукт выглядит так:

1. Компания решает какую-то собственную задачу, изучает контекст и набивает шишки.

2. Исследует рынок или работает со входящими запросами.

3. Понимает, что у клиентов есть запрос на решение такой же проблемы.

4. Оценивает масштабируемость продукта и считает бизнес модель.

5. Проводит техническую и юридическую аналитику и разработку для отделения продукта от своей инфраструктуры.

6. Успешно продает и масштабирует.

7. Или набивает шишки и закрывает проект. Такое бывает тоже.

Как исключить последний пункт из плана

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

1. Если не готовы заниматься заказной разработкой, решение должно быть тиражируемым.

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

2. Процессы клиента могут сильно отличаться от ваших.

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

3. Решения не существуют в вакууме. Думайте про отделяемую инфраструктуру на старте.

IT-продукт — это не только интерфейсы, поля для ввода и сценарии. Не забывайте, что еще это и инфраструктурные решения: СУБД, инструменты управления правами, балансировщики и др.

Как это работает в конкретной компании — нужно обязательно выяснить. Да, если предоставляете продукт как SAAS, то можете обойтись небольшим техническим ревью. Но если это on-prem, будьте готовы к большому бандлу задач для разработки. Очень часто этот пункт остается зря недооценен.

4. Думайте про систему доступа

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

У внутреннего продукта больше шансов на успех

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