Книга будет полезна и ит-менеджерам фирм производителей программного обеспечения, и ит-менеджерам коммерческих банков (потребителей), руководителям коммерческих банков,

Вид материалаКнига

Содержание


Анализ рисков при реализации проектов
Типы рисков в информационном проекте
Проектные риски
Технические риски
Идентификация рисков
Таблица 16Оформление таблицы рисков проекта
Таблица 17Расчет уровня рисков и их влияния
Снижение потерь
Управление критической ситуацией
Таблица 18Оформление плана противодействия рискам
Снижение затрат в проектах
Подобный материал:
1   ...   18   19   20   21   22   23   24   25   ...   33

Анализ рисков при реализации проектов



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

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

Мы уже упоминали, что доля неудачных проектов крайне высока. Почему это происходит и кто виноват в подобных ошибках? Наказать и уволить разработчиков и отдельных исполнителей - самое простое решение, однако это не выход, так как потом выясняется, что ошибки продолжают появляться и проект заходит в тупик.

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

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

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

Типы рисков в информационном проекте



Первый этап рассматриваемых работ - определение ответственных за различные типы рисков. В зависимости от ответственности за риски их условно можно разделить на три группы.

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

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

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

2. Технические риски связаны с проблемами реализации технических решений. Основными проблемами здесь обычно являются проблемы разработки (способность разработчиков реализовать ту или иную задачу), неудовлетворительная производительность системы, внедрение и затруднения, связанные с окончательной адаптацией системы под конечных пользователей.

Ответственное лицо за решение подобных проблем - обычно технический руководитель проекта или ведущий аналитик.

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

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

Идентификация рисков



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

В качестве спецификации возможна разработка менеджером проекта таблицы рисков (табл. 16).


Таблица 16


Оформление таблицы рисков проекта


┌───────────────────────┬──────┬─────────┬─────────┬──────────┬─────────┐

│ Наименование риска │ Тип │ Вероят- │Приоритет│ Сумма │Временные│

│ │ │ность, в │ │ущерба, в │потери, в│

│ │ │ % │ │ руб. │ днях │

├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤

│Увеличение количества│ PS │ 60 │ 3 │ 2 000│ 2 │

│пользователей │ │ │ │ │ │

├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤

│Изменение выходных│ RE │ 60 │ 2 │ 14 000│ 4 │

│отчетных форм │ │ │ │ │ │

├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤

│Неподготовленный │ PR │ 30 │ 4 │ 2 000│ без │

│конечный пользователь │ │ │ │ │ затрат │

├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤

│Противодействие │ PR │ 10 │ 2 │ 15 000│ 10 │

│конечных пользователей│ │ │ │ │ │

│внедрению системы │ │ │ │ │ │

└───────────────────────┴──────┴─────────┴─────────┴──────────┴─────────┘


┌───────────────────────────────┐ ┌─────────────────────────────────────┐

│ Расшифровка типов │ │ Приоритеты │

├────┬──────────────────────────┤ ├───┬──────────┬──────────────────────┤

│ PS │изменения размера системы │ │ 1 │Катастрофа│> 100 000 руб. > 20│

├────┼──────────────────────────┤ │ │ │дней │

│ RE │изменения постановки задач│ ├───┼──────────┼──────────────────────┤

├────┼──────────────────────────┤ │ 2 │Критично │> 10 000 руб. > 3 дней│

│ PR │проблемы с персоналом │ ├───┼──────────┼──────────────────────┤

└────┴──────────────────────────┘ │ 3 │Проблема │> 1000 руб. > 1 дня │

├───┼──────────┼──────────────────────┤

│ 4 │Возможно │< 1000 руб. < 1 дня │

│ │игнориро- │ │

│ │вание │ │

└───┴──────────┴──────────────────────┘


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




"Формула 1"




"Формула 2"


Таблица 17


Расчет уровня рисков и их влияния


┌───────────────────────────────────────────────────────────────────────┐

│ Итоговая таблица по приоритетам │

├─────────┬─────────────────────┬────────────────────┬──────────────────┤

│Приоритет│ Вероятность, │ Средний денежный │Потери времени, в │

│ │ % │ ущерб, руб. │ днях │

├─────────┼─────────────────────┼────────────────────┼──────────────────┤

│ 1 │ 0 │ 0│ 0 │

├─────────┼─────────────────────┼────────────────────┼──────────────────┤

│ 2 │ 64 │ 9900│ 3,4 │

├─────────┼─────────────────────┼────────────────────┼──────────────────┤

│ 3 │ 60 │ 1200│ 1 │

├─────────┼─────────────────────┼────────────────────┼──────────────────┤

│ 4 │ 30 │ 600│ 0 │

├─────────┴─────────────────────┴────────────────────┴──────────────────┤

│ Итоговая таблица по категориям │

├─────────┬─────────────────────┬────────────────────┬──────────────────┤

│ PR │ 37 │ 2100│ 1 │

├─────────┼─────────────────────┼────────────────────┼──────────────────┤

│ RE │ 60 │ 8400│ 2,4 │

├─────────┼─────────────────────┼────────────────────┼──────────────────┤

│ PS │ 60 │ 1200│ 1,2 │

├─────────┴─────────────────────┴────────────────────┴──────────────────┤

│ Общий итог │

├─────────┬─────────────────────┬────────────────────┬──────────────────┤

│ │ │ 11 700│ 4,6 │

└─────────┴─────────────────────┴────────────────────┴──────────────────┘


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

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

Снижение потерь



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

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

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

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

Основой работ по сокращению затрат является разработка плана противодействия рискам проекта. Примером оформления данного плана может служить дальнейшее развитие таблицы рисков (табл. 18).


Таблица 18


Оформление плана противодействия рискам


┌─────┬────────┬────────────────┬───────────────┬──────────────┬────────────────┬──────────────────┐

│ N │Вероят- │ Ущерб │ Подробное │ Профилактика │ Механизм │ Что делать │

│ │ ность │ │ описание │ │ мониторинга │ │

├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤

│ 1 │ 40% │2-кратное увел.│Потеря интереса│Максимальная │Постоянное │Попросить │

│ │ │сроков. │у пользователей│популяризация │обсуждение с│руководство │

│ │ │Профилактика = 1│к развитию│проекта, │группой │заказчика отметить│

│ │ │чел/д; │системы из-за│построение │внедрения │подразделения, │

│ │ │эффект Р = 20%; │угрозы │связи между│отношения │обеспечивающие │

│ │ │преодоление =│сокращения │эффектом от│пользователей к│наибольшую │

│ │ │6000 руб./отдел;│ │проекта и│проекту │поддержку проекта.│

│ │ │эффект = Р/2 │ │ростом доходов│ │Рассмотреть │

│ │ │ │ │ │ │исключение │

│ │ │ │ │ │ │сопротивляющихся │

│ │ │ │ │ │ │подразделении из│

│ │ │ │ │ │ │участия в проекте │

├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤

│ 2 │ │ │ │ │ │ │

├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤

│ 3 │ │ │ │ │ │ │

├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤

│ 4 │ │ │ │ │ │ │

└─────┴────────┴────────────────┴───────────────┴──────────────┴────────────────┴──────────────────┘


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

Снижение затрат в проектах



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

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

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

* персонал;

* помещение;

* вычислительную технику и программное обеспечение;

* коммуникации.

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

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

Временному сотруднику на время проекта требуется компьютер. Можно предложить ему старый компьютер. В 70% случаев этого будет достаточно. Другой вариант: взять компьютер сотрудника, находящегося в отпуске, и заменить жесткий диск. Если сотрудник возвращается из отпуска до завершения проекта, можно переставить данные участника проекта на другой компьютер. Более простой вариант распределенного использования вычислительной техники будет доступен, если в организации для работы используются сетевые диски.

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

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

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

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

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