Позиция Есть парадокс, который все чаще проявляется в работе украинских компаний. Мы тратим деньги на автоматизацию, чтобы бизнес меньше зависел от людей, ручных операций и ошибок. А потом обнаруживаем, что одна недоступная система способна остановить целую цепь процессов, которые раньше могли работать отдельно.
Отключения электроэнергии и проблемы со связью сделали этот парадокс особенно заметным.
Представим интернет-магазин с хорошо настроенной автоматизацией. Заказы с сайта автоматически попадают в CRM, система проверяет остатки, резервирует товар, формирует документы и передает информацию службе доставки. Менеджеру остается контролировать исключения.
В обычный день это эффективная модель.
Но что произойдет, если связь с сервером исчезнет на несколько часов? А если после восстановления интернета часть операций повторится, часть останется в очереди, а информация об остатках в разных системах уже будет отличаться?
Теперь представим, что одновременно исчезло электричество, мобильный интернет работает нестабильно, а резервный спутниковый канал недоступен.
Проблема уже не в том, как быстро восстановить связь. Проблема в том, способен ли бизнес правильно восстановить работу после сбоя.
По моему мнению, именно этот вопрос украинские компании должны задать себе перед следующим этапом автоматизации.
Мы автоматизировали операции, но не всегда предусмотрели их остановку
Большинство проектов автоматизации начинаются с вполне логичной задачи: сократить ручной труд, ускорить обработку заказов, уменьшить количество ошибок, получить прозрачную аналитику.
Для этого компании интегрируют CRM, ERP, складской учет, платежные сервисы, маркетплейсы и логистические платформы. Каждая новая интеграция убирает часть ручной работы. Но в то же время создает зависимость между системами.
Пока все работает стабильно, эти зависимости почти незаметны.
Склад автоматически получает задачи. Бухгалтерия видит оплату. Менеджер получает уведомление об изменении статуса заказа. Клиент — номер накладной. Однако автоматизация не отменяет необходимости управлять исключениями. Она лишь меняет их природу.
Раньше менеджер мог ошибиться при переносе заказа из одного документа в другой. Теперь интеграция может автоматически передать некорректные данные сразу в несколько систем.
Раньше ошибка оставалась локальной. Теперь она потенциально масштабируется вместе с автоматизацией.
Это не аргумент против технологий. Напротив, это аргумент за более зрелый подход к их внедрению.
Автоматизировать нужно не только нормальный сценарий работы, но и поведение системы во время сбоя.
Электроэнергия и связь стали частью архитектуры бизнеса
Октябрьские перебои с электроснабжением снова напомнили, что украинская энергосистема остается уязвимой. И дело не только в количестве доступной электроэнергии.
Энергосистема имеет несколько уровней: генерацию, передачу и распределение. Повреждения сетевой инфраструктуры могут ограничивать поставки даже тогда, когда определенные генерирующие мощности доступны.
Для бизнеса это означает, что стабильность электропитания не всегда можно предсказать только по общему состоянию производства электроэнергии.
Но есть еще один уровень зависимости — телекоммуникационный.
Современная компания может иметь резервное электропитание, однако ее операционные системы будут оставаться недоступными из-за проблем с интернетом.
В октябре 2026 года ограничения работы отдельных военных систем Starshield снова привлекли внимание к спутниковой связи. Важно различать военный Starshield и гражданский Starlink: проблемы одного сегмента не означают автоматического прекращения работы другого.
Однако для бизнеса здесь есть более широкий технологический урок.
Спутниковая связь уменьшает зависимость от наземных сетей, но не устраняет зависимость от поставщика услуги, его программного обеспечения, условий доступа и технических ограничений.
Поэтому даже резервный канал связи не стоит воспринимать как абсолютную гарантию. Настоящий вопрос заключается в том, может ли предприятие продолжить критические операции, когда привычный доступ к цифровым системам исчезает.
Самый опасный момент — не отключение, а возвращение систем к работе
Я считаю, что именно этот аспект недостаточно обсуждают в публичной дискуссии об устойчивости бизнеса.
Представим, что магазин продолжает принимать заказы во время отсутствия связи. Менеджеры записывают их локально, а склад выдает часть товаров по бумажным документам. Через три часа интернет восстанавливается.
Что происходит дальше?
CRM пытается синхронизировать новые заказы. Складская система передает информацию об отгрузке. Платежный сервис отправляет отложенные подтверждения. Интеграции повторяют запросы, не получившие ответа во время сбоя.
Если архитектура системы не предусматривает корректной обработки таких ситуаций, могут возникнуть дубликаты заказов, неправильные остатки или противоречивые статусы оплаты. Здесь стоит объяснить один технический принцип — идемпотентность.
В упрощенном виде он означает, что повторное выполнение одной и той же операции не должно создавать дополнительных нежелательных последствий.
Например, если платежный сервис дважды передал сообщение об успешной оплате, система не должна дважды формировать один заказ.
Для разработчиков это знакомая концепция. Но для владельца бизнеса она может быть значительно важнее, чем очередная функция автоматического формирования отчетов.
Так же важны очереди сообщений, локальное сохранение данных, контроль повторных операций и механизмы согласования информации между системами после восстановления связи. Эти инструменты не делают бизнес полностью независимым от инфраструктуры. Но они позволяют ограничить последствия ее отказа.
Почему автоматизация иногда увеличивает стоимость простоя
Обычно экономический эффект автоматизации оценивают через сэкономленные часы работы персонала, скорость обработки заказов и уменьшение операционных расходов. Однако в условиях нестабильной инфраструктуры к этой модели нужно добавить еще один показатель — стоимость восстановления после сбоя.
Предположим, предприятие автоматизировало складские операции и сократило время обработки одного заказа.
Это неоспоримое преимущество.
Но если после длительного отключения сотрудникам нужно вручную проверить сотни операций, исправить дубликаты и согласовать остатки, часть полученной экономии исчезает. Иногда предприятие даже не может точно определить, какие операции были выполнены, а какие только отправлены на выполнение.
Это особенно опасно для бизнеса с большим объемом транзакций: электронной коммерции, логистики, дистрибуции и розничной торговли.
Поэтому эффективность автоматизации стоит измерять не только в условиях стабильной работы. Нужно оценивать, как система ведет себя во время отключения, сколько времени требует восстановление и какую часть операций приходится проверять вручную.
В международной практике управления непрерывностью работы для этого используют два показателя.
RTO — целевое время восстановления системы после сбоя. RPO — допустимый объем потери данных, который обычно выражают через промежуток времени.
Но я бы добавил к управленческой оценке еще одну характеристику: время до восстановления достоверности операционных данных.
Ведь система может снова открываться через пять минут, но компания еще несколько часов не будет понимать, какие заказы действительно оплачены, отгружены или отменены. Для бизнеса это не менее важно, чем сам факт доступности сервера.
Бизнесу нужен режим ограниченной работоспособности
Есть понятие, которое, по моему мнению, стоит значительно активнее применять к украинским предприятиям, — graceful degradation.
Его можно перевести как контролируемое снижение функциональности.
Идея проста: когда часть системы выходит из строя, остальная часть не должна обязательно прекращать работу.
Например, интернет-магазин может временно отключить автоматическое резервирование товара, но продолжить принимать заявки с пометкой о необходимости подтверждения. Логистическая компания может потерять онлайн-обновление маршрутов, но сохранить доступ к последней проверенной версии графика доставок.
Розничная сеть может временно прекратить синхронизацию аналитики, но продолжить локальный учет операций, если это позволяют ее платежные и фискальные решения. Это не универсальные сценарии. Их нужно проектировать с учетом законодательства, безопасности данных и специфики каждого предприятия.
Однако сам принцип чрезвычайно важен. Не все функции бизнеса одинаково критичны.
Если временно недоступна маркетинговая аналитика, компания может продолжать продажи. Если недоступна система учета остатков, возможно, стоит ограничить часть операций, чтобы не продавать товар, которого нет.
Зрелая автоматизация должна уметь не только ускорять работу, но и безопасно замедлять ее.
Что я изменил бы в подходе к автоматизации украинских компаний
Начинал бы с аудита зависимостей.
Не с выбора новой CRM, ERP или ИИ-ассистента, а с простого вопроса: что произойдет с бизнесом, если завтра на шесть часов исчезнут электричество и интернет? Нужно пройти весь путь заказа — от обращения клиента до получения товара — и определить точки, где процесс может остановиться.
После этого стоит разделить системы по критичности. Не каждый сервис требует дорогостоящего резервирования. Но каждая критическая операция должна иметь понятный сценарий отказа и восстановления.
Далее — проверить интеграции.
Защищены ли они от повторного выполнения операций? Сохраняются ли сообщения при потере связи? Можно ли восстановить правильную последовательность событий? Существует ли журнал изменений, по которому можно проверить спорные транзакции?
И наконец — провести практическое тестирование.
Не презентацию для руководства, а реальное упражнение: на определенное время отключить тестовую среду от внешней связи и проверить, как система восстанавливается. Здесь могут появиться проблемы, которых не видно во время обычной работы. Именно такие проверки я считал бы важной частью любого серьезного проекта автоматизации.
Следующий этап цифровизации — не больше автоматизации, а лучше архитектура
Украинский бизнес уже продемонстрировал чрезвычайную способность адаптироваться. Компании переносили склады, перестраивали логистику, меняли поставщиков, переходили на удаленную работу и внедряли цифровые инструменты значительно быстрее, чем планировали ранее.
Но теперь, по моему мнению, пришло время перейти от быстрых решений к системному проектированию.
Автоматизация не должна превращать каждый процесс в часть одного большого механизма, который останавливается из-за неисправности отдельного компонента. Напротив, правильно построенная цифровая архитектура должна позволять локализовать ошибки, сохранять критические данные и восстанавливать работу постепенно.
Это особенно важно для Украины, где инфраструктурные риски уже стали частью повседневного управления бизнесом.
Мы не можем гарантировать, что электроэнергия никогда не исчезнет. Не можем гарантировать абсолютную доступность мобильной, проводной или спутниковой связи. Не можем полностью контролировать работу внешних облачных сервисов.
Но можем контролировать то, как собственные системы реагируют на их недоступность.
И именно здесь я вижу наибольший потенциал для развития украинской автоматизации. Не в количестве подключенных сервисов. Не в числе внедренных ИИ-инструментов. И даже не в том, сколько операций удалось выполнять без участия человека.
А в том, насколько предсказуемо компания работает, когда привычные условия исчезают.
Ибо настоящий результат автоматизации — не система, которая никогда не ошибается. Это бизнес, способный пережить ошибку, не превратив ее в катастрофу.
Николай Батюк – эксперт по цифровой трансформации бизнеса, автоматизации бизнес-процессов, CRM-системам и внедрению искусственного интеллекта.
ЧИТАЙТЕ В TELEGRAM
самое важное от «Слово и дело»