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

Тема зависимости пользователя от поставщика ИТ глобальна и многогранна. Ее можно рассматривать как на макроуровне (взаимоотношения компьютерной индустрии и всех остальных отраслей экономики), так и на уровне взаимодействия начальника и конкретных специалистов внутри небольшого коллектива. Не претендуя на всестороннее исследование данной проблемы, хотелось бы познакомить читателей с мнениями специалистов по этому вопросу, прозвучавшими на одном из круглых столов, проходивших в рамках конференции “Интеллектуальное предприятие’99”.

ИТ развиваются слишком быстро

Как это ни парадоксально, но один из аспектов проблемы заключается в том, что темпы обновления ИТ опережают реальные потребности бизнеса. В ходе дискуссии была рассказана такая история (она весьма типична, поэтому не имеет смысла называть конкретных действующих лиц).

Одно крупное ведомство для создания своей ИС выбрало аппаратно-программную платформу очень известного поставщика, получив от него уверения в возможности гибкого расширения мощности системы за счет простого увеличения объема памяти, числа процессоров и пр. Через шесть лет заказчику потребовалось осуществить такое расширение, но тут поставщик заявил следующее: “Да, мы готовы выполнить свои обещания, но ведь сменились два поколения техники, такие процессоры уже не выпускаются. Мы, безусловно, сделаем обновление, и даже со скидками, но это будет стоить...” - и здесь выяснилось, что затраты на модернизацию в несколько раз превышают первоначальные.

Нужно отметить, что обновление прикладного ПО на предприятиях осуществляется еще медленнее. В этом плане весьма характерно, что я получаю письма читателей по поводу моей статьи “Clipper-программы могут работать на современных ПК”, опубликованной более года назад (см. PC Week/RE, № 46/98, с. 16). Ситуация довольно стандартная: на предприятиях идет смена парка ПК (чтобы можно было использовать современные приложения), в результате которого перестают работать старые программы (написанные не только на Clipper), в принципе вполне устраивающие пользователя. Факт зависимости потребителя налицо: поставщик давно прекратил поддержку своих старых систем и клиент вынужден приобретать новые продукты только потому, что простая модернизация ему уже не поможет.

Делать самим или заказывать на стороне?

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

Начальник департамента Сибирской нефтяной компании Борис Мироненко рассказал довольно интересную историю, произошедшую на Омском нефтеперерабатывающем заводе (одном из крупнейших предприятий этого профиля в мире). В 1995 г. после тщательного анализа там было решено начать внедрение системы SAP R/3, несмотря на осознаваемую опасность “сесть на иглу”. После довольно крупных начальных инвестиций оказалось, что дальнейшее сопровождение и развитие системы требует постоянно увеличивающихся затрат. Чтобы смягчить остроту этой проблемы, было решено вложить значительные средства (около 15% от общей стоимости работ) в подготовку своих специалистов, создать собственную команду консультантов.

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

Со своими еще больше проблем

Не менее характерную историю рассказал главный инженер Министерства по налогам и сборам Вячеслав Шолохов. В 1992 г. началось создание всероссийской автоматизированной информационной системы “Налог” силами подведомственного этому министерству Главного научного информационно-вычислительного центра (ГНИВЦ) и его региональных филиалов.

Проблема заключалась в том, что центр одновременно был и заказчиком, и исполнителем, т. е. разработка шла фактически без технических заданий и документирования. Результат очевиден: выигрыш на начальном этапе за счет сокращения затрат на “бумажные дела” обернулся потерями, когда наступила необходимость объединения отдельных задач. Кроме того, ГНИВЦ не успевал за реальными потребностями налоговых служб, из-за чего на местах начали либо действовать самостоятельно, либо привлекать сторонние фирмы к разработке программных средств. Все это отнюдь не способствовало появлению унифицированных решений.

С приходом в министерство новых руководителей ИТ-направления, ситуация начала меняться, но понятно, что было бы лучше продумать систему управления проектом изначально. Вывод же г-на Шолохова однозначен: “Если доверить управление разработкой самому разработчику, вы погибли. У заказчика должны быть специалисты, которые точно знают, что они заказывают, могут детально разобраться с документами и тщательно проконтролировать работу”.

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

Руководитель департамента АСУ группы компаний “Май” Владимир Галас считает, что выполнять проект своими силами очень дорого. Где набрать столько человеко-лет, чтобы разработать сложный программный комплекс? Конечно, можно попробовать пригласить команду из некой фирмы, чтобы обеспечить нужную оперативность решения вопросов. Однако исполнитель, оторванный от “альма-матер”, быстро теряет свою квалификацию и опыт, которые так важны для заказчика. Не говоря уже о моральных аспектах подобной операции.

Заинтересован ли исполнитель в контроле над заказчиком?

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

За последние два года ситуация радикально изменилась, теперь поставщики заинтересованы в долговременном сотрудничестве. Однако это требует более высокой квалификации разработчика. В данной связи можно привести мнение Вячеслава Шолохова, который отметил, что попытки найти единого внешнего исполнителя упираются в отсутствие у большинства компьютерных компаний опыта создания крупных систем. Желающих получить подряд много, но большинство хочет выполнять мелкие задачи, а не брать на себя ответственность за организацию всей системы.

За независимость нужно платить

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

Юридическое решение проблемы зависимости заключается не только в том, что нужно более тщательно продумывать договорные обязательства. (Как отметил г-н Шолохов, на практике при создании системы “Налог” в ГНИВЦ техническое задание составлялось только для того, чтобы открыть работу, а большинство его пунктов носило чисто декларативный характер.) В своем выступлении представитель коллегии адвокатов “Мосюрцентр” Светлана Рыбак предложила подходить к данному вопросу с точки зрения бизнес-рисков, необходимости своего рода страхования от возможного появления различных непредусмотренных соглашениями обстоятельств (в том числе форс-мажорных).

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

Что говорит мировой опыт

Еще десять лет назад в нашей стране основной моделью создания прикладного ПО была модель “сделай сам” - практически каждое предприятие и ведомство имело собственный отдел разработки. Сейчас такая схема представляется многим безнадежно устаревшей, но при ближайшем рассмотрении это не совсем так. Например, в США огромное число (возможно, даже большинство) прикладных систем выполняется силами как раз собственных сотрудников фирм. Однако изучение этого опыта выявляет весьма серьезные различия между американской и отечественной практикой реализации такой схемы.

Сошлюсь в данном случае на мнение моего знакомого программиста, который занимался внутрифирменными разработками сначала в одном крупном российском банке, а последние три года - в американской корпорации (в США). Ключевое отличие состоит в более тщательном (у американцев), просто педантичном отношении к документальному оформлению всех этапов создания ПО. Обилие бумаг просто поражает новичков из России, выводит их из себя. Однако именно эта рутинная работа обеспечивает независимость процесса реализации проекта от поведения отдельных его исполнителей. Принятие решения о начале какого-либо проекта занимает в США гораздо больше времени, чем у нас, однако если решение принято, то в 80 - 90% случаев оно доводится до конца. (По оценкам моего знакомого, три года назад в российских компаниях этот показатель для внутрифирменных работ не превышал 40 - 50%.)

Заказчики уходят в отрыв

При всем своем “соответствии мировым стандартам” российская компьютерная индустрия четко отражает состояние отечественной экономики в целом. Так, независимый консультант Сергей Колесников обратил внимание еще на один важный аспект проблемы: “Если мировой информационный рынок основан на стабильности и качестве, то наш - на нестабильности и частых изменениях”. И сейчас парадокс заключается в том, что российские ИТ-поставщики оказались не очень-то готовы к наступившей относительной стабилизации в экономике.

Еще 3 - 4 года назад предложения поставщиков несколько опережали запросы клиентов и как бы поднимали заказчиков на более высокий уровень. Однако в последние годы покупатель “резко пошел вверх”, и сегодня решения, предлагаемые поставщиками, уже не удовлетворяют потребности клиента. Именно этим в значительной степени и объясняется необходимость создания в компаниях собственных коллективов разработчиков-интеграторов.

Возможно, приведенные здесь оценки ситуации покажутся субъективными и не совсем правильными. Но они отражают другую реальность отечественного компьютерного рынка - высокую степень закрытости ИТ-бизнеса, особенно когда разговор заходит о крупных проектах. Поэтому могу только присоединиться к высказыванию генерального директора компании “Диско” Михаила Донского: “Нам нужна нормальная объективная информация о том, кто что может сделать. Об истории состоявшихся проектов мы не знаем ничего”.