Сколько стоит простой

Сколько стоит простой

Несколько лет назад у ИТ-директора состоялся разговор с генеральным директором Корпорации. Речь шла о необходимости закупки более производительного оборудования для централизованной системы, обслуживающей ключевые бизнес-процессы.

Существенная переработка бизнес-процессов значительно увеличила нагрузку на систему, и возникла глобальная просадка по производительности (специалисты называют это «деградацией сервиса»).

Ситуация была сложная, производительность системы упала на 30 %. Ничего необычного в этом нет. С новшествами так бывает. Увлеченные их достоинствами, специалисты не всегда могут сразу оценить возможные минусы, проблемы и побочные эффекты.

В данном случае отказываться от нововведения (а это был важный процесс, связанный с диспетчеризацией отгрузок) очень не хотелось. Поэтому ИТ-директор, как прилежный менеджер, к тому же не так давно пришедший в Корпорацию, пошел к начальству просить об увеличении ИТ-бюджета. Речь шла о сравнительно небольшой сумме, в 4 – 5 миллионов рублей на дополнительное оборудование для существующей серверной инфраструктуры.

В. В. Марков отреагировал неожиданно: «Стоимость часа простоя системы обходится Корпорации в 5 миллионов рублей (интересно, откуда он взял эту цифру? Потом посчитаем сами). Отказаться от доработки — значит лишить наших клиентов удобного и необходимого им сервиса. У компании проблемы, а ты ко мне приходишь за согласованиями. Посчитай сам: 1 – 2 часа простоя, и твое оборудование с лихвой окупится».

Очень своевременный и важный был разговор. Функциональным руководителям весьма полезно время от времени смотреть на ситуацию сверху или сбоку, задумываться о потребностях бизнеса и его приоритетах.

Кстати, а на самом деле — какие потери несет Корпорация от часового простоя ключевой бизнес-системы? Попробуем прикинуть «на пальцах».

Известно, что 95 % всей производимой продукции ТЕХНОНИКОЛЬ реализуется через централизованную систему «ОКС-Сбыт». Выручка компании за 2018 год составила 94 миллиарда рублей.

Остановка системы «ОКС-Сбыт» в то время приводила к полной остановке оприходования продукции на склад, отгрузки, выписки документов. Даже уже загруженные машины не могут покинуть территорию соответствующего завода.

Итак, фактор первый: остановка системы ведет к недополучению прибыли. Размер, видимо, пропорционален времени простоя. Конечно, все это условно, можно сказать, что неотгруженная продукция будет отгружена позже, и Корпорация не потеряет заказы.

Хотя это не совсем так. Строительные материалы требуются в определенном месте в определенное время. И если на объект вовремя не подвезли, к примеру, каменную вату, бригада будет простаивать. Клиент может развернуться и купить продукцию у другого производителя.

А потеря клиента — гораздо более серьезная проблема, чем потеря конкретного заказа. Еще аргумент «вприкуску»: в сезон график загруженности погрузочных эстакад и персонала таков, что мы никак не сможем найти 25‑й час в сутках, чтобы компенсировать потери. Фактор второй — доверие клиентов. Это самый сложный параметр для расчетов. Если упущенную выгоду от продаж худобедно можно посчитать, то лояльность и качество партнерских отношений — понятие «эфемерное», но не менее важное.

Выстраивание долгосрочных партнерских отношений с клиентами — одна из основных задач менеджеров Корпорации. Нестабильная работа системы может создать совсем не благоприятную ауру вокруг бренда и имиджа ТЕХНОНИКОЛЬ. И, конечно, нельзя не учитывать фактор корпоративных и имиджевых рисков при подобных авариях.

Третий фактор — штрафные санкции. Какие бы добрые и даже дружеские отношения ни связывали нас с клиентами, бизнес есть бизнес. Если клиент несет убытки, кто‑то их должен компенсировать.

В книге «Бремя сервиса? Время сервиса» мы уже рассказывали о том, что наши информационные системы в автоматическом режиме (!) генерируют претензии и налагают штрафы — на себя или на партнеров (в зависимости от того, чья эта зона ответственности). Также и от партнеров мы получаем подобные штрафы за невыполнение обязательств.

Не надо забывать еще и о важном для строительной отрасли факторе сезонности. Понятно, что в сезон, с апреля по октябрь, нагрузка на систему максимальная, и стоимость простоя в сезон совсем не равна стоимости простоя, к примеру, в декабре.

Выручка Компании распределяется по месяцам в течение года, примерно как показано на рисунке.

Расчет несложный. Клиенты, как правило, загружаются в рабочие дни, получается в среднем 22 дня в месяц. Отгрузки по всей огромной территории — от завода в Хабаровске до завода в Шотландии — мы ведем по 16 часов в сутки. Получается, что за месяц отгрузка производится в течение 352 часов (16×22).

Как видно из графика, в сезон продукции отгружается на 11 миллиардов рублей в месяц. Несложные вычисления показывают, что остановка отгрузок в сезон на 1 час обойдется в 30 миллионов рублей (!). А 5 миллионов, названные «с лету» генеральным директором Корпорации Владимиром Марковым, действительно цена часового простоя, но только в январе.

Это все без учета имиджевых потерь и штрафных санкций. Так что на обеспечении непрерывности бизнес-процессов, связанных с отгрузками, особо экономить не приходится — все быстро окупается.

Но вернемся к истокам: откуда берутся крайне дорогие простои системы? Что это за аварии, которые сложно спрогнозировать? Мы уже говорили о том, что сначала пришлось устранить технические факторы аварий:

• обеспечить стабильность сети передачи данных, надежность сетевого и серверного оборудования;

• настроить в автоматическом режиме процесс обновления операционных систем и рабочих станций;

• произвести резервирование систем.

И проблема была решена? Нет, конечно. Это был лишь первый этап, можно сказать, «разминка». Вскоре пришло понимание, что главным фактором простоев стали сами процессы внутри Корпорации — она развивалась слишком быстро.

Информационная система, включавшая в себя практически все жизненно важные процессы, росла итерационно и, мягко говоря, не всегда планово. Мы переживали всплески активностей, переписывали целые модули, оперативно встраивали новые подсистемы.

Бизнес очень быстро прогрессировал, требовал все больше изменений в системе, и не было времени остановиться и подумать над архитектурой системы. Строили из «подручных» материалов, зачастую «на коленке». Главное, что бизнес получал требуемые изменения в процессах. ИТ-команду чаще ругали, но иногда и хвалили.

А система постоянно «разбухала» и усложнялась. Вычисления и процессы начали дублироваться, регулярно стали возникать вопросы к целостности данных и к тому, где эти данные вводятся и кем проверяются на достоверность. Копились внутренние ошибки в системе. В ИТ-сообществе это принято называть «техническим долгом».

Что получилось в итоге? Огромная система с недостаточно документированными блоками, очень сложная в обслуживании. К тому же она «капризничала» и требовала постоянных остановок на профилактику. Если серверы не перегружали хотя бы раз в день, накопившиеся «паразитные» данные приводили к сильнейшему падению производительности уже к середине дня.

Любые изменения в системе представляли из себя сложную «операцию на работающем сердце». Небольшое изменение в зоне ответственности финансового блока могло привести к появлению ошибок в подсистеме отгрузки или в подсистеме документооборота.

Каждый релиз (а обновление системы велось тогда по релизам, раз в 1 – 1,5 месяца) вызывал жуткий негатив со стороны бизнеса и такие же страхи у ИТ-специалистов, так как никто не мог предсказать, к каким ошибкам приведут изменения в системе.

ИТ-система явно не успевала за изменениями, которые требовал бизнес. Чем больше вносилось изменений, тем сложнее становилась система и тем больше генерировала ошибок.

И, конечно, профилактические остановки, остановки на обновление системы, аварийные остановки, связанные с неожиданными ошибками и необходимостью их исправления, стали основным фактором, влияющим на доступность системы и, как следствие, на непрерывность отгрузок.

Самое печальное — остановки системы было практически невозможно прогнозировать. Менеджеры, управляющие отгрузками, не могли однозначно и достоверно сказать, когда система будет доступна, а когда возникнут проблемы. Что они могли ответить клиентам, если сами не имели информации?

Уставшие от частых проблем с информационной системой менеджеры уже не просили ИТ-специалистов сделать систему стабильной. Они слезно просили ответить, когда система восстановится после того или иного сбоя. Нередко ответ был: «А кто ж его знает?!»

Четко выстроенный процесс ритмичной погрузки автотранспорта натыкался на сложную информационную систему, которая сама начинала диктовать бизнесу: как работать, когда работать и сколько времени.

Казалось бы, подобные проблемы должны были раз и навсегда отбить у представителей бизнеса желание делать запросы на изменение системы. Но в Корпорации работают преимущественно оптимисты, так что количество запросов на изменение системы постоянно росло — в среднем на 10 – 15 % ежегодно.

ИТ-команде ничего не оставалось, как научиться справляться с этим валом запросов. Изменили процедуру доработки системы, упростили и автоматизировали ряд функций в процессах разработки.

Воодушевленные такими успехами, сообщили бизнес-заказчикам, что готовы выпускать доработки сразу после реализации, что теперь не надо ждать месяц до выхода очередного релиза и изменения можно вносить в систему хоть ежедневно. Шутка ли, большой шаг в ускорении разработки!

Ура? Доблестные ИТ-разработчики были уверены, что заказчики, конечно же, безумно обрадуются. Не тут‑то было. Первой решительно отказалась согласовывать новую схему финансовая служба. Аргумент был убийственный: «Сейчас мы разгребаем проблемы с обновлением системы раз в месяц, а вы хотите заставить нас делать это ежедневно? Ну уж дудки!».

За финансистами последовали менеджеры ОКСа, а потом и производственники. Заверения и клятвы ИТ-специалистов, что «все будет хорошо», не были приняты во внимание (с учетом накопленного опыта), так что быстрые изменения не прижились.

Может, оно и к лучшему.