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

Будь то внедрение крупной системы уровня управления предприятием или новой почтовой системы, прокладка сети или установка сервера для общей базы данных — любой из этих проектов подчиняется обычным законам природы. Как и для человека в его реальной жизни, для каждого из них можно ввести такое интуитивно ясное понятие, как здоровье, а именно «способность максимально удовлетворять поставленным требованиям». Или же «функционировать в оптимальном интервале значений», или просто как «отсутствие болезненных изменений».
Марина Львовна Аншина — директор отдела интеграции программных систем компании TopS BI. Ей можно написать по адресу: MAnshina@topsbi.ru

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

Особо хочется сказать о самом начале — о планировании проекта. Как и при планировании семьи, уже на этой «допроектной» стадии важно задумываться о будущем. Именно здесь закладывается фундамент будущего здоровья организма. А момент рождения! Это и радостный, и очень ответственный момент, который требует максимальной собранности и целеустремленности всех участников. Конечно, и вслед за этим всем мамкам и нянькам надо быть очень осторожными, пока подобные проекты еще «в пеленках».

Но хватит поверхностных сравнений. Попробуем более глубоко использовать наши аналогии и серьезно рассмотреть понятие «здоровье проекта». Ведь правда то, что болезни проектов, как и болезни людей, надо лечить. А еще лучше — предупреждать, чтобы проекты росли здоровыми на радость папам и мамам. Риски проекта — это потенциальная угроза его здоровью. Их исследованием мы и займемся. А также вопросом, как предупреждать болезни проектов и как их лечить, если проект «заболеет».

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

У терапевта (определение рисков)

Врач-весельчак вспомнит крылатые фразы про шампанское и риск как благородное дело. Возможно, так ему удастся успокоить «больного» и показать ему, насколько распространена «рисковая» болезнь. И действительно, риск сопровождает любое необособленное от окружающего мира и протяженное во времени действие, которое направлено на получение результата. Каждое такое действие связано с неопределенностью и зависит от событий, которые могут произойти, а могут и нет. Любой проект имеет определенные цели и, как последовательность действий, обладает вероятностью достижения этих целей, вероятностью краха (разработаем — не разработаем, внедрим — не внедрим) и вероятностью частичной реализации поставленных целей.

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

Что же такое риск? Большинство специалистов достаточно единодушны в описании потенциальной болезни, условий, при которых болезнь можно «заработать», и ее симптомов.

Риском называется событие, наступление которого наносит ущерб какой-либо деятельности.

Два момента оговариваются особо:

1. Имеется в виду будущее событие.

2. Событие должно быть случайным (т. е. заранее неизвестно, произойдет оно или нет).

В применении к проектам это определение выглядит следующим образом.

Риск — это событие, которое препятствует выполнению проекта в соответствии с условиями договора, т. е. в установленный срок, в рамках определенного бюджета, с оговоренными результатами.

Часть диагностов придерживается несколько иной точки зрения.

Риск проекта — это обстоятельства, которые по оценке сторон могут оказать неблагоприятное воздействие на выгоду, которую предполагается получить в результате осуществления проекта.

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

Как вы видите, оба определения оперируют событиями. Но не секрет, что зачастую, особенно в обыденной речи, под риском понимают не само событие, а вероятность его наступления. Ведь говоря: «Риск велик», — мы имеем в виду не масштабы бедствия, а большую вероятность его наступления. В дальнейшем мы будем объединять в понятии риска набор характеристик, связанных с отрицательными последствиями для хода проекта. Надеемся, что вам будет понятно, что именно мы имеем в виду.

По сравнению с приведенными определениями в этой статье мы включим в рассмотрение участников проекта и посмотрим на ситуацию их глазами. У каждого проекта есть два неравноценных «родителя» — исполнитель и заказчик. Если первый обычно выполняет роль заботливой мамы, то второй — требовательного папы. При этом самый «здоровый» проект рождается, если и мама и папа этот проект хотят, ждут и к нему готовятся. Все другие варианты, которые случаются как в жизни, так и — увы — с проектами, чаще всего приводят к печальным последствиям.

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

Основные риски, с которыми сталкиваются исполнители, приведены, в свою очередь, в таблице 2.

Про каждый из рисков, приведенных в этих таблицах, можно написать страницы в историях болезни проектов автоматизации. Множество проектов по их вине закончились «летальным исходом» или остались «калеками» на всю жизнь.

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

Терапевт может высказать еще несколько умозаключений. Невозможно представить ситуацию, когда нет рисков. Любое действие, направленное на достижение некоторой цели, всегда имеет определенную вероятность этой цели не достигнуть. Можно заметить также, что количество рисков — это число ситуаций, наступление которых препятствует достижению цели. По второму определению это число субъективно. В реальной ситуации в рассматриваемые риски не включают события «малой» вероятности и небольшого ущерба (насморки — за пределами нашего изучения!). Понятие «малой вероятности» зависит от конкретного проекта. Тут мы вплотную подошли к измерениям рисков.

Лаборатория (количественный анализ)

Речь пойдет не о разделе математики, а о математическом аспекте понятия «риск». В прикладной математике понятие риска сильнее всего связано со страховой деятельностью. Именно на этой почве возникла и развивается математическая теория рисков. Многие результаты, впрочем, можно применить и к исследуемому нами случаю. Основной предмет этой теории — сравнение привлекательности (или непривлекательности) различных рисков, связанных с тем или иным событием. При этом сложную ситуацию для анализа можно заменить простой, но более рискованной, например, в случае необходимости оценки консервативного, т. е. менее рискованного и более осторожного решения. Способ замены сложных ситуаций или ситуаций с невозможностью определения полного набора параметров более простыми и вычисляемыми ситуациями весьма популярен при оценке рисков. Повторим, что эта замена для гарантии достоверности оценки не должна понижать значение риска, чтобы принятое решение основывалось на более рискованной ситуации.

С точки зрения математики риск — это некоторая неотрицательная случайная величина с конечным математическим ожиданием, которая характеризует наступление рискового события. Например, можно построить распределение вероятностей для величины падения (или роста — в зависимости от того, что является риском в конкретном случае) курса целевой валюты через три месяца. Для рисков, не имеющих естественного числового значения, «оцифровка» может производиться выбором значения из заранее заданной шкалы (например, отсутствие ущерба для репутации фирмы — 5, малый ущерб — 4, серьезный ущерб — 3, ущерб, ведущий к потере имиджа надежной фирмы, — 2, ущерб, ведущий к уходу с рынка, — 1).

Риск имеет еще одну важную характеристику, которая в математической теории называется функцией полезности (скорее, вреда) и определяет величину ущерба, связанную с тем или иным риском (или величину дохода, связанную с отсутствием риска). Эта функция, как следует из предыдущего определения, представляет собой функцию случайной величины и определяет значение ущерба, которого удалось избежать в результате осуществления определенной суммы действий по предотвращению этого риска. Риск Х считается предпочтительнее риска У, если значение функции полезности u(X)кривая 2 на рис. 1).

Мерой опасности рисков служат такие понятия, как математическое ожидание, дисперсия или среднее отклонение. В финансовой математике существует специальная модель — Capital Asset Pricing Model, основанная на анализе средних и дисперсий. Кратко результаты этой модели сводятся к тому, что риск с меньшим средним всегда предпочтительнее, а если средние одинаковы, то предпочтительнее тот, который имеет меньшую дисперсию (рис. 2).

Что надо мерить (температура и давление)

Итак, для измерения рисков имеют значение две величины, первая из которых связана с возникновением рисков, а вторая — с предполагаемым ущербом. В связи с неопределенностью возникновения того или иного события, в качестве первого и основного параметра выступает вероятность возникновения риска. Измерение вероятности возникновения риска основано прежде всего на экспертных оценках. Второй параметр измеряет ущерб, который будет нанесен сторонам при наступлении риска, и также может быть оценен экспертным путем, прежде всего на основе аналогий. Обычно для этого используют величину Value at Risk — ожидаемый максимальный убыток в течение установленного периода времени и с установленным уровнем вероятности. Иногда эти две величины объединяют в единый показатель — значительность риска, для которого приняты качественные градации: высокая, существенная, умеренная, незначительная и низкая.

Методы оценки рисков

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

  1. Метод сценариев. Обычно разрабатываются несколько сценариев развития проекта. Чаще всего ограничиваются оптимистичным, пессимистичным и реалистичным сценариями.
  2. Деревья решений. Этот метод применим при условии наличия конечного числа вариантов развития проекта. Он особенно полезен в ситуациях, когда решения, принимаемые в каждый момент времени, сильно зависят от решений, принятых ранее, и, в свою очередь, определяют дальнейшее развитие событий.
  3. Метод Монте-Карло. Это метод основан на имитационном моделировании и получении последовательностей случайных чисел — значений рисков. С их помощью (существуют различные варианты применения метода, например, задается случайный процент изменений первоначальных требований к результатам проекта) выполняется большое количество испытаний — разовых актов моделирования развития ситуации на проекте с расчетом возможных финансовых потерь. В результате проведения данных испытаний будет получено распределение возможных потерь, на основе которого путем отсечения наихудших ситуаций, согласно выбранной доверительной вероятности, может быть получена оценка функции полезности. Метод Монте-Карло представляет собой последнюю надежду врача в условиях полной неизвестности о состоянии здоровья больного и невозможности проведения обследования.
  4. Метод достоверных эквивалентов. Название метода говорит само за себя. Наиболее распространенный вариант — экспертная корректировка ситуации в зависимости от субъективной оценки вероятностей. Однако интерпретация коэффициентов достоверности как вероятностей, свойственная данному подходу, не всегда соответствует экономической сущности оценки риска. Очевидно, что применение коэффициентов достоверности в такой трактовке делает принятие решений произвольным и при формальном подходе может привести к серьезным ошибкам в управлении. Единственное теоретически верное применение метод достоверных эквивалентов находит в методе предпочтительного состояния, который является обобщением метода вероятных потерь для состояния неопределенности. Метод предпочтительного состояния заключается в явном учете всех альтернативных вариантов событий (фактически — в построении «дерева решений»), для каждого из них используется свой коэффициент достоверности.
  5. Анализ чувствительности. Метод заключается в анализе каждого фактора, влияющего на проект по отдельности.

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

Распределение рисков

После оценки рисков проекта надо определить, кто отвечает за тот или иной риск, на ком будут лежать последствия его возникновения. Такое разделение обычно основывается на простом житейском соображении, что ответственности без прав не бывает. Поэтому за риски платит тот, кто имеет возможности ими управлять: избежать их или снизить наносимый ими ущерб. Самая простая, но «правильная» схема распределения рисков основана на договорных механизмах. Желательно только договориться об этом на ранней стадии ведения проекта и при этом учитывать то, что конкретные риски должны возлагаться на ту сторону, которая в большей степени может оценить риск, контролировать и регулировать его.

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

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

Справочник участкового врача (классификация рисков)

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

По эпидемичности

  1. Общие риски или ОРЗ (общие распространенные заболевания). Риски, относящиеся к автоматизации в целом или к группе проектов по отраслям либо по типам. Это распространенные угрозы здоровью типа ОРЗ или гриппа.
  2. Специфические риски, связанные с отдельным проектом, с его уникальными особенностями. Это не редкость в рассматриваемой области деятельности, где многие проекты (если не их большинство) являются инновационными.

По возможности излечения

  1. Внешние риски или несчастные случаи. Риски-катастрофы, связанные с воздействием внешней среды и вызванные событиями, которые находятся вне сферы контроля сторон. Наиболее свежее и болезненное напоминание — призрак 11 сентября. На такие риски нельзя влиять, от них можно только попытаться защититься; их следует учитывать, отслеживать и определить в договоре, на кого ляжет ущерб при наступлении рискового события.
  2. Внутренние риски проекта, с которыми можно и нужно бороться.

По функциям «организма»

  1. Финансовые риски, связанные с управлением компанией (на эти риски можно влиять).
  2. Политические риски.
  3. Форс-мажор.
  4. Технологические риски.
  5. Риски ведения проекта.
  6. Функциональные риски — риски неадекватных требований.
  7. Профессиональные риски. Недостаточная квалификация проектной команды как со стороны исполнителя, так и со стороны заказчика. Принято относить этот тип риска только на исполнителя, что неверно.
  8. Коммерческие риски. Связаны с тем, что проект не сможет обеспечить получение ожидаемых доходов вследствие изменения состояния рынка.
  9. Внешние финансовые риски (например, связанные с изменением обменного курса, на которые влиять невозможно).

Еще одна классификация основана на использовании двух треугольников, показывающих взаимосвязи и взаимозависимости основных параметров любого проекта:

  • треугольник: «сроки — качество — стоимость»;
  • ресурсный треугольник: «технологии — исполнители — инфраструктура».

Риски можно определить по влиянию, оказываемому ими на одну из вершин каждого из треугольников. (Понятно, что эти треугольники существуют в разных плоскостях и поэтому никак не могут пересекаться. — Прим. автора.)

Как использовать эти классификации? Прежде всего, они позволяют очертить возможности управления рисками. Затем — комплексно бороться с рисками, объединенными в группы. И наконец, очень важно определить весь спектр рисков проекта, для того чтобы убедиться, что ничего не упущено. Вместе с тем не стоит — подобно известному герою Дж. К. Джерома — подозревать у себя все известные болезни, приписывая проекту все возможные риски.

Почему надо заниматься своим здоровьем, или Актуальность анализа рисков

Возможно, что вы не любите ходить по врачам. Возможно также, что, приступая к проекту, вам хочется сохранять оптимистическое настроение и нет желания думать о том, что будет, если «кирпич свалится на голову». К сожалению, подобная беспечность обходится слишком дорого. Вот некоторые цифры, собранные Standish Group по поводу проектов автоматизации (Standish Group Report, 2001 г.):

  • только 16% проектов заканчиваются в срок;
  • 31% проектов закрываются, не завершившись;
  • 53% проектов выросли по цене более чем на 89%;
  • во всех завершенных проектах только 61% требуемых свойств были реализованы.

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

  1. Бизнес компаний находится в прямой зависимости от работоспособности средств автоматизации.
  2. Сроки подобных проектов очень важны. Понятие just-in-time software становится все более популярным.
  3. Возрастают требования к качеству программных средств.
  4. Одновременно возрастают требования к предоставляемому уровню безопасности. Растет число вирусов, взломов сетей и серверов. Компании теряют миллионы долларов.
  5. У компаний-заказчиков появился выбор. Теперь компьютерный рынок настолько богат, что и «авантюрист», и осторожный клиент найдут тут товар по себе. Всегда можно выбрать проект с прекрасными возможностями, но с громадными рисками. Следует только помнить про принцип бесплатного сыра (вероятность попадания в мышеловку — 100%).
  6. В подобные проекты вовлекается обычно очень много людей. Созданная программная система не должна отражать взгляд одного человека. В противном случае риск проекта многократно увеличивается.

Посещение психотерапевта, или

Парадоксы управления рисками

Здесь мы собрали некоторые правила (по сравнению с предыдущими математизированными формулировками их можно назвать «правилами здравого смысла») или соображения, которые следует иметь в виду, но признание и принятие которых требует определенного мужества. Ведь признав какое-либо из этих правил, вы тем самым принимаете на себя ответственность за те случаи, когда будете его нарушать. Впрочем, борьба с рисками предполагает наличие таких качеств, как смелость и хладнокровие.

  • Чем точнее определен риск, тем он менее реален.
  • Точное определение риска связано с большими затратами времени квалифицированных специалистов, что, в свою очередь, приводит к повышению некоторых рисков.
  • Снижение одного риска может привести к росту нескольких других, поэтому управление рисками является комплексной задачей.
  • Количество рисков, их характеристики и методы борьбы с ними зависят от этапа проекта. Риски максимальны в начале проекта и сходят на нет к его завершению (естественно, при грамотном управлении рисками).

Роль хирурга, или

Собственно управление рисками и его планирование

Не надо пугаться. Далеко не всегда управление рисками связано с хирургическим вмешательством в проект. Но «скальпель» желательно иметь под рукой.

Управлением рисками принято называть непрерывный процесс, сопровождающий любой проект от первых контактов заказчика и исполнителя до окончания жизненного цикла системы в целом (или программного продукта в частности) и направленный на отслеживание, минимизацию и компенсацию рисков.

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

Как мы уже говорили, риски заказчика и исполнителя неодинаковы, поэтому методы управления рисками тоже могут отличаться. В западных банках давно есть отдельная должность — менеджер по управлению рисками. Правда, в России подобные менеджеры («риск-менеджеры») появились, да и то не везде, только после кризиса 1998 года. Случаи назначения отдельного менеджера по управлению рисками для проектов автоматизации хотя бы со стороны исполнителя нам неизвестны. Обычно эту функцию возлагают на руководителя проекта. Чаще всего дело ограничивается отдельным пунктом договора, связанным только с одной группой рисков (мы имеем в виду форс-мажор). Что же говорить о том, что совершенно непонятно, кто у заказчика занимается отслеживанием и управлением рисками.

(Хорошо, если таким человеком является ДИС — директор информационной службы, который для управления рисками облечен соответствующей властью и который, естественно, участвует в подписании договора, как минимум, в роли визирующего лица, а в «грамотных» случаях сам, пусть и по доверенности, подписывает договор как полноправный представитель предприятия-заказчика. И такие случаи нам известны! — Прим. ред.)

Основным методом управления рисками должен стать комплексный подход. В этом случае постановка вопроса не сильно отличается от обычного производства, например, выпуска деталей. Создается комплекс планов, и для каждого плана назначается свой ответственный. На Западе сейчас в планировании рисков особенно популярна модель «иерархической голографии» — HHM-модель. С ее помощью оценивается влияние рисков на бизнес с разных точек зрения, для чего применяются следующие методы:

  1. Временной метод. Отслеживает риски по этапам жизненного цикла проекта.
  2. Метод управления. Связан со взаимоотношениями внутри команды разработчиков.
  3. Метод окружающей среды. Связан с оборудованием и стандартным (готовым) программным обеспечением — операционной системой (ми), базами данных и т. д.
  4. Метод качества. Занимается триадой «время-сроки-качество».
  5. Технологический метод. Бывает опасно использовать не только новые, «непроверенные», «сырые» технологии, но и старые, так называемые «наследуемые».

(Некоторые методы представлены в [5].)

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

  • решение о том, какой риск в компании считается допустимым (по значительности — совокупности параметров «вероятность» и «ущерб»);
  • решение о том, применять ли страхование рисков;
  • список учитываемых рисков по группам, который должен постоянно пересматриваться;
  • описание сценариев рисков и признаков рисков (признаки рисков — параметры/ситуации, указывающие на то, что вероятность наступления определенного риска изменилась);
  • стандартные процедуры по управлению рисками;
  • процедуры внутреннего контроля по управлению рисками;
  • разграничение ответственности:
  • кто оценивает риск,
  • кто готовит отчетность,
  • кто устанавливает граничные (пороговые) значения,
  • кто их контролирует.

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

Наиболее «популярные» риски проектов автоматизации

Может быть, в какой-то мере это повторение пройденного, но нам хотелось бы в конце статьи еще раз описать наиболее страшные болезни проектов автоматизации.

Объективные

Динамика бизнеса. Техническое задание определяет состояние бизнеса на момент его написания. По мере реализации проекта цели проекта естественным образом меняются. Поэтому изменения в проекте неизбежны.

Богатство технологий и методов. Любую задачу можно решить различными способами. Выбор зачастую осуществляется интуитивно и субъективно.

Субъективные

Невнимание со стороны руководства заказчика. Нет целей проекта.

Недооценка проекта (цена, сроки, TCO — совокупная стоимость владения) со стороны исполнителя и заказчика. Дешевый сыр!

Неприятие. Проект затрагивает различные подразделения заказчика.

Недооценка сложности проекта со стороны исполнителя. Недостаточно ресурсов или попытка сделать за короткий срок. Страдает качество проекта. Любой проект — компромисс между качеством, сроками и ценой (с точки зрения управления рисками, да и с точки зрения управления проектами в целом).

О физкультуре и здоровом образе жизни, или

Советы по уменьшению рисков

Подводя итоги, приведем некоторые практические меры, направленные на защиту от последствий рисков.

  • Страхование. Хотя это и новинка, на компьютерном рынке России уже появляются первые подобные примеры.
  • Резервирование. Сознательное завышение сроков или бюджета проекта с учетом возможных рисков.
  • Хеджирование и диверсификация. Компенсация одного проекта другим для снижения суммарного риска.
  • Избежание. Отказ от рискованных проектов.
  • Минимизация рисков. Консервативное управление пассивами и активами (то есть технологиями и задачами, принцип «тише едешь — дальше будешь!»).
  • Комплексный подход. Необходимо учитывать тенденции в собственном бизнесе и выбранной области автоматизации, стратегию развития компании, установленные системы, привычки и культуру пользователей.
  • Особые условия в договорах, относящиеся к разграничению рисков.
  • Заинтересованность. Привлечение к проекту всех тех, кто будет пользователями системы. Это позволит снизить негативное отношение к проекту и повысить его внедряемость.
  • Дробление. Деление проекта на как можно меньшие этапы или, как рекомендуется в последнее время, на небольшие проекты, составляющие проектную программу. Запускать (внедрять) систему можно тоже поэтапно — от прототипа до полноценной системы и от ядра с минимумом функций до функционально богатой версии, то есть «очередями». И заказчик, и исполнитель заинтересованы в том, чтобы оплата производилась за каждый этап. Ведь сначала даже не всегда можно сформулировать полную функциональность будущей системы.
  • Выделенность. В проекте должно быть два подразделения: одно отвечает за качество проекта, другое — за сроки и стоимость работ.
  • Техническая грамотность. Необходимо использовать и проверять новые технические решения, например, компонентные системы являются балансом между готовыми (меньше все риски, кроме функциональных; вспомните, сколько коробок пылится в каждом отделе ИТ) и разрабатываемыми (большие риски и обычно большая цена) системами для уменьшения рисков.

О витаминах и пользе врачей

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

Посмотрите сводки внедрения крупных информационных систем. Во всех них обязательно говорится о внедряемости. Не секрет, что эта самая внедряемость колеблется вокруг тридцати процентов. То есть завершаются внедрением меньше половины подобных проектов. Анализ рисков помогает понять и увидеть те ключевые «тонкие» моменты проектов, которые могут привести к подобным печальным результатам, и начать с ними бороться.

Приступите к описыванию рисков ваших проектов и планированию управления ими. Пусть эти разделы в документе «Концепция системы» и в ТЗ на ее разработку составят для начала хотя бы по пять страниц. Это уже будет огромным шагом вперед. Включите в договор часть про разделение ответственности. И если это вам удастся, вы сможете смело сказать, что ваши проекты на пути к здоровому образу жизни!

Литература по теме статьи

  1. Булинская Е. В. Теория риска и перестрахование. Часть 1. Упорядочивание рисков. МГУ, Москва, 2001 г. Книга посвящена математической теории рисков в области страхования. Даются определения рисков и функции полезности, и приводится математический аппарат для сравнения рисков.
  2. Корнилов И. Управление рисками страховых компаний.//«Рынок ценных бумаг», №22, 1999. В статье вводятся понятия эквивалентности рисков в области страхования.
  3. Лобанов А. Риск и неопределенность в экономике. //«Рынок ценных бумаг», №18, 1999. В статье описаны финансовые риски и задачи риск-менеджмента.
  4. Ричард Шис. Пора еще раз задуматься о вашей системе управления рисками. Материалы компании Pricewaterhouse Coopers. В статье рассмотрена методология управления рисками в банках, а также приведена классификация этих рисков.
  5. T. A. Longstaff, C. Chittister, R. Pethia, Y. Haimes. «Are we forgetting the risks of Information Technology?» Computer, декабрь 2000. Большая статья, посвященная рискам в области ИТ: классификация, методы анализа, принципы управления рисками.