Полная автоматизация в облаке

Недавно на Хабре была статья о том, как продавать ^[1] облачные сервисы. Мы решили рассказать о более популярном кейсе — как их использовать — на собственном примере.

Наша компания — провайдер облачного сервиса МойСклад ^[2]. Недавно я задумался — насколько активно мы сами используем облачные сервисы в своей собственной работе? Оказывается, все уже перенесено в облако. У сотрудников на компьютерах установлены только Skype и Microsoft Office. Я хочу рассказать, к какой инфраструктуре мы пришли и с чем столкнулись по пути.

Компания начиналось с того, что компании как таковой не было, была только команда. Команда была распределенной, и поэтому мы с самого начала использовали облачное ПО (тогда это называлось SaaS). Все документы, планы и спецификации создавались в Google Drive (тогда еще Google Docs).

Потом сервис запустился и начались его продажи. В качестве CRM мы по привычке использовали табличку в Google Drive. Я искренне думаю, что при небольшом объеме данных это очень хороший инструмент. Он очень наглядный и очень простой, проще чем любые специализированные сервисы типа Highrise CRM ^[3]. Например, чтобы изменить статус лида, достаточно изменить цвет фона в строке.

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

Разумеется, полноценные сервисы CRM нужны. Табличка в качестве CRM отлично работала, пока у нас было несколько лидов в день. Приемлемо — когда лидов стало несколько десятков в день. И наконец, когда число лидов увеличилось до сотни в день, работать стало практически невозможно, в основном из-за того, что основные операции типа поиска стали выполняться очень медленно.

Люди по природе очень ленивые, поэтому мы упорно продолжали пользоваться табличкой, пока не уперлись в физическое ограничение: в таблице Google Drive не может быть больше 400 тыс ячеек. Только тогда мы перешли на полноценную Zoho CRM ^[4]. На сам процесс перехода мы потеряли одну или две недели своего времени. Но после этого мы ежедневно экономим 20-30 минут рабочего времени каждого сотрудника за счет быстрого выполнения базовых операций и интеграции с биллингом МоегоСклада.
Зоопарк сервисов

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

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

В нашей компании четыре отдела: разработка, маркетинг, продажи и поддержка. Мы пришли к тому, что каждый отдел для автоматизации использует свой собственный сервис. JIRA ^[5] для разработки, Zendesk ^[6] для поддержки, Zoho СRM для продаж. Отдел маркетинга у нас самый непродвинутый и пользуется только универсальным сервисом для управления задач Trello ^[7].

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

Нам очень нравится собственный сервис МойСклад, но он не предназначен для автоматизации отдела продаж в сервисной компании, такой как наша. Для продаж мы используем Zoho CRM. Но Zoho — американский сервис. Он ничего не знает про наши российские акты и счета-фактуры. Поэтому для документооборота мы используем МойСклад, в результате отделу продаж требуется уже два сервиса.

Помимо упомянутых сервисов, мы используем еще и:

• Облачную АТС Телфин ^[8];
• Сервис хранения исходных кодов Bitbucket ^[9];
• Сервис email рассылок Unisender ^[10];
• Площадку Mirapolis ^[11] для проведения вебинаров.

Как вы видите, приходится использовать много отдельных сервисов. Естественно, что весь этот зоопарк хочется как-то интегрировать друг с другом. И это, наверное, самая большая проблема при полном переходе в облака.

У большинства популярных сервисов уже есть стандартные коннекторы для интеграции, но часто их работа по какой-то причине не устраивает. Например, мы не смогли использовать стандартную интеграцию Zendesk (поддержка пользователей) и JIRA (управление разработкой). Сотрудники поддержки работают в Zendesk. Если они считают, что запрос пользователя связан с ошибкой в нашем сервисе, то могут одной кнопкой создать из запроса связанный тикет в JIRA. Это очень удобно. Не очень удобно то, что все изменения в тикете будут автоматически транслироваться в обратно в обращение, и пользователь сможет их увидеть (например, “не будем исправлять — это проблема всего у одного аккаунта”). Поэтому мы не пользуемся этой интеграцией, и сотрудники поддержки копируют заявки из Zendesk в JIRA руками.

Очень многое можно реализовать через API, например, регистрации в нашем собственном сервисе через API автоматически переносятся в CRM. Большинство сервисов предоставляют API. Недостаток этого подхода в том, что работа с API требует квалифицированных разработчиков. Даже у нас — компании, которая занимается разработкой собственного продукта — есть некоторые задачи, до сих пор нерешенные из-за нехватки времени, такие как интеграция нашей CRM с виртуальной АТС. Понятно, что для большинства не-ИТ компаний эта проблема будет еще актуальнее.
Если что-то пойдет не так

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

Мы столкнулись с такой проблемой, неудачно выбрав сервис для поддержки пользователей. В начале для этого мы использовали российский сервис Solvermate. Он привлекал, прежде всего, ценой и хотя у нас было много претензий к функциональности, мы были готовы мириться с этими недостатками, пока сервис развивался. К сожалению, разработчики приняли решение переориентировать сервис на совершенно другие задачи, а затем полностью закрыли его (на его сайте ^[12] сейчас продают аэрогрили). При этом я не могу сказать, что это событие негативно повлияло на нашу работу. Провайдер Solvermate за полгода предупредил нас об изменении политики, поэтому у нас было более чем достаточно количество времени для того, чтобы спланировать и провести миграцию.

Другой часто обсуждаемый вопрос — это безопасность. Мы не очень заморачиваемся этим вопросом. Я уверен, что провайдеры, услугами которых мы пользуемся, обеспечивают лучшую защиту данных, чем это сделали бы мы сами. Действительно, за 6 лет два или три раза из-за поломок мы теряли данные, которые хранились на наших ноутбуках. С облачными сервисами такого еще не происходило. Для спокойствия один или два раза в год мы выгружаем самое главное — базу с лидами и клиентами — из CRM.

Надежность — более актуальный вопрос. Мы полностью зависим от интернета в офисе и если он исчезает, работа останавливается. Впрочем, я думаю, что это уже типично для большинства современных бизнесов, не обязательно перешедших на 100% в облако. На случай недоступности критичных отдельных сервисов у нас предусмотрел аварийный “план B”. Например, в офисе лежит несколько мобильных телефонов. В случае каких-то проблем с виртуальной АТС входящие звонки переадресуются на эти мобильные.
Зачем все это?

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

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

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

Поэтому мы решили проработать другой вариант: свой мини колл-центр в другом городе. Чтобы выбрать оптимальный город, использовали hh.ru ^[13]. Мы сделали чарт из топ-10 городов России (+Минск) по числу резюме с названием “оператор call-центра”. Таким образом мы нашли города, в которых проще всего набирать персонал. После этого мы немного изменили ранжирование, учитывая уровень ожидаемых зарплат, и получили шорт-лист с тремя кандидатами: Воронежем, Минском и Нижним Новгородом.

Из трех кандидатов выиграл Нижний Новгород: у него лучшая транспортная доступность, нет дополнительных юридических расходов и политических рисков (в отличие от Минска).

За полтора месяца мы запустили новый колл-центр. Это время включает поиск офиса и сотрудников — уверен, что в Москве мы не смогли бы уложиться в эти сроки. Но главное — за счет фонда оплаты труда и стоимости аренды каждый месяц мы экономим несколько сотен тысяч рублей.

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

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

Аскар Рахимбердиев ^[14]
МойСклад ^[15]

Автор: oalexeev

Источник ^[16]