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

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

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

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

Как изменяется мотивация в ходе внедрения

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

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

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

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

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

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

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

Основные человеческие риски

Риски редко проявляются внезапно. Обычно они подаются заранее в виде определенных сигналов. Если сотрудники на обучении не задают вопросов, значит, они не усваивают материал или не заинтересованы в освоении. 

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

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

Чтобы не доводить ситуацию до конфликта, необходимо построить дисциплину управления рисками. Риск в проектном контексте — это неопределенное событие с цепочкой «причина — событие — последствие» и с параметрами вероятности и влияния. 

Управление рисками в этом контексте становится не разовой встречей, а целой системой с разными этапами: идентификация, анализ, планирование реагирования, мониторинг, актуализация согласно стандарта ISO 31000 и PMBOK 

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

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

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

Используются техники процессного картирования: SIPOC-диаграммы, разбивка операций по ролям, «путь данных» от первичного источника к отчетности. Во-вторых, анализируются артефакты: переписка с поддержкой, внутренние инструкции, реальные файлы Excel, которыми пользуются подразделения. 

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

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

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

• доля активных вопросов на час обучения;
• процент выполненных практических заданий;
• конверсия «пройдено обучение — успешно пройден тест-кейс»;
• количество замечаний, относимых к «необученность/непонятная инструкция»;
• среднее время реакции руководителей на эскалации. 

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

Качественная оценка рисков дополняется приоритезацией. Применяется матрица 5×5 по вероятности и влиянию, на основе которой формируется «тепловая карта» человеческих рисков: например, «массовая необученность бухгалтерии» попадает в красную зону, «уход одного специалиста при наличии дублера» — в желтую. 

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

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

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

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

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

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

Мониторинг и корректировка рисков

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

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

Для мониторинга используются конкретные метрики:

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

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

Ответственность сторон

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

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

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

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

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

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

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

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

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