Приклад BIA – як розставити пріоритети для критичних процесів, RTO та RPO
Аналіз впливу на бізнес (BIA) стає корисним лише тоді, коли він призводить до встановлення пріоритетів. Аналіз має допомогти компанії зрозуміти, які процеси повинні бути відновлені в першу чергу, як зростають наслідки з плином часу, які залежності є критичними та які цілі відновлення дійсно необхідні.
Приклад: невелика компанія електронної комерції та послуг
Припустімо, що компанія продає цифрові та фізичні товари онлайн. Діяльність залежить від інтернет-магазину, оплати, обслуговування клієнтів, адміністрування замовлень, бухгалтерії та кількох зовнішніх SaaS-сервісів. Керівництво хоче знати, що повинно запрацювати першим після серйозного ІТ-збою.
Для кожного виду діяльності власник процесу опитується щодо наслідків, наприклад, через 2 години, 8 годин, 24 години, 3 дні та 1 тиждень. Наслідки оцінюються в таких сферах, як фінанси, клієнти, юридичні питання/відповідність вимогам, операційна діяльність, репутація та безпека.
Спрощений приклад BIA
| Процес | Критичний наслідок | Пріоритет | Приклад RTO | Приклад RPO |
|---|---|---|---|---|
| Оформлення замовлення та оплата | Втрачені продажі та неможливість завершення покупки | 1 | 4 години | 15 хвилин |
| Обробка замовлень | Зупинка поставок та зростання черги | 2 | 8 годин | 1 година |
| Обслуговування клієнтів | Збільшення часу відповіді та більше скарг | 3 | 24 години | 4 години |
| Фінансова звітність | Затримка, але обмежений прямий вплив на клієнтів | 4 | 72 години | 24 години |
Таблиця — це лише кінцевий продукт роздумів. Важливим є те, чому оформлення замовлення опинилося вище за обслуговування клієнтів і які припущення стоять за RTO/RPO.
Оцініть, як змінюються наслідки з плином часу
Процес не є автоматично «критичним» лише тому, що він важливий у повсякденному житті. BIA має ставити питання, коли наслідки стають неприйнятними. Двогодинний збій може бути керованим, тоді як доба простою може спричинити серйозні фінансові чи правові наслідки.
Тому документуйте порогові значення. Наприклад: через чотири години починаються значні втрати доходів, через вісім годин порушується обіцянка клієнту, через добу виникають ручні черги, які неможливо наздогнати. Тоді цілі безперервності отримають фактичне обґрунтування.
Розрізняйте максимальну толерантність та цілі відновлення
Організації іноді використовують терміни, такі як MTPD або максимально допустимий час простою, для моменту, коли наслідки більше не можна прийняти. На практиці RTO слід встановлювати з достатнім запасом до такої межі, оскільки відновлення ніколи не слід планувати на останню можливу хвилину.
RTO та RPO – використовуйте їх правильно
RTO (Recovery Time Objective), цільовий час відновлення, описує мету того, як швидко сервіс або процес має бути відновлений після збою. RPO (Recovery Point Objective), цільова точка відновлення, описує, як далеко в минуле організація може дозволити втрату даних під час відновлення.
Якщо для оформлення замовлення встановлено RTO 4 години, але технічне рішення потребує 12 годин для відновлення, виникає розрив. Таким чином, BIA виявив ризик, який потрібно вирішувати шляхом кращого резервування, швидшого відновлення, резервної процедури або перегляду бізнес-цілей.
Якщо RPO становить 15 хвилин, а резервне копіювання виконується лише раз на добу, існує такий самий розрив. Отже, RPO — це не просто побажання, яке можна вписати в план без технічної підтримки.
Картографуйте людей, системи та постачальників
Для кожного критичного процесу BIA має визначати залежності. Це можуть бути:
- ключові особи та мінімальний штат персоналу,
- приміщення та обладнання,
- бізнес-системи та інтеграції,
- послуги ідентифікації та входу в систему,
- дані та документація,
- телефонія та зв'язок,
- критичні постачальники та субпідрядники,
- електроенергія, мережа та інші інфраструктурні послуги.
Часто буває, що «другорядний» сервіс виявляється єдиною точкою відмови. Прикладом є постачальник ідентифікації: інтернет-магазин може бути технічно доступним, але персонал не зможе ним керувати, якщо SSO (єдиний вхід) не працює.
Як перенести результати BIA до плану безперервності
BIA відповідає на питання, що потрібно зробити в першу чергу. План безперервності відповідає на питання, як діяльність має продовжуватися і відновлюватися.
Для процесів з найвищим пріоритетом план має визначати критерії активації, відповідальність, резервні процедури, контактні списки, ескалацію постачальників, порядок відновлення, комунікацію та умови повернення до нормальної роботи. Читайте про те, що має містити план безперервності.
Якщо технічна послуга купується як SaaS, цілі відновлення слід порівнювати з SLA постачальника. Див. посібник про SLA, RTO та RPO.
Поширені помилки в роботі над BIA
- Усі процеси стають критичними. Тоді аналіз не розставив пріоритети.
- RTO встановлюється лише ІТ-відділом. Ціль повинна виходити з потреб бізнесу, а потім перевірятися на відповідність технічним можливостям.
- RPO не пов'язано з даними. Різні масиви даних можуть вимагати різного рівня толерантності.
- Залежності пропущені. Особливо ідентифікація, інтеграції та зовнішні постачальники.
- Ніхто не відповідає за результат. Кожен критичний процес потребує відповідального власника.
- BIA ніколи не оновлюється. Нові системи, продукти та постачальники можуть змінити пріоритети.
Контрольний список для вашої власної BIA
- Складіть список видів діяльності та власників процесів.
- Оцініть наслідки для кількох часових інтервалів.
- Визначте, коли наслідки стають неприйнятними.
- Розставте процеси в порядку їх відновлення.
- Встановіть попередні цілі RTO та RPO.
- Картографуйте персонал, системи, дані та постачальників.
- Порівняйте цілі з реальними можливостями відновлення.
- Задокументуйте розриви та заходи з їх усунення.
- Перенесіть результати до плану безперервності.
- Тестуйте та переглядайте після серйозних змін.
Потрібен BIA та план безперервності в одному робочому процесі?
Шаблон плану безперервності + BIA від Mallbutiken 2026 поєднує аналіз, розстановку пріоритетів та планування безперервності у форматах Word, PDF та Excel. Ціна в магазині: 249 шведських крон.
Переглянути План безперервності + BIAЧасті запитання
Чи є RTO тим самим, що й максимально допустимий час простою?
Ні. RTO — це ціль відновлення. Максимально допустимий час простою описує зовнішню межу толерантності. Цілі відновлення, як правило, повинні встановлюватися раніше.
Чи повинні всі процеси мати RPO?
RPO актуальний, перш за все, там, де відновлення даних є центральною частиною. Для ручних процесів інші показники відновлення можуть бути кориснішими.
Як часто слід оновлювати BIA?
Не існує універсального інтервалу, який підходить усім. Проводьте регулярні огляди та переглядайте результати, коли змінюються критичні системи, постачальники, процеси або вимоги.
Пов'язані посібники
Почніть з основного посібника з BIA і переходьте до плану безперервності.
Цей посібник є навчальним прикладом, і значення не слід використовувати як готові вимоги без власного аналізу.
