Как разработать мобильное приложение для ТСД и запустить его на 50 фабриках

Меня зовут Андрей Акулов, я руководитель компании «Вертер. Сенсорные технологии». Мы разрабатываем мобильные решения для складской и производственной логистики.

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

На тот момент оказалось, что на рынке нет мобильных решений, которые могли бы поддерживать маркировку для ТСД. Кроме этого, и фирма «1С» на тот момент ни в одном из типовых решений поддержку не реализовала, поддержка появилась только в октябре 2019 года.

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

Здесь показан пример одной из самых первых версий нашего решения. Его главной функцией было – собрать короб с определенным составом различных коробок обуви.

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

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

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

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

Каждая коробка имеет уникальную пару обуви, сканируется штрих-код, и партия идет дальше.

Чтобы бизнес мог работать на ТСД, необходимо автоматизировать три элемента:

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

• Визуальное сообщение пользователю о том, что произошла какая-то ошибка.

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

Учитывайте, что эти вопросы приходится решать.

А это уже сборка коробов с комплектами одежды на одной из наших фабрик – у нас сорок таких предприятий.

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

Дальше это начинает расходиться по складам и предприятиям, и учитывать все это - очень трудоемкий процесс.

Обратите внимание, какую реакцию выдает ТСД на сканирование.

Мелодичный звук значит, что все хорошо. А если бы все было плохо, то был бы резкий крякающий звук «Error».

И если такой звук возникает, то следующим возникает описание ошибки.

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

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

Чтобы реализовать такое мобильное приложение, мы сначала просто научились сканировать строку, а потом решили главные проблемы функциональности и смогли вытаскивать информацию по этой строке из самого ТСД.

Таким образом перед нами встает три проблемы:

• Проблема создания продукта

• Проблема масштабирования

• Проблема экономики продукта

Проблема создания продукта

Чтобы создать продукт, необходимы следующие составляющие:

• Идея и понимание проблемы клиента. Не собственное представление о том, что мы хотим сделать, а именно реальная проблема клиента. У нас этой проблемой была работа с маркировкой. На рынке для этой проблемы не было решения.

• Пилотный проект. Нельзя работать «в космос», отрабатывать разные технологии впустую – нужно обязательно понимать, как мы будем их пилотировать. Забегая вперед, скажу, что у нас уходит 10 недель на то, чтобы от идеи реализовать проект в готовом прототипе для коммерческого использования. Внутри этих 10 недель 6 недель уходят на разработку и 4 оставшихся уходят на пилотирование на реальном предприятии.

• Команда. Компания должна быть готова вместе с вами экспериментировать и давать обратную связь, потому что мы, ИТ-шники, очень любим придумывать функции, которые в реальности клиентам не нужны. Нужно постоянно проверять наши идеи. Все это – командная работа. Один человек не может создать продукт. Он сможет создать прототип, но не сможет масштабировать его дальше. Нужно видение, куда мы хотим двигаться. Нужен тот, кто будет реализовывать эту функциональность в коде. И нужен тот, кто будет это все продавать. В одном человеке, каким бы он ни был гениальным, соединить все эти три качества практически невозможно.

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

Какие этапы создания продукта?

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

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

• Есть три варианта решения этой проблемы – купить, создать или стать партнером. Мы выбрали вариант создания решения.

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

• И, конечно же, нужен пилот.

Это – четыре необходимых условия для того, чтобы в принципе войти в этот рынок.

В сентябре 2019 года, когда мы вошли в этот проект, у нас было просто желание сделать этот продукт (что тоже очень важно). Но сейчас, мысленно возвращаясь в то время, я понимаю, что на первое место нужно ставить планирование и вопрос «Зачем вообще входить на этот рынок?», потому что не все так радужно, как выглядит.

Архитектура нашего решения состоит из 3-х ключевых элементов:

• Мобильное приложение на самом устройстве. Это не мобильный клиент, не мобильный клиент с автономным режимом, а именно мобильное приложение;

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

• На учетной системе мы разворачиваем специальные АРМ-ы, которые собираем в отдельные расширения.

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

• Зеленый блок – это мобильное приложение,

• Желтый блок сверху – это АРМ-ы,

• А серые блоки – это некие базы, в которых сосредоточена функциональность, связанная с маркировкой и с учетом каждого кода маркировки.

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

На слайде пример автоматизированного рабочего места.

• Слева – интерфейс, который мы поднимаем на мобильном устройстве,

• Справа – интерфейс, который мы вешаем в рабочую учетную базу.

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

У нас есть три точки зарабатывания денег, это:

• Само мобильное приложение, т.е. мы лицензируем каждое устройство.

• Центральная база, деятельность, которая координирует эту деятельность и обеспечивает транспорт данных между учетной системой и ТСД.

• АРМ, который мы делаем для учетной системы.

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

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

В этом АРМ ключевая мысль – это наличие индикаторов. Обратите внимание: здесь пять индикаторов, каждый из них отвечает за некую информацию.

• Первый индикатор отвечает за то, передана ли информация на терминал сбора данных.

• Второй индикатор отвечает за то, прошло ли сканированиена этом ТСД.

• Третий – получены ли данные из личного кабинета «Честного знака».

• Четвертый – переданы ли данные в 1С

• Пятый – отправлены ли данные в «Честный знак».

Внизу зеленым цветом помечаются артикулы, которые приняты верно.

С помощью таких АРМ-ов мы организовываем всю работу наших клиентов. Это очень удобно. Вы сажаете за такой АРМ начальника склада или кладовщика, и они всегда понимают:

• что они отправили на ТСД;

• что им еще нужно отправить;

• что они уже проверили и могут дальше с этим работать.

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

Чтобы мы могли разработать решение за 10 недель, нужно понимать по какой проектной технологии мы будем это делать. Мы не пишем ТЗ, вместо ТЗ мы используем проектный чат.

• Слева у нас проекты, которые находятся под нашим управлением.

• В каждом проекте существует некая группа вопросов.

• Внутри каждой группы вопросов соответствующие темы, которые ведутся по проекту.

• Внутри каждой темы идет общение.

В проектном чате сидят одновременно и наши сотрудники, и представители заказчика: руководство, линейный персонал, в том числе и средний персонал, который участвует.

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

На слайде приведен пример – выкладывается некий скрин, задается какой-то вопрос, комментарий от пользователя.

Скорость реакции на какое-то изменение возрастает в разы. Это и позволяет нам делать решения за 10 недель.

Еще один элемент – контроль проекта.

Мы выработали систему, которая называется «статус проекта». Она построена по следующему принципу:

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

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

• решить проблему с электронной структурой изделия, чтобы материалы двигались и НСИ была нормализована;

• разобраться с рабочими центрами и т.д.

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

• Пустой кружок означает, что мы планируем;

• Черный кружок означает, что данная задача реализована, и цель уже на какой-то процент закрыта.

Теперь переходим в правую часть, где у нас появляется календарь. Мы месяц делим на недели. У нас период всегда начинается с понедельника: каждая неделя начинается с понедельника, даже если она в двух месяцах.

• По каждой задаче отмечаем пустыми кружками, в какую неделю мы планируем над этим вопросом работать.

• Если мы задачу поработали, и все в порядке, ставим черный кружок.

• Красным показано, что мы планировали, но не сделали (в случае на слайде мы отказались от реализации задач по рабочим центрам, поскольку сделали основной упор был сделан на подготовку ресурсной спецификации).

Этот статус проекта позволяет нам оценивать динамику работы над проектом. Актуализируем каждую неделю.

На слайде показан пример с проекта, где мы завод автоматизируем. График статуса помещается ровно на один лист. Больше никакой документации по проекту мы не делаем.

Проблема масштабирования

Есть несколько моментов, которые нужно учитывать:

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

• Клиентская часть по мере развития продукта тоже начинает расширяться. У вас появляются новые города, предприятия, может быть даже страны. Когда наше решение начало работать в Италии и Финляндии, мы поняли, что нам нужно поднимать еще и локализацию.

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

• Данные. Очень важным момент – это мощность системы и время реакции.

Однажды у нас возникла проблема – нужно было проинвентаризировать склад, а эти склады у нас находились в 20-ти городах. На каждом складе лежит примерно 10 000 единиц товара.

Проблема заключалась в том, что на передачу данных из учетной системы на ТСД уходило 10 минут. Мы стали разбираться и поняли, что нужно менять основу, которая заложена в системе и потратили 2,5 месяца на то, чтобы решить эту проблему.

Стали проводить тест – опять 10 минут. Оказалось, что ошибка заключалась в том, что мы 10 000 раз прогнали 10 000 товаров.

Так мы выяснили, что за 10 минут наша система может прогнать через себя 1 000 000 кодов маркировки – это примерно 16 000 позиций в секунду. И когда мы осознали, что наша система позволяет делать такую мощность, то мы поняли, что в принципе можем строить достаточно сложные распределенные решения.

Расскажу про наш путь:

• Вначале мы разработали решение и отпилотировали его на одной фабрике.

• Потом нам предложили поставить нашу систему одновременно в 20 городах на 30 складах под единым управлением и т.д. Мы это сделали.

• Затем нам предложили еще более серьезную задачу: развернуть наше решение одновременно на 40 фабриках. На тот момент мы решили проблему с мощностью системы, поэтому задачу на 40 фабриках мы масштабировали. Для тестирования процесса запуска мы съездили только на 2 фабрики – остальное решались силами ИТ-службы. За 2 недели мы подняли все 40 фабрик.

• Сейчас нам прилетела другая заявка – нужно было поставить наше решение в 100 филиалах по всей России, которые работают 24/7 (если взять временные периоды) и парк ТСД сразу увеличивается где-то на 300 штук. Мы согласились, потому что наша система позволяет все это прокачивать.

Справа на слайде представлен интерфейс мобильного приложения после проработки дизайнером. Мы его реализовали только после того, как год поработали на 1С-овском интерфейсе. И то, до сих пор еще не всех клиентов перевели на новый дизайн.

Более того, у нас до сих пор есть клиенты, которые в ТСД сканируют строчку, и их все устраивает, так как все работает.

Далее мы столкнулись с вопросом, как продвигать наш продукт. Разработать – это одно, а как дальше развивать – здесь уже нужно строить систему.

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

К нам клиенты приходят через соцсети и от текущих клиентов, мы продвигаемся «сарафанным радио». Клиенты сначала внедряют какие-то флагманские решения, известные на рынке, а потом переходят к нам.

Проблема экономики продукта

Под экономикой продукта подразумевается:

• сколько времени нужно, чтобы создать продукт;

• как мы будем это монетизировать;

• как мы будем управлять качеством нашей системы;

• и вопрос инвестиций.

На слайде показано распределение времени на создание продукта (я уже говорил, что у нас это 10 недель, т.е. примерно 400 часов).

Вы можете играть с интерфейсами, придумывать новые технологии, но за 400 часов у вас должен быть готов прототип.

Когда есть такие ограничения, это очень сильно снижает творчество разработчиков.

Стоимость создания прототипа – миллион рублей.

Разработать за 10 недель прототип – решение, которое будет готово для дальнейшей коммерческой эксплуатации, стоит миллион рублей.

Если мне нужно реализовать 20 проектов – мне нужно 20 миллионов рублей, чтобы запрограммировать их в коде и проверить на пилоте.

Возникает вопрос: «Куда мы передаем эти затраты?» Разработать – это хорошо, а вот заработать на этом денег – совсем другое.

Сколько можно заработать на одном мобильном приложении? Мы рассчитываем так: разработав мобильное приложение, планируйте на нем заработать примерно 10 миллионов. Это минимальная граница, которая вполне достижима за 1,5-2 года.

Что же касается сложности прототипа, то нужно помнить, что есть:

• простые решения, которые делаются по шаблону;

• средние решения, которые предполагают какую-то интеграцию с базой данных;

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

• игровые решения.

Далее вопрос о тарифах на лицензии – о том, как монетизировать. Этот вопрос принес нам много головной боли.

Мы пришли к подписной схеме.

У нас есть тарифы:

• на года,

• на три года

• и вечная лицензия.

Политика очень простая:

• есть годовой платеж,

• хотите на три года – это два годовых платежа,

• хотите вечную лицензию – это три годовых платежа.

Чтобы к этому прийти, я разговаривал с клиентами, пробовал разные схемы, но все упиралось в то, что клиент не готов платить более 15 000 за один ТСД, а так есть различные проценты скидок.

Следующая вещь – это тарифы на услуги: на доработку, на гарантийную поддержку и т.д.

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

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

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

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

• Хочет получить скидку 10%? Пусть возьмет больший объем или больший временной лаг.

• Хочет получить еще 20%? Пусть даст мне отзыв, разрешит приехать на предприятие, чтобы сделать фото и видео, провести интервью и все то, что связано с продвижением – то, что я потом смогу использовать для каких-то своих целей.

• Хочет еще скидку? Пусть поучаствует в пилоте. Нам нужно отлаживать наши продукты, и я готов за это клиенту дать скидку.

• Ну и конечно же, если я сразу получаю 100% оплату, я тоже поощряю клиента за то, что он оплатил.

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

Если вы посмотрите, как ваши клиенты работают с поставщиками, то увидите, что они тоже всегда борются с поставщиками за разные скидки – за размещение в промозоне, за объем закупки и т.д.

А мы почему-то так делать стесняемся. Но когда мы ввели такую систему, оказалось, что клиенты нормально ее воспринимают, приводят клиентов и просят 5%. Не вопрос.

Это ключевой момент, к которому мы пришли:

• цена, зафиксированная в прайсе;

• скидка не с потолка, а за конкретное действие клиента.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.