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

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

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

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

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

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

Рис. 1. Определение величины критериев для выявленных рисков

Далее можно ранжировать все риски с использованием матрицы рисков следующего вида:

Рис. 2. Матрица рисков

В зависимости от полученных оценок, риск относится к одной из следующих групп:

· Высокий риск (красная область) - здесь необходимы срочные меры по снижению уровня риска.

· Существенный риск (желтая область).

· Умеренный риск (синяя область).

· Незначительный риск (зеленая область) - усилия по управлению рисками в данном случае не будут играть важной роли.

Рис. 3. Ранжирование рисков по категориям

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

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

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

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

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

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

Во избежание риска неправильной работы интерфейсов необходимо:

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

· тщательно настроить интерфейсы;

· подготовить план тестирования, включающий проверку работы интерфейса в случае исключительных ситуаций;

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

Следующим важным риском при внедрении ИС является квалификация команды внедрения. Члены команды внедрения со стороны поставщика системы должны иметь успешный опыт запусков ИС.

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

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

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

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

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

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

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

Подготовка к реализации проекта

Модуль 1: Подсистема "Учет музейных коллекций"

Модуль 2: Подсистема "Научно-фондовая работа"

Модуль 3: Подсистема "Реставрационная деятельность"

Модуль 4: Подсистема "Издательская деятельность"

Модуль 5: Подсистема "Выставочная и экспозиционная деятельность"

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

Рис. 7. Использование ресурсов в процессе разработки АИС

Детализация процесса разработки по этапам представлена на рисунке 4. В ходе разработки будут создаваться и тестироваться отдельные модули, которые затем будут соединены в единую систему.

Отчеты по проекту

Общий запланированный бюджет проекта составляет 1679,765 тыс. рублей (табл.6.4). Это, согласно текущему курсу (1 американский доллар = 31,302 российского рубля на 28 мая 2013 года), равняется 53663$. Естественно, ни один музей даже самый крупный, не может позволить себе приобретать столь дорогостоящий программный продукт. Поэтому в договоре с заказчиком на разработку была указана цена, не намного превышающая уровень цен на рынке программных продуктов, с учетом масштабов внедрения и затрат разработчика, 12080$ (разработка и внедрение информационной системы на 36 музейных компьютерах), что приблизительно равно 384, 119 тыс. рублей. Это не покроет всех затрат на разработку, однако разработанная информационная система не является эксклюзивной и может быть продана другим клиентам в дальнейшем.

При этом ценовая политика компании-разработчика должна быть такой, чтобы предлагаемая информационная система могла конкурировать с известными представителями этой рыночной ниши. Цены на рынке программных продуктов для автоматизации музейной деятельности колеблются от 800$ до 3500$, как было сказано ранее. Основываясь на этих данных, организация будет строить свою ценовую политику.

Итак, предлагая свою информационную систему другим музеям, скажем, за 2800$, "Ovio-Tech" может рассчитывать на покрытие всех издержек после продажи данной системы еще 15 музеям. Это не составляет проблем, в связи с тем, то создатели ИС "Ovio-Tech" - это достаточно крупная организация, осуществившая уже много проектов, следовательно, может выделить средства на покрытие расходов на разработку. Основной целью сейчас "Ovio-Tech" видит выход на новый для себя рынок и завоевание его доли, в данном случае величина прибыли значения не имеет. После продажи 15 музеям (потребуется меньше одного года) своей информационной системы "Ovio-Tech" вернет свои инвестиции, вложенные в данный проект, станет получать прибыль от продажи разработанного программного продукта. А так как спрос на подобные информационные системы сейчас крайне велик, как мы уже выяснили ранее, он намного превышает предложение, у организации не возникнет проблем с тем, чтобы реализовать свой продукт.

Кроме того, организация считает целесообразным упростить разработанную версию информационной системы, чтобы она стала более доступной для внедрения в маленькие музеи (соответственно, цена при этом тоже снизится). А с другой стороны система дорабатывается до уровня корпоративной информационной системы, которая будет автоматизировать деятельность всего музея в целом. Рассматривается вариант, при котором различные конфигурации данной системы будут продаваться на рынке от 800$ до 3500$ (без учета числа автоматизируемых рабочих мест).

Размещено на Allbest.ru