Застройщик, УК и житель — реально ли их подружить? У нас пока не вышло

Застройщик хотел как лучше: сделать работу УК прозрачной для жильцов с помощью IT-инструмента. Но благие намерения обернулись закрытием пилотного проекта. Делюсь выводами.

Привет! Меня зовут Андрей Никифоров, я работаю в Wave Service — это система для обслуживания коммерческой недвижимости на базе QR-кодов.

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

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

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

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

Работа с застройщиками для нас была в новинку. В основном мы работаем в сегменте управляющих компаний и АХО различных организациий (производственные площадки, университеты, офисы).

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

А вот и мы слева направо, наши цели, задачи и большие надежды на пилот:

Мы видели в этом проекте возможность не только опробовать наш новый (на тот момент) модуль для автоматизации обходов, но и получить ценную обратную связь от застройщика и сотрудников УК.

Да и сама идея прозрачности работы УК нас вдохновила. Думаю, вы тут со мной согласитесь — живя в МКД не всегда понимаешь, чем занимается УК.

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

Сотрудники УК выступили конечными пользователями внедряемого продукта.

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

В этом кейсе тоже шли по протоптанной тропинке.

По заранее настроенному расписанию исполнитель получает уведомление из системы о начале обхода. Вручную ничего оформлять и запоминать не надо, достаточно один раз настроить. Если всё же нужен спонтанный обход — такая возможность тоже есть в системе.

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

Если в ходе обхода исполнитель выявляет проблему, например, что-то сломалось или после уборки остался мусор, в приложении автоматически создаётся заявка на её устранение. Для этого мы заранее настраиваем диспетчеризацию заявки.

Например, Иван Иванович ответственен за кондиционеры. На обходе выяснили, что кондиционер не холодит, отметили в чек-листе. Система отправила Ивану Ивановичу автоматическую заявку о проблеме.

После завершения обхода все данные попадают в систему.

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

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

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

А вот что пошло не так — рассказываю ниже.

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

Получается, Wave Service пригласили в команду, где уже были свои звёзды автоматизации. Сотрудников УК нужно переучивать, а тут в игру вступает привычка и скептическое отношение — а зачем нам что-то ещё?

Здесь нам всё же повезло, потому что девелопер успокоил и вдохновил УК на тестовый заход. Пилоту — быть, но мы в этот момент уже напряглись.

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

Выглядело это так: исполнитель приходит в 8-этажный дом, а в мобильном приложении указано 14 этажей. Были и несостыковки в текстах: обход подразумевает осмотр лифтовой зоны, а в приложении отражаются тексты от межквартирного коридора.

Из-за этого нам пришлось полностью всё перенастраивать, а это ещё 2-3 дня работы и оттягивания запуска. Пока мы работали, исполнители — ждали, а их скептический настрой к внедрению только усиливался.

Суперсила Wave Service — в QR-кодах. Они выступают основным каналом связи с нашим Service desk. Поэтому параллельно с настройкой мы разместили в корпусах объекта QR-коды по установленным зонам: лестницы, этажи, холлы и т.п.

Настройка — готова. QR-коды — на местах. Инструктаж — проведён. Что же, пришло время запускаться.

И-и-и… На первом же обходе выясняется, что стабильный интернет есть не во всех подъездах — это стало полной неожиданностью для всех участников пилота.

Оказывается, даже в новостройках всё ещё можно столкнуться с такими трудностями. А Wave Service нужен выход в интернет, так как это многопользовательская онлайн-система.

Когда мы выяснили о проблемах с интернетом, перед нами встал выбор: останавливать всё, и выходить из пилота, или пойти навстречу и рискнуть, взявшись за быстрые доработки.

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

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

В УК есть менеджер по клинингу, который фиксирует результаты проделанной уборщиками работы. Для этого он обходит здание, делает фотографии, отвечает на вопросы чек-листа.

В зонах без интернета менеджер делал несколько фотографии, затем выгружал их в приложение при появлении связи. Так продолжалось 2 недели, пока мы разрабатывали решение.

Пока временное решение как-то работало, мы писали офлайн-режим. Логика такая: данные хранятся в приложении на телефоне и выгружаются в систему, когда появляется доступ к интернету.

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

Если с клининговыми обходами всё было относительно ясно, то при выходе технических специалистов объём работ значительно увеличился: требовалась тщательная фотофиксация и детальная проверка всех зданий.

Наступает день Х.

Герой нашей истории выходит на обход парадной в 20-этажном здании. В чек-листе не менее 5 пунктов на каждый этаж с обязательной фотофиксацией. Итого: 100 фотографий.

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

Недовольство, разочарование, злость — и это я ещё мягко описал состояние сотрудника УК. Спорить с этим не буду, ситуация неприятная. По-человечески я прекрасно понимаю эти чувства.

Этот случай стал решающим: УК отказалась от дальнейшего использования системы, даже несмотря на усилия застройщика продолжить пилот.

Как я писал ранее, УК уже использовала решения для автоматизации, и внедрение новой системы не вызывало у сотрудников особого энтузиазма. Поэтому первая же серьёзная проблема стала поводом для прекращения пилота.

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

Если взглянуть на цели пилота, то мы даже неплохо справились.

Выяснили, что обходы — это востребованный модуль. Нашли слабые места, набили шишки и научились более детально сверять информацию, чтобы не переделывать работу по два раза.

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

По плану было так: любой жилец может зайти в личный кабинет и открыть отчёт, в котором видно всю работу УК. Там наглядно показывалось бы, как проводились обходы, какие проблемы отмечали исполнители, и как это всё исправляли.

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

Когда эмоции после пилота улеглись, я всё равно обратился к застройщику за обратной связью, и вот какие выводы удалось узнать:

В то время как разработчики и девелоперы активно внедряют автоматизацию, управляющие компании борются за то, чтобы остаться на плаву. Ограниченные бюджеты не оставляют пространства для «новшеств». Проще говоря, умные дома не заложены в стандартных тарифах — за технологии нужно доплачивать.

Задача донести ценность таких решений до жильцов ложится на плечи сотрудников УК. Возникает замкнутый круг: как объяснить «зачем», если они сами не всегда понимают?

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

Если бы меня попросили сделать из этого кейса инфографику, я бы составил вот такой жилищный треугольник:

Конечно, утверждать, что ситуация по рынку обстоит примерно так и никак иначе, когда у нашей команды мало опыта в этой нише, было бы неразумно. Но у меня есть подозрения, что всё же это не случайность, а закономерность — знаю, что и коллеги сталкиваются с подобными проблемами.

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

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

И у линейного персонала тоже не хватает знаний и навыков в использовании современных технологий. Как правило, сотрудники не осваивают что-то сверх чатов в привычных мессенджерах. А ещё у многих есть страх изучать что-то сложное и непонятное — то, что на деле, не сложнее почты.

Здесь можно понять: невысокие заработные платы и большая нагрузка не создадут благоприятную почву для обучения.

Считаю, что нам, разработчикам, нужно продолжать доносить в массы, что всё это доступнее, чем кажется. Мы все не так часто, как хотелось бы, делимся образовательным контентом.

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

В большинстве случаев управляющие считают, что абсолютно все системы автоматизации — это, по классике, очень дорого. Хотя на самом деле это далеко не так, и об этом тоже нужно чаще рассказывать.

Буду ждать ваших комментариев — здесь или в Telegram. Поделитесь вашим мнением о жилищном треугольнике, и о том, как из него выпутаться без потери для всех участников.