Журнал «БИТ» поинтересовался у Softline, КРОК, Xerox Россия, Актив, МайТэк и других компаний, какую методологию ИТ-проектов они используют в работе.

«Опросник» был таким:

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

«Если команда не понимает, что на горизонте, то всё превратится в работу на процесс, а не результат»

Николай Монахов, заместитель руководителя ИТ-отдела компании «Актив»

– Обязательным условием выбора методологии управления ИТ-проектами являются первичные цели, ограничения (границы) и возможные сроки реализации. При этом мы также оцениваем такие аспекты, как:

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

Три основных методологии, которые нам приходится использовать: Scrum, каскадная и итеративные модели. При этом не могу сказать, что на 100% мы следуем всем подходам, этапам, рекомендациям, принятым в каждой из методологий ИТ-проектов. Более того, мы периодически применяем некий симбиоз подходов в рамках одного проекта, так как у каждого есть свои плюсы и минусы, и стараемся найти наиболее подходящий «рецепт» для каждого конкретного проекта.

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

Как упростить работу с проектной документацией? Изучите на примере Directum.

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

Однозначного ответа на вопрос, кто лучше или кого мы предпочитаем, аутсорс или свой штат сотрудников, не существует. Всё зависит от специфики проекта. На каких-то проектах можно 80% всех трудозатрат отдать на аутсорс и получить приемлемый результат. В каких-то мы просто не готовы привлекать аутсорсеров, к примеру, из-за конфиденциальности.

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

Для меня нет такого понятия, как «мотивация» персонала. Я считаю, что его давно нужно заменить на понятие «стимуляция», как бы грубо это ни звучало. Итак:

• цель самого проекта или деятельности. Команде необходимо «видеть» конечный результат своей деятельности, даже если мы работаем по Scrum. Если команда не понимает, что у них на горизонте, то всё превратится в работу на процесс, а не результат. Также необходимо видеть среднесрочные и краткосрочные цели с обязательным их достижением и получением обратной связи от заказчика, даже если заказчик внутренний;
• заинтересованность в результате. К примеру:
• кому-то нужно повышение благосостояния – можно стимулировать премиальной составляющей;
• кто-то хочет отправиться в путешествие, и стандартных двух недель отпуска не хватает. Можно пойти человеку навстречу и обговорить отдельные условия;
• проговаривается отдельный распорядок рабочего дня, вплоть до возможности работы удаленно;
• кому-то хватает обычного доброго слова, поддержки и признания в коллективе его достижений.

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

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

«Самое главное – понимать, что руководитель работает с ЛЮДЬМИ, а не с «ресурсами”»

Максим Андреев, заместитель директора департамента информационных технологий, директор по бизнес-приложениям компании КРОК

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

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

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

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

По нашему опыту наиболее эффективно работа складывается, когда цели проекта «гармонизированы» с целями команды.

Самое главное – понимать, что руководитель работает с ЛЮДЬМИ, а не с «ресурсами». Поэтому в первую очередь он должен не управлять или контролировать, а создавать условия, при которых достижение личных целей человека совпадает с целями проекта, а также оперативно реагировать на отклонения.

У нас был очень интересный совместный опыт с международной компанией GBMC, в чьем портфолио был проект трансформации Airbus в процессе перехода на проектный способ строительства самолетов. Конечно же, нам было интересно, в чем заключается в данном случае российская специфика и как ее учитывать. Ответ был очень простой – нет национальной специфики, есть конкретные люди, их привычки, их культурный «код». Менеджер должен учитывать именно эти факторы, если команда интернациональная. Например, на первой встрече может быть «фиаско» разного рода: немцы придут за 10 минут, французы опоздают на 15, испанцы вообще не придут. Но непосредственная работа с людьми решает быстро все проблемы.

«Если выбранная методология ИТ-проектов становится проблемой самого проекта – смело её меняйте»

Елена Гречихина, руководитель проектов департамента сервисов и технической поддержки группы компаний Softline

– Сам проект и условия, в которых он должен проходить, всегда разнообразны, и именно от этого зависит выбор методологии. В сложных, длительных и комплексных проектах применяются так называемые тяжелые методологии, такие как PMBoK, Prince2. В более простых, где мы понимаем, что реализация будет быстрой и у нас имеется достаточно отработанных компетенции для реализации, можно применять Scrum и Kanban.

Мой положительный опыт совмещен с негативным. В одном из сложных проектов была использована тяжелая методология. Когда основные задачи проекта были успешно решены, мы столкнулись с тем, что он оказалась слишком громоздкой для решения задач попроще. Это создавало дискомфорт для всей команды. По этой причине была выбрана легкая методология ИТ-проектов Kanban, которая позволила быстро и эффективно завершить задачи в срок и с высокими результатами. Так что если выбранная методология становится проблемой самого проекта – смело её меняйте.

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

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

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

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

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

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

Можно многое понимать под фразой «российская специфика», но так как мы живём в России и работаем в ней, для нас это не «специфика», а данность, к которой мы все привыкли.

«Наши проектные руководители часто являются «играющими тренерами”»

Наталья Елисеева, руководитель отдела инфраструктурной поддержки компании Xerox Россия

– Мы не выбираем варианты от проекта к проекту, а используем свою методику управления ИТ-проектами. Когда проектный офис в Xerox только создавался, мы проанализировали существующие методологии и приняли решение использовать стандарты PMI (Project Management Institute). Кроме того, в нашей компании существует культура применения Lean Six Sigma, из которой мы заимствовали ряд элементов, например, оценку качества проекта, выраженного в количестве дефектов. В результате у нас появилась собственная методология ИТ-проектов, которая, на наш взгляд, в полной мере отвечает специфике наших проектов.

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

Мы используем подход PMI с элементами Lean Six Sigma. Методология хорошо зарекомендовала себя, поскольку позволяет гарантировать достижение запланированного результата.

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

Поскольку ИТ-проекты, которые мы реализуем для заказчиков, достаточно краткосрочные, имеют определенную специфику и реализуются на регулярной основе, в нашей компании организован собственный проектный офис. Наши PM часто являются «играющими тренерами», в отличие от классического понимания роли руководителя проектов.

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

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

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

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

«Реальность жизни меняется настолько быстро, что наиболее эффективным способом обучения является практика»

Айдар Сарваров, директор департамента проектов ООО «МайТэк»

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

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

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

При такой работе мы автоматизировали 4 из 13 процессов, добавили необходимую отчётность. А так как остальные процессы были сильно завязаны на первых, то их автоматизация даже не потребовалась. Задача заказчика была решена.

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

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

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

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

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

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

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

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

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

Источник: Полная версия опроса в Журнале «БИТ»

• Авторы
• Файлы

Исаев И.В. 1 1 Волгоградский государственный аграрный университет 975 KB

Проанализированы наиболее значимые информационные риски ИТ. Произведена категоризация ИТ-рисков. Представлен процесс организации процесса минимизации рисков. Охарактеризованы основные правила минимизации ИТ-рисков. Представлен комплекс мер по минимизации ИТ-рисков.

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

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

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

ИТ-риски можно разделить на две категории:

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

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

Процесс минимизации ИТ-рисков:

1. Выявление возможных проблемы, а затем определение способов их решения.
2. Определение сроков интеграции новых технологий при необходимости, по причине преобразования или слияния организации.
3. Оптимизация бизнес-процессов организации.
4. Обеспечение защиты интеллектуальной собственности организации и ее клиентов.
5. Разработка порядка действий при форс-мажорных обстоятельствах.
6. Определение фактических потребностей информационных ресурсов.

Некоторые способы минимизации рисков:

Для обеспечения необходимой защиты от ИТ-рисков и контроля безопасности можно провести следующие мероприятия.

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

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

Классифицировать данные по степени конфиденциальности и разграничить права доступа к ним.

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

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

Разработать и создать систему, позволяющую оперативно восстановить работоспособность ИТ- инфраструктуры при технических сбоях.

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

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

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

Библиографическая ссылка

Исаев И.В. ИТ РИСКИ И ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ // Современные наукоемкие технологии. – 2014. – № 7-1. – С. 184-184;
URL: http://www.top-technologies.ru/ru/article/view?id=34276 (дата обращения: 26.10.2020).Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания» (Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления) «Современные проблемы науки и образования» список ВАК ИФ РИНЦ = 0.791 «Фундаментальные исследования» список ВАК ИФ РИНЦ = 1.074 «Современные наукоемкие технологии» список ВАК ИФ РИНЦ = 0.909 «Успехи современного естествознания» список ВАК ИФ РИНЦ = 0.736 «Международный журнал прикладных и фундаментальных исследований» ИФ РИНЦ = 0.570 «Международный журнал экспериментального образования» ИФ РИНЦ = 0.431 «Научное Обозрение. Биологические Науки» ИФ РИНЦ = 0.303 «Научное Обозрение. Медицинские Науки» ИФ РИНЦ = 0.380 «Научное Обозрение. Экономические Науки» ИФ РИНЦ = 0.600 «Научное Обозрение. Педагогические Науки» ИФ РИНЦ = 0.308 «European journal of natural history» ИФ РИНЦ = 1.369 Издание научной и учебно-методической литературы ISBN РИНЦ DOI

Риски ИС и безопасность: риск менеджмент

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

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

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

• выбор неправильного решения, направленного на автоматизацию;
• ошибки в проектной деятельности;
• несоответствия инфраструктуры и принятого решения по автоматизации;
• ошибки при установке какой-либо системы.

При эксплуатации информационной системы следует учитывать такой перечень факторов, препятствующих достижению желаемых целей:

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

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

Классификация ИТ рисков

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

Классификация рисков информационных технологий

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

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

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

Второй немаловажный фактор – это компетентность и профессионализм сотрудников. Даже если в какой-то сфере ваш сотрудник не является профи, он должен уметь быстро обучаться.

Риски ИТ проектов в области исполнения

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

Типичные для ИТ-проектов риски

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

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

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

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

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

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

Управление рисками в ИТ. Risk IT

Концепция и понятия того, что представляет собой Risk IT

Основным объектом в такой методологии является ИТ-риск. Его можно определить как бизнес риски, связанные с применением, владением, влиянием ИТ на сам бизнес, а также уровень его влияния на использование в организации.

Risk IT имеет несколько базовых принципов.

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

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

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

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

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

Управление рисками ИТ-проектов

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

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

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

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

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

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

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

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

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

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

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

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

Качественный анализ рисков ИТ проектов представляет собой субъективную оценку обнаруженных рисков. Соответственно, нужно понять, как тот или иной риск может представлять угрозу для всего проекта. Один из самых популярных методов, который выявляет группы рисков в ИТ – это оценка по двум основным показателям: вероятность и влияние. Значения для них можно задать в трех категориях: низкое, среднее и высокое. Благодаря такой градации можно определить, какие риски требуют безотлагательного решения и вмешательства, и с какими можно работать потом.

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

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

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

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

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

Управление рисками при внедрении ИТ-проектов

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

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

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

Немного о процессах анализа и управления рисками

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

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

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

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

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

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

Деятельность по управлению ИТ-рисками рассматривается как составная часть общего управления рисками в организации и в основном направлена на:

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

Несмотря на такие благие цели, на пути внедрения процесса управления ИТ-рисками возникает ряд трудностей. Большая часть негатива относится к способу взаимодействия управления ИТ-рисками с определёнными стилями управления. Быть хорошим управленцем – нетривиальная задача. Нужны упорный труд, практическая смекалка и, главное, талант. Люди, которым не хватает требующегося таланта, попадают во власть механических подходов, таких, как управление по целям, планирование по закону Паркинсона («работа заполняет всё время, отпущенное на неё») и «культура страха», при которой подчинённых вынуждают действовать запугиванием. Эти методы несовместимы с любой схемой управления рисками.

Однако сопротивление управлению рисками исходит не только от менеджеров, культивирующих механические подходы. Вот ещё несколько основательных поводов усомниться в том, сработает ли риск-ориентированный подход в ИТ-управлении.

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

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

Уровень неопределённости слишком велик.

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

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

Если бы можно было со 100%-ной уверенностью утверждать, что вероятность какого-то события близка к нулю, т. к. в прошлом такое событие еще не наступало, многие ИТ-менеджеры были бы в восторге. «До открытия Австралии жители Старого Света тоже были убеждены, что все лебеди – белые» (Н. Талеб).

Зачем управлять ИТ-рисками, если нельзя от них полностью избавиться?

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

5.Бессмысленно управлять рисками в одиночку.

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

* * *

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

Цели организации неразрывно связаны с ИТ-целями.

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

Тщательно продуманная классификация рисков позволяет упорядочить процесс их идентификации.

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

Важность ретроспективного анализа.

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

Регулярное исследование источников рисков позволяет понять, что мешает достичь цели ИТ-деятельности.

Риск часто характеризуется путём описания возможного события и его последствий или их комбинации. Событие само по себе является не процессом, а результатом определённых процессов. Анализируя источники риска в привязке к ИТ-объектам (например, ИТ-системам или процессам ИТ-управления), в которых они зарождаются и/или на которые они влияют, можно понять, что в первую очередь мешает достичь ИТ-целей, и найти наилучший способ минимизации негативного воздействия. Одни источники риска самостоятельно способны спровоцировать реализацию конкретного риска, другие – только в комбинации с другими источниками.

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

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

• изъяны, допущенные при проектировании процесса ИТ-управления;
• отсутствие контрольных процедур;
• нехватка адекватного ИТ-персонала;
• деградация производительности ИТ-систем.

Далее каждый источник риска можно оценить по степени влияния.

Например, 0 – нецелесообразно принимать во внимание, 1 – среднее влияние, 2 – высокое влияние. Эта оценка может быть проведена экспертным путем. Дополнительно рекомендуется проанализировать зависимость от других рисков и их источников.

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

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