Выбрать главу

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

Поэтому верно, что информационная система должна быть специфична для организации.

 

3. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

3.1. Практика

Исследование британских компаний, проведенное компанией KPMG Peat Marwick McLintock (KPMG, 1990), показало, что "30% крупнейших компьютерных проектов в Великобритании значительно превышали бюджет, выполнялись сверхурочно, а если и завершались, то не справлялись с поставленными задачами". Кроме того, Willcocks (1992) утверждает, что "к 1992 году расходы Великобритании на ИТ превысили £ I0 млрд. в год", причем эта цифра не включает расходы государственного сектора. Все эти цифры вместе взятые свидетельствуют о том, что необходим мета-метод, хотя бы для того, чтобы сократить часть из этих примерно 3 млрд. фунтов стерлингов, потраченных впустую.

Примеров такого расточительства из-за неудач в разработке множество, я выделю два.

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

Второй - это проект по сокращению штатов, описанный и проанализированный в работе Mansell (1993). Первоначальная спецификация проекта заключалась в переносе системы мэйнфрейма в сеть ПК без изменения функциональности. Для переноса был выбран метод SSADM. Это метод разработки инфологических систем, который должен использоваться при разработке новых информационных систем. Он включает в себя анализ требований пользователей, когда требование, уже заданное, заключалось в сокращении масштаба, переходе от мэйнфрейма к сети на базе ПК без изменения функциональности. Это противоречие между инфологическим подходом, что завышенные ожидания пользователей и требуемый даталогический подход, при котором у пользователей не должны были спрашивать их мнение, вызвали конфликт. Конфликт привел к затягиванию проекта, в результате чего его размеры и стоимость увеличились настолько, что Мэнселл (1993) назвал его провальным.

Являются ли эти примеры необычными? Обычно менеджеры выбирают методологии разработки информационных систем с учетом требований фирмы и подбирают подходящий метод? В отчете CFM Group (1994 г.) обобщены результаты исследования критериев принятия решений руководителями компаний в отношении аутсорсинга. Выводы, сделанные в отношении ИТ-функций, заключаются в том, что тремя главными преимуществами аутсорсинга ИТ являются: предсказуемость затрат, снижение затрат и гибкость ресурсов. При аутсорсинге функций, не связанных с ИТ, таких как юридические и бухгалтерские функции, эти три критерия оказались наименее важными. Это говорит о том, что решения в ИТ-секторе, в отличие от решений, принимаемых во многих других критически важных областях, преимущественно основываются на стоимости. При выборе подрядчика или консультанта для управления или разработки информационной системы организации решение, основанное в основном на стоимости и не уделяющее должного внимания методам разработки, скорее всего, приведет к созданию непригодной системы.

3.2. Теория

В этом разделе я рассматриваю две работы, посвященные выбору или классификации методологий разработки. Обе методики относятся к разработке компьютерных систем. Однако я считаю, что извлеченные из них уроки могут быть экстраполированы на разработку всей информационной системы, независимо от того, основана ли она на компьютерах, бумажной работе, взаимодействии с человеком или их сочетании, а также на других средствах передачи и хранения информации. Для того чтобы не превысить установленный объем статьи, я просто бегло проанализировал работы Коннора (Connor, 1985) и Олле (Olle, et. al.) (1991), чтобы выделить, на мой взгляд, их сильные и слабые стороны.