Работа современной компании сильно зависит от информационных систем, которые помогают автоматизировать, а следовательно, упростить и ускорить бизнес-процессы. Однако есть и существенный нюанс: стоит такой системе по какой-то причине выйти из строя, и всё остановится. Важно знать цену остановки — это поможет взвешенно принимать решения о модернизации системы, анализировать возможные варианты оптимизации и разработать эффективные «аварийные сценарии».
Вот живой пример из практики ТЕХНОНИКОЛЬ. Несколько лет назад у IT-директора состоялся разговор с генеральным директором Корпорации. Речь шла о необходимости закупки более производительного оборудования для централизованной системы, обслуживающей ключевые бизнес-процессы. Существенная переработка бизнес-процессов значительно увеличила нагрузку на систему, и возникла глобальная просадка по производительности (специалисты называют это «деградацией сервиса»).
Отказываться от нововведения (а это был важный процесс, связанный с диспетчеризацией отгрузок) очень не хотелось. Речь шла о сравнительно небольшой сумме в 4–5 миллионов рублей на дополнительное оборудование для существующей серверной инфраструктуры.
«Час простоя системы обходится Корпорации в 5 млн рублей. Отказаться от доработки — значит лишить наших клиентов удобного и необходимого им сервиса. У компании проблемы, а ты приходишь ко мне за согласованиями. Посчитай сам: 1–2 часа простоя, и твоё оборудование с лихвой окупится», — так ответил генеральный директор ТЕХНОНИКОЛЬ Владимир Марков.
Деньги счёт любят
Какие потери несёт Корпорация от часового простоя ключевой бизнес-системы? 95% всей производимой продукции ТЕХНОНИКОЛЬ реализуется через централизованную систему «ОКС-Сбыт». Остановка системы «ОКС-Сбыт» в то время приводила к полной остановке оприходования продукции на склад, отгрузки, выписки документов. Даже уже загруженные машины не могут покинуть территорию соответствующего завода.
Итак, фактор первый: остановка системы ведёт к недополучению прибыли пропорционально времени простоя.
Фактор второй — доверие клиентов. Это самый сложный параметр для расчётов. Выстраивание долгосрочных партнёрских отношений с клиентами — одна из основных задач менеджеров Корпорации. Нельзя не учитывать фактор корпоративных и имиджевых рисков при подобных авариях.
Третий фактор — штрафные санкции. Какие бы добрые отношения ни связывали нас с клиентами, бизнес есть бизнес. От партнёров компания получает штрафы за невыполнение обязательств.
Не надо забывать ещё и о важном для строительной отрасли факторе сезонности. В сезон, с апреля по октябрь, нагрузка на систему максимальная, и стоимость простоя в сезон совсем не равна стоимости простоя, к примеру, в декабре. Клиенты, как правило, загружаются в рабочие дни, получается в среднем 22 дня в месяц. Отгрузки по всей огромной территории — от завода в Хабаровске до завода в Шотландии — мы ведём по 16 часов в сутки. Получается, что за месяц отгрузка производится в течение 352 часов (16 × 22). В сезон продукции отгружается на 11 миллиардов рублей в месяц. Несложные вычисления показывают, что остановка отгрузок в сезон на 1 час обойдётся в 30 миллионов рублей. 5 миллионов, о которых говорил Владимир Марков, составляют цену часового простоя, но только в январе. Это всё без учёта имиджевых потерь и штрафных санкций. Так что на обеспечении непрерывности бизнес-процессов, связанных с отгрузками, экономить точно не нужно — всё быстро окупается.
Откуда берутся крайне дорогие простои системы?
Что это за аварии, которые сложно спрогнозировать? В первую очередь необходимо устранить, что и было сделано, технические факторы аварий:
- обеспечить стабильность сети передачи данных, надёжность сетевого и серверного оборудования;
- настроить в автоматическом режиме процесс обновления операционных систем и рабочих станций;
- произвести резервирование систем.
Далее главный фактор простоев — процессы внутри Корпорации: она развивалась слишком быстро. Информационная система, включавшая в себя практически все жизненно важные процессы, росла итерационно и не всегда по плану. Бизнес очень быстро прогрессировал, требовал всё больше изменений в системе, и не было времени остановиться и подумать над архитектурой системы. А система постоянно «разбухала» и усложнялась. Копились внутренние ошибки в системе. В IT-сообществе это принято называть «техническим долгом». Что получилось в итоге? Огромная система с недостаточно документированными блоками очень сложна в обслуживании.
Каждый релиз (а обновление системы велось тогда по релизам, раз в 1–1,5 месяца) вызывал негатив со стороны бизнеса и такие же страхи у IT-специалистов, так как никто не мог предсказать, к каким ошибкам приведут изменения в системе. Чётко выстроенный процесс ритмичной погрузки автотранспорта натыкался на сложную информационную систему, которая сама начинала диктовать бизнесу, как работать, когда и сколько времени.
IT-команде ничего не оставалось, как изменить процедуру доработки системы, упростить и автоматизировать ряд функций в процессах разработки. IT-специалисты сообщили бизнес-заказчикам, что готовы выпускать доработки сразу после реализации, что теперь не надо ждать месяц до выхода очередного релиза и изменения можно вносить в систему хоть ежедневно. Однако первой решительно отказалась согласовывать новую схему финансовая служба. За финансистами последовали менеджеры ОКСа, а потом и производственники. Так что быстрым изменениям не суждено было прижиться.