Как потребность бизнеса может перерасти в коммерческий продукт

Мы поговорили с Натальей Акулиничевой, генеральным директором IT-компании LogicBPM о том, что первично при создании стартапов: идея или конкретная задача

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

В нашем случае это была конкретная задача. Я руководила и продолжаю руководить компанией, которая организовывает IT-поддержку для ресторанов. Речь идет об очень большом количестве клиентов и таком же количестве заявок на обслуживание, которое от этих клиентов приходит. Чтобы вы понимали масштаб — это 1500+ клиентских заявок в день. Для таких компаний очень важны два фактора: а) скорость (не только реакции, но и решения вопроса); б) качество (когда клиенты не возвращаются повторно с одной и той же проблемой). И, конечно, нужно предоставлять высокий уровень сервиса 24/7, что без внутреннего ПО просто невозможно.

Как на тот момент выглядел IT-ландшафт этой компании?

Все клиентские заявки и процессы велись в специальной системе. За основу была взята BPM-система с low-code инструментарием, и наши разработчики выстроили нужные процессы с учетом особенностей нашего бизнеса. Но проблема заключалась в том, что эта система регулярно «падала». А когда у тебя такая нагруженная поддержка, и клиенты ждут помощь «прямо здесь и сейчас», ты не можешь себе позволить работать на «падающем» ПО. При этом мы честно пытались привести систему в чувство, но все наши попытки не увенчались успехом. Чем больше росло количество новых клиентов, тем больше росла наша нагрузка, и тем чаще случались эти «падения». Клиенты не получают помощь — и уходят. Бизнес их теряет.

Однажды предыдущий сервис не работал несколько дней. Несколько дней! Клиенты обращаются, звонят, пишут. А сотрудники вынуждены работать буквально на листочках. Естественно, клиенты разочаровываются — мы не оправдываем их ожиданий. Сотрудники при этом стрессуют и не понимают, как мы дошли до такой жизни. Мы (топ-менеджмент) боремся за то, чтобы оперативно восстановить все данные и поднять систему… Но это занимает время.

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

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

Естественно, сначала мы искали ПО на рынке. Потому что создание собственного продукта не всегда является оптимальным решением. Мы сформировали пул требований, при этом я бы не сказала, что они были из разряда фантастики. Первым пунктом шло требование на устойчивость — чтобы несмотря на нагрузки и масштабирование компании система оставалась в стабильном состоянии. Второй пункт — нам необходимо было видеть метрики. Речь шла о таких метриках, например, как: SLA по скорости принятия задачи в работу, SLA решения задачи, данные о движении задач в стеке. Причем метрики хотелось видеть реальные, а не придуманные. Например, когда система считает срок выполнения задачи, она может при некоторых статусах останавливать счетчик времени: инженер получил задачу и сразу запросил у клиента дополнительную информацию, перевел задачу в статус «Ожидает ответа клиента» — счетчик времени остановился; клиент ответил через 15 минут, но инженер вернулся к задаче только через 5 часов и доделал всю работу за 5 минут. По метрикам задача решалась 5 минут, а клиент в реальности ждал более 5 часов. 

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

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

Конечно, к проекту мы подошли со всей ответственностью. У команды были навыки ведения бизнеса в других отраслях, на которые мы опирались. Мы оценивали потенциальный рынок (причем не только российский), общались с потенциальными клиентами и изучали продукты других игроков. Мы хотели понять, а сможем ли мы закрыть потребности рынка, при этом создав не баснословно дорогое ПО. И в какой-то момент мы осознали, что есть еще одна боль, на которой до этого мы не фокусировали свое внимание: продукты, которые подходили компаниям на начальном этапе развития, могут уже через год-два им совсем не подходить. Это происходит за счет того, что не каждое ПО способно масштабироваться вместе с бизнесом, который его использует. Поясню: очень много продуктов способны подстраиваться под формат бизнеса клиента. То есть в моменте, когда клиент его покупает, он может подстроить его под себя и увидеть цену именно этой конкретной версии. А потом, когда клиент начинает расти и развиваться, ему приходится примерять на себя новую версию такого ПО, и вот она уже может стоить совсем других денег. 

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

Насколько рискованным тебе на тот момент казалось решение создать продукт с нуля?

Любой стартап — это риск. Особенно в турбулентное время. Но если ты не попробуешь — ты не узнаешь, попал ты или не попал. Страшно, да, было очень страшно. Но не делать было невозможно. Мотивировала мысль, что мы нашли решение реальной задачи, боли, которая есть на рынке. И что если мы не будем ее закрывать, то это рано или поздно сделает кто-то еще. 

Скажи, а что тебе, как руководителю, пришлось делать по-другому, когда ты сменила роль с «заказчика» на «производителя» решения?

Мне необходимо было быстро перестроиться, чтобы смотреть на продукт не глазами заказчика системы, а глазами производителя. Производитель ведь думает не об одном заказчике, а о разных категориях клиентов. И в этом есть большая разница: когда ты заказчик, ты ориентируешься только на свои бизнес-процессы и составляешь техническое задание под себя. А когда ты создатель рыночного продукта, тебе необходимо «надевать шляпы» разных клиентов и смотреть на функционал с разных точек зрения. Уже не пройдет тот фокус, когда ты приходишь в команду разработки и говоришь «в этом разделе делаем табличный вид». Ты начинаешь изучать: а кто пользуется табличным видом? А зачем они это делают? А какую потребность закрывают и можем ли мы закрыть эту потребность каким-то другим способом? Принимая те или иные решения я даже удивляюсь сама себе — на месте заказчика я бы думала абсолютно по-другому. 

Пришлось ли менять саму логику продукта, когда ты стала смотреть на него глазами внешнего клиента?

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

С какими главными сложностями ты столкнулись при выводе LogicBPM на рынок?

Кажется, что сейчас на рынке самое непростое время. Идет борьба буквально за каждого клиента. И важным становится не только процесс продажи, сколько процесс дальнейшего обслуживания и поддержки. «Плечо после покупки» становится очень важным элементом. И если вы поговорите с клиентами многих IT-интеграторов, вы услышите одну и ту же жалобу: «После того, как мы оплатили счет на покупку ПО, мы как будто попали в другой мир. Мир, где мы вынуждены стоять в очереди, стучаться во все двери, бесконечно эскалировать проблемы и надеяться, что нам помогут разобраться с нашей задачей вовремя». 
И сейчас мы как IT-компания надеемся изменить парадигму: переместить фокус с продаж на фокус постпродажного обслуживания. На легкий процесс содержания системы. В идеале — максимально самостоятельного.

Были ли моменты, когда хотелось «откатить все назад» и не заниматься больше стартапом?

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