В новом супермаркете только дали электричество. Я приехал настроить программное обеспечение, проверить рабочие места и обучить сотрудников.
Кассы заработали, магазин начал печатать ценники. Во время разговора с директором выяснилось, что официальное открытие назначено на следующее утро.
В торговом зале стояли коробки. Часть товара не была выложена, ценников не хватало. Формально моя работа была закончена. Но утром магазин бы не открылся.
Я остался помогать с ценниками и позвонил руководителю. Он приехал. Потом ему позвонил собственник сети, узнал, что происходит, и через сорок минут тоже был в магазине. Следом приехали еще несколько сотрудников офиса.
К четырем утра товар выложили, ценники расставили. В десять магазин открылся для покупателей.
Дату мы не сорвали. Но обеспечили это не процессом, а ручным вмешательством собственника, руководителей и людей, которые вообще не должны были ночью выкладывать товар.
После открытия собственник сказал мне:
«Если еще раз увидишь такое - звони сразу».
Для конкретной ситуации это было правильно. Но строить так работу растущей сети нельзя. Нельзя рассчитывать, что кто-то случайно заметит проблему, найдет нужный номер и ночью соберет сотрудников офиса.
Позже, уже в сети с большим потоком запусков, я выстраивал процесс по-другому.
Когда магазин открыт только формально
Перенос открытия в рознице стоит денег еще до того, как первый покупатель переступил порог.
К дате уже привязаны реклама, графики сотрудников, аренда и первая поставка. Если приехал фреш, задержка означает списания. Расходы уже начались, а выручки нет.
Поэтому установка была простой: магазин должен открыться в запланированную дату. Перенос допускался только при проблеме, которую невозможно безопасно обойти.
Но дата открытия для покупателей не означала, что проект закончен.
Мы разделили запуск на три контрольные точки.
За два-три дня до запуска проходило техническое открытие. Сотрудники прогоняли основные операции и проверяли, что магазин действительно может работать.
Затем наступала официальная дата - двери открывались для покупателей.
Проектная команда уходила позже, когда магазин переходил на обычное обслуживание и переставал требовать отдельного внимания.
Раньше этот период мог занимать больше месяца. Магазин уже работал, но инженеры продолжали держать его в голове. Руководитель проекта вручную собирал статусы. Директор магазина звонил знакомым сотрудникам, потому что так быстрее. Часть информации оставалась в переписке или у людей, которые участвовали в запуске.
Внешне объект был открыт. Внутри компании он еще оставался проектом.
Этот период удалось сократить с 30+ до 7 дней.
Проверка проходила до приезда покупателей
На техническом открытии мы не спрашивали руководителей функций, все ли у них готово. Магазин проходил реальные операции.
Проверяли основной и резервный интернет, Wi-Fi для ТСД, рабочие места, кассы, фискальный контур, эквайринг, доступы сотрудников, загрузку цен и работу с маркированным товаром.
Строительство и эксплуатация подтверждали готовность инженерных систем и торгового оборудования. Безопасность - видеонаблюдение, СКУД и пожарную сигнализацию. Логистика - первую поставку и готовность зоны приемки. Розница и HR - готовность персонала.
Ответственность была разделена по функциям, но за общий результат отвечал руководитель проекта открытия.
Руководитель функции мог честно сообщить, что провайдер не успевает подключить интернет или что товар задерживается. Руководитель проекта не мог ограничиться этой информацией. Он должен был собрать участников и найти вариант, при котором дата будет сохранена.
По результатам технического открытия формировалась матрица дефектов.
Если нет ни основного, ни резервного канала связи, не работает фискальный контур, не загружаются цены, отсутствует эквайринг или не работает пожарная сигнализация - это блокер. Открытие переносится либо требуется отдельное решение ответственного руководителя.
Если не работает одна касса из пяти, сбоит отдельный прайс-чекер или не настроен принтер в подсобке, магазин можно открывать. Дефект остается в работе, но у него должны быть владелец и срок.
Закрывать все замечания до последнего было бы неправильно. Тогда любая мелочь могла сорвать запуск. Но и открывать магазин с незакрытыми критичными проблемами нельзя: последствия пришлось бы разбирать уже при покупателях.
Итоговое решение о переносе принимал директор по развитию. Руководитель проекта приходил к нему с заполненным чек-листом, перечнем дефектов и вариантами решения.
Не с общей фразой «магазин не готов».
Что изменилось на комитетах
До изменения процесса встречи по открытиям часто превращались в последовательность объяснений.
Логистика сообщала, что не успевает привезти товар. HR - что не набраны сотрудники. ИТ - что провайдер задерживает подключение. Строительство - что не завершены отдельные работы.
Каждая функция описывала свой участок достаточно точно. Но ответа на вопрос, откроется ли магазин в установленную дату, не было.
CEO приходилось разбирать каждый риск отдельно: выяснять причины, соединять функции и искать решение уже на комитете.
Мы выделили в каждой функции человека, который отвечал именно за открытия. Не за логистику, персонал или ИТ вообще, а за готовность своей части к конкретной дате.
Если появлялся риск, ответственный сначала шел к руководителю проекта. Там фиксировались причина, варианты обхода, срок и владелец следующего действия. На комитет вопрос попадал только после этого.
Если решение существовало, докладывали, что произошло и что делаем. Если решения не было, директор по развитию принимал решение о переносе.
Мы изменили правила работы. Сообщить о проблеме стало недостаточно. Ответственный участвовал в ее решении, пока риск не был снят или официально принят директором по развитию.
Руководители перестали впервые узнавать о проблемах на самом комитете. CEO больше не тратил время на ручную маршрутизацию каждого вопроса.
Первая неделя дала неожиданный результат
С первого дня обращения нового магазина шли через стандартную техническую поддержку.
Мы не создавали отдельный телефонный справочник проектной команды. Заявки нового объекта получали повышенный приоритет, а L1 сразу передавала их проектным инженерам, L2 или соответствующему вендору.
Такой режим обычно сохранялся три дня. Если впереди были выходные, сопровождение продлевали, чтобы пройти первый период высокой нагрузки.
Раз в две недели я разбирал обращения от новых магазинов. Нужно было понять, какие ошибки проходят через техническое открытие и становятся видны уже после запуска.
Первая гипотеза была очевидной: проблема в оборудовании и настройках.
Но значительная часть заявок вообще не относилась к техническим сбоям.
Новый магазин писал в ИТ по вопросам поставки, правил работы, кассовой дисциплины и действий сотрудников в нестандартных ситуациях. Люди не понимали, к кому обращаться, и выбирали техподдержку как единственный известный вход.
Сначала каждому новому директору назначили куратора - опытного директора другого магазина. Это снизило часть нагрузки, но результат сильно зависел от занятости конкретного человека.
Я сопоставил темы обращений с программой обучения новых сотрудников.
Сотрудники проходили обучение, но программа была слабо связана с реальностью первых недель работы.
Их учили процессам, которые понадобятся позже. При этом типовые ситуации первого месяца, порядок действий при сбое и границы ответственности разных функций оставались неясными.
Программу пересобрали на основе реальных обращений.
В нее вошли первые операции нового магазина, наиболее частые вопросы, порядок действий, правила создания заявки и объяснение, куда обращаться по вопросам, не связанным с ИТ.
После этого количество обращений от новых объектов снизилось более чем на 85%.
Наращивать L1 или подключать больше инженеров не имело смысла. Большая часть нагрузки возникала не из-за технических сбоев, а из-за того, что сотрудникам не дали нужную информацию в нужный момент.
Остальные проблемы возвращались в процедуру подготовки магазина. Если один и тот же дефект повторялся на нескольких открытиях, мы меняли чек-лист, обучение или владельца процесса.
Почему каждый второй магазин рисковал остаться без интернета
Связь долго оставалась повторяющейся проблемой.
Почти каждый второй объект перед открытием рисковал остаться без проводного интернета. Команда устанавливала мобильный модем, магазин начинал работать, затем проводное подключение доделывали отдельно.
Формально ответственный был: связь находилась в зоне руководителя проекта открытия. Он закладывал расходы в бюджет и заключал договор с провайдером.
На практике подключение интернета было для него одной из большого количества задач. Он занимался конкретным объектом, а проблема была общей для всей сети.
Добавление новых проверок не помогло бы. Руководитель проекта и так знал, что интернет нужен к открытию.
Я передал этот контур отдельному менеджеру внутри ИТ. Он занимался не только новыми магазинами. В его зоне ответственности находились действующие договоры со всеми провайдерами, текущие вопросы по связи и подключения новых объектов.
Менеджер заранее получал реестр планируемых открытий и вел подключение от появления адреса в плане, а не за несколько дней до запуска.
Провайдеры по-прежнему могли сдвигать сроки, а незавершенные строительные работы - мешать подключению. Поэтому резервный LTE остался в комплекте.
Но мобильный модем снова стал резервом, а не обычным способом компенсировать позднее подключение.
Проблема решилась не еще одной галочкой в чек-листе. Мы перенесли ответственность от человека, который открывал один конкретный магазин, к человеку, который постоянно управлял связью всей сети.
Когда проект можно было закрывать
Полностью закрывать все дефекты до передачи магазина не требовалось. Критичные должны были быть устранены. Остальные могли остаться в работе, если зафиксированы владелец и срок.
Второй критерий - количество обращений. Пока новый магазин создавал заметно больше заявок, чем обычная точка сети, проектная команда продолжала сопровождение.
Третий - готовность стандартной поддержки. В Service Desk передавались исполнительная документация, паспорта оборудования, схемы портов, фотографии коммутационного шкафа и известные ограничения.
Магазин может быть подключен, акты подписаны, а информация остается у инженера, который участвовал в запуске. При первом инциденте сотрудники поддержки звонят ему напрямую, потому что больше никто не знает, как собран объект.
Так появляется параллельная система поддержки. Заявка зарегистрирована в Service Desk, но реально решается через личные сообщения и звонки.
Мы закрывали проект только после того, как обычная поддержка могла принять магазин без постоянного обращения к проектной команде.
Техническое открытие и первые дни сопровождения требовали дополнительных ресурсов. Проектные инженеры, L2 и вендоры должны были быть доступны в период запуска. Руководителю проекта приходилось чаще собирать статусы и контролировать отклонения.
Чек-лист тоже не защищал от формального подхода. Можно подписать блок, не проверив его полностью. Можно оставить допустимый дефект без владельца. Можно продолжить отвечать директору магазина напрямую, потому что так быстрее.
Поэтому мы регулярно возвращались к обращениям и отклонениям. Без этого любая процедура со временем превращается в заполнение таблиц.
На выстроенном процессе сеть могла открывать до 15 объектов в день. Переносов по причине неготовности ИТ-функции не было. ИТ-затраты на открытие одного объекта снизились на 65%.
Но для оценки качества запуска я использовал два показателя: сколько дней магазин остается на отдельном сопровождении и насколько его поток обращений отличается от обычной точки сети.
Период ответственности проектной команды сократился с 30+ до 7 дней. После изменения программы обучения количество обращений новых объектов снизилось более чем на 85%.
Мы перестали считать проект закрытым в день официального открытия. Он закрывался только тогда, когда обычная поддержка принимала магазин без прямых звонков проектным инженерам.