ИТ и разработка

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

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

Независимо от размера ИТ-подразделения.

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

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

Все четыре причины управляемы на старте и почти неуправляемы в середине. Поэтому по проектам внедрения имеет смысл проводить отдельную стартовую сессию по рискам, а не ограничиваться общим реестром проекта.