BC/NW 2013, №2 (23):12.1
СИСТЕМНАЯ ИНТЕГРАЦИЯ: ЭКОНОМИЯ СРЕДСТВ
ИЛИ ДОПОЛНИТЕЛЬНЫЕ ЗАТРАТЫ
В.О.Рыбинцев
Данная статья продолжает изложение вопросов по тематике Системной интеграции, начатое в [1] и [2]. Приведенные ранее рассуждения показывают, что всякий потенциальный заказчик информационной системы (ИС) неизбежно стоит перед выбором: привлекать Системного интегратора для построения/модернизации своей ИС или решать данную задачу своими силами. Понятно, что этот вопрос не стоял бы, если бы стоимость услуг Системного интегратора не доходила до 20% от стоимости проекта. Поэтому, руководитель компании, принявший решение о создании/модернизации ИС должен понять, оправданы ли будут эти дополнительные затраты. Попробуем ответить на данный вопрос и рассмотрим, какие «подводные камни» существуют на пути создания/модернизации ИС, и способен ли Системный интегратор исключить/снизить потери от некачественного решения обозначенной задачи.
Чтобы построить ИС требуемого бизнесу качества, это качество нужно оценить. Как было отмечено в [2], наиболее распространенным (но не единственным!) критерием качества ИС является ее производительность, которую целесообразно оценивать по результатам доступных промышленных тестов. Тесты – это тот инструмент, с помощью которого можно измерить и сравнить по производительности разные варианты построения ИС. Понятно [2], что в зависимости от класса решаемых задач (DB, HPC, WEB), эти инструменты для измерения (тесты) будут разными.
В общем случае, если нарисовать ось качества ИС по выбранному тесту, то требуемое бизнесу качество Q можно определить в виде некоторого диапазона {Qmin:Qmax}. Качество ИС ниже Qmin не позволит бизнесу решить поставленные производственные задачи, а качество выше Qmax – приведет к неоправданно высоким затратам на ИС. Текущее состояние (качество) ИС на этой оси обозначено как Q0, а целевое – как Q1. Таким образом, в процессе построения/модернизации ИС предстоит осуществить перевод существующей ИС из состояния Q0 в состояние Q1 (см. Рис. 1).
Рис. 1. Общая постановка задачи достижения требуемого качества ИС
Первой проблемой на пути решения данной задачи является правильная оценка текущего (Q0) состояния системы. На первый взгляд может показаться, что именно пользователи ИС могут наилучшим образом произвести такую оценку. На самом деле, оценка качества системы изнутри сопряжена как с риском переоценки, так и с риском недооценки, что одинаково плохо, так как неправильная исходная точка неизбежно даст ошибочную оценку стоимости проекта. Понятно, что при построении ИС «с нуля» ошибиться в оценке Q0 невозможно, но таких ситуаций уже практически не осталось: какие-то средства автоматизации текущих бизнес-процессов у заказчика непременно имеются.
В процессе оценки текущего состояния ИС своими силами многое зависит от такого субъективного фактора, как возраст (опыт) руководителя данного проекта. Молодому руководителю присущ некоторый избыточный оптимизм: переоценка текущего и недооценка требуемого качества ИС (купим пару «писишек», за два месяца напишем/перепишем прикладное программное обеспечение и решим задачу). Такие высказывания очень импонируют финансовому руководству, но с весьма высокой вероятностью приводят к отрицательному результату. Тот факт, что финансовые затраты на подобный эксперимент окажутся не слишком большими, вряд ли сможет кого-то успокоить, так как будет потерян другой (невосполнимый) ресурс – время.
Более опытный руководитель подобного проекта будет склонен к чрезмерному пессимизму как в оценке текущего состояния ИС, так и в формировании требований к целевой системе. Исходя из подобного пессимистического взгляда на ситуацию, его оценка стоимости проекта может оказаться столь высокой, что породит у финансового руководства сомнения в целесообразности реализации данного проекта вообще. В итоге, это вновь может привести к потере времени. Трудно предположить, что «стреляя» из неправильного места по неправильной мишени удастся попасть в нужную точку, да еще и с первого раза!
Все сказанное схематично отражено на Рис. 2.
Рис. 2. Возможные варианты оценки требуемого качества ИС
В подобной ситуации у Системного интегратора гораздо больше шансов объективно оценить текущее состояние ИС (точка Q0), и правильно сформировать диапазон {Qmin:Qmax} для целевой системы, поскольку у него за плечами [1]:
· опыт выполнения подобных проектов;
· знание современных и требуемых заказчику информационных технологий;
· правильная методология проведения работ.
При этом, ориентируясь на формирование долгосрочных отношений с заказчиком (правило Системной интеграции №3 [2]), Системный интегратор будет стремиться непременно «попасть» в диапазон {Qmin:Qmax}, чтобы качественно решить поставленную задачу. Одновременно, исходя из правила Системной интеграции №2 [2] – обеспечение разумной достаточности качества ИС, точка Q1 будет выбрана интегратором в первой трети указанного диапазона, чтобы, с одной стороны, гарантированно решить поставленную задачу, а с другой стороны - оставить возможность дальнейшего развития ИС в рамках заданного уровня сложности этой задачи. Такой подход позволит заказчику ИС избежать как непродуктивных финансовых, так и временных затрат.
Другим субъективным фактором, способным оказать существенное (негативное) влияние на процесс построения/модернизации ИС собственными силами, является специализация руководителя проекта. Типичными являются следующими варианты:
· руководитель проекта – специалист в области IT (далее – «компьютерщик») со своей командой «компьютерщиков»;
· руководитель проекта – специалист в той предметной области, для которой строится ИС (далее – «прикладник»), со своей командой «прикладников».
Если руководителем проекта является «прикладник» и его команда, а «компьютерщики» занимают подчиненное положение, то типичным является следующий сценарий развития событий.
«Прикладники», исходя из своего понимания задачи, выбирают прикладное программное обеспечение (SW) и предоставляют руководству оценку его стоимости (как правило, несколько вариантов от разных производителей). Поскольку «прикладники» - главные в проекте, именно они обращаются к производителям SW за рекомендациями по выбору оборудования (HW) и его параметров. Далее (с помощью «компьютерщиков» или без них) осуществляется оценка стоимости HW, которая и предоставляется финансовому руководству для принятия решения. Понятно, что запрошенный объем финансирования никогда предоставлен не будет (всегда будет меньше), т.е. проект придется урезать (например, на 25%).
В сложившейся ситуации «прикладники», являясь руководителями проекта, обратятся к производителям SW с просьбой снизить стоимость проекта на обозначенные 25%. Не нужно быть пророком, чтобы предугадать действия производителя SW: в первую очередь будут снижены затраты на HW!
Может возникнуть вопрос: почему «прикладники» по вопросу снижения стоимости проекта обратятся за помощью именно к производителю SW. Ответ весьма очевиден: с производителем SW они будут разговаривать на понятном им языке предметной области, а не о процессорных ядрах, гигагерцах, терабайтах и гигабитах в секунду, что характерно для производителя HW.
Важным параметром любого интеграционного проекта является соотношение стоимости HW/SW, обеспечивающее построение сбалансированной ИС. Понятно, что для каждого класса прикладных задач это соотношение будет своим. Пусть, например, это соотношение для рассматриваемой предметной области составляет 40% на 60%, и в исходном состоянии было выдержано. Поскольку общий объем финансирования проекта сократился (на 25%), а за помощью в сокращении затрат обратились к производителю SW, это сокращение будет реализовано в основном за счет HW (см. Рис. 3).
Рис. 3. Соотношение стоимости HW/SW до ( I ) и после ( II ) сокращения объема
финансирования проекта на 25% (вариант производителя SW)
При этом аргументация может быть следующей:
· Важно обеспечить пользователей ИС лицензиями на SW, чтобы они могли работать;
· На начальном этапе, пока пользователи не полностью овладели навыками работы с SW, они не смогут полностью загрузить ресурсы HW;
· Необходимые для полноценной работы параметры HW (количество процессорных ядер, объем дискового пространства, емкость систем хранения и пр.) могут быть достигнуты позже;
· Оборудование постоянно дешевеет, и «завтра» вы потратите на улучшение параметров HW меньше средств, чем «сегодня».
В результате, проект будет реализован с существенным перекосом соотношения HW/SW в пользу SW, что, скорее всего, приведет к следующим негативным для заказчика ИС последствиям:
· Использовать все купленные лицензии не удастся по причине отсутствия необходимого количества подготовленного персонала;
· Специалисты, способные решать действительно сложные задачи с применением новой ИС, не смогут этого сделать по причине нехватки ресурсов HW;
· Покупка (спустя некоторое время) дополнительного оборудования встретит однозначно отрицательную реакцию со стороны финансового руководства и может весьма затянутся по времени.
Рассмотрим альтернативный сценарий развития событий, при котором руководителями проекта построения/модернизации ИС являются «компьютерщики». Они, опираясь на пожелания «прикладников» относительно прикладного SW, идут к производителям HW с запросом на формирование аппаратной платформы. При этом, безусловно, проверяется, сертифицировано ли предлагаемое оборудование для работы с выбранным «прикладниками» SW. Пусть предложенные производителем HW параметры оборудования будут такими, что идеальное соотношение стоимости HW/SW (40%/60%) удалось сохранить. Полученные оценки стоимости «компьютерщики», являясь руководителями проекта, предоставляют финансовому руководству. Как и в первом случае, объем финансирования урезают (пусть, вновь на 25%), и компьютерщики направляются к производителю HW с целью снизить стоимость проекта.
Почему они пойдут именно к производителю HW? По той же причине, по которой «прикладники» пойдут к производителю SW: им трудно разговаривать на языке предметной области, а вот язык терабайтов и гигагерц для них привычен и понятен.
Результат такого обращения не трудно предвидеть. Производитель HW найдет массу убедительных аргументов, чтобы обеспечить снижение стоимости проекта за счет уменьшения стоимости SW (см. Рис. 4):
· На этапе обучения достаточно иметь по одной лицензии на каждый функциональный модуль SW;
· На первых порах использования ИС самые сложные (самые дорогие) модули использовать не удастся по причине нехватки квалификации персонала;
· Дополнительные лицензии легко купить в любое время, так как для них практически не существует понятия «время поставки», а оборудование нужно заказать, изготовить, привезти;
· Докупать будете только те лицензии и в том количестве, которые действительно необходимы для работы.
Рис. 4. Соотношение стоимости HW/SW до ( I ) и после ( II ) сокращения объема
финансирования проекта на 25% (вариант производителя HW)
В результате, проект будет реализован, но теперь уже с перекосом отношения стоимости HW/SW в пользу HW, что тоже плохо:
· Загрузить все купленное оборудование не удастся, и оно будет простаивать;
· Процесс обучения затянется, так как нехватка требуемого количества лицензий приведет либо к групповой форме обучения (с меньшей эффективностью), либо к посменному характеру этого процесса;
· Наиболее сложные (наиболее важные для производства) задачи вообще не будут решаться из-за отсутствия нужных лицензий, хотя часть персонала вполне была бы способна их освоить;
· Обращение к финансовому руководству за дополнительным финансированием вызовет ту же (негативную) реакцию, что и в первом случае.
В рассматриваемой ситуации Системный интегратор будет действовать совершенно иным образом. Понятно, что его услуги потребуют дополнительного финансирования, но источник этого финансирования (HW или SW) для него не имеет значения. Заработок Системного интегратора определяется общей сложностью (стоимостью) проекта и не зависит от соотношения стоимости HW/SW.
Ориентируясь на долгосрочные отношения заказчиком (правило Системной интеграции № 3 [2]), интегратор будет стремиться обеспечить требуемое соотношение стоимости HW/SW, так как ему нет смысла искусственно формировать перекос!
Прежде, чем строить/модернизировать ИС, Системный интегратор проведет кропотливый анализ текущего состояния, чтобы определить исходную точку (Q0), и путем долгих переговоров с заказчиком определит истинное требуемое качество (диапазон {Qmin : Qmax}) целевой системы. Конечно, все эти оценки тоже будут не идеальными, но погрешность заметно снизится. В результате будет «произведен выстрел из правильного места по заданным координатам мишени, и стрелять будет снайпер (он уже много раз стрелял и набил руку)». Как уже отмечалось выше, следует стремиться попасть в точку Q1, которая делит диапазон {Qmin : Qmax} в соотношении 1 к 2.
При данном сценарии развития событий переговоры с производителями SW и HW будет вести Системный интегратор, для которого данная процедура является штатной, в отличии от представителя заказчика ИС, который, возможно, делает это первый раз в жизни. Вероятность получения «правильных» (более низких) цен от производителей SW и HW у Системного интегратора будет заметно выше, так как подобные переговоры уже неоднократно происходили, интегратор знает реальную рыночную стоимость товара и умело аргументирует необходимость снижения стоимости, опираясь на цены конкурентов, текущее положение на рынке данного производителя и даже дату проведения переговоров. Полученными в результате умелого проведения переговоров с производителями HW и SW скидками Системный интегратор непременно поделится с заказчиком ИС, что может компенсировать затраты последнего на интеграционные работы, т.е. интегратор сам заработает себе необходимые средства.
Поскольку финансовые руководители потенциальных заказчиков на работы по построению/модернизации ИС вряд ли читают статьи по методологии проведения интеграционных работ, а если и начинают читать, то, скорее всего, не дочитывают их до конца, в заключении будет уместным упомянуть об еще одном важном преимуществе привлечения Системного интегратора. Общий успех проекта и его финансирование в существенной степени зависят от переговоров с финансовым руководством заказчика. Известная мудрость - «нет пророка в своем отечестве» справедлива и в рассматриваемом случае. Практика показывает, что финансовый руководитель заказчика с большим вниманием относится к рекомендациям Системного интегратора, который в процессе переговоров ссылается на аналогичные (успешные) проекты, выполненные им, чем к рассуждениям и аргументации своих сотрудников. В результате, первоначальная стоимость проекта непременно будет снижена (иначе, зачем финансовый руководитель тратит свое время!), но снижена, например, на 15% вместо 25%. Важно, что опытный Системный интегратор может заранее спрогнозировать подобное развитие событий и принять адекватные шаги по корректировке исходной стоимости проекта.
В результате, привлечение Системного интегратора (как это ни удивительно!) окажется выгодным всем участникам процесса:
· производители HW и SW продадут свои продукты, а несколько большая скидка, выданная Системному интегратору, окупится тем, что интегратор следующий раз при выполнении очередного проекта обратится именно к этим производителям, а не к их конкурентам;
· заказчик получит действительно сбалансированную информационную систему, которая в течение запланированного периода использования будет успешно решать производственные задачи;
· Системный интегратор честно заработает положенные ему деньги, и не будет считать данный проект убыточным (выделяемые интегратором ресурсы на выполнение проекта и отношение конкретных сотрудников интегратора к работе существенно зависят от уровня финансирования).
1. Рыбинцев В.О. Системная интеграция – это просто! http://network-journal.mpei.ac.ru/cgi-bin/main.pl?l=ru&n=21&pa=13&ar=1
2. Рыбинцев В.О. Системная интеграция: искусство или ремесло. http://network-journal.mpei.ac.ru/cgi-bin/main.pl?l=ru&n=22&pa=10&ar=1