Привет, меня зовут Надя, я продуктовый менеджер сервиса «Фейскит». Наша команда делает программу, которая помогает не терять шуруповерты, болгарки и пассатижи в суровой реальности стройки. Изначально мы задумывали продукт как простой и надежный способ учета инструментов и материалов. Но жизнь распорядилась иначе: за четыре года мы прошли путь от систематизации данных из Excel-таблиц до запроса на интеграцию с бухгалтерией. Рассказываю по порядку, как все было. 

Почему обычные сервисы для складского учета не подходят прорабам 

Если коротко: потому что на стройплощадке нет склада в привычном понимании. Вы не увидите здесь аккуратные стеллажи с маркировкой на каждой полке. Скорее это будет бытовка, где вперемешку лежат инструменты, материалы и спецодежда. 

История «Фейскита» началась не с мечты о великой инновации, а с конкретного запроса. Мы работали над продуктом «Синтека» — системой для автоматизации снабжения. Клиенты постоянно жаловались, что с товарно-материальными ценностями (ТМЦ) творится полный беспорядок на объектах.

Вот вы смотрите на новый жилой комплекс: красивый, современный, с панорамными окнами и подземной парковкой. А теперь представьте, сколько инструментов и материалов прошло через стройку. На каждой площадке находятся сотни единиц — от перфораторов до лазерных нивелиров. И часто никто не знает, где и что лежит. 

Генераторы исчезают как по волшебству, УШМ уходят в отпуск без возвращения, а бригадир часами бегает в поисках нужного ключа или сверла. При этом один инструмент стоит копейки, а другой обходится компании в десятки тысяч рублей. 

По нашим оценкам, на строительных объектах теряется от 10 до 15% инструментов за год. Они пропадают, ломаются или их крадут. Каждый потерянный перфоратор — это деньги, простои и крики вместо нормальной работы. Поэтому наши клиенты просили такое приложение, чтобы рабочие за минуту могли разобраться, где сейчас дрель, кто ее взял и когда вернет. Без всяких бумажек и сложных таблиц.

Фокус на реальных процессах в строительстве стал отправной точкой для проектирования архитектуры сервиса. Мы поняли: в центре внимания должны быть не склад и хранение сами по себе, а весь жизненный цикл ТМЦ. Нам нужно создать программу, которая проследит историю предмета — с момента доставки на площадку до списания. Эта смена оптики сформировала подход к разработке продукта.

Какие проблемы решила первая версия нашего сервиса 

Мы начали с простого и сделали MVP — минимально жизнеспособный продукт. Он закрывал три базовых вопроса в учете материальных ценностей на стройке: 

  • Где инструмент? Сначала каждому предмету присваивали уникальный номер, а потом перешли на QR-коды. Пользователь сканирует маркировку и видит: шлифмашинка на объекте, в ремонте, у бригадира или в пути на другой участок. 

  • В каком состоянии ТМЦ? Предмет может быть: «активен», «в ремонте», «списан» или «утерян». Нет ситуаций, когда человек рассчитывает на инструмент, а оказывается, что его вернули сломанным с другого объекта. Понятные статусы обеспечивают четкие действия и убирают лишнюю суету.

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

Первая MVP закрывала, прежде всего, боли бизнеса. Это и понятно — за подключение и внедрение сервиса платит компания. При этом нельзя проектировать продукт только под бизнес-требования. Если сотрудникам неудобно пользоваться системой, нужного результата не будет. И тут мы подошли к главному конфликту любого B2B-продукта. 

Что делать, если бизнесу нужен контроль, а пользователи не заказывали цифровизацию

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

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

Нет смартфона? → Добавили незарегистрированных пользователей. Мы называем их «мертвыми душам», прямо как у классика. 

В эпоху алгоритмов, чат-ботов и голосовых помощников многие строители пользуются кнопочными телефонами по разным причинам. Например, чтобы не разбить дорогой смартфон на тяжелой работе. Если нужно передать инструмент такому сотруднику, прораб создает в приложении аккаунт-заглушку и закидывает ТМЦ на «мертвую душу». Чтобы не забыть, что и кому отдал. Участие самой «души» при этом не требуется. 

Много кнопок? → Снабдили предметы, склады и сотрудников QR-кодами. Допустим, бригадир Петров хочет выдать рабочему Иванову сварочный аппарат. Петров сканирует смартфоном код на инструменте и личный код Иванова — одна операция и предмет передан в системе. Похожим образом работает перемещение между складами: каждой площадке можно присвоить свой QR. 

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

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

Как обратная связь от пользователей развивает продукт

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

Именно так произошло с функцией «Стоимость владения». В финансовом учете этим термином обозначают полную сумму затрат на покупку и обслуживание актива. В нашем случае — строительного инструмента. 

Компания может купить электрогенератор за 40 000 ₽, который пять лет проработает без ремонта. А может купить за 25 000 ₽, но потратить на обслуживание еще 30 000 ₽ за тот же период. По стоимости владения дешевый генератор окажется дороже. 

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

Как продукт вырос за рамки строительного бизнеса 

Время показало, что программа для наших любимых строителей подходит и другим компаниям, которые ведут учет ТМЦ. Сервис оброс функционалом, а кастомизация помогает адаптировать продукт под конкретные бизнесы. Поделюсь примерами. 

Кейс №1. Первым неожиданным клиентом стала клининговая компания. Пылесосы, моющие машины, швабры с датчиками влажности постоянно перемещаются с объекта на объект и часто теряются. «Где аппарат для мытья окон?» — «Он у Марии на пятом этаже». — «А почему не отметили выдачу со склада?». Типичный диалог в этой сфере. «Фейскит» помогает отслеживать инвентарь и закреплять ответственных. 

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

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

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

Почему технические задачи бывают проще аналитических 

Сейчас на повестке дня у нас интеграция с программами бухучета 1С. Это очень популярный запрос среди клиентов. На первый взгляд обычное дело: есть две системы, и нужно организовать передачу данных между ними. 

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

  • Бухгалтер работает с первичными документами — УПД, транспортной накладной, счет-фактурой. Принимать инструменты и материалы к учету он готов только по этим данным. 

  • Складу неважно, как предмет называется в 1С. Кладовщик хочет найти перфоратор и отдать рабочему. Некогда ждать, пока бухгалтер получит первичку через ЭДО и поставит инструмент на учет. А во многих компаниях электронный документооборот вообще не прижился, и УПД передают в бумажном виде, что еще дольше. 

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

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

Что мы поняли о проектировании B2B-сервисов для полевых сотрудников 

За несколько лет работы над продуктом для учета материальных ценностей мы сделали выводы, которыми хочу поделиться: 

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

  • Пользователям нельзя навязать систему. Даже если так распорядится строгий начальник. При проектировании B2B сервисов в равной степени учитывайте бизнес-требования и удобство для сотрудников. Только тогда программа станет естественной частью работы. 

  • Ищите закономерности в обратной связи от клиентов. Угодить всем и выполнить каждый запрос невозможно. Расставляйте приоритеты и дорабатывайте продукт по частым пожеланиям пользователей. 

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

Если интересно, как наши решения выглядят в реальном продукте, вот ссылка: «Фейскит».