Разочаровывающий кризис-менеджмент на примере СДЭК

Или инструкция как НЕ надо поступать с пользователями в сложных ситуациях. Расскажу как компания могла, но не захотела выдавать посылки раньше 29-30 мая

Всем привет, я Алексей, последние 12 лет работаю в ИТ, руковожу компаниями по разработке веб-сервисов и мобильных приложений.

Сегодня напишу о масштабнейшем сбое СДЭК, восстановлю хронологию событий, расскажу почему главный провал СДЭК не в ИТ проблеме и поделюсь мыслями как намного раньше можно было начать выдавать посылки. Погнали!

Основной провал - клиентский сервис

За несколько дней реального ИТ коллапса нет ни одного эффективного антикризисного решения от менеджмента, pr, gr служб СДЭК.

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

Коммуникация с клиентами, которые больше всего пострадали от коллапса - оставляет желать лучшего. Главными источниками информации почему-то стали ПВЗ, которые зачастую являются франшизными.

Компания СДЭК НЕ:

- открыла горячую линию для разъяснения ситуации и поддержки особо тревожных пользователей;

- выпустила полноценный, всеобъемлющий пресс-релиз с описанием проблемы. Что можно было бы описать в пресс-релизе: шаги, которые предпринимает компания для решения ситуации; причины возникновения проблем (далекие от ИТ люди просто в панике); позицию компании по посылкам со скоропортящимися товарами; позицию компании по посылкам со срочными грузами (документы и прочее); разъяснение регулирования особо проблемных случаев и контактные линии для их фиксации, урегулирования.

- постаралась придумать экстренное, кривое, НО рабочее решение для посылок, находящихся в ПВЗ (тему раскрою ниже);

- выпускала полноценные, понятные, полные информационные релизы в социальных сетях, которые не были бы похожи на отписки;

- использовала GR от слова совсем.

Критикуешь - предлагай. Почему посылки можно (и нужно) было начать выдавать раньше

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

Первое что приходит в голову - это выдача заказов, уже находящихся в ПВЗ. Но как это можно сделать, если всё лежит и нет данных. Ответ простой и сложный одновременно - надо обратиться к историческим данным, хранящимся на стороне пользователей и которые невозможно скомпрометировать. Например, к письмам, которыми заботливо СДЭК сопровождает весь жизненный цикл покупки.

Если сбой произошел 26 мая утром, значит можно обслужить пользователей, у которых есть письмо о готовности к выдаче заказа. В этом письме указывается номер заказа (который есть на упаковке), отправитель, получатель, контактные данные ПВЗ.

Что необходимо сделать для выдачи заказа:

- Выделить категории посылок, которые стоит выдавать. Кажется, что это оплаченные посылки, лекарства, скоропорт.

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

- Сделать дополнительную юридическую обвязку выдачи. Случай экстраординарный, поэтому надо было удостовериться в соответсвии правовым нормам при выдаче. Дополнительно следовало отметить изменения условий договора, если они были. Смысл простой - каждый получатель получает товар, фиксирует это подписью, в случае, если он не оплатил, то компания может потребовать его оплатить (либо какие-то бомбические штрафы)

- Выдачу посылки надо зафиксировать. Для этого можно сделать множество решений, где у каждого ПВЗ будет логин+пароль (например), а далее заполнение анкеты в веб-интерфейсе или боте. Например, можно попросить обязательно сделать фото получателя с посылкой (думаю клиенты поняли бы и не противились). Таким образом мы бы имели базу отправлений, которые были выданы в критической ситуации.

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

Таким образом посылки можно было бы начать выдавать вечером 26 мая, либо утром 27 мая.

26 мая

Утром становится известно о техническом сбое в работе СДЭК. Компания выпускает первую коммуникацию. Перестают работать сервисы компании, сайт, мобильное приложение.

27 мая

Технический сбой продолжается. Выходит вторая коммуникация компании.

Хакерская группа head mare берет на себя ответственность за сбой в работе СДЭК. Прикладывая довольно убедительные скриншоты консоли управления виртуальными машинами и рассказывая о просто НЕВЕРОЯТНОМ раздолбайстве девопс/сис.админ команды. Утверждается, что команда делала полные бэкапы раз в 6 месяцев без использование инкрементных, дифференциальных, либо гибридных способов резервного копирования. Не говоря уже о дублировании резервных данных в сторонние нескомпрометированные места. Если верить скриншотам, то все виртуальные машины с данными были удалены.

28 мая

Выходит третья коммуникация компании. Третий день коллапса ИТ системы СДЭК. В коммуникации общие слова, описывающие ситуацию, при этом нет указания горячей линии, куда можно обратиться по острым вопросам или бота/поддержки, которая окажет любого рода помощь.

Дополнительная коммуникация со сроками восстановления частичной работоспособности.

29 мая

Дополнительные коммуникации и уведомление о старте выдачи отправлений.

30 мая

Компания начала выдавать посылки, которые уже находятся в ПВЗ.

Прозрачность, проактивность, смекалка и грамотное использование PR, GR позволили бы значительно снизить накал вокруг коллапса в СДЭК. Но по какой-то причине всё пошло как пошло.