Вместо предисловия
Сначала спрошу, кто из присутствующих – разработчики 1С:Франчайзи. Поднимите, пожалуйста, руки: вас совсем мало. Я так понимаю, все остальные – представители компаний, которые работают в реальном секторе экономики, представители бизнес-сообщества. Вас я попрошу сфокусироваться, потому что вещи, о которых я расскажу, их, правда, можно делать.
После того как вы сделаете подобные вещи, останется мало того, что сделать уже нельзя. Представителей партнеров фирмы 1С я прошу смотреть на мой доклад, как на рассказ о пережитых страданиях. То, что мы сделали, было тяжело. Мы делали это больше двух лет – с 2016 года до середины 2018.
Условия, в которых проходил проект
В 2017-2018 году розничная сеть «Магнит» полностью перешла на управление процессами ремонта и технического обслуживания оборудования с помощью смартфонов.
Что такое сеть «Магнит» на данный момент:
-
20 тысяч торговых точек – супермаркетов и гипермаркетов, магазинов в формате «у дома», магазинов «Магнит Косметик»;
-
38 логистических центров;
-
5 часовых поясов нашей родины, где представлены магазины;
-
5 миллионов единиц оборудования, которые находятся в ведении департамента эксплуатации, осуществляющего ремонт всего оборудования;
-
300 тысяч сотрудников – это крупнейший частный работодатель в стране. Я знаю, у «Почты России» 350 тысяч работников, больше только у РЖД.
В каждом магазине «Магнит» есть:
-
холодильное оборудование;
-
система кондиционирования;
-
внутреннее и внешнее освещение;
-
отопительное оборудование.
В идеале все это должно работать, как часики. Чтобы мы с вами, приходя в магазин, хотели прийти сюда снова. Это высококонкурентный рынок, и чем идеальнее все работает, чем красивее, тем больший поток клиентов собирает компания.
К чему я это рассказал? К тому, что требования к работоспособности оборудования у руководства «Магнита» достаточно высокие. Обеспечением работоспособности всего оборудования занимается департамент эксплуатации. В этом департаменте эксплуатации и проходил наш проект.
Наше мобильное приложение было всего лишь частью проекта. Основная задача проекта – внедрить систему 1С:ТОИР. Это большая система на платформе 1С, предназначенная для технического обслуживания и ремонтов оборудования (промышленного и непромышленного) любых инфраструктур, зданий и сооружений. Мобильное приложение предназначалось для людей, которые непосредственно выполняют ремонты. На начальном этапе их было 3 тысячи человек, потом количество сотрудников уменьшилось до 2,2 тысяч пользователей. Это люди, которые крутят гайки, чинят компрессоры в холодильниках и так далее.
Всего в компании 19-20 тысяч объектов, которые генерируют заявки. В большом ТОИР работают аналитики, инженеры, в чьем подчинении есть группы пользователей нашего мобильного приложения. Поток заявок на ремонт в месяц – порядка 40 тысяч.
Что было до того, как внедрили проект?
Никакой системы управления не было. «Магнит» – быстро развивающаяся сеть: когда проект начинался, у компании было 16 тысяч торговых точек, а сейчас – 20 тысяч. Так что вы представляете темпы открытия магазинов – порядка 1-2 тысяч магазинов в год. Если поделить на дни, получается, от 3 магазинов в день.
Но единой системы управления ремонтами не было. Сотрудники, которые крутят гайки, контролировались вручную. Задачи раздавали по телефону либо в офисе.
Между моментом инициации заявки на ремонт и моментом, когда ее получал конкретный исполнитель, проходило примерно 2 часа. На картинке представлен процесс до реализации проекта – с использованием диспетчера в виде участкового инженера.
Что надо было сделать?
Надо было исключить этого диспетчера, сделать автоматический процесс назначения заявки, чтобы сократить время между возникновением заявки и ее получением. А еще надо было внедрить механизмы контроля за деятельностью этих людей. Причем максимально автоматизированного контроля, потому что количество этих людей – 2,2 тысячи человек.
Что изменилось после реализации проекта
Я не буду говорить про большой ТОИР, а сфокусируюсь именно на мобильном приложении. Ниже схема, как выглядит процесс после реализации проекта.
Сотрудник любого подразделения генерирует обращение через портал сети «Магнит» MyIT. Оно регистрируется и попадает на мобильный телефон сотрудника, который выполнит заявку.
Когда заявка на ремонт обработана, инициатор заявки получает возможность оценить качество исполнения.
В плане информационных систем это выглядит примерно так:
Следует сказать, что у департамента эксплуатации есть внутреннее SLA – соглашение об уровне услуг по восстановлению работоспособности оборудования. С помощью портала MyIT в Service Desk регистрирует обращение. Затем обращение (заявка) поступает в ТОИР, после попадает в мобильное приложение, обрабатывается в мобильном приложении, а затем по обратной цепочке доходит до инициатора.
Проект изначально был рассчитан на год, но делался 2 года и 4 месяца. В нем участвовала команда из 124 человек. Большинство из них – сотрудники «Магнита» из департамента эксплуатации, ИТ-департамента плюс большая команда бизнес-аналитиков, которые помогали проектировать все процессы и операции так, чтобы это было приемлемо и удобно для заказчика.
Наше мобильное приложение
Еще раз повторю: мобильное приложение у рабочих, а участковые инженеры – в прошлом диспетчеры – работают в большой системе.
Под этот проект сделали централизованную закупку смартфонов в компании Samsung. Модель телефона, если не ошибаюсь, Samsung Galaxy J3.
Кто наши пользователи? Это люди, которых представители компаний-партнеров фирмы 1С боятся: они никогда не работали с компьютером – ремонтники, чей средний возраст 45 лет. При этом 30% из них никогда не пользовались смартфонами.
Чтобы не обучать большое количество пользователей, нам надо было создать приложение, которое было бы интуитивно понятным.
Функциональность мобильного приложения:
-
получить задание;
-
посмотреть документацию по оборудованию, инструкции (большое количество видео-инструкций);
-
заявки, которые поступают в мобильное приложение, приоритизируются;
-
должен быть чат с участковым инженером;
-
должна быть возможность спросить и получить ответ, но при этом не спамить других пользователей;
-
должна быть возможность заказать запчасти на складе, хотя у каждого рабочего есть свой мини-склад в багажнике автомобиля;
-
нужно иметь возможность зарегистрировать дефект и отчитаться о выполненных работах;
-
работа должна вестись в оффлайне.
Но это только front. А есть еще и back. Нужны были инструменты контроля за деятельности сотрудников, сравнение эффективности и т.д.
Вот так выглядит интерфейс нашего мобильного приложения
Основные экраны содержат те функции, которые я перечислил. Они представлены в меню. Основные функции были вынесены на первый экран, вспомогательные – на второй, и сервисные – на третий.
Иконки и интерфейс, наверное, далеки от идеала. Но это не тиражное мобильное приложение, и мы считаем, что интерфейс достаточно хорошо и глубоко проработан, и людям, не связанным с ИТ-средой, удобно и интуитивно понятно, как им пользоваться. Кстати, иконки не скачаны из интернета, их разработали наши дизайнеры конкретно для этого приложения.
Когда заявок много, естественно, нужно иметь возможность их быстро перегруппировывать: определять, у каких высокий приоритет, какие находятся ближе к конкретному исполнителю, и т.д. Поэтому мы сделали фильтры кнопками, сделали раскраску (подсветку) для разных ситуаций: где-то по статусу, где-то по приоритету. На свайпы выносили в разных документах разные действия, чтобы максимально эффективно использовать те средства, которые у нас есть.
Интересную штуку сделали в плане упорядочения заявок. Можно упорядочить заявки на ремонт по геокоординатам, по положению, по ближайшему расстоянию от рабочего. И еще можно упорядочить по текущему подразделению: если человек приехал в магазин по одной заявке, он легко может посмотреть другие заявки из этого же магазина. Кроме того, можно отфильтровать по геопозиционированию те заявки, которые находятся в ближайшей зоне.
Я уже сказал, что мобильное приложение работает в связке с большим ТОИР. Естественно, когда вы владеете подобной системой, нужна возможность управлять настройками централизованно. Поэтому большинство настроек вынесено в большую систему. В мобильном приложении остались те настройки, которые не очень влияют на общую работоспособность, но дают возможность людям максимально настроить его под себя там, где это можно.
Расскажу про еще одно из наших интересных решений. Из-за большого количества пользователей любую настройку можно установить для всех, но перекрыть для части людей. Например, для отдельно взятого региона можно общую централизованную настройку изменить.
Сложности, с которыми мы столкнулись, и технические решения
Как я говорил, очень важно было организовать контроль за деятельностью рабочих. Потому что это люди, условно говоря, с обеспечением за счет компании, бензин и запчасти покупают за счет компании, они в свободном режиме решают те задачи, которые им поставлены. И все это фактически без каких-то инструментов контроля. То есть у людей появляется возможность отдохнуть больше, чем положено, сделать что-то в рабочее время не по работе, прочие вольготности. Эти вещи нужно было исключить. Очень сильно в решении данной задачи помог геотрекинг и геокоординаты.
Проблема, которая появляется сразу, – что делать, если приложение выгружено из памяти. На тот момент, когда писалось мобильное приложение, платформа не умела считывать координаты, если мобильное приложение выгружено из памяти. Данные поступали только при запуске приложения. Что мы сделали? Мы написали нативное приложение-службу, задача которого с определенной периодичностью (в виде настроек) считывать геокоординаты и хранить у себя. Система забирает себе эти данные с определенной периодичностью и обеспечивает постоянный контроль за тем, где находится сотрудник. Также регистрируются простои.
Геокоординаты используются еще для того, чтобы убедиться, что ремонтируется именно тот объект, на который пришла заявка на ремонт. Потому что любой человек, имея мобильное приложение, может «говорить», что работает (ремонтирует оборудование), фактически находясь в другом месте. Поэтому в момент, когда у заявки появляется статус, что она пошла в работу, записываются геокоординаты. Эти геокоординаты в автоматическом режиме сравниваются с геокоординатами объекта, на ремонт которого пришла заявка. Если есть отклонение, о нем узнает сотрудник головного офиса, который следит за действиями рабочих. Если все нормально, координаты совпадают, никакие уведомления, предупреждения ни у кого не возникают, и считается, что процесс идет в штатном режиме.
С этим еще помогают штрих-коды. Рабочий приехал, отсканировал штрих-код на объекте ремонта, данные передались в систему.
Кстати, если вы зайдете в магазин «Магнит» и посмотрите внимательно, например, на холодильное оборудование, вы увидите на каждом из них штрих-код с подписью 1С:ТОИР: «Магнит» обклеил все оборудование штрих-кодами. Это была отдельная задача по паспортизации оборудования, и для этого вообще делалось отдельное мобильное приложение.
На слайде как раз данные про фиксацию всех перемещений и те настройки, которые для этого предназначены.
Еще одна интересная настройка – время жизни координат по умолчанию. Что это такое? Это время, которое считается актуальным для последней записи геокоординат. Так или иначе, смартфон может выключиться, приложение для геотрекинга или «ТОИР Магнит» могут выгрузиться. Когда приложение снова запустится, как система поймет, что те геокоординаты, которые у нее есть, актуальны? В «Магните» на данный момент время жизни координат, которые считаются актуальными, – полчаса. Это последние зарегистрированные геокоординаты.
Я рассказывал про уведомления по поводу работы в другом месте. Точно так же фиксируется и простой сотрудника. Если геокоординаты на протяжении какого-то количество времени одинаковые, срабатывает настройка «количество регистраций по одним геокоординатам для учета остановки». Система фиксирует простой рабочего и оповещает кого нужно.
Теперь про чат рабочего с инженером в мобильном приложении. Чат сделали только в рамках конкретной заявки, и написать в чат может только тот рабочий, который эту заявку обрабатывает. Тем самым мы добились отсутствия спама. Это не общий чат, и это удобно.
В чат можно пересылать файлы, скриншоты, скинуть ссылку на техдокументацию. Благодаря этому достигается оперативность получения рабочим той информации, которая нужна для выполнения работы.
Наши ребята в команде очень гордятся тем, что чат в «ТОИР Магните» был сделан за месяц до того, как Сбербанк сделал его в «Сбербанк Онлайн». Эти события, конечно, никак не связаны друг с другом. Да, и мы опередили фирму 1С в рамках проекта, стандартная функция чата в мобильной платформе 1С появилась только через год.
Еще одна проблема, когда у вас большое количество пользователей, – их начальная синхронизация. Проблема связана с тем, что передается большое количество данных (учитывая 5 миллионов объектов ремонта). И мы разработали такие механизмы, которые позволяют рабочему, который трудится в одном регионе, не передавать информацию из других регионов. Мы максимально резали эти данные, но, несмотря на это, вначале стадия начальной синхронизации занимала около 5-6 часов. Впоследствии мы сократили это время примерно до 20-30 минут. Это начальная синхронизация – передача всех справочников, технических инструкций, видео-инструкций, всей информации, которая нужна на мобильном приложении.
Как мы технически сделали так, что большое количество устройств не уложили сервер на начальной синхронизации? Естественно, ограничили количество задач начальной синхронизации через настройку и количество задач на начальной синхронизации на одно фоновое задание. Это сделано через механизм фоновых заданий – чтобы фоновое задание не разрасталось на сервере.
Одновременно инициализируется примерно тысяча мобильных пользователей, и их начальная синхронизация занимает не более 30 минут. В файле обмена было до 50 тысяч объектов загрузки.
Проблемы, которые возникали в ходе эксплуатации
Механизм регистрации изменений платформы 1С работает примерно следующим образом: изменение в основной базе данных регистрируются через планы обмена для тех узлов, для которых оно предназначено. По умолчанию это были все узлы. Нам пришлось переписать этот механизм учета изменений и сократить, скажем так, регистрацию изменений для тех узлов получателей, для которых эта информация актуальна. То есть если один рабочий обрабатывает какой-то территориальный округ, то передача на мобильное устройство данных об изменении в других объектах ремонта для него не актуальна. Этот механизм сильно облегчил эксплуатацию и заметно снял нагрузку на серверы. Но этого мало.
Есть такие ситуации, когда рабочий трудится, например, 1 день из 5. И если так, то мы удаляем узел обмена, чтобы снизить нагрузку на сервер. То есть в следующий раз человеку предстоит снова пройти начальную синхронизацию, если он заходит в приложение через пять дней или после отпуска, больничного. С точки зрения управления мощностями, это «дешевле», чем сохранять узел обмена на весь период. Дешевле не по деньгам, дешевле по нагрузке.
Естественно, нужно было по максимуму уменьшить память, используемую приложением, на мобильном устройстве. Поэтому все резали по максимуму, удаляли закрытые заявки, все лишнее просто отсекали. И еще мы ограничили максимальный возраст документов, которые хранятся в мобильном устройстве. К примеру, если заявка висит неделю, то мы ее удаляли с мобильного устройства, но она оставалась в большом ТОИР и привлекала внимание инженеров.
Еще оптимизировали интерфейс. Это то, о чем я уже говорил.
Также мы ограничили пакеты передаваемых данных. Опять же опытным путем мы вышли на оптимальный размер пакета, когда достигается баланс между ожиданием, передачей и нормальной работой мобильного приложения.
Следующая тема очень интересная – безопасность в плане использования мобильных приложений. Нужно было дать возможность сделать удаленный WIPE-данных, нужно было сделать авторизацию через Active Directory (AD), что мобильная платформа в принципе не умеет делать. Еще нам надо было интегрировать решение с EMM-системой AirWatch.
Для этого тоже писали нативное приложение, которое является прокси между AirWatch и мобильным приложением «ТОИР Магнит» на платформе 1С. Добились тем самым удаленного WIPE.
Следует еще сказать, что у «Магнита» свой корпоративный Store (магазин) приложений, и обновление может быть принудительным через Store, то есть инициировано в головном офисе.
Естественно, проходит синхронизация версий мобильного и большого приложений. При старте приложения идентифицируется та версия, которая должна работать с текущим релизом большого ТОИР.
Наши находки
Мы начали использовать разные типы шрифтов. Курсив означает один статус документа, обычный шрифт – другой статус документа. То есть это тоже информация, которая помогает.
Свайпы, понятно. Фильтры – кнопками, статусы – цветом, «умная» сортировка.
Это то, что мы нашли интерфейсно.
Я уже говорил, что делается фото до ремонта и после ремонта. Это тоже элемент контроля. К заявкам прикрепляются видео- и фото-инструкции, которые «сквозняком» пробрасываются во все остальные документы.
Есть «пуши», заказчик оценивает качество ремонта. Фиксацию геокоординат при любом движении тоже обсуждали.
Эффекты от внедрения проекта
Путем автоматизации мы сократили время поступления заявки до рабочего в 24 раза – с 2 часов до 5 минут. Это параметры, которые не мы придумали или измерили. Это параметры, о которых заявлял заказчик при подведении итогов проекта.
Вдвое ускорилось исполнение заказов. То есть после внедрения системы оборудование восстанавливается в два раза быстрее.
Рост производительности труда – плюс 35%. Теперь тем же количеством людей стали делать на треть больше. Выводы вы можете сделать самостоятельно.
Также сократили длительность простоев оборудования на 60%. Складские запасы снизили на 40%, при этом повысили их оборачиваемость. Поскольку все вывели на свет, и деятельность стала прозрачной, мы говорим о том, что на четверть сократили трудозатраты. Перестали уходить запчасти туда, куда не положено: каждая запчасть привязана к конкретному ремонту. За счет всего этого сократили расходы.
После запуска системы в эксплуатацию отказались от лицензий на BMC Remedy. А это экономия 56 миллионов в год.
Попробуем этот эффект умножить на тот масштаб «Магнита», про который я рассказывал (20 тысяч магазинов).
Какие выводы для нас, как для посетителей этих магазинов? Мы покупаем курятину или пельмени, которые не разморозились, мороженое, которое не переморозилось. Атмосфера в магазинах стала лучше, потому что кондиционирование и освещение работает хорошо.
Цена победы
Теперь о больном: о том, как это было сложно. Общий объем наших, как исполнителя, трудозатрат на проект – больше 20 тысяч человеко-часов. Из них на мобильное приложение ушло 4 тысячи. В эту цифру не включена адаптация большого ТОИР под работу с мобильным приложением.
Для чего я этого говорю? Чтобы развеять иллюзии, которые мы можем испытывать. Ведь, кажется, что разработка мобильного приложения должна быть гораздо дешевле, чем разработка большого приложения. Но это не так. Если возьмем стандартную среднерыночную ставку за работу, округлим ее до 3 тысяч рублей, получаем стоимость разработки мобильного приложения порядка 12 миллионов. Примерно так.
За время создания и год поддержки выпущено 113 релизов. Это примерно 1 релиз в неделю.
За время исполнения проекта написано 20,5 тысяч электронных писем, мы налетали половину расстояния до Луны, наши сотрудники провели 250 дней в командировках.
На окончание проекта мы сделали одну интересную штуку. На большом плакате мы собрали супергероев и поставили им лица наших сотрудников. Мы вырисовали из них супергероев, потому что это реальные герои. Это был достаточно тяжелый проект с точки зрения исполнения. На подведении итогов мы вручили ребятам – команде проекта – этот плакат, а каждый получил памятную статуэтку с надписью «Магнит-2018». Ребята были довольны.
Наши награды
Хотелось бы отметить, что наш проект получил награду «Проект года» по версии ассоциации ИТ-директоров Global CIO.
Проект также получил звание лучшего инновационного мобильного проекта от группы Samsung. Это крупнейший проект в Европе с использованием мобильных телефонов Samsung. Руководитель проекта от компании «Магнит» был приглашен на обед с президентом Samsung в Корею. Он прислал нам оттуда видео, было очень интересно.
Мобильное приложение, разработанное в рамках этого проекта, получило первое место на конкурсе мобильных приложений фирмы 1С в прошлом году. И в этом году проект стал победителем конкурса 1С:Проект года-2018.
На этом у меня все. Спасибо за внимание.
****************
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.
Приглашаем на конференции Инфостарта 2025 годаINFOSTART TEAMLEAD EVENT
Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров. INFOSTART A&PM EVENT (Анализ & Управление проектами)
Практическая конференция для аналитиков и руководителей проектов 1С. |