Офисная картография — серьезный вызов для растущей компании, да и для серьезной корпорации может стать головной болью. Новички теряются в огромных офисных пространствах и не могут найти дорогу от переговорки до своего рабочего места, старожилы сталкиваются с тем, что коллеги переехали неизвестно куда — все это влечет за собой организационные проблемы.
У нас в IBS уже давно существовала картография (как минимум с 2010 года), и с тех пор она, увы, критически устарела. Поэтому недавно мы прокачали свои офисные карты, создав решение с использованием Visio, Leaflet JS и собственных наработок.
Тема эта на «Хабре» уже поднималась, но давно: несколько лет назад (в 2012-м и 2013-м годах) компания Positive Technologies также поставила перед собой задачу создать корпоративные карты. Однако они пошли противоположным путем: от прорисовывания помещения Visio и данных в Excel к полноценным планировкам в «Автокаде» с последующим экспортом в 2D, 2.5D, 3D.
Мы же с AutoCAD работали изначально, но сегодня пришли к Visio (как к инструменту первоначальной подготовки планировки), научившись работать с форматом и использовать его функциональность и гибкость под ряд нестандартных картографических задач.
Кому интересен наш тернистый путь — добро пожаловать под кат.
Долго мы использовали самописное решение, актуальность которого была под вопросом уже очень давно. По сути, это был обычный растр с возможностью поиска по меткам. Один сотрудник отрисовывал этажи в AutoCAD (не только для картографии), эта схема сохранялась в формате png, в веб-приложении наносилась разметка (т.е. фактически карты рисовались в двух местах). Вот, собственно, и все. Какие были минусы у такого решения?
- информация быстро устаревала. Любая перепланировка офиса означала перерисовку и повторную разметку карты, а это уйма времени и усилий. Дожить до следующего переезда, пока в карте не отразился предыдущий, было вполне реально;
- чтобы все-таки актуализировать такую картографию, требовались подготовленные кадры;
- низкая детализация. Картинка офиса была обычным PNG, поверх которого раскиданы основные сектора.
Ситуация затруднительная: и оставаться в ней было затратно, и развиваться, не меняя подхода, практически невозможно. Кроме того, на тот момент у нас было уже больше пяти стремительно растущих офисов в крупных городах, для которых картографии не было вообще, а движок невозможно было масштабировать.
Необходимо было двигаться вперед. К офисной картографии был сформулирован ряд требований — как к функционалу, так и к движку. Кроме запросов самых обычных (возможность создания нескольких карт, зумирования, перемещения по этажам, поиска ближайшей переговорной, etc.), были и более сложные и интересные: поиск сотрудника по ФИО, принтера — по возможностям печати, уровни доступа с различным допуском к информации… В конце концов, карты также должны были удовлетворять интерес пользователей в предоставляемых рядом с офисами или внутри них услугах, нормально открываться на мобильных устройствах, а еще — работать только на наших серверах, никуда не отправляя данные.
С этими требованиями мы и начали искать пути, как исправить ситуацию.
Первый подход/первое причесывание
Мгновенно все изменить было невозможно, поэтому сначала мы сделали ужасное на тот момент решение хотя бы временно терпимым:
- нанесли на карту новую разметку — раньше у нас были только кластеры, теперь же появилась детализация до рабочего места;
- добавили в карточки сотрудников номера телефонов с тегом TEL — появилась возможность связаться с сотрудниками прямо с карты при установленном софтофоне;
- добавили принтеры и прикрутили принт-сервер, его веб-службу, веб-принтинг — теперь пользователи могли сами подключать принтеры.
Но проблему это не решило. Все объекты на карте оставались просто послойной рамочкой над картинкой, зум был невозможен (точнее, возможен, но ужасен. Растянуть PNG в 150pt — такое себе), разнести находящиеся рядом объекты тоже было нельзя.
Кроме того, оставалось несколько требований разной важности и разного уровня:
- стратегически важно было уйти от двух источников данных, сосредоточить картографию в одном движке. AutoCAD для этого был слишком тяжел, потому что:
- система должна была стать простой в поддержке и развитии, ведь нам был нужен инструмент для создания и поддержания карт для целого ряда офисов;
- детализация все еще оставляла желать лучшего;
- автоматизация обновления сведений на карте также все еще была затруднена.
Плюс ко всему прочему, наша картография была именно корпоративным сервисом, а потому глубоко интегрирована со смежными системами нашей компании. Новое решение должно было работать так же! Поиск нового варианта это затрудняло, но мы его продолжили.
Второй подход/второе причесывание
Самой длительной фазой создания нашей офисной картографии стала научно-исследовательская работа по подбору инструментов. Этот этап длился почти год: мы перебирали варианты, платные и бесплатные сервисы и приложения, экспорт из «Автокада» в промежуточные конвертеры, бесплатные аналоги. Мы рассматривали серьезные универсальные промышленные системы — ArcGIS, ArchiCAD, что-то, не заточенное под картографию в целом. Был даже вариант написать весь комплекс с нуля подрядной командой разработчиков (ценники и сроки — проще на Луну слетать). Тогда у нас вырисовывалась система с большим и мощным CAD, с рендерингом, трехмерным моделированием…
Однако использование AutoCAD как раз несло многие минусы, от которых мы стремились уйти: временные затраты, требовательность к квалификации администраторов, высокая сложность поддержки продукта, да и высокая стоимость использования.
Во всем этом Visio показывал себя противоположностью. Его использование радикально упрощало работу администраторов систем, с ним было легко верифицировать и поддерживать существующие схемы офиса, и, главное, это позволяло наконец-то уйти от двух источников данных. Кроме того, Visio-документы очень гибки — их можно сконвертировать в веб-представление, можно распечатать и отдать какой-то службе, в них можно отключить слой и распечатать без него. И все это делается на простом офисном компьютере и не требует особо глубоких познаний.
Всего разнообразных вариантов было рассмотрено десятка два. В вырисовывающейся системе использовались Microsoft Visio Pro, в документе которого хранятся визуальные данные и мета-информация. Оттуда они извлекаются и обрабатываются. Для отображения используется библиотека Leaflet, где при помощи дополнительных слоев и плагинов реализуется бизнес-логика и интерактивное взаимодействие (например, выбор и подсветка объектов в результате действий пользователя). Для хранения извлеченных сведений может быть использована любая СУБД, основные данные — это номер рабочего места, тип (переговорная, кабинет, рабочее место в open space и др.) и геометрия объекта.
Почему же мы остановили свой выбор именно на Visio?
- Из него можно корректно получить картинку, хорошо отображающуюся на вебе, и сами данные об объектах — о том, что стул — это стул, а принтер — это принтер.
- Конфигурация с его использованием позволяла развивать картографию: можно скрестить карты и любую информацию о сотрудниках. Например, получить на выходе тепловую карту возрастов, стажа, зарплат. По потенциалу развития нашим бизнес-требованиям такая схема тоже отвечала.
- С ним было возможно воплотить модель непрерывной интеграции — сотрудник вносит изменения в офисный документ, и через какое-то время карта становится доступной уже в обновленном состоянии. Сборка этой карты фактически осуществляется без участия человека.
- При этом все составляющие конфигурации были проверены множеством пользователей, а мы могли дописывать ее как угодно под свои нужды.
- Кроме того, у нас возникли особые требования: в картах хранились данные служебного уровня. Нужно было, чтобы расположение сетевых розеток, сведения о площадях, занимаемых разными подразделениями и т.п., сохранились в системе, и Visio также позволял это.
В результате процесс создания карт предполагал их отрисовку в формате Visio, конвертирование (бесплатными инструментами) в SVG-шки с наложением тайлом (т.е. вектор плюс растр), затем бесплатным лифлетом отображение на портале. Если по шагам, мы:
- Создаем схемы в Visio в соответствии с выработанными соглашениями.
- Кодифицируем все специальные фигуры с добавлением к ним необходимых мета-данных.
- Сохраняем схему в svg-формате. Она должна содержать только те элементы, которые видны всем пользователям будущей карты; на этом шаге формируется рабочая поверхность карты — ее базовый слой.
- Экспортируем «Специальные фигуры». На данном этапе происходит получение информации о типе элементов и их расположении на будущей карте и графическом представлении.
- Трансформируем svg-схемы, полученной на шаге 3, в растровый формат.
- Трансформируем растровый файл большого размера, полученного на шаге 5, в серию картинок меньшего размера, с формированием tiles-слоя.
- Согласуем данные на карте и в БД, где аккумулируются все сведения.
Конечно, это не идеальная сферическая комбинация в вакууме, но у нас и не было задачи такую найти. Зато она удовлетворяла нашим корпоративным требованиям!
Проблемы пилота
Пришло время приступать к прототипу. Мы отрисовали один этаж нашего офиса в Москве и сразу зарылись в проблемы производительности. То, что работало в масштабе кабинета и трех столов, на уровне тысячи рабочих мест дико тормозило. Отладить это было несложно, но пришлось избавиться от части визуализации, теней, атрибутов, всплывающих окон — и упрощенная версия выглядела неплохо, а работала достаточно быстро.
Чтобы нанести уже продуктивные данные, мы привлекли подрядчика, который скрупулезно обошел пространства пилота с карандашом и распечаткой планировки, и задокументировал для нас все актуальные изменения, а также уточнил всякие мелочи — вплоть до того, в какую сторону открываются двери. Другой подрядчик прорисовал изменения, и тут нам пришлось вносить неожиданные корректировки.
Дело в том, что наш план получался слишком реалистичным — реалистичным до непрактичности. Например, на нем сложно было попасть мышкой в принтер, т.к. он занимал свои законные четыре пикселя, что на пользу картографии, ориентированной и на сотрудников тоже, совсем не шло. Толщина стен, размер лестниц — многие детали пришлось изменить, упростить, а то и вовсе отбросить, просто чтобы картами было проще пользоваться. Те же самые принтеры, например, пришлось сделать здоровенными, размером со стол — зато теперь с ними стало проще работать.
Так что при создании своей картографии не отказывайте себе в возможности отредактировать реальность. Карты — это в первую очередь сервис для людей, и хотя точность для него очень важна, удобство использования необходимо учитывать.
Пилот помог нам установить «основные правила игры», составить шаблон документации для корпоративной картографии (об этом ниже). Обкатанную на одном этаже и хорошо себя показавшую технику мы сравнительно скоро тиражировали на остальные этажи, а потом и на все офисы.
Затем следовала активная совместная работа с администраторами подразделений — можно назвать этот этап бета-тестами. Мы вылавливали баги, обкатывали обычные функции, искали, у кого что не отображается, где всплывают глюки, где расползается картинка. По ее завершении прототип системы вывели в опытно-промышленную эксплуатацию, мониторили реальную нагрузочную способность, искали, где и из-за чего система может падать. Теперь карты уже введены в использование — и ими может воспользоваться каждый наш сотрудник.
Структура взаимосвязей
В основе процесса лежит файл поэтажного плана, откуда считываются данные — они конвертируются, в них дописывается системная информация; результат мы уже видим на сайте. Поверх разметки интерактивных объектов уже в веб-интерфейсе наносятся метаданные. Это может быть ссылка на подключение принтера (и его фото), описание переговорной, фотография внешнего вида, в общем, все, что отображается поверх рисунка объекта на карте при клике на объекте.
Каждый из объектов Visio может обладать или не обладать набором данных, без которых любая графика выводится на карте как картинка-подложка. А вот с набором она становится интерактивной. Основные атрибуты — это id (уникальный идентификатор) и номер, обязательным атрибутом также является тип (для группировки интерактивных объектов, также задает фильтрацию объектов в веб-интерфейсе карт).
Также объекты увязываются по слоям — каждый слой объединяет разнотипные объекты единой характеристикой. Есть свой слой для стен, для дверей и окон, есть для мебели, пометок на карте, для разграничения по секторам, принтеров, надписей, даже для украшений карты.
Как выглядит процесс подготовки данных в целом. Сначала объект — принтер, стол, переговорная, банкомат (перечень типов объектов ограничен только фантазией) прорисовывается администратором системы как графика: просто набор дуг и линий, заливок и пр. Затем та часть графики, которая должна будет стать интерактивной, группируется в макроэлемент, и этой группе присваивается набор атрибутов, по которому в дальнейшем программа-конвертер определит, что перед ней интерактивный объект. Значения атрибутов — тип объекта, порядковый или «географический» номер (номер кабинета, к примеру) — задаются тут же. В дальнейшем, после прохождения конвертации, каждому такому объекту будет присвоен и записан обратно в файл свой уникальный ID-номер, не меняющийся при манипуляциях с объектом. Это позволяет, в частности, решить задачу перенумерации объектов без изменения их географического или логического положения на карте.
Перед конвертацией каждая карта проходит валидацию на соответствие договоренностям по формированию данных. Это самописный плагин к «Визио», который проверяет: уникальность ID объектов, их номеров, отсутствие наложений и дублей и пр. Все недочеты визуально подсвечиваются и на лету могут быть исправлены.
После конвертации указанные как интерактивные объекты становятся доступны для доработки в админке на стейдж-сервере. Тут уже в WYSIWYG-редакторе можно прицепить фото к объекту, гиперссылки на подключение принтера или ссылки на описание того или иного объекта и прочее текстово-графическое описание, которое будет отображаться в карточке этого объекта на продуктивном сервере. После этого, если к концу рабочего дня все прогрузки закончились и метаданные нанесены, по ночной прогрузке все переезжает на продуктивный сервер, т.е. становится доступно сотрудникам компании.
Для отработки каких-то новых фич и функций заведен отдельный тестовый сервер. Там ведется копия данных по пользователям и оборудованию и, как в конструкторе, можно собрать что-то новое, не боясь обрушить что-то в продуктивной системе.
Поддержка и развитие
Мир не стоит на месте, а уж IT-мир и подавно. Даже если нас сейчас удовлетворил получившийся картографический проект, его все равно придется постоянно актуализировать и развивать.
Чтобы карты оставались актуальными, мы поддерживаем постоянную связь:
- с администраторами подразделений — они владеют правами, чтобы самостоятельно исправлять карточки сотрудников, а также присылают нам информацию о переездах или перемещении мебели. Каждую неделю они получают автонапоминалку о необходимости вносить корректировки, если они за неделю накопились;
- с офис-менеджерами — они постоянно обновляют информацию об изменении геометрии офисного пространства: переносе дверей, перестановке принтеров и т.д.;
- с обычными пользователями — они могут сами ловить неточности и давать нам обратную связь через кнопку «сообщить об ошибке».
При этом карты постоянно развиваются. Поскольку нам было выдвинуто требование сделать новую картографию гибкой и открытой для доработок, теперь у нас есть множество возможностей. Например, под коронавирусные условия мы реализуем возможность работы с мобильными местами: кроме обычных постоянных рабочих мест, организуется особая их категория. Сотрудники могут бронировать эти рабочие места на какой-то определенный период времени, чтобы выходить и занимать их на ограниченное время, а потом возвращаться на удаленную работу.
Ну и конечно, есть в этой системе многообещающие возможности, к реализации которых мы еще не подступались. Например, мобильное направление картографии, когда с помощью смартфона и наклеенных на стены QR-кодов можно отследить на карте свое положение, выстраивать от него маршрут до нужной точки. В критических ситуациях можно даже автоматически показывать маршрут эвакуации, ведущий к ближайшему аварийному выходу.
Другое текущее направление разработки — функционал переговорок. К переговорной подвязывается информационная система, которая показывает, по сути, открытый календарь этой переговорной и позволяет бронировать ее прямо из карты. Информационные системы других сотрудников будут «в курсе» этой брони и будут выдавать ее как занятую в эти часы.
Сейчас наша офисная картография — внутренний сервис, но однажды, быть может, станет доступна как одна из наших услуг, уж очень хорошо получилось. Если кому-то есть чем дополнить наш рассказ, если у вас возникли мысли, как организовать систему лучше, или возникли по ней вопросы — добро пожаловать в комменты!
