Давно хотел порассуждать на тему отличия создания SaaS (он-лайн) сервисов для малого и среднего бизнеса от создания классических систем автоматизации того же сегмента бизнеса, что собственно, и начну делать сегодня. В моей терминологии классическое решение — это десктопное платформенное решение, которое реализует тот или иной функционал для СМБ и может быть кастомизировано под потребности клиента.
Факторы, влияющие на разработку.
Вместо преамбулы посмотрю на создание нового сервиса с точки зрения цены вопроса/необходимых ресурсов и их экономии.
В случае SaaS команды cтартапов обычно в начале пути имеют:
а) ограниченные бюджеты;
б) понимание как и для кого делать сервис — full house функциональности решения, классификацию системы автоматизации или стандарт прикладной области, т.е. некое классическое понимание правил создания приложения;
в) временные и другие ограничения — команда вынуждена начинать продавать быстро и не всегда продукт, соответствующий законченному Roadmap;
Каждый пункт влияет на процесс, сроки, качество разработки в целом. Все ограничения обусловлены самой задачей и постоянны, кроме не финансовых ограничений (пункт «б»). На мой взгляд, при создании SaaS cервисов необходимо смотреть более свободно на классические требования к процессу разработки, оптимизируя так остальные постоянные затратные части проекта без видимых изменений качества решаемой задачи. Т.е. необязательно применять при создании SaaS сервисов постулаты, которые работали раньше при создании классических систем автоматизации.
Упрощение сервисов без риска для результата.
Первый — делать не фичи, но вертикальные простые решения, даже не вертикальные, а закрывающие потребности работы отдела, группы в компании, распределенной группы. В этом случае главное угадать куда приложить усилия — что автоматизировать. Например, Василий Шабат в начале эпохи зарождения SaaS в России сделал сервис учета командировок и только потом понял, что сервис востребован крупными компаниями, не продает сам себя, требует усилий по интеграции с учетными системами и уже реализован многими консервативными игроками.
Пример облачных сервисов: Департамент логистики Columbus Мой склад
Классический подход: больше функционала — сделать все по максимуму, в надежде, что вдруг кому и пригодиться 1053-ая нужная функция.
Второй — идти по пути «отрезания лишнего функционала». Что я под этим подразумеваю — не следование стандартам, например, ITIL и “обрезания» большого пласта функциональности решения, например, прав доступа. Из удачных примеров последнего ASANA, философия cоздателей которой в том, что в небольшой группе сотрудников администрирование прав доступа в целом не нужно — все 10 пар глаз итак понимают, что они в отличном коллективе единомышленников и скрывать друг от друга нечего, да и руководитель прекрасно видит, что делает подчиненный в «открытом» пространстве сервиса и в офисе 5 на 5 метров.
Классический подход: Servis Desk — это ITIL, Pink Elephant, но зачем это команде из 10 человек?
Третий — пробовать сочетать простые продукты в бандлы, которых еще нет или начинать разработку огромного Шатла с такого нестандартного сочетания — бандл просто может оказаться удачным. Но не экспериментируйте с Unified communications — этого уже достаточно.
Примеры облачных сервисов: Quickme SMEOn
Классический подход: рамки CRM или HRM или Docflow + консалтинг + обучение + изменение мышление компании… для чего это в SaaS? SaaS призван экономить!
Шансы есть (вместо выводов).
Я не пытался пока говорить о технологическии создания приложений SaaS, которая сама по себе дешевле (мультитенантность, например) и сделал акцент на идеологических вещах, которые помогут упростить и удешевить процесс cоздания. Получилось, что первый подход — это явная экономия при попадании в цель. Второй подход — оптимизация затрат на разработку из-за ненужности части функционала СМБ. Третий — поиск своего пути и позиционирования. Таким образом, чтобы приблизить успех делайте простой сервис — применимый тремя сотрудниками компании, оставьте все лишнее и езжайте с одним чемоданом, в котором будет одна сорочка — решение проблемы клиента. Ну и сочетайте классику и Casual в подходах, если не страшно.
! Важно, что у разработчиков SaaS приложений есть уникальная возможность экспериментировать — упрощать свои сервисы и создавать новую философию автоматизации.
Будет продолжение и будут интересные гости от разработчиков ведущих российских SaaS сервисов.
Алексей Калачников
Блог автора http://www.bootstrap24.ru/
http://Quickme.ru/
Материалы серии «Как создавать и зарабатывать на SaaS»
- Часть I / убрать все лишнее, попасть в цель, экспериментировать
- Часть 2 / бесценный опыт российских ISV
- Часть 3 / продажи через партнерский канал, который, возможно, и не нужен
- Часть 4 / cтартап Quickme – коммуникации и совместная работа небольших команд
- Часть 5 / повсеместная интеграция SaaS, как милая угроза остальному бизнес ПО или как 1+1 превращается в 3
- Часть 6 / Quickme история для партнеров или 7 причин делать дела вместе
- Часть 7 предфинал / почему же не продается SaaS?
- Часть 8 — ФИНИШ / SaaS — реалии российского рынка
- Случайно забытая Часть 9 / Юридический туман SaaS
- Часть 10 / Метрики бизнес модели
- Часть 11 / Обзоры облачных сервисов / UX и юзабилити тестирование
