Инновационные мероприятия в сфере информатизации призваны обеспечить своевременное и эффективное внедрение новых и новейших достижений для успешного и эффективного ее развития.
Корпоративные заказчики выплачивают миллионы долларов ведущим производителям и консультантам, в конечном счете вверяя им свое будущее. Но руководителям информационных служб при этом хотелось бы убедиться в том, что нынешние лидеры в области высоких технологий завтра не утратят позиций и фирма не попадет в плен устаревшей технологии.
Лидеры рынка, закрепившиеся на своих позициях, иногда склонны сознательно избегать кардинальных изменений технологии до самого последнего момента; примерами могут служить равнодушное отношение IBM к зарождению ПК, отрицательное отношение Кеннета Олсена (DEC) к RISC-процессорам, а также то, как Microsoft пропустила возникновение Интернет.
Обычно фирмы уделяют основное внимание закупочным ценам, однако не менее важно проанализировать планы производителей в отношении модернизации их продукции с учетом появления новых технологий. И быстрый рост оборота, и значительные расходы на исследования и разработки далеко не всегда преобразуются в новые технологии. К тому же если производитель выпускает продукты, которые необходимы потребителям именно сейчас, то это хорошо только на первый взгляд: слишком сильная ориентация на пользователей приводит к недооценке так называемых «разрушительных» технологий, т.е. тех, которые пока еще не интересуют потребителей.
В результате может сложиться ситуация, когда корпоративным заказчикам понадобится некая радикально новая («разрушительная») технология, а производитель, следовавший на поводу у пользователей по пути развития стабильных технологий, вполне вероятно, упустит подходящий момент ее внедрения. В свою очередь, и потребитель почти так же беспомощен перед «разрушительной» технологией, как и производитель.
Существует несколько достаточно расплывчатых методик, которые могут выявить инновационную готовность производителей.
Одна из них – ориентация на разработку прототипов. Она возникла на основе изучения методов, используемых компаниями, выпускающими аппаратное и программное обеспечение. Дело в том, что традиционная модель разработки ориентируется на спецификации, т.е. компания анализирует требования к системе, пишет и утверждает спецификацию, а затем постепенно реализует продукт. Эту модель еще называют каскадной или подходом «сверху вниз».
Подход, ориентированный на создание прототипов, намного более адаптивен: разработчик быстро создает прототип и затем совершенствует его. В средах, которые быстро меняются, модель разработки на основе прототипов выглядит более подходящей. Все, кто работает в мире Интернет, отдают предпочтение именно этой модели. К примеру, Microsoft использует прототипный подход к исследованиям и разработке офисных приложений.
Правда, несмотря на преимущества прототипной разработки, руководители корпоративных информационных служб считают более удобной модель, определяемую спецификациями, как более предсказуемую. В то же время многие потребители скорее предпочтут увидеть работающий прототип, на создание которого ушло меньше месяца, а затем еще шесть месяцев понаблюдать за его развитием, а также за реакцией разработчика на свои замечания, чем после пятимесячного ожидания результата воплощения спецификаций получить продукт, который совсем не похож на то, что нужно.
Интерес представляет и то, сколько проектов производитель разрабатывает одновременно. Выявлено, что средняя высокотехнологичная компания обычно пытается разработать больше продуктов, чем в состоянии сделать. Общее же эмпирическое правило состоит в том, что ведущие специалисты должны вести не более двух ключевых проектов одновременно.
Администраторы ИС также должны внимательно изучить стратегию приобретений, принятую их поставщиками. Например, некоторые доминирующие корпорации типа Cisco и Microsoft пришли к выводу, что целесообразнее приобретать идеи для продуктов следующего поколения у начинающих фирм, чем генерировать их самим. Анализируя приобретения компании и судьбу купленных ими технологий, администраторы ИС могут получить представление о способности поставщика воспользоваться новым «имуществом». Покупка, а не создание новой технологии – это законный и даже эффективный подход, хотя, вероятно, он все же свидетельствует о том, что такая компания скорее склонна сразу извлекать из будущего коммерческую пользу, вместо того чтобы это будущее создавать собственными силами. Конечно, подобный подход может оказаться успешным, если компании-покупатели сохранят свой основной персонал и будут финансировать продолжительные разработки.
Как показывает зарубежный опыт, представляет интерес также и оценка практики сотрудничества фирм с университетами и лабораториями.
Не все фирмы в состоянии сами решать задачи оценки возможностей поставщика и его технологии. За рубежом обычно всегда находятся независимые компании, готовые решать эти задачи за определенную плату. Более того, независимые консультанты и системные интеграторы помогают выявить и испытать еще не вышедшие из стен исследовательских лабораторий перспективные технологии. Такие независимые испытания нужны еще и потому, что большинство крупных компаний обычно стараются скорее продвинуть пусть и перспективные, но еще сырые технологии на рынок.
Руководители информационных служб предприятий при выборе поставщиков склонны недооценивать необходимость анализа их стратегии в области инноваций. Однако проблема инноваций именно в сфере информатизации всегда возникает при выполнении программ развития в самых разных областях деятельности. Более того, при развитии любой сферы деятельности практически неизбежно нужно проводить инновационные мероприятия по информатизации.
В качестве примера можно привести характерную ситуацию, сложившуюся летом 1998 г. в европейских финансовых учреждениях вокруг перехода европейских стран на единую европейскую валюту евро. Страны, отказывавшиеся от перехода на евро, в качестве одного из основных аргументов приводили необходимость существенных изменений в банковской сфере, прежде всего в области ее информатизации. Банки этих стран стояли перед необходимостью создания или приобретения программных средств, работающих в двух или более валютах. Ранее у них такие операции не требовалось обеспечивать, и таких программ во многих банках просто не было. Оказалось, что для этого требуются огромные средства.
