Главная страница Visual 2000 · Общий список статей

Как избежать зависимости заказчика от исполнителя

Андрей Колесов

© 1999, Андрей Колесов
Авторский вариант. Статья была опубликована c незначительной литературной правкой в еженедельнике PC Week/RE № 46/99, c.48.


По мере возрастания значения информационных технологий...

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

В начало статьи

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

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

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

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

В начало статьи

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

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

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

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

В начало статьи

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

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

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

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

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

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

В начало статьи

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

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

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

В начало статьи

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

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

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

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

В начало статьи

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

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

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

В начало статьи

Готовы ли исполнители угнаться за заказчиками?

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

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

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

В начало статьи