Как известно, тон на рынках (и ИТ не исключение) задают "большие игроки" (например, для рынка ПО это такие компании как Microsoft, Oracle, SAP и др.). О преимуществах "больших" компаний над "малыми" и говорить как-то не удобно (много у них преимуществ, все и не перечислишь). Но так ли безнадежно обстоят дела у небольших компаний (в том числе у stratup'ов)? Не совсем. В данной статье я постараюсь осветить некоторые аспекты из области работы на рынке корпоративного ПО небольшой компании.
Так случилось, что в начале своей ИТ карьеры я начал работать в корпоративном секторе на стороне одной из финансовых компаний. Затем перешел в другую, третью, а потом попал в software startup, который также работает в корпоративном сегменте. Являясь директором немецко-украинской компании
«Softgenic Systems», я достаточно часто участвую в презентациях и переговорах, в ходе которых приходится отвечать на относительно стандартные вопросы о работе с поставщиками-startup'ами. В этой статье я хотел бы высказать свое личное мнение (которое может никоим образом не пересекаться с мнением моего работодателя) по данному вопросу.
Вот некоторые из стандартных вопросов, которые мы рассмотрим в данной статье:
- Маленькие компании разрабатывают продукты для небольших компаний, корпорации – для корпораций
- «Тендер обязателен!»
- Если продукт успешно работает в корпорации XYZ, он будет успешно работать и у нас
- «Большие продукты» стоят дешевле «маленьких»
- «Мы покупаем только готовые решения!»
- «Мы ищем универсальное решение для всех наши проблем!»
- «Мы сами разрабатываем собственные ИТ продукты!»
1. Малому – малое, большому – большое.
С этим мнением спорить сложно, но возможно. Скорее всего, когда компания декларирует, что она покупает только продукты у «больших» производителей, она преследует следующие цели:
- уменьшение рисков, связанных с исчезновением производителя или продукта (производитель перестал развивать продукт, потерял интерес к рынку и пр.).В последнее время большие компании исчезают (разоряются и/или меняют собственников) не реже малых. Крупные компании также часто меняют приоритеты развития, отказывают в поддержке продуктов и изменяют ценовую политику. Если клиент хочет себя обезопасить от полного исчезновения компании - рассмотреть, возможно, вариант с предложением ему услуги ESCROW.
- наличие квалифицированного персонала, способного быстро и в срок выполнять заказы корпорации.Вопрос правильный, но опять же к размеру компании отношения не всегда имеющий. Ваша задача показать, что в компании работают только профессионалы и что проект, о котором идет речь, не станет «полигоном для обкатки студентов», как это иногда происходит при внедрении «больших продуктов». По поводу качества и сроков, возможно, предлагать заказчику «превентивное оружие» - штрафные санкции в случае нарушения сроков выполнения работы (убедитесь только, что у вас будет существовать механизм «алгоритмизации» взаимоотношения с клиентом). Наша компания, к примеру, предлагает контракты с гарантированной скоростью реакции на возникающие у клиентов проблемы, что также позитивно сказывается при обсуждении данного вопроса.
Хочу обратить внимание читателя на ряд преимуществ, которые часто присутствуют у небольших компаний:
- высокая скорость реакции на запросы клиентов. Особенно это касается вопросов связанных с исправлением ошибок, экстренными доработками и прочими «чрезвычайными» ситуациями (это только мне так «везет», что доработки это почти форс-мажор?). Вы можете представить вечерний звонок в офис крупной software корпорации с просьбой выпустить им на утро обновление (patch, hot fix, service pack, обновленную версию) с новой функциональностью (исправлением ошибки, новым отчетом и т.д.)? Я – нет. А вот с небольшими поставщиками – это практически стандартная ситуация.
- быстрое и качественное решение вопросов клиента. По-другому и быть не может – stratup’ы не могут позволить себе роскошь решать вопросы неделями или месяцами.
- доступность всех ресурсов для решения возникающих проблем. В вашей практике бывали ситуации, когда вам звонит клиент в панике с рассказами о том, что «система не запускается», «день не закрывается», «баланс не сходится», и из-за этого работа большинства сотрудников приостановлена? В моей – были. В таком случае задача поставщика всегда сводится к одной простой вещи: решить проблему любыми способами. Решить, а вот потом уже начинать анализировать, что произошло. У небольших компаний на такие «авралы» бросаются часто все силы (вплоть до разработчиков и уборщиц :). Расскажу об одной такой истории, поведанной мне экс-сотрудником. Они разрабатывали корпоративную систему. Установили ее у «самого главного заказчика». А через некоторое время к ним обратились с жалобой, что система «падает» (crash’ится) через произвольное время после начала работы. Ситуация происходила только на главном сервере клиента (ни в офисе поставщика, ни на других серверах клиента проблема не воспроизводилась). После установки непосредственно на сервер, кажется, Visual Studio, запуска системы из исходников и включения режима логирования (был такой режим в их ПО) проблема исчезла. Причем удаление Visual Studio или выключение режима логирования возвращали ситуацию на круги своя. Исходники удалили и написали специальный процесс, который «обрезал» логи, чтобы «не мешали жить» и в таком виде заказчик еще долго работал с этим ПО. Проблема в конце концов решилась переустановкой Windows на сервере, но Вы можете представить себе реакцию заказчика на сообщение о том, что система неработоспособна без переустановки на сервере Windows ;)? Я – могу, но вот мнение заказчика о компетентности такого поставщика, даже если переустановка решит проблему, может пошатнуться.
2. «Тендер обязателен!»
Решать, конечно, заказчику. Тендер однозначно стоит проводить, если существуют несколько продуктов, которые заказчику на 100% подходят, и задача выбрать тот из них, который будет «лучше».
Зачастую, в корпоративном мире не все так просто: одного продукта, который бы решал все вопросы, нет (или такой продукт есть, но его стоимость значительно превышает бюджет проекта), а есть ряд продуктов, которые можно доработать, добавив недостающую функциональность, или несколько продуктов, которые совместно могут решать поставленные задачи. Скорее всего, в таком случае тендер даст только «short-list» – список продуктов и их комбинаций, которые могли бы подойти, а вот как из них сделать правильный выбор - это уже каждая компания решает индивидуально.
Лучший ли вариант даст тендер? Не во всех случаях. Если есть, что выбирать, то, пожалуй, да, а вот если продукт нужно дорабатывать, выбрать несколько продуктов для совместной работы или разработать под заказ – скорее всего, нет.
Зачем нужен тендер? Вопрос сложный. Один из вариантов ответа – это снятие ответственности за принятие решений (к процессу привлечены многие специалисты, решение и ответственность - коллегиальные). Второй – универсализация (или, если хотите, алгоритмизация) механизма принятия решений в корпорации.
Про тендер могу сказать одно: он ВСЕГДА неопределенно затягивает процесс принятия решения. И если Вам говорят, что Ваш продукт уже выбран, но нужно провести «небольшой формальный тендер», то не обольщайтесь. Тендер может быть растянут на год, а потом у компании изменяться приоритеты, бюджет будет урезан и т.д.
3. Если продукт успешно работает в корпорации XYZ, он будет успешно работать и у нас
Как там у классика: «Все счастливые семьи счастливы одинаково, каждая несчастливая семья несчастна по-своему»… Точно также обстоят дела и с корпоративными системами. Некоторые пункты, которые следует иметь в виду:
Идентичные названия продуктов (с разницей, например, в версиях) ни о чем не говорят. Это могут быть разные продукты, объединенные под одной торговой маркой.
В ходе внедрения продукта X часто получается индивидуальная версия продукта, которая работает в корпорации A. Эта версия прямо или косвенно «принадлежит» корпорации и вам ее не продадут. Возможно в ходе того внедрения был собран опыт или разработаны новые модули, который могут быть применены при новых внедрениях.
Внедрения одного и того же продукта в одной и той же стране одной и той же компанией могут привести к разным результатам. Например, внедрять продукт могут разные команды с разным уровнем знаний. А о внедрении в разных странах, разными компаниями и пр. и говорить не приходится.
4. «Большие продукты» стоят дешевле «маленьких»
Как часто вам доводилось слышать фразы?
- Мы посчитали, что ваш продукт стоит 50$ за лицензию, а у большой компании 200$, но у нас уже есть купленные лицензии и мы будем использовать продукт большой компании, так как он нам обойдется дешевле.
- У вас стоимость человека-часа 100$, а у конкурентов 20$. Мы выбираем их продукт, та как он нам обойдется дешевле.
Я твердо уверен, что считать нужно
ТСО. Даже если лицензии уже куплены, но продукт содержит скрытые затраты (например, требует наличия дорогостоящей версии базы данных, сервера приложений, дополнительных людских ресурсов и т.д.), ваше решение может оказаться дешевле. Еще одна часть
ТСО – стоимость доработки и поддержки. Стоимость поддержки многих продуктов определяется как % от стоимости приобретенных лицензий (соответственно, чем меньше стоимость лицензий, тем дешевле обойдется поддержка).
Сравнение продуктов на основании стоимости человека-часа выглядит еще забавнее: как известно в ИТ индустрии производительность среднего и высококвалифицированного ИТ специалиста отличается в разы (а между низко- и высококвалифицированным – на порядок). Соответственно, что будет дороже - работать с компанией со стоимостью 100$ за человеко-час или с компанией со стоимостью 20$? Не известно. Мне кажется, что корректная оценка в таких случаях может быть получена только при сравнении бюджетов идентичных проектов, которые будут рассчитаны компаниями, которые сравниваются (я сознательно написал «бюджет», так как «дешево и долго» сравнивать с «дорого и быстро» сложно).
5. «Мы покупаем только готовые решения!»
Спорить сложно. Однако, иногда решений, которые бы удовлетворяли всем запросам, просто не существует (или их стоимость значительно превышает бюджет проекта). И даже в случае, когда есть готовое решение, которое на 100% соответствует требованиям на бумаге (на сайте, в email-e), не лишним будет убедиться, что заказчик и продавец говорят на одном и том же языке и что объем функциональности, который часто скрывается за лаконичным «Реализовано», «Поддерживается» или просто «Да», соответствует ожиданиям заказчика. Еще один момент, который следует учитывать, - это стоимость и срок настройки (адаптации, custom’изации) программного обеспечения, которое на 100% подходит. В моей практике были случаи, когда бюджет настройки (адаптации, custom’изации) на 100% готового продукта превышал бюджет доработки продукта, у которого не было части функциональности (я имею в виду, что полученный в результате функционал обоих систем был сравним).
6. «Мы ищем универсальное решение для всех наши проблем!»
Такие заявления мне напоминают поиски ИТ специалистами «серебряной пули»: универсального инструмента для решения любых задач. Не знаю как в корпоративном секторе, а вот в ИТ такой инструмент пока не найден. С прагматичной точки зрения, если такое решение было обнаружено, не лишним будет сравнить бюджет и
ТСО этой системы с другими вариантами (одна или несколько систем с рядом доработок).
7. «Мы сами разрабатываем собственные ИТ продукты!»
Есть и такой подход. Он мне встречался в нескольких случаях:
Компания хочет сэкономить («Ваш продукт нужно покупать, а у нас все будет бесплатно» - т.е. за зарплату)
У компании есть know-how, которого нет у других, соответственно, для его автоматизации нет продуктов и делиться с кем-либо им нет желания. В этом случае, наверное, делать нечего. Как спорить с такими аргументами я не знаю.
Компания была поставлена в безвыходные условия поставщиком и самостоятельная доработка была единственным выходом (мне встречались случаи, когда коммерческий банк выкупал разоряющегося разработчика ПО для того, чтобы продолжить эксплуатацию продукта).
В любом случае, компания, которая занимается in-house development’ом становится в некоторой степени заложником отдела (управления) ИТ, ответственного за продукт. С уходом ведущих специалистов у компании могут наступить «тяжелые времена». К слову, с моей точки зрения, риск того, что один или несколько из разработчиков решат сменить место работы, несколько выше риска, описанного в пункте 1.
И в заключении: почему все же иногда побеждают большие компании?
Вот мои варианты ответов:
- Их предложение действительно лучше вашего
- Вы не смогли развеять озвученные выше и другие сомнения потенциального клиента
- Иррациональный страх человека, принимающего решение (у «большой системы» воооон сколько внедрений значит и у нас с ними все будет ОК)
- Меркантильный аспект принятия решения
- Причины, не имеющие к вопросам ИТ никакого отношения (например, увеличение стоимости компании см. также здесь)
