Искусство бега по граблям. Стратегическое управление ИТ в условиях неопределенности - страница 34

Аналогичные рассуждения можно повторить и для разработки технологий изготовления продукта, во время которой вектор параметров проектирования [DP] отображается на вектор параметров процессного домена [PV], но при обсуждении ИС это отображение обычно не рассматривается.

Вторая аксиома (информационная) требует минимизировать объем информации в процессе проектирования или, не вдаваясь в детали, увеличить вероятность удовлетворения функциональных требований. Информация в данном случае определяется как Ii=-log2 pi , где pi – вероятность удовлетворения функционального требования FRi. Когда необходимо удовлетворить n требований, лучшим проектом будет тот, который соответствует минимальному объему информации

Рассмотрение принципов проектирования адаптивных систем необходимо начать с обсуждения возможности распространить методы гибкой разработки ПО (XP, Scrum, RUP и др.) на создание и развитие корпоративной ИС системы в целом, поскольку эти методы достигли уже значительной степени зрелости. Однако при этом возникает ряд ограничений, связанных с масштабом проектов. Фактически, команды разработчиков, следующие гибким методам, используют свою способность чрезвычайно быстро создавать программный код для выяснения и уточнения требований пользователей. Отсюда вытекают особенности организации процесса разработки – небольшие команды, сосредоточенные в одном месте, интеграция заказчика в такую команду, отказ от утвержденных спецификаций до начала разработки и т.д. Все это позволяет разрабатывать относительно небольшие слабо интегрированные в корпоративную ИС приложения. Задача распространения гибких методов на корпоративную ИС исследована Д. Леффингвеллом[114], где отмечается, что в таком случае возникают вопросы координации отдельных распределенных команд, согласования релизов, предварительной разработки общей архитектуры системы и т.п. Решение всех этих вопросов в рамках исключительно модели гибкой разработки невозможно, появляется потребность в создании единого координирующего и планирующего органа. Вторым обязательным условием реализации гибких методов на корпоративном уровне является соблюдение требований первой аксиомы аксиоматического дизайна, только это позволит обеспечить относительную автономность команд разработчиков, отвечающих за реализацию различных функциональных требований. В противном случае решения групп будут влиять друг на друга, что радикально усложнит их взаимодействие.

Другой способ поддержания адаптивности ИС обеспечивается технологией – это концепция платформы, на базе которой создается семейство продуктов, причем и платформа, и продукты должны управляемо эволюционировать[115]. Процессы разработки и поддержки платформы и приложений на ее базе должны быть разделены. Под платформой здесь понимается не программная среда типа Java или .Net, а некий набор слабо связанных бизнес-объектов и средств интеграции и автоматизации бизнес-процессов, которые могут быть достаточно просто переконфигурированы в зависимости от текущих задач предприятия. Существующие индустриальные тренды (SOA, BPM, model business management – MBM, бизнес-правила, отделение реализации от интерфейса и т.д.)[116], кажется, позволяют создавать системы, которые могли бы в дальнейшем легко реконфигурироваться.

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

Отметим также, что платформенный подход к созданию семейства продуктов получил широкое распространение не только в ИТ, но и, например, в машиностроении.

Третий способ обеспечения адаптивности, более социотехнический, это концентрация не на функциях ИС и даже не на поддержке бизнес-процессов, а на предоставлении сервисов. Сервис можно трактовать как бизнес-процесс с подписанным соглашением об уровне сервиса (SLA), где указаны поставщик и потребитель, ключевые параметры оказания услуги, включая стоимость, время восстановления и т.д. Разница в подходах, ориентирующихся на процесс и на сервис, исследована М. Урамом и Б. Стефенсоном[117] (см. таблицу 6.2).