Совокупная стоимость владения системой и риски

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

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

В любой момент проекта

дисконтированные интегральные затраты на систему могут быть оценены как

(1)

где

— оценка дисконтированных интегральных затрат проекта в момент

;

E— норма дисконтирования4;

— дисконтированная сумма фактических интегральных затрат проекта к моменту

;

T— период жизненного цикла системы;

— оценка интегральных затрат на проект в периоде t;

В свою очередь, оценку интегральных затрат на проект в периоде t можно представить как

(2)

где

— плановые затраты на проект в периоде t;

— оценка потерь, связанных с бизнес-рисками в периоде t.

Далее, плановые затраты на проект определяются следующим образом:

(3)

где

— затраты на приобретение готового программного обеспечения и технических средств в периоде t;

— затраты на проектирование системы в периоде t;

— затраты на строительно-монтажные работы в периоде t;

— затраты на внедрение системы в периоде t;

— эксплуатационные затраты в периоде t;

— затраты на сопровождение в периоде t;

Отметим, что в предложенном методе оценки затрат использована величина

— оценка потерь, связанных с бизнес-рисками в периоде t.

Конечно, мы будем использовать характеристики и чисто технических, ИТ-рисков. Для того, чтобы знать и правильно организовать описание всего набора возможных рисков, полезно опираться на некую общую модель архитектуры - как предприятия, так и его ИС. В качестве таких моделей могут применяться модели Захмана [3] или Зиндера [4].

По всей видимости, с каждой из ячеек этих моделей связаны свои специфические риски. А связи этих ячеек, предусмотренные неявно в [3] или явно в [4], позволяют, например, хорошо определять связи между техническими, операционными и бизнес-рисками, которые будут разбираться далее. Кроме того, наличие временной оси в модели [4] позволяет работать не со статической "фотографией" проекта или жизни системы, но учитывать их существование во времени (имеется ввиду то самое время, которое "работает" в формульных оценках затрат). Кроме того, наличие этой оси времени позволяет вычленять бизнес-риски типа "неопределенность" (см. ниже) при рассмотрении проекта в бизнес-времени и проектным рискам при рассмотрении проекта в проектном времени.

Вопросы соответствия различных типов рисков ячейкам архтектурной модели [4] и их связям требуют дополнительной теоретической проработки. Однако и без нее знакомым с вышеуказанными моделями нетрудно будет соотнести определенные ячейки архитектуры (architecturalframework) с различными рисками и таким образом составить, назвать и описать актуальные для проекта/системы группы рисков. Мы же - в рамках данной статьи - выделим несколько наиболее значимых и принципиально различных типов рисков:

• проектные риски при создании системы;
• риски бизнес-потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из-за технических рисков). Такие риски бизнес-потерь назовем бизнес-рисками. Каждый бизнес-риск принадлежит по крайней мере одному из вариантов бизнес-использования системы. Например, для интернет-магазина бизнес-риски “Покупатель не может сделать заказ и уходит” и “Покупатель делает заказ, но уходит рассерженный функционированием системы” принадлежат вариантов бизнес-использования “Сделать заказ”.
• риски бизнес-потерь, связанные с вариативностью бизнес-процессов. При этом потери происходят оттого, что а) бизнес-процессы надо изменять, а информационная система не готова к этому и потери связаны с неоптимальным функционированием бизнеса и б) оттого, что имеется стоимость модификации системы. Такие риски бизнес–потерь назовем неопределенностями (RUP упоминает аналогичные по смыслу "варианты изменения" (change cases)).
• технические риски, состоящие в простоях, отказах, потере или искажении данных и т.п.;

Затраты на создание и эксплуатацию системы с некоторой точностью оцениваются достаточно прямолинейно. Динамические бизнес-риски количественно учесть невозможно и их следует оценивать исключительно качественно (на уровне понимания, насколько бизнес-процессы в организации являются определенными / застывшими / неустоявшимися). Наиболее интересной частью совокупной стоимости владения системой являются статические бизнес-риски и проектные риски.

Каждый вариант бизнес-использования реализуется с помощью набора операций соответствующих бизнес-процессов. Соответственно, бизнес-риск возникает по причине неисполнения одной или нескольких операций бизнес-процесса — это мы называем операционными рисками. Таким образом, операционные риски являются источниками бизнес-рисков.