160+ магазинов и маркетплейсы на 15 лицензиях: кейс O’HARA
Почему первое внедрение трекера провалилось и что изменил переход на платный тариф
В этом кейсе интересна не столько итоговая схема работы, сколько путь к ней. Кайтен появился в компании дважды: первый раз — как эксперимент, о котором через полгода все забыли, второй — как ответ на конкретную проблему. Разница между двумя заходами объясняет, почему одни внедрения приживаются, а другие остаются в списке «мы это пробовали».
Как устроена работа сети сегодня, рассказал Константин Гримашевич, заместитель руководителя отдела аналитики O’HARA.
О компании
O’HARA больше 20 лет продает верхнюю одежду — пуховики, куртки, дубленки — и сопутствующие аксессуары. Сеть насчитывает свыше 160 магазинов по всей стране, к этому добавились продажи на Wildberries и Ozon.
Задача отдела аналитики — считать: какой объем товара закупить, как распределить его по торговым точкам и как оценить эффективность каждой из них. Плюс разработка отчетности: коллеги из других отделов приходят с запросами, чего им не хватает в BI-системе, а аналитики проектируют и делают.
Почему мессенджеры перестали работать
Первое время схемы «задачи в чат, документы на почту» хватало. Проблемы начались, когда выросло количество проектов:
- сообщения в чатах быстро уходили вниз, их перекрывали новые обсуждения;
- назначить ответственного было негде;
- восстановить историю обсуждений спустя время становилось почти невозможно.
Острее всего это ощущалось в работе с аутсорсом. Задачи регулярно терялись между чатами, а доказать потом что-либо было сложно: договоренность есть, но она растворена в переписке вперемешку с двадцатью другими темами.
Первый заход: инструмент есть, но им никто не пользуется
Больше четырех лет назад HR-руководитель компании принесла Кайтен — не через маркетинг и не по итогам сравнения сервисов, а под конкретную задачу. Компания только начинала заходить на маркетплейсы, и был открытый вопрос, как всем этим управлять.
Полноценного внедрения тогда не случилось. Система была бесплатной, и каждый использовал ее так, как считал удобным: кто-то заводил карточки, кто-то продолжал писать в мессенджеры. Через какое-то время большая часть команды перестала туда заходить — не было ни такого объема задач, ни необходимости держать все процессы в одном месте.
Инструмент без владельца процесса превращается в еще один необязательный канал — и проигрывает мессенджерам, потому что в мессенджерах уже все. Пока у команды нет проблемы, которую трекер закрывает лучше чата, он остается вкладкой, которую не открывают.
Второй заход: та же система, другой запрос
Через несколько лет тема маркетплейсов снова стала приоритетной. Объем задач вырос: больше заказов, больше подрядчиков, больше информации, которую нужно контролировать. На очередном совещании кто-то из сотрудников вспомнил: «У нас же есть Кайтен».
Вернуться сразу не получилось — аккаунт оказался привязан к почте бывшего сотрудника. Пришлось восстанавливать доступы, переоформлять аккаунт и фактически запускать систему заново.
Но разница с первым разом была принципиальной. В компании внедряли не новый сервис, а решение под сформулированную проблему: нужно видеть все задачи, ответственных и статусы работы в одном месте.
Почему в 2022 году не стали искать замену
Когда сервис стал платным, Константин потратил несколько недель на целенаправленные поиски альтернативы: прошелся по российским решениям, вспомнил опыт работы с Trello, который до этого был главным ориентиром.
Заменить оказалось не так просто. У части сервисов интерфейс был перегружен: при первом знакомстве система сразу вываливала десятки возможностей — спринты, интеграции, автоматизации, настройки для разработчиков. Большинству команд на старте это не нужно.
В итоге компания осталась на Кайтене. Начать можно было с базовой доски — несколько колонок и карточки, — а разбираться со сложными функциями по мере необходимости. Не понадобилось ни отдельного проекта по внедрению, ни длинных регламентов, ни обучения: сотрудники просто заходили и начинали работать.
Неожиданный эффект дал сам переход на платный тариф. Пока сервис был бесплатным, он воспринимался как временное решение. Как только за него начали платить, стало понятно, что процессы пора выстраивать по-настоящему.
Как устроена работа сегодня
Работа команды организована по трем направлениям: аналитическая разработка, дизайн и маркетплейсы. Каждое живет в своем пространстве, и каждая команда постепенно адаптировала его под себя.
Аналитическая разработка
Сюда попадают все запросы на аналитику от коллег и руководителей других подразделений: кому-то нужен новый показатель в BI-системе, кому-то дополнительный отчет под конкретную задачу или другой срез данных.
Каждый запрос оформляется отдельной карточкой: постановщик задачи, описание, цель, сроки и вся дальнейшая коммуникация — комментарии, правки, решения. Метки помогают фильтровать задачи между собой.
Карточка проходит четыре этапа: «Очередь» → «В работе» → «Тестирование» → «Готово». Сначала она попадает в общую очередь, откуда аналитик берет ее в работу. После выполнения задача уходит на тестирование — заказчик проверяет результат и либо принимает его, либо возвращает карточку с конкретными замечаниями. В «Готово» она попадает только после согласования.
Этап тестирования здесь стоит отдельного внимания. Он превращает приемку в такой же видимый статус, как и остальные: пока заказчик не подтвердил результат, задача не закрыта, а замечания фиксируются в карточке, а не в устном «тут надо переделать».
Дизайн
Дизайнеры работают в отдельном пространстве по той же логике, но со своими процессами. Команда выстроила систему под себя самостоятельно, без участия аналитики.
Для крупных задач дизайнеры используют чек-листы внутри карточек. Это помогает декомпозировать работу на этапы: подготовка материалов, правки, согласования, публикация и другие мелкие шаги, которые легко упустить.
За счет этого большая задача становится понятной для каждого сотрудника: видно, что уже сделано, где работа остановилась и какой следующий шаг нужен команде.
Рядом — доска с полезными материалами. По сути это база знаний, откуда сотрудники берут информацию и доступы для работы.
Сайт
Параллельно в компании начали координировать часть задач по сайту O’HARA. В основном это контент и обновления: изменения карточек товаров, правки информации и задачи, которые требуют согласования между несколькими людьми.
Маркетплейсы
Самое нагруженное пространство. Принцип жесткий: одна карточка в Кайтене равна одной карточке товара на Wildberries или Ozon.
Команда работает удаленно, поэтому в ходу таймеры. Дедлайны на маркетплейсах критичны: пропустил окно на размещение или обновление карточки товара — потерял позицию. Внутри пространства сотрудники двигают карточки по статусам и обсуждают задачи, здесь же ведут инвентаризацию, работают с возвратами, публикуют отчеты и хранят инструкции.
К этому же пространству подключили подрядчиков, которые помогают с маркетплейсами. С аутсорсом все получилось быстрее, чем ожидали: людей поставили перед фактом — теперь работаем здесь, — и они согласились.
Как команда уместилась в 15 лицензий
Компания работает на 15 лицензиях и признает, что их не хватает. Переходить на следующий тарифный порог пока не стали: он ощутимо дороже, а платить за функции, которые не нужны, не хочется. Текущий набор возможностей закрывает потребности команды.
Часть нагрузки помогают снять гостевые пользователи. Тем, кому нужно только следить за статусами карточек и оставлять комментарии, полная лицензия не требуется — для части команды и подрядчиков этого достаточно.
Что изменилось
Главный результат простой: задачи перестали теряться. Раньше именно из-за этого возникала большая часть хаоса — работа шла в чатах, и было сложно понять, кто за что отвечает и что вообще обсуждали раньше.
Но показательнее другое. Команды сами не хотят возвращаться к мессенджерам и почте — а это надежнее любых регламентов. Не нужно искать задачи в потоке сообщений, вспоминать, где обсуждали правки, и тратить часы на восстановление контекста.
Для команд, которые сейчас выбирают трекер, вывод из кейса такой: сравнение функций решает меньше, чем ответ на вопрос, чью боль система закрывает в первую неделю. O’HARA обошлась без проекта внедрения именно потому, что к моменту второго запуска у нее уже была эта боль — и было понятно, кто именно от нее страдает.
