Вы решили автоматизировать бизнес-процессы. Что делать дальше? Провести тендер. Учтите — организация и проведение тендера потребует пристального внимания ключевых сотрудников и руководства компании. Но это единственный способ для адекватного выбора.
Преимущества автоматизации только тогда становятся таковыми, когда решение подходит конкретной компании. Тендер помогает детально сравнить функциональные возможности решений, комплекс сопутствующих услуг и стоимость предложений подрядчиков.
IT-системы, о которых идет речь, глубоко встраиваются в бизнес. По опыту участия в десятках тендеров в роли поставщика IT-решений, рекомендую обратить внимание на несколько моментов, общих для разных целей и ситуаций.
Подготовка к тендеру
1) Первый шаг — формирование проектной команды для сбора и обработки информации для тендера. Необходим внутренний заказчик, драйвер проекта. Готовьтесь к тому, что он будет уделять этой задаче практически все время. В зависимости от специфики компании, остальными членами команды будут IT-специалисты, sales-support, бизнес-аналитики.
Два признака грамотно сформированной проектной команды:
- Совокупная компетентность достаточна для оценки ситуации со всех точек зрения, важных для бизнеса;
- Проект приоритетен для участников команды.
2) Первичное техническое задание. Бизнес называет требования, а технический специалист, sales-support или человек на стыке бизнеса и IT переводит их на формальный язык. Так вырабатывается начальное представление о том, какая система нужна.
3) Список разработчиков и названий систем. Для этого IT-специалисты изучают рынок решений. Способы задействуются разные: начиная с поиска в интернете и заканчивая проведением инсайдерских опросов. Выход за рамки списка контактных лиц, которые предоставляет поставщик по запросу, поможет получить ценную информацию и об опыте эксплуатации системы, и о надежности самого разработчика. Хорошего поставщика продают клиенты. Поэтому его такие опросы не «напрягут», даже если он о них узнает.
4) Собрать подробную информацию о системах. Самое правильное — обратиться к разработчикам. Начните с просмотра сайтов поставщиков систем, обычно там есть подробная информация о продуктах и контакты. Некоторые разработчики выкладывают демо-версии программ. На этом этапе отсеиваются поставщики, которые вызывают явные сомнения. Например, настораживает, если у IT-компании не работает сайт или его нет вовсе, если нет портфолио. Кроме того, для крупных заказчиков характерно избегать только что образованных компаний: слишком большие риски.
5) Первичный отсев систем по классу и базовым возможностям. Не стоит приглашать в тендер всех, кто вышел в первую десятку по запросу в Яндексе или Google. IT-эксперты на своем уровне убирают из списка заведомо неподходящих поставщиков. Причем без углубления в детали — время для тщательного изучения еще не пришло.
К примеру, открыт тендер для поиска решения автоматизации торговых агентов. На рынке присутствуют разработчики, автоматизирующие дистрибуцию, но мобильного приложения для торговых агентов у них нет, есть только офисная часть. В тендере на поставку SFA (Sales Force Automation — система автоматизации продаж) такой поставщик участвовать не может — он непрофильный.
6) Не делайте предварительных оценок. Бывают случаи, когда в компании стоимость проекта согласовывается на подготовительном этапе, без обращения к поставщику. Риск в том, что эта сумма может значительно отличаться в меньшую сторону от цен, названных разработчиками в тендере. И тогда цена становится единственным критерием выбора — бюджет-то уже согласован. В сфере IT дешевое хорошим быть не может. Чтобы из-за этого не возникало сложностей, нужно понять, что цену называет рынок, а не заказчик. Поэтому за порядком цифр лучше обратиться к разработчикам.
Итак, в списке остались профильные компании.
Тендер
1) Техническое задание (ТЗ). В IT лучше, когда абстрактное представление о программе подкреплено формализованным документом. Он экономит время и поставщику, и заказчику. Сформулируйте бизнес-требования и переведите их на технический язык. Чтобы ТЗ содержало исчерпывающую информацию, потребуются усилия всей проектной команды. Когда IT-поставщик получит такой документ, он быстрее и с меньшим количеством вопросов подготовит встречное предложение, легче войдет в тендер.
2) Пора обратиться к поставщикам. Проектная команда приступает к проверке функциональности программ. Напишите официальный бриф, позвоните, отправьте запрос через форму обратной связи на сайте — любой канал связи годится. Главное — довести до разработчиков техническое задание и спросить: «Мы ищем вот такое решение. Что вы можете нам предложить? Какие статьи расходов могут быть? Сколько стоит такой проект?».
3) Приглашение в тендер. Сколько поставщиков пригласить в тендер? Все зависит от желания руководства компании-заказчика найти объективно лучшее и подходящее IT-решение. Если автоматизация управления признана важной, компания пригласит всех, кто в данный момент имеет на рынке хоть какой-то вес.
Если же у компании нет времени или уже принято решение (может быть, негласное), то конкурс проводится формально. В таких фейковых случаях часто приглашают разработчиков заведомо разных направлений либо несопоставимых систем. Среди них оказывается единственный поставщик, который покрывает потребности компании.
4) Сроки. Хотя бы к моменту формирования шорт-листа запланируйте, сколько времени компания потратит на отбор и когда запустит проект. При плохо организованном вялотекущем процессе без сроков заказчик не понимает, сколько ресурсов потребуется вложить в проект, когда он запустится. Примерно укажите, когда ожидаете получить результат: «5-10 дней на первичную обработку», «14-20 дней на ответ по ТЗ». Для запуска проекта подойдет и приблизительное «Мы хотим запуститься в этом году». Тогда поставщик включит проект в график. Организация проектных процессов у нормального разработчика похожа на заводские. Он должен четко понимать, на какой срок резервировать человеческие и технологические ресурсы в случае выигрыша. Если вы не обозначаете срок, готовьтесь подождать, пока победитель приступит к работе.
Сроки зависят от потребностей. Если ваши конкуренты уже автоматизировались, IT-системы приносят им прибыль, очевидно, что ждать два года не стоит. Но и торопиться не следует. Не только из-за того, что в спешке легче ошибиться. Нужно выбрать такое время, когда отсутствие ключевых специалистов компании в текущих процессах пройдет безболезненно для бизнеса. Проанализируйте сезонность, ресурсы, инвестиционные возможности. Для этого полезно получить от поставщика грамотный график движения денежных средств, чтобы с учетом этих сведений корректировать сроки и ресурсы.
5) Заявки в тендер «самотеком». Если заказчик забыл кого-то пригласить, а поставщик сам узнал о тендере, то он может «попроситься» в него самостоятельно. В таком случае заявку оценивают по общей схеме «подходит — не подходит», и если первичный отбор успешно пройден, высылают техническое задание.
6) Сопоставление возможностей решений и потребностей компании проводится в диалоге с поставщиком. Значит, на стороне заказчика должны быть компетентные представители, готовые обсуждать функционал программы. На этом этапе будут очные встречи, видео- и телеконференции. По итогам переговоров из списка уберутся «лишние». Это только на первый взгляд, чем шире выбор, тем лучше. От числа участников зависит длительность процедуры, так как у крупных поставщиков оценка и согласование проекта занимает время.
Если организатора тендера поджимают сроки, нужно тщательно проработать первичный список участников и возможности рассматриваемых IT-решений. На заявки каждого участника тендера потребуется одинаковое время. Логично потратить его на профильных участников, а не на желающих «попытаться».
7) Внимание на отношение. Тендер похож на сватовство. Помимо оценки технических характеристик решения, обращайте внимание на общение с поставщиком. Он может быть молодым и неопытным в тендерах, но открыт к разговору. Не бывает «неудобных» или «глупых» вопросов на тему технических характеристик и функциональности системы, ведь у разработчика намного больше знаний и компетенций в своей области, чем у IT-директора компании-заказчика.
Если поставщик дружески объясняет и рассказывает, с ним получится работать как с партнером и дальше. Ведь проект длится не один день, скорее даже не один год. Коммуникации критично важны. Есть и другие факторы, которые стоит оценить: организованность, полнота предоставления информации.
8) Хорошая презентация — плохая основа для выбора поставщика. Не каждая IT-компания может похвастаться эффектной рекламой. Шикарно, если динамичную презентацию с красивыми картинками показывает человек, специально обучавшийся ораторскому искусству. Но это не показатель качества программы. Это показатель умения компании себя продавать. Поэтому не стоит делать выводы о возможностях поставщика и его месте на рынке, основываясь на маркетинговых материалах.
Нарисовать можно все, что угодно. Не стоит опираться на красивые картинки при принятии важных решений
Реклама – это реклама. На слайдах легко нарисовать что угодно. Включая скриншоты, отредактированные в Photoshop. Разработчики, которым сложно выдерживать честную конкуренцию, иногда даже в своих демонстрационных решениях имитируют то, чего еще нет в действующем программном обеспечении. Вот когда собрали хорошие референсы, наладили коммуникации, оценили систему, и появилось видение поставщика как будущего партнера — тогда презентация становится «вишенкой на торте». Но такой презентации может и не быть вовсе, по существу ничего не изменится.
9) Коммерческое предложение — еще не финал, а интересный этап. Уже накопили много знаний о системах и разработчиках, теперь настал момент оценки предложений. Сложность в том, что каждая компания, предоставляющая некие цифры в ответ на запросы, вкладывает в них разное значение. Важно суметь привести их к единому знаменателю.
Например, практически в каждом проекте присутствует статья о технической поддержке. Но цифры, предоставляемые поставщиками, различаются в разы. Почему? Возможны два варианта. Первый — неоправданно дорогой поставщик. В таком случае сориентироваться поможет информация о предполагаемом сервисе и о ставках специалистов. Второй вариант — у одного поставщика учитываются траты, которые не включил другой. Например, в SFA-проектах одни разработчики предлагают выезд специалистов по внедрению на площадку, а другие — нет. Опытный поставщик решения также может увидеть, что компания не учла какие-то моменты при составлении ТЗ, и сказать об этом. Это честный подход, он помогает избежать ситуации, когда проект невозможно закончить без дополнительного бюджета, потому что появились скрытые затраты. Лучше сразу выяснить, сколько стоит проект.
Обычно после углубленного анализа функциональных возможностей, описаний сервисов и перспектив развития систем остаются один-два лидера, с которыми продолжаются переговоры по коммерческим условиям.
Финишная прямая
Проведение «пилотов» (пробных проектов) — великолепный шанс проверить поставщиков в бою. Это нужно для определения лидера, если он не проявился по итогам рассмотрения коммерческих предложений. И если выбор основывался на красивой презентации, «пилот» покажет, соответствуют ли обещания реальности.
Учтите, проведение «пилотов» не только хороший способ проверить работу программ и команды разработчика в штатном режиме. Это еще и дополнительные вложения. Проектная команда будет несколько месяцев заниматься трудоемкой работой и уделять проектам большую часть времени. Особенно затратны параллельные «пилоты». Недавно мы участвовали в тендере, где проводилось семь параллельных «пилотных» внедрений.
Выбрали? Станет проще
Теперь над проектом работают другие люди под руководством технического руководителя. Как правило, у руля становится IT-директор, ему передаются требования заказчиков внутри компании и делегируются необходимые полномочия. Руководитель проекта внедрения занимается организационными моментами, коммуникациями, контролем. В том числе он отвечает за бюджет и сбор дополнительных требований.
Помогает, когда проекту присваивается статус приоритетного для компании. Это гарантирует оперативную обратную связь подразделений, обеспечивает доступ к топ-менеджерам, если вопросы выходят за рамки полномочий оперативного руководителя, и создает продуктивный настрой на успешное завершение проекта.
Все перечисленное возможно только в том случае, когда проектная команда фокусируется на проведении тендера. Это важно, поскольку выбирается партнер по бизнесу, от работы которого зависит успех компании.
P.S. За помощь в подготовке статьи благодарю PR-менеджера ГК «Системные Технологии» Татьяну Беспалову.
Источник изображения: dreamstime.com
Редактор рубрики «IT для бизнеса» – Сергей Соловьев
Поднята тема интересная, но скажу, как человек, работающий в большом IT со стороны большого Заказчика и как раз отвечающий в т.ч. и за проведение тендеров на проекты по ИТ - в правильно проведенном тендере вы уже знаете, кто победит. В данном случае "тендер" - это выбор решения. На этапе проработки проекта приглашаются участники, которые сначала по очереди предлагают разные варианты, смотрят на задачу под своим углом, рассказывают какие-то новые подробности. После такой проработки обычно, как минимум, приходит детальное понимание, что хотим, а как максимум в принципе задача кардинально изменяется. После такой проработки данные решения сравниваются между собой, часто предполагаются очные встречи между конкурентами, которые защищают свои решения. В конце формируется полное понимание, что должно быть в проекте (обычно это формируется из разных частей разных предложений от разных участников). И в финале, если дело доходит до тендера, то побеждает цена. Обычно на этом этапе уже понятно, кто будет выполнять работы, т.к. большинство партнеров отсеиваются на этапе проработки. При этом критичное снижение стоимости чревато увеличением рисков в проекте. Вы ставите подрядчика в крайне жесткие условия, когда любая проблема в проекте способна свести его прибыльность в 0 или -, и тогда желание его доделывать и приоритет очень сильно снижается. Поэтому "тендер" в ИТ-проектах, на мой взгляд, не очень правильная тема. Тут скорее оптимален конкурс.