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

Измерение уровня адаптивности ИС

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

Как уже было сказано, Р. Дав предложил для измерения операционных проявлений адаптивности использовать четыре количественных показателя[131]:

Время, требуемое для реакции на изменения;

Стоимость изменений;

Качество, понимаемое как устойчивость процесса изменений;

Объем изменений.

Частично этот подход реализован в банке Credit Suise Switzerland[132], где используется следующая метрика адаптивности ИС:

Здесь – осредненное время выполнения проектов по созданию новых систем, Ti – время выполнения i-го проекта (дни), si - размер i-го проекта, выражаемый в UCP (use case points);  – осредненная стоимость проекта, Ci – затраты на выполнение i-го проекта. UCP это специальная мера функциональной сложности проекта, построенная на основе use case моделей языка UML[133]. Она предполагает выявление акторов и сценариев использования и оценку сложности на основе их весовых коэффициентов. Данная мера хорошо подходит для стандартных информационных бизнес-систем, где много пользовательского интерфейса и мало сложных алгоритмов. Альтернативами являются методика функциональных точек (functional point) и ее модификации. Таким образом, показатель, вычисляемый по приведенной формуле, представляет квадрат количества реализованной функциональности в UCP, отнесенный к произведению истраченных времени и затрат, что является комбинацией метрик времени, стоимости и объема, предложенных Р. Давом. В Credit Suise Switzerland показатель адаптивности, вычисляемый по этой формуле, в результате направленных действий вырос за 17 кварталов от 0,15 (июнь 2005) до 0,25 (сентябрь 2009). Интересно, что для проектов на базе собственной технологической платформы среднее значение показателя адаптивности за это время составило 0,24; для прочих проектов – 0,09.

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

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

На основании результатов Дж. Хоббса и Р. Шиперса[134] можно предложить модель поддержания адаптивности ИС (рис. 6.11), которая предполагает формирование действий на основе непрерывного анализа текущих и предсказания потенциальных будущих потребностей. Отметим, что под внешней средой при этом понимаются все возможные системы, находящие вне периметра ИТ-департамента (другие подразделения организации, ее партнеры и конкуренты, разработчики и поставщики технологий, регулирующие органы и т.д.).

При этом деятельность ИТ-департамента по обеспечению адаптивности ИС на этапе ее эволюционного развития включает два процесса – разработка новой функциональности и поддержка системы. Оценить эффективность этих процессов можно с помощью энтропийной метрики, которая была предложена в пятой главе. Будем считать, что обнаружение потребности в изменении системы включает не только формирование заявки на изменение, но и согласование сроков ее выполнения. В случае запроса на поддержку эти сроки обычно регламентируются SLA, в случае разработки новой функциональности – устанавливаются путем переговоров в зависимости от объема изменения, его важности, доступного бюджета и т.д. (см. модели процессов инкрементального и революционного процессов изменения, рассмотренные выше). И в том и в другом случае назначенный срок является результатом соглашения между ИТ - департаментом и пользователями. Таким образом, в качестве характерного параметра процессов разработки и поддержки целесообразно определить отклонение фактического срока исполнения заявки от согласованного. Это дает возможность оценивать эффективность внесения изменений в ИС в целом.