Как создавать и продавать персонализированные решения, разбираемся вместе с генеральным директором АО «Гринатом Простые Решения» Светланой Борматовой и директором Департамента разработок и исследований ООО «ЛЕ-Интеграция» Сергеем Кружилиным.
Продажи технологичных продуктов зачастую находятся в прямой корреляции от подхода исполнителя к запросу заказчика — если он не индивидуален, в 90% случаев работа обречена на провал. Почему это так, и что необходимо сделать, чтобы выйти на успешные продажи? Сейчас разберемся.
Шаг I: Провести анализ
Представим, что запрос заказчика — небольшой юридической компании — разработка пропускной системы для сотрудников и клиентов. Она необходима, чтобы отслеживать опоздания и переработки сотрудников и ограничивать круг лиц, которые могут попасть в офис без приглашения.
Вариант 1: внедрить базовую стандартизированную систему, где n-ное количество безымянных пропусков распределят по сотрудникам, а оставшиеся будут вручать постоянным клиентам. Работоспособность этого пути — неубедительная: типовое решение не отвечает запросам заказчика.
Вариант 2: направить в офис заказчика аналитика и, на основе собранных им данных о бизнес-процессах клиента, разработать индивидуальную пропускную систему, которая будет учитывать персональные пропуска сотрудников и безымянные пропуска клиентов. Работоспособность в этом случае — гарантированная: все запросы заказчика проработаны.
В ИТ-компании со специальной экспертизой до старта разработки бизнес-процессы компании-заказчика изучают специально обученные специалисты. Они должны не только быть компетентными в своей сфере деятельности, но и уметь подстроиться и оперативно изучить бизнес клиента.
Работа на этом этапе может длиться от недели до года — в зависимости от сложности проекта.
Например, в компании, которая нуждается в импортозамещении на отечественные ОС и прикладное ПО, необходимо применить многоступенчатый подход и изучить всю инфраструктуру предприятия, связанную с процессом автоматизации: принципы работы, количество отделов и сотрудников, структуру бизнес-процессов, используемое программное обеспечение и так далее. Такое исследование будет намного более ресурсозатратным, нежели внедрение пропускной системы из примера выше.
Без детальной аналитики любое IT-решение рискует оказаться нерабочим. Поэтому ответственная команда никогда не будет экономить время и ресурсы, необходимые для этого процесса. Это залог успеха всего предприятия.
Только детальное изучение бизнес-процессов и специфики деятельности клиента дает аналитику и возможность выступить с решением по автоматизации.
Зачастую на этапе аналитики и разработки становится очевидным, что автоматизация целевого процесса, над которой работают IT-специалисты, будет неактуальна, если смежный процесс так и останется на прежнем уровне. Тогда появляется потребность расширить работу над задачей как со стороны разработчиков, так и со стороны клиента.
Подобная инертность иногда позволяет добиться даже больших результатов, чем было запланировано в самом начале пути.
Индивидуальный подход здесь имеет не меньшее значение. В автоматизации, созданной из коробки с лицензией, зачастую нет никакого смысла: она не работает, потому что не учтена специфика тех или иных подразделений, и отсутствует единое решение. В любом случае такое решение потребуется докручивать и настраивать под нужды клиента. Для этого должно быть одно из двух: либо высокая экспертиза внутри бизнеса заказчика, либо привлеченный IT-интегратор или IT-специалист.
Шаг II: Следовать циклу сделки
Масштабные проекты, в которых заказчику нужно все и сразу, могут потерять свою актуальность к моменту завершения. Жизнь вносит коррективы в экономическую реальность.
Именно поэтому проект можно и нужно разбивать на логические части, поэтапное решение которых обеспечит результативность всей работы. Их длительность при этом может варьироваться от 3 месяцев до 3 лет — в зависимости от масштабов.
Цикл включает в себя:
аудит;
предпроектное обследование процессов клиента;
составление технического задания, согласованного с клиентом на основании предпроектного обследования;
разработка;
внедрение;
тестирование и отслеживание проекта — под ключ или этапами.
Шаг III: Рассчитывать издержки
Каждый проект несет клиенту издержки. Исполнитель рассчитывает их во время аудита: какое программное обеспечение необходимо, каков цикл разработки, и сколько потребуется времени, ресурсов и человеко-часов для его реализации.
Расходы зависят от уровня продукта и экспертизы: есть редкие специалисты, которые стоят очень дорого, а есть те, которых на рынке много, а значит и цены за их услуги ниже.
Если заказчик и исполнитель понимают, что уровня экспертизы обоих не хватает для грамотной разработки какой-то части IT-решения, не стоит стесняться помощи опытных IT-интеграторов — подрядчиков, которые помогут наладить никак не поддающийся процесс или найти людей, которые на это способны.
Небольшой бизнес может и вовсе не прибегать к помощи крупных IT-корпораций. Для задач их уровня достаточно найти грамотного фрилансера. Однако стоит помнить, что при работе с компанией рисков намного меньше.
На стоимость проекта может повлиять также выбор технологий, сложность задач, необходимая заказчику скорость реализации. Результат работы над проектом может привести к очевидной экономии для бизнеса.
Чтобы клиенту это было так же прозрачно, как и исполнителю, составляется финансовая модель, которая отражает затраты заказчика и экономическую выгоду от внедрения решения в долгосрочной перспективе. Горизонт планирования не ограничен и может составлять от нескольких месяцев до десятилетий.
Шаг IV: Грамотно составить техническое задание
Составление технического задания (ТЗ) — самая болезненная для айтишников тема. Действительное понимание того, что и как хочет сделать заказчик, есть у него очень редко. В таких исключительных случаях клиент сам пишет ТЗ, по которому может работать команда.
Однако чаще всего разработчики сталкиваются с заказчиком, который не различает видение продукта и техническое задание на его воплощение, и рассказывает, скорее, пользовательскую историю о том, как должен выглядеть результат.
Запрос к IT-компании чем-то похож на тот, что люди оставляют, обращаясь к строителям. Чтобы дом построили так, как нужно клиенту, необходимо сообщить исполнителю, какой проект дома, какие материалы использовать, как клеить обои и класть кирпич. Но если строитель построит по указанию заказчика дом, то каким этот дом будет, отвечает исключительно заказчик.
Поэтому, чтобы IT-решение было действительно рабочим и используемым, в идеале техническое задание составляется исполнителем при плотном взаимодействии аналитиков с заказчиком.
В этом случае будут запрошены все данные и показатели о бизнес-процессах заказчика, необходимые для успешной разработки и внедрения рабочего решения.
Существует четыре стратегии работы с ТЗ:
Доверить все одному исполнителю.
Это — самый распространенный вариант. Однако заказчику всегда стоит внимательно оценивать экспертизу и компетентность исполнителя: иногда профессионалы в генерации идей и составлении ТЗ оказываются абсолютно посредственными специалистами, когда дело доходит до реализации проекта.
Разделить работу над проектом и составление ТЗ между разными исполнителями.
Поскольку техническое задание — это большой, весомый и объемный документ, на его разработку требуется много времени и средств. Поэтому иногда заказчик сначала обращается к одной компании для того, чтобы сделать предпроектное обследование и написать ТЗ, а потом нанимает другую компанию для непосредственной разработки.
Доверить составление ТЗ сотрудникам компании заказчика.
В редких случаях внутри компании клиента достаточно собственных квалифицированных кадров для составления ТЗ, и передавать задачу на аутсорсинг не требуется.
Не составлять ТЗ.
Бывают ситуации, когда необходимости в составлении технического задания нет. Это происходит, если заказчик хочет сэкономить деньги, исключив этап составления ТЗ из цикла работы над проектом. В таких случаях делают предпроектное обследование и сразу приступают к внедрению. За счет тесной связи аналитиков и разработчиков без этого этапа действительно можно обойтись, но только в некоторых случаях.
Шаг V: Выстроить личные отношения с клиентом
Несмотря на то, что реализацией проекта занимается IT-команда, заказчику необходимо объяснить, что участвовать в этой работе — его прямая задача.
Лучший вариант — договориться с клиентом о том, чтобы отдельный специалист из компании-заказчика непосредственно взаимодействовал с процессом разработки. Таким образом, у проекта появляется два руководителя: со стороны клиента и со стороны исполнителя.
Выгода такого решения — возможность оперативно решать вопросы, не размышляя о способах получить ответ от начальства или менеджера.
Оптимальное количество рабочих встреч с руководителем со стороны клиента — раз в неделю или две. Однако все зависит от масштабов проекта и этапа разработки или внедрения.
Успешный проект
Создание персонализированного IT-продукта — комплексный процесс, который начинается задолго до его разработки.
Эффективность коммуникации компании-исполнителя и компании-заказчика и — как результат — успешный проект зависят от доверительных взаимоотношений потенциальных участников с обеих сторон, а также качественного планирования и прохождения указанных выше значимых шагов сделки.
В таком случае компания-исполнитель позиционирует себя как безопасного, ответственного и качественного партнера, что вероятнее приведет к взаимовыгодному сотрудничеству.
Начать дискуссию