Статья в разработке. Вы можете читать все, что написано ниже, но на свой страх и риск 😎
Вы можете говорить на одном языке и с разработчиками и с бизнесом. У вас есть силы и желание этим зарабатывать — нанять айтишников, найти клиентов и делать полезные штуки для бизнеса.
Вы можете внедрять корпоративные решения (CRM, ERP, BPM и так далее) клиентам и решать их проблемы одним из следующих способов.
Это самый хардкор. Это круто. Убедитесь, что у вас или у вашего партнера есть серьезное техническое образование. Если вы выбрали этот путь — будьте готовы к enterprise огромным проектам, которые длятся годами.
Следите, чтобы не было слишком большой текучки айтишников. У вас под рукой всегда должны быть те, кто может починить и доработать систему.
Если компания клиента может себе позволить внедрение за десятки миллионов рублей, то они могут взять проверенные решения:
— Microsoft
— Oracle
— SAP
Это будет очень дорого для клиента и для вас, но так делают все крупные игроки.
Если процессы клиента полностью совпадают с тем, что настроено в готовых коробках:
— 1С
— Битрикс24
— amoCRM
— Megaplan
Пусть клиент выбирает их — это самый дешевый способ получить рабочее решение.
Во всех остальных случаях клиенту нужен конструктор:
— гибче, чем коробка
— дешевле, чем решение для крупного бизнеса
— прост в использовании, чтобы справляться даже небольшими усилиями IT специалистов.
Внедрение может быть совсем небольшим. Например, вы можете взять шаблон, который уже реализован создателями платформы и доработать его. В таком случае клиент обычно платит вам одним платежом. У вас проект не занимает много времени и в основном вы зарабатываете на доработках и технической поддержки по этому проекту.
Большие проекты по внедрению обычно бьются на стадии. Отдельно берутся деньги за анализ и описание бизнес-процессов, отдельно за первый пилот и уже за само внедрение. Это нужно для того, чтобы и вы и клиент могли в любой момент выйти из сделки с небольшими потерями.
Так во время анализа может оказаться, что внедрение системы займет слишком много времени и клиент не готов сейчас к таким затратам. Или наоборот, что у вас нет идей, как ему вообще решить свою проблему в текущем виде и сначала клиенту стоит перенастроить процессы в компании, а только потом заниматься автоматизацией.
Доработки обычно главная статья дохода у среднего интегратора. Дело в том, что любую систему можно улучшить. Как только вы реализовали клиенту то, что он хотел — ему в голову тут же приходят мысли как еще удобнее организовать процесс. После первого дашборда для руководителя отдела продаж к вам приходит директор по маркетингу и просит что-то похожее собрать для него. Собственник хочет автоматизировать не только продажи, но и склад. И так далее. С клиентом, у которого есть деньги на развитие чем больше вы делаете, тем больше он хочет сделать.
Самая стабильная статья дохода. Часто, если low-code платформа достаточно гибкая, ее создатели не могут оказывать техническую поддержку клиенту, который получает от вас конечное решение. Просто потому, что вы можете настраивать систему как угодно и только вы и клиент знаете “где кнопка” или “как открыть все транзакции, которые заводила Наталья Игоревна в прошлом месяце”. Клиент может забирать часть этих функций на себя через своих сисадминов, а может заключить с вами договор на техническую поддержку от вас и вы будете отвечать на запросы его сотрудников по системе. Денег не много, но если вы верно выстроите процесс, часто задаваемые вопросы выпишите в корпоративную wiki и будете вовремя отвечать на запросы, со временем поддержка может отнимать мало сил, но генерировать хороший постоянный доход.
Обычно вы покупаете лицензии у вендора со скидкой, а продаете конечному клиенту за полную стоимость. Часто полная стоимость лицензии регулируется вендором. Узнайте на сайте платформы, с какой начальной скидкой вам будут продавать лицензии. Помните, что чем больше вы покупаете лицензий у вендора, тем большую скидку он готов вам дать.
Уточните, как долго вы будете получать деньги с лицензий клиента. Бывают платформы, которые проводят через вас лицензии клиента только первый год. Есть системы, где вы получаете свой бонус от лицензий до тех пор, пока клиент не позвонит вендор и не попросит сменить партнера. Узнайте, насколько просто это сделать. Какая политика создателей платформы на этот случай.
На рынке есть no-code конструкторы. Они прекрасны. Там можно накликать себе решение вообще без разработчика.
Проблема с такими решениями обычно возникает, если пользователь хочет в одну таблицу положить больше чем 10 000 записей. Все перестает работать. Так как часто такие решения не выдерживают серьезных нагрузок.
Но если клиент небольшой — это может быть отличный ход. Пример no-code платформ можно посмотреть в гугле по запросу no-code. Там много интересного.
Но, если вы выберете одно из no-code решений, будьте готовы, что клиент в какой-то момент скажет “а дальше я сам” и пойдет руками донастраивать ваши таблички, формы и процессы. Может, все сложится отлично. Может быть, вам придется спустя полгода пытаться понять, что он там “донастроил” и как клиента спасти от неверного бизнес-процесса.
Low-code платформы обычно чуть более требовательны к разработчику (надо уметь программировать хотя бы немного). Но они также гибче и поэтому обычно более интересны интегратору. Так как, дорабатывать платформу в любом случае будет кого-то с техническим образованием. То есть не придется потом все бесконечно переделывать за клиентом.
Главное правило при оценке стоимости разработки: чем больше требований к разработчику тем больше он стоит. Самые дешевые — вчерашние студенты. Самые дорогие — те, кто освоил очень много и очень разных технологий.
Обычно складывается из требований к разработчикам. В мире ИТ главные затраты — это зарплаты. Поэтому важно смотреть на то, какого уровня требуются сотрудники для разработки на конкретном low-code решении. Для этого анализа хорошо подойдет hh.ru.
Например, если вы хотите внедрять SAP вам стоит посмотреть, какие зарплатные ожидания у кандидатов разработчиков с опытом работы с этой системой и сколько предлагают работодатели.
Если платформа на рынке недавно, то стоит посмотреть, какие навыки требуются для изучения платформы и попросить сотрудников, у которых есть эти навыки собрать простенькое решение на этой платформе.
Например, для создания на платформе ozma.io надо, чтобы разработчик знал SQL и JavaScript. То есть можно просто выслать любому начинающему разработчику с этими навыками ссылку на документацию wiki.ozma.io и попросить собрать какую-нибудь небольшую CRM со сделками по статусам и карточками клиентов.
Зайдите на сайт вендора как клиент.
Если вы понимаете, как получить клиентов, которые готовы столько платить — можно смело выбирать этого вендора. Если нет — стоит придумать, как организовать ваш маркетинг и продажи, чтобы начать общаться с такими клиентами.
Задайте какой-нибудь вопрос про платформу. Если не можете придумать — попросите разработчиков. Задайте этот вопрос. Как быстро вы получите ответ от технической поддержки? Вы можете им написать? А позвонить? Кто создатели платформы? Вы можете с ними связаться?
На проекте с клиентом у вас не будет время ждать 10 рабочих дней ответа от создателей платформы. Вам надо, чтобы реакция была быстрой. Убедитесь, что это так заранее.
Почитайте сайты, отзывы и поговорите с создателями платформы. Будут ли вам приходить заявки на внедрение от платформы с их сайта, или все ваши заявки вам придется добывать самим? Как устроен этот процесс? Занимается ли вендор сам внедрением и не будет ли он все самые вкусные заявки оставлять себе? Хорошие вендоры не конкурируют со своими партнерами.
Самый верный способ понять, стоит ли вам работать с конкретной платформой — попробовать что-то простенькое собрать под себя или просто “в стол”. Для такого проекта нужно несколько дней разработчика. Но так вы точно поймете основные возможности и ограничения платформы. Будете знать, что предлагать клиенту.
Если на это совсем нет ресурсов и времени — можно посмотреть видеообзоры платформы, скриншоты на сайте и пообщаться с создателями.
Если вы выберете одного вендора и будете предлагать решения только от него — это очень интересно вендору. Он может даже вам предлагать какие-то бонусы за это. Но дело в том, что не существует универсальных решений. И в разных ситуациях разным клиентам нужны разные системы. Кому-то для идеальной работы не хватает просто нормально настроенной доски в Trello, а кому-то для выхода на IPO очень нужен SAP.
Дайте клиенту выбор. Ориентированность на одну платформу сужает ваши возможности. По ходу работы вы нащупаете, с какими платформами вам проще всего работать и что чаще нужно клиентам.
Я Кирилл Маркин, основатель компании Ozma Inc. Занимаюсь развитием партнерской сети платформы ozma.io: мы помогаем разработчикам, интеграторам освоить low-code платформу и собирать для своих клиентов красивые CRM и ERP системы. Моя цель — чтобы любой разработчик мог собрать решение для конечного клиента за несколько дней.
Чтобы попробовать собрать что-то на платформе ozma.io для своих клиентов, зарегистрируйтесь в партнерской программе: ozma.io/ru/partners/.
Или напишите мне в telegram: @kirmark.