история о том, как поставщик нагрел заказчика на миллионы долларов
В прошлом году я работал в составе комиссии, управляющей проектами одного из крупнейших оборонных подрядчиков. Я сам был подрядчиком, получая почасовую оплату за помощь в планировании проекта,прогнозировании и другие консультации в области IT. Я мог наблюдать, так сказать, «из первого ряда», как IBM проводила махинации на миллионы долларов.
Благодаря войне в Ираке подрядчик разросся как на дрожжах, несмотря на то, что он и так имел штат из 130 тысяч сотрудников и доход в 30 миллиардов долларов. Он смог позволить себе разработку внутренних IT-проектов, о которых руководство мечтало годами. Я работал как раз над ним. Проект включал в себя построение портала, объединяющего ресурсы предприятия, и разработку системы управления знаниями.
Одной из часто критикуемых черт систем управления знаниями является то, что под видом новых разработок продаются косметически измененные старые. Производители берут электронную доску объявлений, связывают ее с системой управления документами, добавляют к этому поисковой механизм для интранет, называют получившуюся солянку «Система управления знаниями» и продают ее за миллионы долларов. Мое мнение по данному вопросу таково: я считаю, что подобные системы, несомненно - очень удачное решение, но их возможности слишком сильно переоцениваются, а цены взвинчены до совершенно неадекватных значений.
Когда я начал работу над проектом, основные поставщики уже были выбраны. Opentext — для управления документами, Verity — для поиска, Microsoft — для управления службой каталогов, Netegrity — для разработки решения единого входа в систему, IBM — для создания корпоративного портала. От IBM с нами постоянно работал один консультант, и еще один время от времени приезжал. Первый был аналитиком проекта. Его задачей являлся контроль взаимодействия портала и остального программного обеспечения, а также помощь в планировании всего проекта. Но мы так и не получили от него никакой помощи в планировании или в анализе. Большинство времени он тратил на вопросы продажи.
Грамотное решение задачи выбора поставщиков является весьма сложной задачей. Если руководство выбирало поставщика, или даже просто подумывало об этом, консультант должен был проработать вопрос и выдать готовые предложения. Руководство, со своей стороны, должно было выбрать и радоваться решению очередной проблемы. Вопросы, существуют ли конкурирующие с IBM решения, как правило, не задавались.
Работа второго консультанта была еще более странной. Он показывал нам примеры, в которых какие-то компании использовали такие же решения и экономили тем самым миллионы долларов. Презентации имели отличное качество. Они выглядели убедительно и логически связанно. Перед уходом консультант пригласил нас прослушать в записи телеконференцию, которую проводил его гуру, Лари Прусак. Прусак — глава подразделения IBM, занимающегося системами управления знаниями, автор нескольких книг по этой тематике.
Постепенно, компоненты разных производителей были заменены на аналоги от IBM. Наконец, все пришли к решению использовать DB2. Проблема заключалась в том, что никто не знал, сколько это будет стоить, и заработает ли это все вообще.
Где в это время был технический персонал? В большинстве своем они старались держаться подальше, поскольку явно не хотели нести ответственность за реализацию проекта. В общем-то они не хотели чуть что оказаться на крючке, осуществляя предложенные IBM решения. Разумеется, IBM была более чем довольна сложившейся ситуацией.
Конечно, в мою задачу входило информирование руководства о том, сколько в итоге обойдется портал и система управления знаниями. Для этого я получал отчеты от IBM и технической команды. Но IBM поступала довольно хитро, указывая в качестве стоимости что-то вроде: «если все пойдет по плану, на выполнение большинства этих задач уйдет не более пары недель». Нашу техническую команду было трудно заставить что-либо посчитать в данном направлении, так как, как было сказано выше, они не хотели брать на себя никакой ответственности за реализацию этого проекта. Иногда, когда их все же удавалось уговорить сделать расчеты, их прогнозы выглядели слишком оптимистично и также были полны различных оговорок. Дэдлайн приближался быстро, но проект был еще далек от завершения. Количество необходимых ресурсов росло с каждым днем его продвижения. Руководство очень неохотно отодвигало дэдлайн, так как завершение проекта до конца года сулило множество бонусов. Было решено использовать решения IBM везде, где это было возможно, даже не смотря на то, что планирование проекта еще не было до конца завершено (из-за недоработок консультантов IBM).
Кроме того, наши конференц-залы были переполнены консультантами IBM Global Services. Когда я поинтересовался, во сколько они нам обходятся, то получил ответ: 250 $/час. Однако это оказалось неправдой. На самом деле мы платили за них по 325 $/час. Что же мы получали за 325 $/час? Руководство считало, что мы получаем настоящих экспертов от IBM. Однако мы получали работников от субподрядчика. Мы платили IBM 325 $/час; IBM платила их субподрядчику 165 $/час. Субподрядчик платил людям зарплаты от 90 до 100 тысяч долларов в год, что в пересчете эквивалентно 75 $/час, т.е. среднерыночному значению. Таким образом, мы переплачивали 333%.
Были ли те люди экспертами? Да, безусловно, среди них было несколько настоящих экспертов. Большинство же было простыми Java-программистами или администраторами Websphere. И еще несколько были совсем бесполезны для нашего проекта. Это было совершенно типичное распределение работников: несколько звезд, серое большинство и бесполезное меньшинство. Я хорошо знаю рынок контрактной разработки, поскольку сам как-то выполнял на заказ несколько Java-проектов и имею друзей, которые до сих пор этим занимаются. Средний разработчик получает от 50 до 100 долларов в час, в зависимости от его опыта, сертификатов и текущей обстановки в регионе. Большинство таких разработчиков работают на контрактные агентства, которые добавляют к цене разработки еще 30 $/час. Если вам удается найти собственных клиентов и стать независимым разработчиком, вы сможете зарабатывать 100 $/час.
Так что когда я увидел цифры, я был шокирован, потому что знал множество людей, которые согласились бы выполнять такую же работу за 80-100 $ в час, причем делали бы это намного лучше. Но руководство не хотело создавать себе лишние проблемы при работе с независимыми разработчиками, даже, несмотря на то, что они выполнили бы в 4 раза больший объем работы за ту же цену. IBM заявляла, что эксперты закончат проект намного быстрее, а на самом деле предоставляла обычных сотрудников, которые не обладали каким-либо неординарными навыками.
Еще одной интересной вещью, которую я обнаружил, является то, что организация компании-субподрядчика IBM - эффективный способ зарабатывания денег. Дело в том, что хозяином конторы-подрядчика, с которой мы работали, был бывший сотрудник отдела продаж IBM. Ему не составляло труда подсчитать, что можно заработать кучу денег, набрав толпу специалистов и продавая их IBM по 165 $/ час. Именно так все обычно и происходит. Мы подсчитали, что подобный предприниматель зарабатывает 90 тысяч долларов в неделю на нашем контракте, при этом ничего по сути не делая. Нанимай народ да выставляй счета – вот и вся работа :)
нехватка денег
Наши затраты настолько превосходили бюджет, что мы даже боялись говорить об этом. Мы предполагали, что IBM просидит у нас 3 месяца, за которые как раз и освоится предполагаемый бюджет (с помощью обсуждавшихся выше 325 $/час). Но на этом дело не кончилось. IBM находилась в нашем проекте 7 месяцев, прожигая больше четверти миллиона долларов в неделю. Более того, затраты на Global Services — это еще не все. Мы платили также за лицензии и поддержку Websphere, Websphere Portal, Websphere Content Management, Tivoli Access Manager, и DB2.
IBM, представившая себя ведущим производителем и интегратором, не сдержала обещаний, и это при таких высоких ценах!
В итоге мы получили сложный в использовании корпоративный портал с несколькими достаточно стандартными портлетами и несколькими встроенными приложениями. Множество аспектов интеграции приложений были просто оставлены без внимания. Ни одна идея из тех красочных презентаций по управлению знаниями, что мы видели в начале, не была реализована.
что пошло не так
Несомненно, что наше руководство допустило серьезные ошибки. Это мой второй совместный проект с IBM, и я опять вижу те же самые проблемы. Я писал руководству множество предупреждений, но они не обращали на них внимания, так как IBM – солиднейшая компания и их решения – по крайней мере бумаге - выглядели очень красиво. Это привело к тому, что продукты IBM выбирались даже в том случае, когда их применимость для нашего проекта было под большим вопросом или вообще они выглядели... как бы это сказать помягче... в общем, устрашающе :)
IBM представляет себя другим как провайдер бизнес-решений. Такая позиция позволяет им давать рекомендации по архитектуре и выбору продуктов. Не сложно догадаться, чьи программные и аппаратные решения обычно рекомендуются клиентам.
Несмотря на то, что IBM позиционирует себя как компания с большими возможностями (например, шахматные суперкомпьютеры), большинство из ее клиентов нуждается в самых простых вещах: в системах, поддерживающих веб, базы данных и компетентных технических специалистах, которые могли бы все это установить и запустить. Все это теперь — обычные потребительские услуги, и почему компании должны переплачивать IBM за это в троекратном размере?
учитесь на наших ошибках
Говорят, что образованных людей гораздо проще обмануть, так как они считают, что их нельзя обмануть. Так что если вы слишком умны для следующих советов, не проходите мимо — это именно то, что вам нужно. Не повторяйте ошибок нашего руководства!
Итак, советы.
1. Не упрощайте процесс выбора поставщиков. Выбор должен производиться на основе тендеров. Никогда (слышите, никогда!) не спрашивайте у реализаторов совета по поводу стратегии, архитектуры или выбора продуктов. У них нет никакого мотива действительно помочь вам, зато мотивации продать вам какой-либо бесполезный продукт втридорога – этого предостаточно :)
2. Использование открытых стандартов обеспечивает большую гибкость в выборе поставщиков. Используйте это! Вы должны хорошо чувствовать рынок и уметь быстро просчитать накрутку, которую делают перепродвацы. Запоминайте значения накруток отдельно от стоимости самих реализаций.
3. Проверяйте резюме индивидуальных консультантов. Консультант, претендующий на 250$/час, должен уметь ходить по воде, что должно быть отражено в резюме.
4. Создайте себе список возможных реализаторов проекта, который должен включать крупных и мелких производителей оборудования/софта, небольших независимых подрядчиков и обладающих необходимыми навыками собственных работников предприятия.
5. Запустите небольшой тестовый проект для проверки на практике выбранных архитектур, технологий и, конечно же, поставщиков :).
6. Неплохо бы разжиться «инсайдерской информацией». Хехе. самое время поделиться с вами моей светлой мыслью! Представляете, если бы IT-директора хотя бы нескольких компаний из списка Fortune 500 поделились бы с дргуими информацией о «профпригодности» своих поставщиков и инсталляторов? ;) Разумеется, вряд ли кто-то просто так поделится информацией такого рода с конкурентами. Например, Coca-Cola вряд ли будет делиться информацией с Pepsi, но, скорее всего, поделится ей с Dow Chemical, Allstate, Bank of America, Diageo и с еще несколькими не конкурирующими компаниями. Подумайте на досуге над рассказами о проектах, которые реализованы в других компаниях, и – главным образом - об их ошибках, которых можно будет избежать.
В общем, одна из главных проблем в том, что руководство не может получить объективную информацию об том или ином поставщике, читая их официальный веб-сайт, журнал с их рекламой или общаясь с представителями лично. Таким образом, если руководители хотят получать объективную информацию, так пусть поймут, что информацией этой надо делиться. Иначе ей появиться неоткуда...
И вот еще. Если мы будем покупать продукты и услуги фирм, которые задирают цены, перегружают проекты лишними компонентами и не выполняют требования договоров, то скоро такая модель ведения бизнеса станет типичной для IT-рынка. С другой стороны, если мы приложим усилия для поиска хорошо работающих компаний, другие, увидев это, также приложат усилия и изменят свою стратегию, чтобы повторить наш успех. И рынок двинется в правильном направлении.
Tristan Yates, MBA, PMP, www.tristanyates.com.
Tristan Yates
Благодаря войне в Ираке подрядчик разросся как на дрожжах, несмотря на то, что он и так имел штат из 130 тысяч сотрудников и доход в 30 миллиардов долларов. Он смог позволить себе разработку внутренних IT-проектов, о которых руководство мечтало годами. Я работал как раз над ним. Проект включал в себя построение портала, объединяющего ресурсы предприятия, и разработку системы управления знаниями.
Одной из часто критикуемых черт систем управления знаниями является то, что под видом новых разработок продаются косметически измененные старые. Производители берут электронную доску объявлений, связывают ее с системой управления документами, добавляют к этому поисковой механизм для интранет, называют получившуюся солянку «Система управления знаниями» и продают ее за миллионы долларов. Мое мнение по данному вопросу таково: я считаю, что подобные системы, несомненно - очень удачное решение, но их возможности слишком сильно переоцениваются, а цены взвинчены до совершенно неадекватных значений.
Когда я начал работу над проектом, основные поставщики уже были выбраны. Opentext — для управления документами, Verity — для поиска, Microsoft — для управления службой каталогов, Netegrity — для разработки решения единого входа в систему, IBM — для создания корпоративного портала. От IBM с нами постоянно работал один консультант, и еще один время от времени приезжал. Первый был аналитиком проекта. Его задачей являлся контроль взаимодействия портала и остального программного обеспечения, а также помощь в планировании всего проекта. Но мы так и не получили от него никакой помощи в планировании или в анализе. Большинство времени он тратил на вопросы продажи.
Грамотное решение задачи выбора поставщиков является весьма сложной задачей. Если руководство выбирало поставщика, или даже просто подумывало об этом, консультант должен был проработать вопрос и выдать готовые предложения. Руководство, со своей стороны, должно было выбрать и радоваться решению очередной проблемы. Вопросы, существуют ли конкурирующие с IBM решения, как правило, не задавались.
Работа второго консультанта была еще более странной. Он показывал нам примеры, в которых какие-то компании использовали такие же решения и экономили тем самым миллионы долларов. Презентации имели отличное качество. Они выглядели убедительно и логически связанно. Перед уходом консультант пригласил нас прослушать в записи телеконференцию, которую проводил его гуру, Лари Прусак. Прусак — глава подразделения IBM, занимающегося системами управления знаниями, автор нескольких книг по этой тематике.
Постепенно, компоненты разных производителей были заменены на аналоги от IBM. Наконец, все пришли к решению использовать DB2. Проблема заключалась в том, что никто не знал, сколько это будет стоить, и заработает ли это все вообще.
Где в это время был технический персонал? В большинстве своем они старались держаться подальше, поскольку явно не хотели нести ответственность за реализацию проекта. В общем-то они не хотели чуть что оказаться на крючке, осуществляя предложенные IBM решения. Разумеется, IBM была более чем довольна сложившейся ситуацией.
Конечно, в мою задачу входило информирование руководства о том, сколько в итоге обойдется портал и система управления знаниями. Для этого я получал отчеты от IBM и технической команды. Но IBM поступала довольно хитро, указывая в качестве стоимости что-то вроде: «если все пойдет по плану, на выполнение большинства этих задач уйдет не более пары недель». Нашу техническую команду было трудно заставить что-либо посчитать в данном направлении, так как, как было сказано выше, они не хотели брать на себя никакой ответственности за реализацию этого проекта. Иногда, когда их все же удавалось уговорить сделать расчеты, их прогнозы выглядели слишком оптимистично и также были полны различных оговорок. Дэдлайн приближался быстро, но проект был еще далек от завершения. Количество необходимых ресурсов росло с каждым днем его продвижения. Руководство очень неохотно отодвигало дэдлайн, так как завершение проекта до конца года сулило множество бонусов. Было решено использовать решения IBM везде, где это было возможно, даже не смотря на то, что планирование проекта еще не было до конца завершено (из-за недоработок консультантов IBM).
Кроме того, наши конференц-залы были переполнены консультантами IBM Global Services. Когда я поинтересовался, во сколько они нам обходятся, то получил ответ: 250 $/час. Однако это оказалось неправдой. На самом деле мы платили за них по 325 $/час. Что же мы получали за 325 $/час? Руководство считало, что мы получаем настоящих экспертов от IBM. Однако мы получали работников от субподрядчика. Мы платили IBM 325 $/час; IBM платила их субподрядчику 165 $/час. Субподрядчик платил людям зарплаты от 90 до 100 тысяч долларов в год, что в пересчете эквивалентно 75 $/час, т.е. среднерыночному значению. Таким образом, мы переплачивали 333%.
Были ли те люди экспертами? Да, безусловно, среди них было несколько настоящих экспертов. Большинство же было простыми Java-программистами или администраторами Websphere. И еще несколько были совсем бесполезны для нашего проекта. Это было совершенно типичное распределение работников: несколько звезд, серое большинство и бесполезное меньшинство. Я хорошо знаю рынок контрактной разработки, поскольку сам как-то выполнял на заказ несколько Java-проектов и имею друзей, которые до сих пор этим занимаются. Средний разработчик получает от 50 до 100 долларов в час, в зависимости от его опыта, сертификатов и текущей обстановки в регионе. Большинство таких разработчиков работают на контрактные агентства, которые добавляют к цене разработки еще 30 $/час. Если вам удается найти собственных клиентов и стать независимым разработчиком, вы сможете зарабатывать 100 $/час.
Так что когда я увидел цифры, я был шокирован, потому что знал множество людей, которые согласились бы выполнять такую же работу за 80-100 $ в час, причем делали бы это намного лучше. Но руководство не хотело создавать себе лишние проблемы при работе с независимыми разработчиками, даже, несмотря на то, что они выполнили бы в 4 раза больший объем работы за ту же цену. IBM заявляла, что эксперты закончат проект намного быстрее, а на самом деле предоставляла обычных сотрудников, которые не обладали каким-либо неординарными навыками.
Еще одной интересной вещью, которую я обнаружил, является то, что организация компании-субподрядчика IBM - эффективный способ зарабатывания денег. Дело в том, что хозяином конторы-подрядчика, с которой мы работали, был бывший сотрудник отдела продаж IBM. Ему не составляло труда подсчитать, что можно заработать кучу денег, набрав толпу специалистов и продавая их IBM по 165 $/ час. Именно так все обычно и происходит. Мы подсчитали, что подобный предприниматель зарабатывает 90 тысяч долларов в неделю на нашем контракте, при этом ничего по сути не делая. Нанимай народ да выставляй счета – вот и вся работа :)
нехватка денег
Наши затраты настолько превосходили бюджет, что мы даже боялись говорить об этом. Мы предполагали, что IBM просидит у нас 3 месяца, за которые как раз и освоится предполагаемый бюджет (с помощью обсуждавшихся выше 325 $/час). Но на этом дело не кончилось. IBM находилась в нашем проекте 7 месяцев, прожигая больше четверти миллиона долларов в неделю. Более того, затраты на Global Services — это еще не все. Мы платили также за лицензии и поддержку Websphere, Websphere Portal, Websphere Content Management, Tivoli Access Manager, и DB2.
IBM, представившая себя ведущим производителем и интегратором, не сдержала обещаний, и это при таких высоких ценах!
В итоге мы получили сложный в использовании корпоративный портал с несколькими достаточно стандартными портлетами и несколькими встроенными приложениями. Множество аспектов интеграции приложений были просто оставлены без внимания. Ни одна идея из тех красочных презентаций по управлению знаниями, что мы видели в начале, не была реализована.
что пошло не так
Несомненно, что наше руководство допустило серьезные ошибки. Это мой второй совместный проект с IBM, и я опять вижу те же самые проблемы. Я писал руководству множество предупреждений, но они не обращали на них внимания, так как IBM – солиднейшая компания и их решения – по крайней мере бумаге - выглядели очень красиво. Это привело к тому, что продукты IBM выбирались даже в том случае, когда их применимость для нашего проекта было под большим вопросом или вообще они выглядели... как бы это сказать помягче... в общем, устрашающе :)
IBM представляет себя другим как провайдер бизнес-решений. Такая позиция позволяет им давать рекомендации по архитектуре и выбору продуктов. Не сложно догадаться, чьи программные и аппаратные решения обычно рекомендуются клиентам.
Несмотря на то, что IBM позиционирует себя как компания с большими возможностями (например, шахматные суперкомпьютеры), большинство из ее клиентов нуждается в самых простых вещах: в системах, поддерживающих веб, базы данных и компетентных технических специалистах, которые могли бы все это установить и запустить. Все это теперь — обычные потребительские услуги, и почему компании должны переплачивать IBM за это в троекратном размере?
учитесь на наших ошибках
Говорят, что образованных людей гораздо проще обмануть, так как они считают, что их нельзя обмануть. Так что если вы слишком умны для следующих советов, не проходите мимо — это именно то, что вам нужно. Не повторяйте ошибок нашего руководства!
Итак, советы.
1. Не упрощайте процесс выбора поставщиков. Выбор должен производиться на основе тендеров. Никогда (слышите, никогда!) не спрашивайте у реализаторов совета по поводу стратегии, архитектуры или выбора продуктов. У них нет никакого мотива действительно помочь вам, зато мотивации продать вам какой-либо бесполезный продукт втридорога – этого предостаточно :)
2. Использование открытых стандартов обеспечивает большую гибкость в выборе поставщиков. Используйте это! Вы должны хорошо чувствовать рынок и уметь быстро просчитать накрутку, которую делают перепродвацы. Запоминайте значения накруток отдельно от стоимости самих реализаций.
3. Проверяйте резюме индивидуальных консультантов. Консультант, претендующий на 250$/час, должен уметь ходить по воде, что должно быть отражено в резюме.
4. Создайте себе список возможных реализаторов проекта, который должен включать крупных и мелких производителей оборудования/софта, небольших независимых подрядчиков и обладающих необходимыми навыками собственных работников предприятия.
5. Запустите небольшой тестовый проект для проверки на практике выбранных архитектур, технологий и, конечно же, поставщиков :).
6. Неплохо бы разжиться «инсайдерской информацией». Хехе. самое время поделиться с вами моей светлой мыслью! Представляете, если бы IT-директора хотя бы нескольких компаний из списка Fortune 500 поделились бы с дргуими информацией о «профпригодности» своих поставщиков и инсталляторов? ;) Разумеется, вряд ли кто-то просто так поделится информацией такого рода с конкурентами. Например, Coca-Cola вряд ли будет делиться информацией с Pepsi, но, скорее всего, поделится ей с Dow Chemical, Allstate, Bank of America, Diageo и с еще несколькими не конкурирующими компаниями. Подумайте на досуге над рассказами о проектах, которые реализованы в других компаниях, и – главным образом - об их ошибках, которых можно будет избежать.
В общем, одна из главных проблем в том, что руководство не может получить объективную информацию об том или ином поставщике, читая их официальный веб-сайт, журнал с их рекламой или общаясь с представителями лично. Таким образом, если руководители хотят получать объективную информацию, так пусть поймут, что информацией этой надо делиться. Иначе ей появиться неоткуда...
И вот еще. Если мы будем покупать продукты и услуги фирм, которые задирают цены, перегружают проекты лишними компонентами и не выполняют требования договоров, то скоро такая модель ведения бизнеса станет типичной для IT-рынка. С другой стороны, если мы приложим усилия для поиска хорошо работающих компаний, другие, увидев это, также приложат усилия и изменят свою стратегию, чтобы повторить наш успех. И рынок двинется в правильном направлении.
Tristan Yates, MBA, PMP, www.tristanyates.com.
Tristan Yates
Сетевые решения. Статья была опубликована в номере 01 за 2006 год в рубрике бизнес
