Опыт создания комплексной цифровой модели сети магазинов общественного питания средствами HiveUP Objects

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

В практике управления нашими торговыми сетями, включающими сеть магазинов шаговой доступности и продовольст-венныйй интернет-супермаркет, мы ори- ентировались на принципы бизнес-моделирования, описанную в работах Davenport T. и Short J. [2], которые описывали бизнес-процессы, интегрированные в общую стратегию предприятия на основании общности целей и конечных результатов операционной деятельности, где модель позволяет определить количественные показатели ресурсов на входе и выходе. При оптимизации бизнес-процессов мы также учитываем исследования Hammer M. и Champy J., посвященные реинжинирингу, которые описывают бизнес-процессы, как преобразование ресурсов на ходе в результат, соответствующий ожиданиям потребителя [3].

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

Обилие инструментов сбора и анализа информации в процессуальной модели управления обычно замедляет принятие решений, так как составляющие бизнес-процессов разобщены и представлены многочисленными документами. Информацию приходится запрашивать у соответствующих отделов и специалистов, интегрировать данные из многочисленных (от 5 до 10) программ и сервисов. Это в свою очередь усложняет процесс принятия решений и детерминирует высокие риски ошибок управления, как следствие неучтенной значимой информации о проблеме, либо процессе. Чтобы избежать временных потерь и снизить вероятность ошибок, которые критичны при управлении торговлей, было решено создать комплексную цифровую модель торговой сети с общей базой данных, интегрирующей всю значимую информацию.

Выбор средства

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

– информативность (возможность учета всех значимых показателей компании в целом и отдельных объектов);

– возможность ввода числовых значений и текстовой информации);

– возможность визуальной декомпозиции в виде графа, таблицы, диаграммы, объединённых общей базой данных;

– возможность моделирования и отображения логистических процессов на карте или схеме, отображения логистически значимых объектов (использование апи Google Map или Yandex карты);

– скорость (возможность создания элементов структуры в один два клика);

– возможность экспорта из баз Excel;

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

создавая различные изолированные процессные и структурные м

До начала 2020 года мы не использовали системы комплексных средств моделирования. В феврале 2020 к нам обратились разработчики Hiveup Objects, предложив провести пользовательское тестирование веб-приложения для моделирования, чтобы оценить юзабилити, практическую полезность функционала и внести необходимые изменения.

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

– Graph – напоминает стандартные ин-теллект-карты, позволяет доступно визуализировать многоэлементные структуры со связями;

– Tree – применяется для отображения иерархических структур (в нашем случае кадровых и иерархии управления структурных подразделений);

– Map – функционирует благодаря апи Google Map, позволяет привязывать объекты к конкретной локации в Google Map.

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

Терминология

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

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

– свойство – поле объекта, которому может быть присвоено числовое значение (в т.ч. календарное) или текстовое описание;

– связь – логический графически отображаемый элемент модели, описывающий вид связи между объектами, может быть скалярным и векторным (в зависимости от типа, может иметь одно название (или числовое значение) или два («начало» и «конец», определяющие направление действия, зависимость объектов друг от друга и т.п.);

– консоль – собственная консольная строка сервиса, через которую вводятся команды;

– ввод через консоль – создание объектов при помощи консоли;

– drag and drop – оперирование элементами интерфейса, при котором объект создается путем перетаскивания символа в рабочую область;

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

– вид – сохранённый набор объектов;

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

Структура базы данных

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

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

– организационная структура предприятия (руководство, централизованная бухгалтерия, отдел маркетинга, отдел закупок, отдел развития, отдел офлайн торговли, подразделение интернет-торговли, служба доставки, подструктуры магазинов);

– кадровая структура (должности, специалисты);

– торговая структура (магазины, дарк-сторы, поставщики, данные о потребителях, спросе, товарных группах);

– финансовая структура (оборот, прибыль, средние чек, объемы инвестиции, объем продаж);

– логистическая структура (склады, магазины, авто, водители);

– информационная инфраструктура (сайт, каталог, группы каталога);

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

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

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

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

Объекты, свойства, связи и сценарии применительно к некоторым структурам модели

Все приведенные в разделе данные о компании, в том числе данные в скриншотах являются условными, приводятся в качестве примера и использованы для демонстрации принципов построения модели, они не соответствуют реальным данным, которые представляют коммерческую тайну и распространение которых запрещено NDA. Между тем, связи и объекты, равно как принципы создания и отображения структур соответствуют тем, которые использовались при создании реальной модели предприятия.

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

Рис. 1. Объекты организационной структуры в рабочей области сценария Graph

Для получения представления о структуре управления мы также использовали иерархический сценарий Tree.

5 Бухгалтерия | Брингстон, Ближнии

О, Отдел закупок | Брингстон. Ближний

□ Брингстон | Call центр. Отдел закупок. IT отдел. Администрация!, Бухгалтерия, Darkstores, Отдел маркетинга 1 | Компания

^Администрация! | Брингстон, администрация общая | Брингстон

^ Q Call центр | Брин гстон v О IT отдел | Брингстон

Отдел маркетинга 11 Брингстон ту Darkstores | darkstorel, darkstoreZ, darkstore3, darkstore41 Брингстон | darkstorel. darkstoreZ. darkstoreS, darkstore4, darkstoreS

S Ближний | Отдел закупок. Сеть магазинов, Администрация2. Бухгалтерия. Отдел маркетинга 2 | Компания

@Администрация2 | Ближний, администрация общая | Ближний

1гГ Отдел маркетинга 2 | Ближний

Д Сеть магазинов | магазин 1, магазин 2, магазин 3, магазин 4, магазин 5, магазин 6 | Ближний | магазин 1, магазин 2, магазин 3, магазин 4, магазин 5, магазин 6

Рис. 2. Объекты организационной структуры в рабочей области иерархического сценария Tree

В процессе создания мы добавляли свойства и связи, которые интегрировали объекты в иные структуры модели. Например, для упрощения кадрового моде- лирования были реализованы связи типа “управляет”, с помощью которых отражена структура вертикального подчинения между подразделениями компании:

Рис. 3. Часть модели в рабочей области сценария Graph, демонстрирующая организа- ционную структуру компании

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

Рис. 4. Объекты торговой инфраструктуры компании, отображенные в сценарии Map

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

Также мы пользуемся картой для составления маршрутов наших курьеров с учетом предположительного расчета вре- мени прибытия заказов к покупателям в том или ином районе. При необходимости оценить возможности отдельных авто или посмотреть на количество транспорта, которое связано со службой доставки, можно использовать команду ADD Objects и отразить объекты с соответствующим тегом. В рабочем поле сценария Graph это выглядит следующим образом:

Рис. 5. Объекты “Службы доставки”, отображенные при использовании add tag “транспорт”

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

Свойства объектов, описывающих должности, позволяют получить представления о требованиях к кандидату или о критериях оценки компетенций специали- ста. Так, в зависимости от должности и конкретной задачи определялся набор свойств, например, для руководящих кадров мы определяли уровень образования, минимальные и максимальные требования по оплате труда, рабочий график, минимально допустимый KPI сотрудника (если такой высчитывался). В случае, если должность вакантна – она отмечалась специальным тегом.

Рис. 6. Фрагмент кадровой инфраструктуры в сценарии Tree с демонстрацией свойств и тегов одного из объектов в пункте Details

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

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

– Трафик;

– Коэффициент конверсии;

– Средний чек;

– Количество возвратов;

– Прибыль;

– Зарплатоемкость;

– Продажи на кв. метр (в случае с офлайн ритейлом).

Используя сценарий Table, мы проводили сравнительный анализ данных о KPI магазинов нашей сети шаговой доступности.

Применение связей с объектами бизнес показателей имеет особенность. Как правило, создаются только связи, привязывающие объект показателей к конкретному объекту, например, KPI магазина к магазину, а показатели эффективности бизнес процессов к бизнес процессам. Таким образом, финансовые показатели мало интегрированы в общую структуру модели.

Моделирование бизнес-процессов

Как уже упоминалось, мы создавали модели бизнес-процессов с использованием как уже существующих объектов, так и тех, которые создаются вне модели предприятия на основании данных о поставщиках, потребителях, значимой сторонней инфраструктуре и т.п. Основным поводом для создания таких моделей является оптимизация бизнес-процессов, которая применяется в тех случаях, когда предприятию необходимо улучшить свою работу: снизить затраты, сократить производственный цикл, уменьшить количество управленческих ошибок, принять неот- ложные меры по выходу из кризиса и т.д. [5].

Основные объекты большинства моделей бизнес-процессов, которые мы создавали:

– Заказ;

– Товар (ТМЦ);

– Поставщики;

– Транспорт;

– Магазин или Darkstore;

– Торговая площадь или сайт;

– База данных;

– Персонал (кадры) занятые в процессе;

– Потребитель.

Степень детализации объектов модели могла быть различной и зависела от конкретной задачи по оптимизации. В целом структура модели торговых процессов была аналогична классическим моделям в работе Оборина М.С. и Стариковой Л.Н. [6].

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

– Объем реализованной продукции.

– Сумма затрат на процесс.

– Время выполнения процесса.

– Процент выполнения плана по продажам и времени выполнения процессов.

– Коэффициент роста остатков готовой продукции.

– Процент реализации продукции.

Показатели эффективности, в случае наличия данных, могут вноситься в модель в виде свойств соответствующего объекта «Эффективность», а также указываться как свойство других моделей объекта. Совместно с разработчиками внедрили функцию автоматизации расчетов показателей по соответствующим формулам, исходя из значений других свойств, например, из объектов в финансовой структуре.

Сравнение эффективности

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

Результаты исследования моделей должны были быть представлены в виде коротких отчетов, аргументировано отражающих перспективность создания объектов в этих локациях на основании значимых экономических показателей. В обоих случаях предлагалось создавать базу с нуля, не используя базы готовых моделей. Для каждого из случаев группа специалистов должна была проанализировать 22 источника данных, создав на их основе модель нового магазина.

Созданием моделей последовательно занималась одна и та же группа из 3-х сотрудников. В первом случае, группа использовала стандартные средства представления в виде конструктора интеллект-карт Mindmeister, редактора таблиц MS Excel, конструктора диаграмм MS Visio и Google Maps. Во втором, применялись сценарии Hive Up Objects, в том числе с интегрированным апи Google Maps, а также с использованием документов MS Excel, как исходников для импорта данных (через стандартное средство импорта). Все данные нужно было запрашивать у соответствующих подразделений, значимые данные вносить в модель и затем анализировать, создавая отчет.

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

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

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

Во втором случае, с использованием преимущественно HiveUp Objects, группа справилась с задачей за 15 рабочих часов. Задача также была решена верно. Модель и отчет были сравнительно полные, при этом на карте-схеме торговых предприятий не был указан один из значимых торговых объектов. Следует отметить, что его учет не изменил бы ситуацию. Была также допущена ошибка в кадровой подструктуре, где была неправильно рассчитана штатная численность, необходимая магазину. Это гипотетически могло бы стать проблемой при дефиците кадров.

Группа отметила очень высокую скорость создания объектов (более 40 объектов, содержащих не менее 20 свойств и связей за час) и удобство работы с единой базой, в которой можно гибко комбинировать данные для сравнения. При этом оценила пользовательский интерфейс как “необычный”, “не интуитивный”, требующий понимания и адаптации (особенно консольный ввод). Кроме того, возникали постоянные проблемы с программными ошибками, которые значительно замедляли процесс и не позволяли концентрироваться на задаче в полной мере. Сотрудни- вующих в настоящий момент грубых ошибок в работе web-приложения позволило бы в 2 раза ускорить создание модели, так как 45% занятого времени отводилось на ресинхронизацию сервиса и попытки вставить необходимый тег.

Заключение

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

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