Автоматизация · 10 мин
1С парк рисков: что это такое и как вести реестр рисков
Что такое парк рисков в 1С, зачем ведут реестр рисков, как оценивать вероятность и ущерб, назначать владельцев и контролировать мероприятия по снижению рисков.
Под «парком рисков» в контексте 1С обычно понимают реестр (перечень) рисков организации, который ведётся в информационной системе на платформе 1С:Предприятие — в типовых конфигурациях с блоками управления рисками, в отраслевых решениях партнёров или в самостоятельно разработанных доработках. Сам термин «парк» здесь используется по аналогии с «парком оборудования» или «парком техники»: это совокупность всех идентифицированных рисков компании, собранных в едином справочнике с атрибутами, оценками и ответственными.
Задача такого реестра — перевести управление рисками из разрозненных таблиц Excel и устных договорённостей в управляемый процесс: каждый риск описан, оценён по вероятности и ущербу, имеет владельца, план мероприятий и статус. Это нужно для внутреннего контроля, аудита, требований регуляторов (например, в банковской сфере и у компаний с системой внутреннего контроля) и для осмысленных управленческих решений.
Важно понимать: «1С:Парк рисков» — не единый типовой продукт с фиксированной методологией. В разных внедрениях реестр рисков реализован по-разному: от простого справочника с парой полей до полноценной подсистемы с матрицей рисков, регламентными расчётами и отчётами для руководства. Ниже разберём, из чего состоит такой реестр, как его вести и каких ошибок избегать.
Что входит в карточку риска
Минимальный набор атрибутов, без которых реестр превращается в бесполезный список, включает: наименование и содержательное описание риска, категорию (финансовые, операционные, правовые, репутационные, ИТ-риски), владельца риска — конкретного сотрудника или роль, оценку вероятности и оценку последствий (ущерба), а также статус: выявлен, в работе, принят, закрыт.
Расширенные карточки дополнительно содержат дату выявления, источник риска, связанные бизнес-процессы, причины и факторы, мероприятия по снижению с датами и ответственными, остаточную оценку после мероприятий и историю переоценок. Именно история изменений отличает рабочий инструмент от формальности: по ней видно, как менялась оценка и что было сделано.
Как оценивают риски: вероятность и ущерб
Стандартный подход — оценка по двум осям: вероятность наступления события и размер последствий. Шкалы бывают качественными («низкая / средняя / высокая») или количественными (например, баллы от 1 до 5, ущерб в денежном выражении). Произведение оценок даёт уровень риска, по которому строится матрица: зелёная, жёлтая и красная зоны.
Главная ошибка на этом этапе — выдумывать точные цифры там, где их нет. Если статистики по событию не существует, честнее использовать качественную шкалу с письменными критериями каждого уровня, чем присваивать псевдоточные проценты. Критерии шкал должны быть зафиксированы в методике, иначе разные сотрудники будут оценивать один и тот же риск несопоставимо.
Как организовать ведение реестра в 1С
Технически реестр реализуют тремя путями. Первый — использование готовой подсистемы управления рисками, если она есть в применяемой конфигурации или отраслевом решении. Второй — самостоятельная разработка: справочник «Риски», табличная часть или регистр сведений для мероприятий и переоценок, документ «Оценка риска» для истории. Третий — промежуточный вариант: ведение реестра в блоке задач и проектов, где мероприятия по рискам оформляются как задачи с контролем сроков.
Независимо от способа реализации потребуются: права доступа (кто видит все риски, кто — только свои), регламентное напоминание о сроках переоценки и мероприятий, а также отчёты — матрица рисков, список просроченных мероприятий, динамика уровня риска. Без автоматических напоминаний реестр быстро устаревает: переоценки не делаются, статусы не обновляются.
- 1Утвердите методику: категории, шкалы вероятности и ущерба, периодичность переоценки
- 2Создайте справочник рисков с обязательными полями: описание, категория, владелец, оценки, статус
- 3Проведите первичную идентификацию: соберите риски от руководителей подразделений
- 4Назначьте владельца и план мероприятий для каждого риска из красной и жёлтой зон
- 5Настройте напоминания о сроках мероприятий и переоценок
- 6Постройте отчёт-матрицу и проверьте его на тестовых данных
Кто должен участвовать в процессе
Рабочая схема предполагает три роли. Риск-координатор (или служба внутреннего контроля) ведёт методологию, следит за полнотой реестра и готовит сводную отчётность. Владельцы рисков — руководители направлений, которые оценивают свои риски и выполняют мероприятия. Руководство компании рассматривает сводную матрицу и принимает решения по рискам верхнего уровня: снизить, принять, передать (застраховать) или избежать.
Распространённая организационная ошибка — поручить ведение реестра одному сотруднику «в нагрузку» без полномочий требовать данные от подразделений. В этом случае реестр наполняется формально, оценки выдумываются, и система дискредитирует саму идею управления рисками.
Начинайте с ограниченного контура: 2–3 подразделения и 20–30 рисков. Реестр на несколько сотен позиций, запущенный сразу по всей компании, чаще всего забрасывается в первые месяцы — сотрудники не успевают его вести, а ценности ещё не увидели.
Как проверить, что реестр работает
Работающий реестр отличается от мёртвого по нескольким признакам: у каждого риска есть актуальная (не просроченная) оценка, мероприятия выполняются или осознанно переносятся с решением владельца, сводная матрица регулярно рассматривается руководством, а по итогам периода видны изменения уровней рисков. Если оценки не менялись год — это верный признак формализма.
Как проверить результат
Дата последней переоценки в пределах установленного регламентом срока
Оценки старше периода переоценки, статусы не меняются
У каждого риска назначен конкретный владелец, он подтверждает ответственность
Владелец — «подразделение» или пустое поле
По рискам высокого уровня есть мероприятия со сроками и исполнителями
Риски в красной зоне без единого планового действия
Матрица рисков входит в материалы управленческих совещаний
Отчёт формируется только для галочки перед аудитом
Типичные ошибки и ограничения
Первая группа ошибок — методологические: смешение рисков и проблем (проблема — уже случившееся событие, риск — возможное), слишком абстрактные формулировки вроде «риск неудачи», отсутствие критериев шкал. Вторая группа — организационные: отсутствие владельцев, нереалистичные сроки мероприятий, отсутствие периодичности переоценки. Третья — техническая: ведение параллельных реестров в 1С и в Excel, из-за чего данные расходятся и доверие к системе падает.
Отдельно стоит сказать об ограничениях. Реестр рисков в 1С — инструмент учёта и контроля, а не прогнозирования: система фиксирует оценки людей, но не предсказывает события. Качество результата полностью зависит от дисциплины участников и качества методики. Автоматизация убирает рутину и потери данных, но не заменяет экспертную оценку.
Когда нужна доработка, а когда хватит типовых средств
Если требуется просто фиксировать риски с оценками и статусами, часто достаточно типовых механизмов: справочника, задач и отчётов, которые есть или легко добавляются в большинстве конфигураций. Доработка оправдана, когда нужны специфические расчёты (например, агрегирование рисков по иерархии процессов), интеграция с системой внутреннего контроля, сложные матрицы полномочий или отраслевая отчётность.
Как выбрать действие
Что важно запомнить
Парк рисков в 1С — это реестр рисков компании с оценками, владельцами и мероприятиями. Ценность даёт не сама программа, а методика, дисциплина переоценок и реальное использование матрицы рисков в управлении. Начинайте с малого контура, утвердите шкалы до заполнения и уберите параллельные Excel-реестры.
Частые вопросы
«1С:Парк рисков» — это отдельная типовая программа?
Нет, это не название единого типового продукта фирмы «1С». Так обычно называют реестр рисков, реализованный в конкретной системе: в отраслевом решении партнёра, в доработанной конфигурации или в подсистеме управления рисками. Перед покупкой или разработкой уточняйте, какая именно функциональность входит в предлагаемое решение.
Чем риск отличается от проблемы в реестре?
Риск — событие, которое ещё не произошло, но может наступить; для него оценивают вероятность и ущерб. Проблема (инцидент) — уже случившийся факт, её нужно устранять, а не оценивать. Смешение этих понятий в одном списке делает оценки бессмысленными, поэтому инциденты обычно ведут отдельно.
Как часто нужно переоценивать риски?
Универсальной нормы нет — периодичность задаёт внутренняя методика. Практикуемый подход: риски высокого уровня пересматривают чаще (например, ежеквартально), низкого — реже (раз в полгода или год), плюс внеплановая переоценка при существенных изменениях: новых проектах, смене законодательства, произошедших инцидентах.
Можно ли вести реестр рисков без доработки конфигурации?
Да, для базового сценария достаточно имеющихся механизмов: пользовательского справочника или классификатора, задач для мероприятий и отчёта для матрицы. Доработка понадобится, когда нужны история оценок, автоматические напоминания, сложные права или специальные расчёты.
Кто должен быть владельцем риска?
Руководитель того подразделения или процесса, где риск возникает и где есть реальные рычаги влияния на него. Назначать владельцем службу внутреннего контроля — ошибка: она координирует процесс, но не может снижать, например, производственный или кредитный риск своими силами.
Что делать с рисками, которые компания решила принять?
Они остаются в реестре со статусом «принят» и зафиксированным решением уполномоченного органа. Принятие — осознанное решение не тратить ресурсы на снижение, но не удаление риска из учёта: его продолжают периодически переоценивать, потому что условия могут измениться.