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

Лидеры рынка, закрепившиеся на своих позициях, иногда склонны сознательно избегать кардинальных изменений техно­логии до самого последнего момента. Примерами могут служить равнодушное отношение IBM к зарождению ПК, отрицательное отношение Кеннета Олсена (DEC) к RISC-процессорам, а также то, как Microsoft пропустила возникновение Интернет.

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

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

Существует несколько достаточно расплывчатых методик, которые могут выявить инновационную готовность производи­телей. Одна из них – ориентация на разработку прототипов. Она возникла на основе изучения методов, используемых компания­ми, выпускающими аппаратное и программное обеспечение. Дело в том, что традиционная модель разработки ориентируется на спецификации, т.е. компания анализирует требования к системе, пишет и утверждает спецификацию, а затем постепенно реализу­ет продукт. Эту модель еще называют каскадной или подходом «сверху вниз».

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

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

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

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

Администраторы ИС также должны внимательно изучить стратегию приобретений, принятую их поставщиками. Например, некоторые доминирующие корпорации типа Cisco и Microsoft пришли к выводу, что целесообразнее приобретать идеи для про­дуктов следующего поколения у начинающих фирм, чем генери­ровать их самим. Анализируя приобретения компании и судьбу купленных ими технологий, администраторы ИС могут получить представление о способности поставщика воспользоваться новым «имуществом».

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

Как показывает зарубежный опыт, представляет интерес так­же и оценка практики сотрудничества фирм с университетами и лабораториями.

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

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

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