Выбор корпоративного ПО: большие и малые поставщики

Как известно, тон на рынках (и ИТ не исключение) задают "большие игроки" (например, для рынка ПО это такие компании как Microsoft, Oracle, SAP и др.). О преимуществах "больших" компаний над "малыми" и говорить как-то не удобно (много у них преимуществ, все и не перечислишь). Но так ли безнадежно обстоят дела у небольших компаний (в том числе у stratup'ов)? Не совсем. В данной статье я постараюсь осветить некоторые аспекты из области работы на рынке корпоративного ПО небольшой компании.

Так случилось, что в начале своей ИТ карьеры я начал работать в корпоративном секторе на стороне одной из финансовых компаний. Затем перешел в другую, третью, а потом попал в software startup, который также работает в корпоративном сегменте. Являясь директором немецко-украинской компании «Softgenic Systems», я достаточно часто участвую в презентациях и переговорах, в ходе которых приходится отвечать на относительно стандартные вопросы о работе с поставщиками-startup'ами. В этой статье я хотел бы высказать свое личное мнение (которое может никоим образом не пересекаться с мнением моего работодателя) по данному вопросу.

Вот некоторые из стандартных вопросов, которые мы рассмотрим в данной статье:

1. Маленькие компании разрабатывают продукты для небольших компаний, корпорации – для корпораций
2. «Тендер обязателен!» 
3. Если продукт успешно работает в корпорации XYZ, он будет успешно работать и у нас 
4. «Большие продукты» стоят дешевле «маленьких» 
5. «Мы покупаем только готовые решения!» 
6. «Мы ищем универсальное решение для всех наши проблем!» 
7. «Мы сами разрабатываем собственные ИТ продукты!» 

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.

И в заключении: почему все же иногда побеждают большие компании?
Вот мои варианты ответов:

1. Их предложение действительно лучше вашего
2. Вы не смогли развеять озвученные выше и другие сомнения потенциального клиента
3. Иррациональный страх человека, принимающего решение (у «большой системы» воооон сколько внедрений значит и у нас с ними все будет ОК) 
4. Меркантильный аспект принятия решения 
5. Причины, не имеющие к вопросам ИТ никакого отношения (например, увеличение стоимости компании см. также здесь)