67
обсуждается, конкретизируется и планируется еще на ранних стадиях ЖЦ
разработки. План приемки продукта заказчиком пишется на этапе планирования,
а само испытание системы - на фазах разработки и анализа проекта и т.д. Такой
процесс создания планов испытания выделен пунктирной линией между
прямоугольниками V-образной модели
В процессе применения V-образной модели при создании проекта, для
которого она оптимально подходит, реализуется несколько преимуществ:
• Модель придает особое значение придается планированию,
направленному на подтверждения и проверки создаваемого ПО еще на
начальных стадиях его разработки. Этап модульного тестирования подтверждает
правильность детализированного проектирования. Этапы внедрения и проверки
описывают архитектурное проектирование или проектирование на высоком
уровне. Этап проверки системы подтверждает правильность выполнения этапа
требований к продукту и его параметров;
• Модель предусматривает аттестацию и подтверждение всех
внешних и внутренних полученных данных, а не только исходного ПО;
• V-образной модель выполняет определение требований перед
началом разработки проекта системы, а само проектирование ПО проходит
перед созданием компонентов;
• Модель определяет продукты, полученные в результате процесса
разработки, и все полученные данные подвергаются тестированию;
В процессе применения V-образной модели в работе над проектом, для
которого она не совсем подходит и недостаточно приемлема, проявляются ее
недостатки:
• Этой модели непросто справиться с параллельными событиями;
• В ней не учитываются итерации между фазами;
• В ней нет внесенных требований динамических изменений на
разных этапах ЖЦ;
• Проверка требований в ЖЦ реализуется слишком поздно, поэтому
невозможно внести корректировки, не повлияв при этом на сроки выполнения
проекта;
• Модель не включает действия, направленные на анализ рисков.
68
Как и каскадная модель, V-образная модель также лучше срабатывает
тогда, когда вся информация о требованиях заранее известна.
Общераспространенная модификация V-образной модели, направленная на
преодоление ее недостатков, включает в себя внесение итерационных циклов
для разрешения изменения в требованиях за рамками фазы анализа.
Для того, чтобы выбрать способ внедрения ИС, необходимо описать все
существующие способы внедрения, которые позволят понять какой же способ
необходим для задачи.
Существуют следующие стратегии внедрения [32]:
параллельная стратегия – для случая, когда старую работающую
систему необходимо заменить новой. Например, п/с «Зарплата». Одновременно
работают старая (ручная) и новая система, и их выходные документы
сравниваются. Если они согласуются длительное время, можно переходить на
новую систему. Проблема в том, что большинство предприятий, внедряющих
АСУП, заменяют программным обеспечением неавтоматизированный вариант, а
не одну часть программного обеспечения другой.
«скачок». Эта стратегия привлекательна, но мы бы ее не
рекомендовали. «Скачок» означает, что прежняя система работала еще в
пятницу, а в понедельник начали работать по новой системе. Некоторые
считают, что такая позиция заставляет всех «тонуть и всплывать» с
понедельника. Но в действительности, может утонуть все дело. Если данные не
столь точны, как хотелось бы, если люди не обучены, тогда есть риск
ввергнуться в хаос, сорвать поставки и финансовые расчеты.
опытная эксплуатация «плотного проекта» - это тактика «скачка»,
но применяемая к ограниченному числу изделий. Область применения стратегии
- малый участок деятельности. Такой подход наиболее надежен, он снижает
риск, и сегодня практически все фирмы применяют эту тактику.
«узкое место» - это наиболее критичная малая часть
производственного процесса. При внедрении «узкого места» план внедрения
выполняется только для «узкого места» и для людей, работающих в нем.
Точность данных повышается только для изделий в этом «узком месте»,
69
переподготовка - только для людей, работающих в нем; анализ «затраты –
эффект» делается только для него и т. д.
Описав стратегии внедрения, можно сказать, что к автоматизированной
задаче (задаче учета и обработки заявок) применима технология «пилотного
проекта», т.к. внедрение происходит на малый участок деятельности компании.
Данная стратегия внедрения информационной системы была выбрана,
потому что это наиболее часто используемая компаниями стратегия. Такой
подход снижает риск и наиболее надежен.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Современные ИС представляют собой комплексные и достаточно
сложные решения, и их реализация, как правило, требует серьезных финансовых
вложений со стороны компании. ИТ системы – представляют собой комплекс
технических и программных средств, используемых для хранения, обработки и
анализа данных. Средства анализа, включенные в ИТ системы, дают
возможность быстро обрабатывать огромные массивы данных и уже в
результате предлагать конкретные действия в соответствии с исходной
ситуацией.
Современные ИТ тесто интегрированы в бизнес-процессы компании,
организуя все службы и уровни компании. И любое изменение в такой структуре
так или иначе оказывает влияние на все сферы деятельности компании. Данное
обстоятельство очень затрудняет оценку эффективности использования ИТ,
поскольку порой сложно выделить их влияние на функциональные процессы,
вывести для этого отдельную переменную и тяжело охватить все направления
влияния применяемых ИТ.
Выделим некоторые типичные причины реализации рисков при
проведении ИТ-проектов:
1. Неподготовленность управляющего звена к переменам в бизнес-
процессах предприятия и организационной структуры.
2. Отстраненность руководства главных подразделений и их
непосредственных подчиненных.
70
3. Изменения в кадровом составе в процессе реализации ИТ-проекта.
4. Недостаточность квалификации менеджера проекта и других
ответственных исполнителей.
5. Неимение четких и понятных методологических основ такого
процесса.
Основываясь на указанных выше факторах, отслеживание рисков
проектов по внедрению ИТ, аппаратного и программного обеспечения, методик
сохранения данных, сетевых технологий, реализующих доступность
коммуникации и ИС состоит в том, чтобы на начальном этапе выявить все
возможные риски и провести некоторые защитные мероприятия для
минимизации последствий серьезных проблем на всем протяжении реализации
проекта.
Успех ИТ-проекта зависит от многих факторов. Но основополагающих
можно выделить три: ресурсы, время и качество. Главная задача руководителя
ИТ-проекта – успеть все реализовать в заданные сроки с указанным бюджетом и
требуемым качеством. Поэтому основные риски, зачастую характерные для
любых ИТ-проектов состоят в срыве сроков реализации проекта, увеличении
стоимости и ухудшении качества. Но главной причиной реализации этих рисков,
особенно в ИТ-проектах, является физическая неподготовленность компании к
реализации таким проектам.
Говоря о проектах внедрения ИТ важно заметить, что почти все новые
технологии создаются в условиях высокой неопределённости и негативного
окружения. Это объясняется тем, что реализация почти всех ИТ-проектов,
особенно крупных, делается в условиях, когда все другие стандартные методы
управления уже не применить. Уникальность целей проекта и неимение
подобных практик в прошлом порождает некую неопределенность касательно
выбора современных технологий, выражения методов и средств достижения
указанной цели, поддержки той или иной методологии.
Управление рисками в сегодняшних компаниях становится тщательно
продуманным процессом. Процесс управления рисками рассматривается не
только как отдельно стоящая задача, которая требует решения, а как часть общей
корпоративной системы управления. Целью контроля рисков, в конечном счете,
71
становится увеличение эффективности бизнеса за счет работы компании и
полноценная отдача от применяемой методики.
Есть множество методик, содержащих различные варианты и способы
управления проектными рисками. Но поскольку почти каждый проект
внедрения, как правило, не является единообразным в связи со спецификой
построения компании, ее структуры и существующими бизнес-процессами,
всегда есть отдельные моменты, не подходящие в полной мере для исследуемой
фирмы. Это означает, что процесс управления рисками почти всегда связан со
спецификой отрасли и направлением деятельности компании. Очень часто
специалисты создают собственный подход к управлению рисками, являющийся
комбинированным решением нескольких методик и приспособленным к
требованиям организации. Быстрое распространение ИТ требует пристального
внимания и созданию специальных методов контроля рисков, связанных с
реализацией и применением ИТ на предприятии.
Опираясь на различные источники, можно представить 6 базовых
процедур управления рисками, которые адаптируются к специфике ИТ-
проектов:
1. Планирование контроля возможных рисков, т.е. выбор подходов и
описание деятельности по управлению рисками проекта.
Данный процесс включает в себя решения по организации, кадровому
обеспечению методик управления рисками проекта, выбору наилучшей
методологии, источников информации для определения рисков, правила
реализации процедур. Важно грамотно спланировать управление рисками, чтобы
оно соответствовало и неопределенности, и рискам, так и важности проекта для
самой компании.
Исходя из отчета консалтинговой компании Accenture, которая занимается
разработкой проектов в области ИТ, на подготовительной стадии и
планировании создания проекта (первые 10%) реализуется более 90% его
полезности. Именно в этот момент учитываются наиболее болезненные
последствия: увеличение сроков, огромный бюджет, минимальная
функциональность. При этом заказчик и консультант могут рассматривать
проблему по-разному, что часто приводит к разным методам управления
72
рисками, которые закладываются на ранних этапах. Поэтому каждая компания
создает собственный план управления рисками, включающий общие регламенты
и приемлемые методики.
2. Выявление рисков, которые могут повлиять на проект, и описание их
характеристик.
Определение рисков ИТ-проекта состоит в подготовке перечня факторов
рисков, которые могут повлиять на выполнения ИТ-проекта в срок, в границах
бюджета и с указанным заранее качеством. Реализация определения рисков
требует понимания процессов ИТ в самой компании, понимания бизнеса,
осуществляемого с помощью ИТ и раздельно, основных взаимосвязей
информационных, управленческих и производственных процессов внутри
фирмы, а также связи с внешним миром и окружением.
Исходный список рисков создается командой ИТ-проекта или группой
аналитиков рисков. В качестве средств поиска может применятся обзор
документации, предполагающий проведение анализа уже созданных документов
группой управления рисками проекта, сочетает в себе поэтапный анализ плана
проекта и созданных ограничений, как на уровне проекта в целом, так и на
уровне каждой работы, в частности. Могут применятся методы «мозгового
штурма», метод Дельфи, проведение опросов, SWOT-анализ и пр.
3. Качественная оценка рисков включает в себя анализ рисков и
условий их реализации для выявления их влияния на итог проекта.
Такая оценка реализуется на этапах анализа, планирования и создания
проекта с учетом имеющихся данных по определению рисков. Примером
выбранного критерия и качественной оценки в отдельном ИТ-проекте
становится вероятность поломки любого оборудования, например, ПК, за
некоторый промежуток времени. Примером субъективного критерия при оценке
ИТ риска становится оценка владельца информационного ресурса процента
возможного выхода из строя ПК. Для этого строится качественная шкала с
несколькими градациями.
Источниками данных, предназначенных для оценки риска ИТ-проект,
зачастую служат:
73
• Техническая инфраструктура для выявления технических и
технологических рисков;
• Требования к защищенности данных для выявления рисков для
информации;
• Штатное расписание и организационная структура компании для
определения организационных рисков;
• Карты технологических потоков для выявления технико-
производственных рисков;
• Контракты и договоры для выявления юридических и деловых
рисков и т.д.;
4. Количественная оценка включает в себя некий анализ вероятности
реализации и влияния последствий выполнения рисков на сам проект.
При качественной оценке реализуется ряд мероприятий для выявления
уровня каждого риска, который может применяться и для оценки рисков ИТ-
проекта. Большое распространение имеет методика вероятностной оценки риска,
вычисляемая при помощи вероятностного анализа для отдельного риска на базе
2 факторов: степени влияния риска и вероятности его возникновения.
5. Планирование реакции на риски подразумевает ряд процедур и
методов по уменьшению негативных последствий рисков и применению
возможных преимуществ.
Типичные методы реагирования для ИТ-проекта состоят из
дополнительных методов реагирования на риски ИТ, к примеру:
• Комплексный подход. Важно учитывать тенденции в собственном
бизнесе и указанной области автоматизации, план развития компании,
внедренные системы, привычки и культуру пользователей.
• Заинтересованность. Использование в проекте всех тех, кто станет в
итоге пользователями системы. Это даст возможность минимизировать
негативное отношение к проекту и увеличить его внедряемость.
• Дробление. Разделение проекта на небольшие этапы или на
самостоятельные проекты с отдельными задачами и целями, в совокупности
составляющие проектную программу. Создавать систему лучше всего поэтапно
74
— от прототипа до полноценной системы, от ядра с минимальным
функционалом до полноценной рабочей версии, то есть «очередями».
• Выделенность. В проекте нужно иметь подразделения: первое,
отвечающее за качество проекта, второе — за стоимость и сроки работ.
Опираясь на план реагирования на риски ИТ-проекта выбирается решение
о реализации или отказе от противорисковых мер.
6. Отслеживание и контроль рисков – выявление рисков, подсчет еще
не ликвидированных рисков, выполнение плана управления рисками проекта, и
подсчет показателя эффективности решений по уменьшению рисков.
Реализация мониторинга и контроля рисков влечет за собой выбор иных
стратегий, проведение корректирующих действий, изменение плана проекта.
Изменяется БД по рискам, которая может в будущем применяться при
разработке подобных проектов и в повседневной деятельности компании. Для
лучшей реализации плана управления рисками между менеджерами проекта и
специалистами по управлению рисками необходимо постоянное
взаимодействие.
При разработке и внедрении ИС существует много причин, приводящих к
возникновению рисков: ошибки в выборе стратегии проекта, нечетко
поставленные цели и задачи, изменение внешних и внутренних требований,
низкая квалификация персонала и т. д.
Одна из важных особенностей предлагаемой модели - управление рисками
такого проекта, которое во многом строится на управлении конфигурацией ИС и
процессами проекта.
Существуют следующие типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с
проблемами реализации технических решений и человеческим фактором, а
именно риски, связанные с неспособностью специалистов выполнить
необходимую задачу.
75
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих
большой опыт работы в соответствующей области и при этом
взаимозаменяемых на сотрудников, не менее соответствующих данным
характеристикам.
Основные риски и способы их уменьшения приведены в таблице 2.1.
Таблица 2.1
Основные риски при разработке проекта и способы их снижения
Виды рисков
Снижение видов
риска
Распределение
риска
Снижение
вероятности
возникновения
риска
Риски, связанные
с масштабом
проекта
Детальный анализ
каждого этапа
работ,
взаимодействия
участников,
организации работ
Разделение
проекта на
несколько
подпроектов,
выделение
пилотного проекта
по подсистемам
(ограниченного
масштаба)
Детально
проработанная
программа
качества,
отработанное
управление
конфигурацией
проекта
Риски, связанные
с недостаточным
опытом в сфере
ИТ
Проведение
обучения
пользователей,
включая
руководство,
соблюдение
технологий работы
Согласование
большинства
проектных
документов,
согласование всех
изменений в
функциональности
системы
Разработка и
утверждение
концепции
проекта на
возможно более
ранней его стадии
Технические
риски проекта
Строгий отбор
проектной
команды по
квалификационным
Документально
зафиксированная
персональная
ответственность
Использование
стандартов
предприятия на
проектные
76
критериям.
Обучение
участников проекта
технологии
проектных работ,
инструментальным
средствам
участников
проекта,
документальное
фиксирование
всех изменений в
процессе проекта
работы,
разработка
стандартов
проекта
Организационные
риски проекта
Обучение
участников проекта
(курс "управление
проектом"),
тренинги команды,
как можно более
полная
формализация
деятельности
Включение
представителей
заказчика в
рабочие группы
Включение в
команду
администратора
проекта,
детальное
распределение
ролей в проекте
Операционные
риски проекта
Многократное
тестирование
созданных
продуктов
Фиксирование
отсутствия
претензий
заказчика по
каждому этапу
работы
Строгое
выполнение
процедур
программы
качества
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В качестве основных направлений обеспечения информационной
безопасности компании применяются:
Обеспечение информационной безопасности при ведении
делопроизводства и осуществлении документооборота(как бумажного так и
электронного);
Обеспечение безопасности конфиденциальных переговоров;
Обеспечение информационной безопасности при осуществлении
взаимодействия с деловыми партнерами и клиентами;
Обеспечение информационной безопасности при проведении работ
по модернизации информационных систем компании;
Обеспечение информационной безопасности при соблюдении
правовых и договорных требований;