Станіслав Андрєєв, операційний директор SharksCode, визначив основні ризики, пов'язані з залежністю B2B-продукту від постачальників IT-послуг.
При виборі зовнішнього IT-сервісу B2B-компанії повинні враховувати ціну ліцензії, умови її зміни, доступ до даних та потенційні наслідки у випадку збою. COO SharksCode Станіслав Андрєєв радить зосередити увагу на цих аспектах при оцінці постачальників технологічних рішень.
SharksCode — це українська технологічна компанія, яка зосереджується на створенні масштабованих програмних рішень для індустрії iGaming, B2B-платформ і мобільних додатків, що включають підтримку платіжних та інших сервісів.
Залежність від сервісу може формуватися поступово. На початковому етапі команда впроваджує інтеграцію для виконання певної функції, поступово адаптуючи до неї суміжні процеси та формати даних. Внаслідок цього, перехід на інше рішення може зажадати модифікацій у декількох модулях платформи, а іноді навіть в основній бізнес-логіці.
Станіслав Андрєєв вважає, що визначення критичності постачальника має базуватися на наслідках його недоступності та труднощах, пов'язаних із заміною. Якщо відсутність сервісу призводить до зупинки важливої для клієнта діяльності, цей ризик потрібно врахувати в операційному плані. А якщо процес міграції займає декілька місяців, витрати на це слід розглянути ще до укладення угоди.
Що впливає на вартість залежності
При придбанні зовнішніх рішень важливо звертати увагу на умови SLA, терміни повідомлення про зміни в API, можливості експорту даних і правила завершення співпраці. Для оцінки рівня безпеки постачальника можна використовувати звіт SOC 2 та сертифікат ISO 27001. Проте ці документи не можуть повністю замінити перевірку того, як компанія реагує на інциденти і чи надає підтримку клієнтам при перенесенні даних.
Окремий ризик полягає у залежності від унікальних можливостей певного постачальника. Хоча такий функціонал може прискорити процес розробки, він також може ускладнити наступний перехід на інші рішення. Тому важливо документувати рішення щодо використання специфічних функцій разом із попередньою оцінкою можливостей міграції.
Для контролю компаніям доцільно вести реєстр зовнішніх інтеграцій. У ньому зазначають функції продукту, відповідальну особу, доступ постачальника до даних, критичність та доступні альтернативи. Перегляд реєстру дає змогу виявити застарілі підключення і зміни в залежностях, які виникли після оновлення платформи.
Як зменшити наслідки зупинки сервісу
Розділення зовнішніх інтеграцій на окремі кодові компоненти значно полегшує процес заміни постачальників у майбутньому. Проте для забезпечення безперервності функціонування необхідно впровадити додаткові механізми, такі як моніторинг помилок, контрольовані повторні спроби, черги для не критичних завдань та надійні резервні інтеграції в тих випадках, де це є економічно обґрунтованим.
З особливою увагою варто підходити до операцій, результати яких потрібно чітко зафіксувати. У випадку, якщо зовнішній сервіс не відповідає, перед повторною спробою слід перевірити статус операції на платформі, щоб уникнути дублювання чи розбіжностей у даних. Для менш критичних сервісів, таких як передача аналітичних подій, допускається відкладене виконання після відновлення доступу.
Згідно з даними Annual Outage Analysis 2026, що були опубліковані Uptime Institute, за останні дев'ять років приблизно 66% всіх задокументованих збоїв у сфері IT-послуг і датацентрів мали місце у сторонніх постачальників, зокрема у хмарних і телекомунікаційних компаніях. Це дослідження зосереджується на випадках, які були офіційно зафіксовані.
COO SharksCode Станіслав Андрєєв також рекомендує заздалегідь призначити відповідальних за важливі інтеграції та встановити чіткий порядок комунікації з клієнтами під час інцидентів. Це дозволяє швидше оцінити масштаб проблеми і прийняти рішення щодо відновлення.
Таким чином, під час оцінки зовнішнього сервісу важливо співставляти швидкість його впровадження з витратами на потенційний вихід, ризиками для даних і впливом на клієнтські операції. Ці параметри дають бізнесу основу для рішення про постачальника та потрібний рівень резервування.
Якщо ви виявили помилку в написанні, будь ласка, повідомте нам про це.
