Давно хотел порассуждать на тему отличия создания SaaS (он-лайн) сервисов для малого и среднего бизнеса от создания классических систем автоматизации того же сегмента бизнеса, что собственно, и начну делать сегодня. В моей терминологии классическое решение — это десктопное платформенное решение, которое реализует тот или иной функционал для СМБ и может быть кастомизировано под потребности клиента.
Цена вопроса создания во главе угла.
Вместо преамбулы посмотрю на создание нового сервиса с точки зрения цены вопроса/необходимых ресурсов.
В случае SaaS команды cтартапов обычно в начале пути имеют:
а) небольшие бюджеты на создание;
б) понимание «как делать» — full house функциональности решения, классификацию системы автоматизации или стандарт прикладной области, т.е. некое классическое понимание архитектуры создания приложения;
в) временные и другие ограничения — команда вынуждена начинать продавать быстро и не всегда продукт, соответствующий законченному Roadmap;
г) сочетание ограниченного бюджета разработки и небольшая цена продажи решений SaaS в будущем.
Каждый пункт влияет на процесс разработки в целом, но найдя новые подходы в не финансовых и ресурсных ограничениях разработчики могут начинать создание SaaS cервисов, меняя классические подходы, ограничения и зависимость от ранних знаний о разработке.
Как же оптимизировать стоимость разработки?
На мой взгляд, эффективны несколько подходов оптимизации не ресурсных составляющих проекта разработки.
Первый — делать не фичи, но вертикальные простые решения, даже не вертикальные, а закрывающие потребности работы отдела, группы в компании, распределенной группы. В этом случае главное угадать куда приложить усилия — что автоматизировать. Например, Василий Шабат в начале эпохи зарождения 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 сервисов.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий