Поставщики обожают перекладывать риск выбора аппаратного обеспечения достаточной производительности на директоров информационных служб своих заказчиков. Не позволяйте им этого делать.

Мало кто принимает на себя риск того, что оборудование, которое покупается в рамках большого проекта, будет действительно соответствовать частоте транзакций и пакетной обработке, ради которых и делается приобретение

.... Итак, свершилось: ваша организация взяла курс на проект по развертыванию автоматизированной корпоративной системы. Если организация велика, вам светит что-то вроде SAP или Baan или PeopleSoft, работающих поверх Oracle, либо Informix на машинах IBM, HP или Sun. Бюджет сверстан плотно, однако интегратор (Andersen, KPMG или кто-то другой из той же серии) заверяет, что уложиться можно: нужно только минимизировать объем работ, индивидуальных для этого заказчика.

Приходит время составления контракта, работы искусной, но, по правде, не внушающей уверенности в том, что операция пройдет полностью согласно установленному плану. Один пункт под названием «Роли и ответственности сторон» вас даже слегка ошарашивает — из него будто бы вытекает, что большая часть работ достанется именно вам, а не консультанту. Ясность приходит в самом начале: этот заплыв не рассчитан на детей. Ваше воображение так захвачено только что потраченными на покупку и установку программного обеспечения миллионами и так невосприимчиво ко всему, кроме платежей, что риски, связанные с аппаратным обеспечением, ускользают от вашего внимания. И тем не менее: откуда известно, что аппаратура, рекомендованная интегратором, справится с ожидаемой нагрузкой? Поставщик не только скромно умалчивает о каких-либо гарантиях на сей счет, но мало того, в контракте, ближе к его концу, вы замечаете одну неприятную фразочку. Она декларирует, что за выбор аппаратного обеспечения адекватной производительности отвечаете именно вы, а не интегратор («консультант», как обычно он зовет себя сам по причинам, о которых пойдет речь ниже). Чаще всего заказчик соглашается подписать договор с такой фразой, утешаясь соображением, что как-никак он приобретает современное оборудование с числом миллионов операций в секунду, большим, чем у всего другого в его хозяйстве. Хотя есть и альтернатива: нанять третью фирму с целью проверки адекватности производительности аппаратуры. Ведь цель для вас должна быть в покупке работающей системы, а не в неприкасаемости бюджетных границ.

MIPSы способны ввести в заблуждение. Из всех «неприличных» маленьких секретов в проектах масштаба предприятия одним из самых неприличных является секрет риска выбора аппаратуры неадекватной производительности. Десятилетия крупнейших проектов по интеграции программного обеспечения сформировали традицию без всякого намека на прогресс: ответственность за то, что покупаемое в рамках большого проекта оборудование сможет на самом деле поддерживать требуемые скорости обработки транзакций и пакетной обработки, не берет на себя ни поставщик техники, ни поставщик ПО, ни интегратор. А всякий риск, если он не предусмотрен поставщиком, целиком падает на заказчика, при этом многократно возрастая по своим последствиям.

Причины, по которым поставщики уходят от ответственности, просто обескураживают. IBM, Sun и Hewlett-Packard не знают, насколько раздутым будет ПО. SAP и Oracle не могут предвидеть объем работы по настройке, выполняемой KPMG или Andersen. А консультант хочет выступать в роли советчика, а никак не интегратора. Но миллионы долларов уже уплачены, и все, чего вы хотите, — это добиться от кого-нибудь ответа: не умрут ли ваши сотрудники от старости в ожидании реакции от машины? Потребует ли ночное задание пакетной обработки полярной ночи для своего выполнения?

Об описанной выше традиции приходится сожалеть. Возникла она довольно просто, с наблюдения, сделанного программистом еще в стародавние времена (автор впервые услышал эту фразу в 1975 году): «аппаратное обеспечение дешевеет ежеминутно».

Это так, конечно. И все же оно еще недешево, а скорость, с которой разбухают программы и трафик, делают шаг спирали снижения цен почти незаметным. То есть реализация одних и тех же функций обходится вам сегодня не дешевле, чем десять лет назад, и противоречия закону Мура здесь нет.

Изготовители техники имеют свои модели подбора конфигурации и с радостью берутся помочь консультанту определить мощность установки. Однако они не дадут вам гарантий, поскольку их модели подбора могут основываться на значениях функций и объемов, совершенно отличных от ваших. (Скептики уверяют, что на самом деле подобные предположения производителей не отвечают попросту ничему, реально существующему в природе.) Более того, побудительные мотивы поставщика техники могут быть прямо противоположны вашим. Купив однажды систему за миллион или больше долларов, вы уже связаны с ней на всю жизнь. Или, в единицах жизней директора информационной службы, на много-много жизней.

Мы уже не говорим о предсказании времени реакции системы с точностью до десятой доли секунды. Ведь что требуется знать вашей организации? Будет ли новая техника в состоянии поддерживать необходимые функции и объемы в той степени, чтобы время отклика оказалось разумным, а выполнение ночных пакетных заданий или старт системы перед началом рабочего дня не вызывали судорожных действий группы поддержки — не более того. Оценки ожидаемых объемов неплохо предсказуемы на основе знания бизнес-функций (число обрабатываемых счетов и т. д.), и, хотя к началу проекта консультант может и не иметь исчерпывающего представления о требуемом объеме работ по настройке и доработке системы, даже самый скромный опыт разных проектов указывает на возможные варианты установки. Достаточно грубые параметры уже позволяют существующим программам выбора конфигурации давать вполне пристойные оценки оборудования.

Часть риска в выборе нужных моделей и конфигурации техники должен взять на себя интегратор. Но чтобы обеспечить честную игру всех сторон, и вашей в том числе, вам следует специально оговорить это в предложении участия в проекте (request for proposal, RFP). А в составляемом затем контракте нужно проследить за пунктами, касающимися отчетности интегратора. Поделиться с ним риском обойдется вам дороже, но не намного.

Оценка компьютерной производительности при реальной загрузке стоит достаточно дорого (так что в небольших проектах гнаться за ней не стоит), но в преддверии большого проекта эти деньги не пропадут.

Почти всегда выясняется, что скорости процессора хватает. Часто вам предложат купить процессор более быстрый, чем реально требуется. Со скоростью доступа к внешней памяти все иначе. После моделирования загрузки вашей системы поставщик начнет рекомендовать использование второго или третьего экземпляра базы данных, а они вызывают каскад архитектурных изменений. Выяснив характерные времена выполнения ночных пакетных заданий (и, хотелось бы, задолго до фактического программирования), вы можете изучить последствия реальных изменений архитектуры типа использования параллельной обработки, если только таковая будет иметь смысл. Все это нужно изучать в начале проекта, а не ждать, пока проблемы возникнут.

К несчастью, только немногие интеграторы готовы взять часть рисков на себя. Будучи свободными от подобных обязательств, многие не удосуживаются ознакомиться даже с процессом выбора технической конфигурации и, что еще важнее, с архитектурными аппаратными решениями. Даже в наиболее типовых ERP-проектах интеграторы редко опускаются до забот о правильном выборе оборудования.

Было бы крайне интересно получить из всех аналитических материалов, существующих на сегодняшний день, информацию о количестве организаций, вынужденных существенно увеличить затраты на оборудование уже в разгаре работ по проекту и расходующих таким образом драгоценные резервные фонды бюджета, если только последние существуют. Готов предположить, что подавляющее большинство этого не делает. Впоследствии динамично растущий заказчик может обнаружить, что фактическая нагрузка превышает ожидаемую. Тогда интегратор вздыхает с облегчением. Однако директора информационной службы заказчика не оставляет вопрос: действительно ли предложенное оборудование было в состоянии обработать первоначально заявленные объемы данных или поставщик удачно увильнул от неприятностей благодаря неверной оценке, сделанной заказчиком?

Тем, кто говорит, что все еще сложнее, и не удовлетворится относительно простыми вычислениями, я отвечу так: вы можете поддаться на покупку товара «списком». Этот список есть первая линия защиты поставщика. Вторую линию обороны образует его довод о том, что, перекладывая часть риска на поставщика, вы вынуждаете его указывать более мощное оборудование, чтобы гарантировать отсутствие с вашей стороны претензий к интегратору. Это серьезный аргумент, и он подчеркивает необходимость сформулировать обязанности с самого начала (еще в предложении участия в проекте) так, чтобы вы смогли проанализировать конкурирующие предложения еще на чистом от игры поле. Если вы предпочитаете сформулировать эти обязанности сразу после выбора поставщика, для защиты всех сторон в контракте нужно будет конструировать более детально разработанную схему рисков и компенсаций.

Так же, как и с прочими рисками, обозначенными в контракте, к риску от неадекватной производительности используемого оборудования вы вправе относиться как к реальному либо как к неактуальному. Но не начинайте дело с любимой поставщиками установки о том, что риск не касается никого, кроме вас.

Уэйн Д. Беннетт — руководитель направления коммерческих технологий юридической фирмы Bingham Dana. В прошлом Беннетт был математиком, разработчиком и директором компании по созданию ПО, многократно выступал с лекциями. Мало кто из представителей юридических фирм способен так, как Беннетт, определенно указать на законодательные мины, заложенные в пространстве между каждым директором ИС и его бизнес-целями. Еще меньше специалистов готовы рассказать нам о нередком присутствии скрытых мотивов, спрятанных за глянцем юридических документов.