CC BY
90
Воронова О.В., Ильин И.В., Ильяшенко О.Ю.
ФОРМИРОВАНИЕ АРХИТЕКТУРЫ ДАННЫХ СЕТЕВЫХ КОМПАНИЙ FMCG-РИТЕЙЛА НА ОСНОВЕ МОДЕЛИРОВАНИЯ ОСНОВНЫХ БИЗНЕС-ПРОЦЕССОВ (НА ПРИМЕРЕ БИЗНЕС-ПРОЦЕССА «ЗАКУПКА»)
Аннотация. В статье рассмотрен процесс формирования архитектуры данных сетевых компаний FMCG-ритейла на основе моделирования основных бизнес-процессов. Исследование проведено на примере бизнес-процесса «Закупка». В процессе исследования выявлены основные бизнес-процессы сетевых розничных компаний. Рассмотрена типовая структура бизнес-процесса «Закупка», представлена классификация основных документов в рамках анализируемого бизнес-процесса. На основе анализа подпроцессов процесса «Закупка» рассмотрены основные этапы разработки архитектуры данных, взаимосвязь отчетных документов и видов данных, архитектура данных (слой информационных систем). В результате исследования сформирована архитектура данных верхнего уровня, отражающая модель информационного обмена в соответствии с реализуемыми основными бизнес-процессами сетевых компаний FMCG-сегмента.
Ключевые слова. Документооборот, электронный обмен данными, архитектура данных, моделирование данных, бизнес-процесс, FMCG-сегмент, розничная торговля.
Voronova O.V., Ilyin I.V., Ilyashemko O.Y.
DATA ARCHITECTURE FORMATION IN FMCG CHAIN RETAILING COMPANIES BASED ON THE BASIC BUSINESS PROCESSES MODELING (THE CASE OF "PURCHASE" BUSINESS PROCESS)
Abstract. This article considers the process of data architecture construction for FMCG chain retailing companies based on the basic business processes modeling. The study is conducted on the example of the "Purchase" business process. During the study, basic business processes of chain retailing companies were identified. The paper also considers typical structure of the "Purchase" business process and suggests classification of basic documents within the business process analyzed. the analyzed business process. Following the analysis of the "Purchase" subprocesses, the article considers stages of data architecture development, interconnection between reporting documents and data types, as well as data architecture (information systems layer). As a result of the study, the authors construct top-level data architecture that reflects the infor-
ГРНТИ 06.71.15
© Воронова О.В., Ильин И.В., Ильяшенко О.Ю., 2019
Ольга Владимировна Воронова - кандидат экономических наук, доцент, доцент Высшей школы сервиса и торговли Института промышленного менеджмента, экономики и торговли Санкт-Петербургского политехнического университета Петра Великого.
Игорь Васильевич Ильин - доктор экономических наук, профессор, директор Высшей школы управления и бизнеса Института промышленного менеджмента, экономики и торговли Санкт-Петербургского политехнического университета Петра Великого.
Оксана Юрьевна Ильяшенко - кандидат педагогических наук, доцент, доцент Высшей школы управления и бизнеса Института промышленного менеджмента, экономики и торговли Санкт-Петербургского политехнического университета Петра Великого.
Контактные данные для связи с авторами (Воронова О.В.): 191023, Санкт-Петербург, Новороссийская ул., 50 (Russia, St. Petersburg, Novorossiyskaya str., 50). Тел.: 8 (981) 711-02-11. E-mail: [email protected]. Статья поступила в редакцию 11.09.2019.
mation interchange model in accordance with the basic business processes of the FMCG chain retailing companies.
Keywords. Document management, electronic data interchange, data architecture, data modeling, business process, FMCG segment, retail.
В настоящее время в условиях интенсивного развития сетевой розничной торговли новые технологии позволяют крупным торговым компаниям предоставлять своим потребителям весь спектр возможностей получить то, что им необходимо, максимально удобным для них способом. Продолжают эффективно работать розничные компании, ассортимент которых построен на максимальном закрытии потребностей за счет комплементарных продуктов и партнерских услуг. Тем не менее, даже в условиях относительной стабильности экономической ситуации в розничной торговле, внешние резервы роста сетевых компаний FMCG-сегмента постепенно исчерпывают себя. Особое внимание в этой ситуации руководство сетевых компаний начинает уделять поиску внутренних резервов роста. К таким резервам, в условиях цифровизации розничной торговли, следует отнести оптимизацию документооборота сетевых компаний FMCG-сегмента [5].
Особое значение совершенствование системы документооборота приобретает в условиях оптимизации бизнес-процессов, поскольку даже незначительные изменения в бизнес-процессах (основных, управляющих и/или обеспечивающих) влекут за собой неизбежное изменение в документообороте компании, что, в свою очередь, формирует новые требования к архитектуре данных сетевой компании FMCG-сегмента. Таким образом, осуществлять разработку архитектуры данных целесообразно на основе моделирования основных бизнес-процессов. В сетевых компаниях FMCG-ритейла, как правило, выделяют четыре основных бизнес-процесса [4]: А1 Закупка; А2 Логистика; А3 Маркетинг; А4 Продажи. Типовая структура бизнес-процесса «Закупки» сетевых компаний FMCG-сегмента представлена на рисунке 1.
На первом этапе бизнес-процесса «Закупка» осуществляется подготовка прогнозов цен на период. Для эффективной деятельности необходимо проанализировать цены по всем каналам распределения -у непосредственных производителей, дистрибьюторов, конкурентов и т.д., поскольку только понимая ценообразование производителя, можно оценить объективность цен и определить стратегию переговоров с потенциальными поставщиками товаров. Для эффективной организации процесса закупок необходимо разработать и согласовать с постоянными поставщиками график поставок. Графики поставок требуют соблюдения дисциплины поставок, позволяют свести к минимуму складские запасы и, как следствие, понизить издержки на закупочную логистику.
На втором этапе бизнес-процесса «Закупка» осуществляется выбор потенциальных поставщиков товаров FMCG-сегмента, так как от правильного выбора поставщика зависит в конечном итоге не только цена, но и стабильность поставок, обеспечение гарантий поставки в соответствии с заказом, сервисное обслуживание, продвижение товара и многое другое. Взаимодействие с поставщиками, как правило, начинается на порталах сетевых компаний. Для участия в отборе производителю необходимо зарегистрироваться в информационной системе сети на сайте, получить ссылку в личный кабинет, внести данные по всем производимым товарам и разместить коммерческое предложение. Коммерческое предложение проходит верификацию, товары производителя попадают в тендерную таблицу и ранжируются системой, причем в верхние строки выводятся товары, имеющие лучшие показатели по прогнозу продаж, маржинальности, соответствию критериям качества (на основании данных Роскаче-ства) и т.д. Тендерная таблица постоянно обновляется.
В случае успешного участия потенциальных поставщиков в конкурсном отборе, следующим этапом бизнес-процесса «Закупка» становится заключение договора [1]. С каждым поставщиком и/или производителем в ходе переговорной кампании глубоко прорабатываются условия сотрудничества, ассортимент и программы продвижения. Важным разделом договора являются условия платежа, такие как предоплата, частичная предоплата, отсрочка платежа, поставка товара под реализацию. Совместно с поставщиками выстраивается сбалансированная структура ассортимента. За основу берутся данные о продажах в разных регионах присутствия сетевой компании, а далее производится тонкая настройка ассортимента для каждой сети в зависимости от региона, формата, позиционирования и запросов потребителей.
Типовая структура бизнес-процесса «Закупка»
-► А 1.1 Планирование закупок товаров
-► А 1.1.1 Подготовка прогнозов цен на товары на период
-► -► -► А1.1.2 Расчет потребности товаров на период
А 1.1.3 Формирование графика поставок товаров на период
А.1.14 Подготовка плана обязательств перед поставщиками товаров на период
-► А 1.2 Выбор поставщиков
-► -► -► -► А1.2.1 Анализ рынка поставщиков товара
А1.2.2 Выявление возможных условий работы с поставщиками товаров
А1.2.3 Оценка надежности поставщиков товаров
А1.2.4 Проведение конкурсного отбора поставщиков товаров
-► А 1.3 Заключение договора с поставщиком товара
-► А1.3.1 Подготовка договора с поставщиком товара
-► -► А1.3.2 Юридический аудит договора с поставщиком товаров
А1.3.3 Подписание договора с поставщиком товара
-► А 1.4 Оперативное управление поставками товара
-► -► -► -► А1.4.1 Поступление товаров
А1.4.2 Контроль выполнения условий договора с поставщиком товаров
А1.4.3 Претензионная работа с поставщиками товаров
А1.4.4 Возврат товаров поставщикам
-► А 1.5 Оценка поставщиков товара
-► -► -► А 1.5.1 Анализ регулярности поставок товаров поставщиком
А1.5.2 Анализ качества товаров, получаемых от поставщика
А 1.5.3 Уточнение критериев отбора поставщиков ресурсов
Рис. 1. Типовая структура бизнес-процесса «Закупка»
Следующим важным этапом бизнес-процесса «Закупка» является оперативное управление поставками, которые осуществляются, как правило, в распределительные центры сети, непосред-
ственно снабжающие товарами розничные точки продаж. На этом же этапе осуществляется претензионная работа с поставщиками и возврат товара. Большое значение имеет договор, поскольку взыскать претензии по неисполнению договора предприятие сможет только в том случае, если он законодательно признан юридически правомочным. В условиях цифровой трансформации реализация бизнес-процесса «Закупка» становится невозможной в отрыве от современных информационных технологий. Наибольшее распространение при взаимодействии сетевых компаний с поставщиками товаров получил электронный обмен данными [4]. В настоящее время большинство сетевых компаний FMCG-ритейла уже активно работают с системой электронного обмена данными EDI, причем в последние годы количество их партнеров, подключившихся к данной системе, неуклонно возрастает. При этом, подключение партнеров, интеграцию систем, преобразование и передачу сообщений между партнерами осуществляют специализированные компании - EDI провайдеры [6].
Завершающим этапом бизнес-процесса «Закупка» является оценка поставщиков, в том числе анализ регулярности поставок товаров, оценка качества товаров и, как результат этого, уточнение критериев отбора поставщиков товаров FMCG-сегмента. Для расширения базы потенциальных поставщиков и повышения конкуренции между ними необходимо регулярно проводить исследования рынка производителей и дистрибуторов. Следует заметить, что эти исследования проводятся на базе анализа больших данных, омниканальности, цифровизации внутренних процессов и выстраивания цепочки поставок с целью максимально быстрого удовлетворения потребности клиентов.
Классификация основных документов, используемых в рамках бизнес-процесса «Закупка» представлена на рисунке 2 [5]. Следует заметить, что система документооборота сетевых торговых компаний в рамках бизнес-процесса «Закупка» существенно зависит от места распределительных центров, осуществляющих обработку входящих грузов и их перераспределение для отправки по отдельным розничным точкам продаж, в структуре сетевых торговых компаний [7].
На сегодняшний день на практике возможны следующие варианты принадлежности распределительных центров:
• распределительный центр может входить в организационную структуру сетевой торговой компании наряду с теми розничными точками продаж, которые он обслуживает;
• распределительный центр может быть частью холдинга или большой торговой сети, объединяющей несколько юридических лиц. То есть, с одной стороны, он обслуживает только участников одного холдинга, но, с другой, центр и обслуживаемые им розничные точки продаж (супер-, ги-пермаркеты и т.д.) являются хоть и взаимосвязанными, но отдельными юридическими лицами. Поэтому движение товара между ними фактически подразумевает уже не внутреннее перемещение, а переход права собственности от одной организации к другой;
• распределительный центр может принадлежать сторонней компании, чаще всего логистической. В этом случае речь может идти о 3PL (Third Party Logistics) услугах, то есть о предоставлении специализированной логистической компанией различным торговым организациям определенного комплекса логистических услуг: управление заказом, доставка груза от поставщика до распределительного центра логистической компании, грузообработка товаров, их хранение и отгрузка клиентам.
В зависимости от принадлежности распределительных центров сетевой компании перечень документов и направление потоков их движения в системе общего документооборота может существенно различаться. Таким образом, совокупное влияние всех внешних и внутренних факторов, оказывающих существенное влияние на систему документооборота, приводит к необходимости формирования архитектуры данных сетевой компании FMCG-сегмента.
Рассмотрим основные этапы разработки архитектуры данных на примере бизнес-процесса «Закупка». На основе анализа подпроцессов процесса «Закупка», можно сформировать архитектуру данных, отражающую модель информационного обмена в соответствии с реализуемыми бизнес-процессами. Прежде чем приступать к формированию архитектуры данных, необходимо знать, какие требования и ограничения предъявляются к данным, обеспечивающим информационное со-
провождение рассматриваемого бизнес-процесса, что является источником данных, поддерживающих данный процесс. Для выявления требований необходимо проводить структурированные интервью с владельцами процесса и с сотрудниками, непосредственно задействованными в реализации процесса.
Классификация основных документов, используемых в рамках бизнес-процесса «Закупка»
-► Формирование реестра поставщиков товаров и оперативное управление
-► Договоры с поставщиками товаров
-► -► Дополнительные соглашения
Рекламации
-► Поступление товаров
-► -► -► -► -* Товарно-транспортная накладная от поставщика товара
Счет-фактура от поставщика товара
Акт приемки товара (с подписями передающей и принимающей сторон)
Ведомость или акт установления расхождений по количеству и качеству
Товарный отчет (ежедневно)
-► Перемещение товарно-денежных ценностей
-► -► Накладные по форме ТОРГ-12 или 1-Т (ТТН) в случае транспортной доставки, с указанием формы оплаты.
Накладные на возврат товара
-► -► Накладные на перевозку товара
Акты на списание товара
Рис. 2. Классификация основных документов, используемых в рамках бизнес-процесса «Закупка»
Детальный анализ подпроцессов показал, что данные, сопровождающие процесс, можно разделить на три категории: данные, получаемые из транзакционной системы (например, данные о поставщике, данные о товаре и т.д.); данные, формируемые на основе проведенной операции, например, данные о проведенной закупке - объем закупки, цена, по которой была проведена закупка товара, и т.д.; данные, полученные из внешних источников: из социальных сетей или из внешних баз, например, данные о поставщиках для проведения анализа рынка поставщиков.
Первый и второй типы выделенных данных формируются в результате функционирования транзакционной системы. На основе этих данных функционал транзакционной системы позволяет сформировать требуемую отчетность, являющуюся документальным сопровождением подпроцессов. В таблице 1 представлен пример взаимосвязи отчетных документов и видов данных.
Таблица 1
Взаимосвязь отчетных документов и видов данных
Отчетность Вид данных
О поставщиках О товарах О закупке
Отчет по итогам анализа рынка поставщиков товаров +
Карточка товара +
Товарная накладная + + +
Счет-фактура + + +
Договор организации с поставщиком + + +
График поставок товаров на период + + +
План обязательств перед поставщиками товаров на период + + +
В представленном перечне присутствуют этапы практически всех подпроцессов процесса «Закупка: планирование закупок товаров; выбор поставщиков; заключение договора с поставщиком товара; оперативное управление поставками товара. Второй и третий тип данных используются для загрузки в BI приложение с целью формирования различной аналитики, в том числе: расчет потребности товаров на период; формирование графика поставок товаров на период; анализ рынка поставщиков товаров; анализ регулярности поставок товаров поставщиком. Из этого следует, что данные, поддерживающие все подпроцессы, должны быть аккумулированы в одной транзакционной системе. В случае использования разных транзакционных систем, необходима интеграция данных между этими системами. Еще одним важным аспектом является возможность загрузки данных из транзакционных систем и из внешних источников в BI приложение.
На основании вышеизложенного можно сформулировать следующие общие требования, предъявляемые к архитектуре данных: возможность автоматической обработки информации, сопровождающей все подпроцессы; необходимость учета ситуаций, когда в рамках одного факта закупки у поставщика приобретаются товары в соответствии с определенной номенклатурой, т.е. более одного вида товара; единый формат данных, используемых для реализации всех подпроцессов; целостность данных, непротиворечивость данных; возможность формирования отчетности, например, графика поставок на период, договора с поставщиком товаров и т.д.; возможность интеграции с BI приложением, позволяющим провести аналитику по различным срезам (анализ рынка поставщиков товаров, анализ регулярности поставок товаров поставщиком, возможность загрузки данных из внешних источников).
На рисунке 3 представлен верхний уровень архитектуры данных бизнес-процесса «Закупки» сетевых компаний FMCG-сегмента.
Рассмотрим более детально архитектуру данных транзакционной системы учета закупок / возвратов товаров. Детализация архитектуры на следующем уровне предполагает создание модели данных для транзакционной системы [9]. Для проектирования моделей данных транзакционной системы чаще всего применяется методика моделирования методом «сущность-связь» (ER-modeling) с использованием таких понятий, как: сущности, взаимосвязи между ними и атрибуты для описания свойств сущностей и связей.
На первом этапе моделирования выявим сущности рассматриваемой предметной области. Сущности представляют собой абстрактное представление объектов реального мира с фиксированным набором свойств. Сущность обладают некоторыми свойствами, которые описываются с помощью атрибутов. Атрибут или набор атрибутов, который однозначно идентифицирует каждый экземпляр сущности, называют первичным ключом данной сущности (Primary key, PK).
Между сущностями, так же, как между реальными объектами, существуют осмысленные ассоциации или связи. Связи между сущностями устанавливаются посредством внешних ключей (Foreign key, FK) - атрибутов, которые являются составляющей первичного ключа родительской сущности и передаются в дочернюю [2]. При этом необходимо учесть степень связи сущностей и класс их принадлежности, которые, в свою очередь, определяются на основе анализа диаграмм ER-экземпляров соответствующих сущностей.
Корпоративный портал компании
Формирование аналитических отчетов
Планы закупочных процедур
Мониторинг выполнения договоров закупки
"Ж"
Данные для комплексного анализа процесса Закупки
Витрины данных
Уровень надежности поставщиков
Регулярность поставок товаров
Количество возвратов, причины
-Ж-
I
Данные для анализа показателей процесса Закупки
Интерфейс приложений
Уровень надежности поставщиков
Формирование договоров
Хранилище данных
Данные о поставках
-^—
Данные о по-
ставках
Данные для
рейтинга поставщиков
-А-
Данные для формиров. прогнозов
А
Данные для формирования отчетности
Данные о поставщиках
Данные о ценах на товары
Очистка, преобразование и загрузка данных из ОЫР систем в Хранилище данных
-А-
I
Данные о надежности поставщиков
А
Обработка данных для предоставления отчетности А
Факты и метрики
Данные для формирования
I
запросов
Внешние источники данных
Данные о поставщиках из внешних источников
Транзакционная система учета закупок
Справочник Данные Справочник
поставщиков о закупке товаров
Рис. 3. Архитектура данных бизнес-процесса «Закупки» (слой информационных систем)
Степень связи является характеристикой связи между сущностями, которая может быть типа: 1:1 («один-к-одному»), 1:М («один-ко-многим») или М:1 («многие-к-одному»), №М («многие-ко-многим») [8]. В результате моделирования методом «сущность-связь» сформируем ЕЯ-модель в виде диаграммы «сущность-связь». В ходе анализа предметной области, а также сформулированных требований и ограничений, были выявлены следующие сущности: товар; поставщик; менеджер; бизнес-регион. Между выявленными сущностями определены следующие связи:
• сетевая компания инициирует торговую операцию (закупку или возврат товара). Компания может совершать много закупок или возвратов товара, но каждая закупка/возврат товара может быть инициирована только Компанией. Поставщиков товара у Компании, реализующих поставку товара в соответствии с договором, много. Связь «один-ко-многим»[10];
• факт торговой операции (закупка/возврат) содержит номенклатурную позицию. Одна позиция может отражаться во множестве торговых операций, при этом одна торговая операция, отражаемая в транзакционной системе, может содержать много позиций номенклатуры. Связь «многие-ко-многим»;
• закупка или возврат осуществляется со склада или на склад. Один склад может осуществлять отгрузку товара по множеству торговых операций, но каждая торговая операция учитывает в системе один склад. Связь «многие-к-одному»;
• поставщик осуществляет свою деятельность в определенном бизнес-регионе, но один бизнес-регион может быть местом деятельности для множества поставщиков. Связь «многие-к-одному»;
• поставщик обслуживается только менеджером, который за ним закреплен. При этом один менеджер может работать более чем с одним Постащиком. Связь «многие-к-одному»;
• менеджер работает только в одном отделе Компании, однако в одном отделе Компании работают множество менеджеров. Связь «многие-к-одному».
На рисунке 4 представлена ER-диаграмма данных в нотации П. Чена. На основе концептуальной модели в дальнейшем может быть построена логическая модель данных бизнес-процесса «Закупка». В качестве примера, в таблице 2 представлен список основных сущностей и их атрибуты. Если в логическую модель данных включить сущность «Торговая операция» в виде, представленном в таблице 2, это приведет к нарушению одного из правил целостности данных: возникнут аномалии добавления, удаления и редактирования данных. Это связано с тем, что сущность «Торговая операция» (закупка/возврат) не приведена ко второй нормальной форме. В этой ситуации требуется декомпозиция данной сущности на две сущности, например, сущность «Закупки» (Purchases) и сущность «Факт» (Fact).
Рис. 4. Модель «сущность-связь» в нотации П. Чена
Сущность «Товар» характеризуется такими атрибутами как «ТоварнаяГруппа» и «СтранаПроизво-дитель. С целью избежать аномалий добавления и удаления данных предлагается в логической модели данных выделить две дополнительные сущности - справочники «Товарная группа» (Classifier) и «Страна-производитель» товара (Country) [3]. В результате формирования логической модели можно дополнить архитектуру данных верхнего уровня, включив слой ИТ-инфраструктуры. Это позволит сформировать целостную модель архитектуры данных, начиная от отношений базы данных, которая лежит в основе транзакционной системы и завершая верхним уровнем - уровнем данных корпоративного портала организации, представленную на рисунке 5.
Таким образом, архитектура хранилища данных должна быть достаточно гибкой, чтобы расти и меняться с потребностями бизнеса, поскольку требования сетевого ритейла FMCG-сегмента меняются под влиянием рынка достаточно быстро [1]. На сегодняшний день уже недостаточно случайных усилий по нормализации архитектуры корпоративных хранилищ данных, а несогласованность методов моделирования неизбежно приводит к напряженной реализации решений.
Таблица 2
Сущности и атрибуты бизнес-процесса «Закупки»
Сущность Описание Атрибут Название в модели
Товар Товарная позиция, которая заказывается у Поставщика или возвращается на склад Поставщика Код продукта Product ID
Наименование NameProduct
Артикул VendorCode
Товарная группа NameClass
Страна-производитель NameCountry
Поставщик Партнер Организации, поставляющий товар Поставщик ГО (РК) ID SP
Наименование NameSP
БизнесРегион NameRegion
Адрес Address
Телефон Phone
Мобильный телефон MobilePhone
ИНН INN
Банковский счет BankAccount
УровеньНадежности SupplierReliability
ДополнительнаяИнформация AdditionalInformation
Бизнес-регион Бизнес-регион, в котором осуществляет свою деятельность поставщик БизнесРегионы ГО (РК) Region ID (PK)
Наименование Name_Region
Менеджер Менеджер компании, который обслуживает партнера и работает в организации КодМенеджера Manager ID (PK)
Фамилия менеджера SurnameManager
Имя менеджера FirstnameManager
Отчество менеджера LastnameManager
Код департамента (РК) Department ID
Департамент Департамент, в котором проводится закупка и работают менеджеры Код департамента (РК) Department ID
Наименование NameDepartment
Торговая операция Факт закупки (возврата) товара, характеризующийся количественными показателями торговой деятельности сетевой компании КодФактаПоставкиТовара (РК) ID Fact
КодТовара ГО (РК) Product ID
КодПоставщика ГО (РК) ID SP
ТорговаяОперация Arrival
ДатаЗаключенияДоговора DateContractFirst
ДатаЗавершенияДоговора DateContractEnd
КодМенеджера (РК) Manager ID
КоличествоПоДоговору Quantity Contract
ЦенаЗакупки Price
Количество Поставки Quantity
ДатаПоставки DateFact
Корпоративный портал компании
Формирование аналитических отчетов Планы закупочных процедур Мониторинг выполнения договоров закупки
-Ж-
I
Данные для комплексного анализа процесса Закупки
Витрины данных
Уровень надежности поставщиков
Регулярность поставок товаров
Количество возвратов, причины
-А-
Данные для анализа показателей процесса Закупки
Интерфейс приложений
Уровень надежности поставщиков
Формирование договоров
Хранилище данных
Данные о поставках
Данные для
рейтинга поставщиков
Данные о поставках
-Ф-
I
Данные о поставщиках
Данные для формиров. прогнозов А -
Данные для формирования отчетности
Данные о ценах на товары
Очистка, преобразование и загрузка данных из ОЫР систем в Хранилище данных
Обработка данных для предоставления отчетности
■-Д-
Факты Данные^ для формирования
и метрики запросов
Данные о надежности поставщиков
Внешние источники данных
Данные о поставщиках из внешних источников
Транзакционная система учета закупок
Справочник поставщиков Данные о закупке Справочник товаров
Данные о надежности поставщиков
Базы данных поставщиков
Статистические отчеты по поставщикам
Отзывы о работе с поставщиками
->
Бизнес регион
Данные для формирования запросов
Поставщики
Базы данных процесса
Менеджеры
Ф з т
а а о
к к в
т у а
ы п р
к ы
и
Товарная группа
Страна про-исхожд.
Рис. 5. Архитектура данных (верхний уровень) бизнес-процесса «Закупка»
Итак, в процессе исследования были выявлены основные бизнес-процессы сетевых розничных компаний. Рассмотрена типовая структура бизнес-процесса «Закупка», представлена классификация основных документов, в рамках анализируемого бизнес-процесса. На основе анализа подпроцессов процесса «Закупка» рассмотрены основные этапы разработки архитектуры данных, взаимосвязь от-
четных документов и видов данных, архитектура данных (слой информационных систем). В результате исследования сформирована архитектура данных верхнего уровня, отражающая модель информационного обмена в соответствии с реализуемыми основными бизнес-процессами сетевых компаний
FMCG-сегмента.
ЛИТЕРАТУРА
1. Портал о ритейле. [Электронный ресурс]. Режим доступа: https://www.retail.ru/articles (дата обращения 10.09.2019).
2. Барсегян А.А., Куприянов М.С., Степаненко В.В., Холод И.И. Методы и модели анализа данных OLAP и DataMining. СПб.: БХВ-Петербург, 2004.
3. Воронова О.В., Ильин И.В. Агрегированная модель мотивационного расширения для построения архитектурных решений сетевого ритейла FMCG-сегмента // Экономика и управление. 2019. № 2 (160). С. 7S-S5.
4. Воронова О.В., Ильин И.В. Референтная модель бизнес-процессов верхнего уровня для построения архитектурных решений сетевых компаний FMCG-ритейла // Экономика и управление. 2019. № 5 (163). С. S1-SS.
5. Воронова О.В., Харева В.А. Документооборот в системе управления сетевых торговых компаний // Научный вестник Южного института менеджмента. 2019. № 2 (26). С. 5-11.
6. Ильина О.В., Стародубцев Г.Ю., Давлятова М.А. Сертификация электронных бизнес-систем // Международный технико-экономический журнал. 2017. № 2. С. 72-76.
7. Ильина О.В. Управление экономическими ресурсами розничного торгового предприятия // Экономика и управление. 2007. № 3 (29). С. SS-93.
S. Мартишин С.А., Симонов В.Л., Храпченко М.В. Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench: методы и средства проектирования информационных систем и технологий. М.: Форум, 201S.
9. Спирли Э. Корпоративные хранилища данных. Планирование, разработка, реализация. Т. 1. М.: Вильямс, 2001.
10. Borremans A.D., Zaychenko I.M., Iliashenko O.Y. Digital economy. IT strategy of the company development // MATEC Web of Conferences, 201S. С. 01034.
