Моделирование бизнес процесса интернет магазина

Содержание:

Введение

Электронная торговля в виртуальном магазине основывается на той же структуре, что и традиционная торговля. Преимущества виртуального магазина перед реальным очевидны. Уменьшается численность персонала за счет сокращения объема взаимодействия с клиентами, аренда оборудования или услуг виртуального-хостинга у хостинг провайдеров и размещение списка продаваемых товаров в виде каталога на сайте дешевле и проще аренды торговых помещений и размещения товаров на полках, нет нужды в кассовом обслуживании и так далее. Оплата товаров и услуг по доставке в виртуальных магазинах осуществляется с помощью различных платежных систем работающих в сети интернет. Их подключение к процессинговой системе проведения платежей осуществляется программистом при помощи интерфейсов программирования приложений (API – application programming interface) предоставляемых этими сервисами, примеры таких систем: «Paypal», «QIWI», «Merchant WebMoney Transfer», «Яндекс.Деньги» (перечисленные системы имеют возможность привязки кредитных карт к счету в системе), и другие системы.

Интернет-магазин называют также виртуальным магазином. К нему полностью подходит определение виртуального предприятия. Иначе говоря, виртуальный магазин – это сообщество территориально разобщенных сотрудников магазина (продавцов, кассиров, менеджеров-консультантов) и покупателей, которые могут общаться и обмениваться информацией через электронные средства связи при полном (или минимальном) отсутствии личного прямого контакта. Покупки через интернет – это процесс, при котором потребители непосредственно покупают товары или различного рода услуги через интернет, осуществляя оплату при помощи платежных систем или напрямую с банковской карточки. Консультирование может осуществляться с помощью систем: мгновенного обмена сообщениями, таких как ICQ, Skype и др., электронной почты, а также по телефону используя IP-телефонию и другие доступные средства связи.

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

Цель данной работы – проектирование информационной системы интернет- магазина.

Для достижения поставленной цели нужно выполнить ряд задач:

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

1. Описание предметной области

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

Сотрудник каждого отдела должен иметь свое автоматизированное рабочее место, состоящее из ЭВМ с определенным набором программ. Так как интернет-магазин будет доступен по средствам веб- браузера, не требуется закупать мощные рабочие станции, для комфортной работы сотрудникам будет достаточно иметь бюджетные модели ПК.

Оплата заказов клиентами осуществляется при помощи платежных систем, поддерживающих привязку к банковской карте, а именно: “PayPal” и “Яндекс.Деньги”. Все вырученные средства поступают на счет компании и затем обрабатываются сотрудниками бухгалтерского отдела. Данные обо всех финансовых операциях будут экспортироваться в корпоративную информационную систему 1С: Предприятие или другую систему, выбранную для эксплуатации. Но это отдельная задача, в этой работе будет рассматриваться только проектирование и разработка непосредственно веб-сайта виртуального магазина и его установка (развертывание) на производственном сервере.

Почтовые отправления осуществляются с помощью различных компаний по отправке почты, таких как EMS, DHL, “Почта России” и других на выбор клиента. Клиент должен оплатить стоимость доставки самостоятельно, если ее стоимость не включена в стоимость товара. Выбор способа доставки осуществляется клиентом во время оформления заказа на веб-сайте. После отправки товара клиенту выдается номер почтового отправления (почтовый идентификатор), по которому можно отслеживать текущий статус и местоположение посылки. Денежные средства за оплаченный товар резервируются до тех пор, пока системой отслеживания почтовых отправлений не будут получены данные о том, что клиент получил свою посылку.

На предприятии, осуществляющем торговлю через интернет, обычно присутствуют следующие отделы:

• отдел продаж
• отдел маркетинга
• отдел закупок
• бухгалтерский отдел
• отдел информационных технологий
• почтовый отдел

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

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

Сотрудники отдела закупок отвечают за закупку различных товаров у поставщиков для осуществления их продажи в виртуальном магазине, в их обязанности также входит поиск поставщиков и связь с ними.

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

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

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

1.2. Функциональная модель бизнес-процессов

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

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

Моделирование деловых процессов, как правило, выполняется с помощью case- средств. К таким средствам относятся: BPwin (изготовитель программного продукта компания PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. В данной работе для создания диаграмм IDEF0 был использован программный продукт BPwin.

1.2.1. Функциональные диаграммы

Функциональное моделирование IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов.

Построение модели информационной системы начинается с описания функционирования системы в целом в виде контекстной диаграммы. Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Данная модель используется при организации бизнес- проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

Рассмотрим контекстную диаграмму «Работа интернет- магазина» (рис. 1).

Рисунок 1 – Контекстная диаграмма «Работа интернет-магазина»

Взаимодействие системы с окружающей средой описывается с помощью входов – «Товары» и «Заказы» совершаемые клиентами, выходов – «Обслуженный клиент», «Не обслуженный клиент» и «Доходы», управления – «Документы», и ресурсов необходимых для решения поставленной задачи – «Сотрудники», «ПО» и «ЭВМ».

Товары – закупленные для продажи товары.

Заказы – заказы совершаемые покупателями.

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

Сотрудники – персонал магазина, распределенный по отделам.

Обслуженный клиент – клиент получивший товар или предоставленную услугу.

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

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

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

Далее рассмотрим диаграмму декомпозиции «Организовать работу интернет-магазина» (рис.2)

Как видно из диаграммы, весь процесс функционирования виртуального магазина разбивается на три основные задачи:

1. Закупка товаров – закупка товаров, которые будут в дальнейшем продаваться в магазине, у поставщиков;
2. Хранение – обеспечение хранения закупленных товаров на продовольственном складе, отправка товаров по почте при поступлении заказов;
3. Продажа – непосредственно продажа товаров. Так как система оформления заказа будет полностью автоматизирована, в основные обязанности сотрудников отдела продаж будут входить консультирование клиентов, изменение статусов заказов и разрешение возникающих спорных ситуаций.

Рисунок 2 – Контекстная диаграмма «Организовать работу интернет-магазина»

Произведем дальнейшее разбиение на подсистемы процесса «Закупка товаров».

Рассмотрим диаграмму декомпозиции процесса «Закупка товаров» (рис.3). Опишем процессы, представленные на данной диаграмме декомпозиции.

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

Составить перечень закупок – сотрудник отдела закупок, основываясь на данных отчета о состоянии рынка, решает какие товары следует закупить и составляет перечень закупок.

Найти поставщиков – сотрудник отдела закупок просматривает данные о поставщиках, анализируя установленные ими, оптовые цены на товары которые находятся в перечне закупок.

Сформировать заявку на закупку – исходя из перечня необходимых закупок и списка поставщиков, формируется заявка на закупку товаров оптом.

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

Рисунок 3 – Диаграмма декомпозиции «Закупка товаров»

Далее продолжим декомпозицию диаграммы «Организовать работу интернет- магазина», произведем дальнейшее разбиение на подсистемы процесса «Хранение» и построим соответствующую функциональную диаграмму (рис. 4)

Рисунок 4 – Диаграмма декомпозиции «Хранение»

Опишем процессы, представленные на данной диаграмме декомпозиции.

Получить товар – кладовщик получает закупленные у поставщиков товары.

Отсортировать товар – сотрудник склада сортирует товар и передает список товаров, которые есть на складе, системному администратору.

Обеспечить хранение – сотрудники склада осуществляют контроль над хранением товара.

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

Теперь произведем разбиение на подсистемы процесса «Продажа» и рассмотрим диаграмму декомпозиции этого процесса.

Опишем процессы, представленные на диаграмме декомпозиции процесса «Продажа» (рис. 5).

Рисунок 5 – Диаграмма декомпозиции «Продажа»

Сформировать заказ – клиент через сайт формирует заказ, при этом он должен принять пользовательское соглашение (если еще не был зарегистрирован на сайте). Затем клиент оплачивает счет.

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

Отследить получение посылки – часто случается, что товар может затеряться во время доставки, поэтому нужно отслеживать состояние посылки до момента ее вручения адресату.

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

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

1.2.2. Анализ функциональной модели

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

Оформление заказа клиентом – чтобы оформить заказ клиент должен будет зарегистрировать аккаунт на веб-сайте, в процессе регистрации он вводит свои данные, такие как: адрес доставки, контактный e-mail адрес, фамилию, имя и другое. Просматривая каталог товаров на веб-сайте, клиент начинает оформлять заказ. Выбрав товары, которые клиент хочет приобрести, он кликает на кнопку “Добавить в корзину”, после выбора всех необходимых товаров клиент нажимает кнопку “Оформить заказ”, выбирает на следующей диалоговой странице способ доставки и способ оплаты. Когда заказ оформлен, система автоматически посылает данные о сделанном заказе по электронной почте в почтовый отдел, сотрудники которого после получения письма должны сформировать посылку по данным заказа и сделать почтовое отправление.

Отслеживание посылки – когда сотрудник почтового отдела отправляет заказ, он заносит номер для отслеживания посылки в данные оформленного заказа. Клиент сможет отслеживать местоположение отправленного ему товара по уникальному почтовому идентификатору посылки (распространенно сокращение трек-номер посылки).

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

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

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

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

Опишем, как происходит обработка платежа через платежную систему. Типичный вариант использования: пользователь, после оформления заказа, кликает на кнопку оплаты и перенаправляется на сайт платежной системы (при этом, в ссылке передается маркер безопасности будущей транзакции и идентификатор получателя платежа), где он непосредственно осуществляет платеж. Если платежная транзакция завершается успешно, то, как правило, система возвращает ответ в виде специально сформированного xml файла, который содержит результат транзакции и другие сведения, необходимые для идентификации состояния платежа виртуальным магазином. Подключение систем оплаты сводится к созданию модуля осуществляющего синтаксический анализ структуры xml файла возвращенного платежной системой после проведения транзакции.

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

2. Моделирование предметной области

2.1 Диаграмма вариантов использования

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

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

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

Сценарии прецедента выделяют в отдельные прецеденты, связанные отношением включает (include), при выполнении следующих условий:

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

Взаимосвязь расширяет (extend) предоставляет дополнительную возможность в том случае, когда основной прецедент нельзя модифицировать. Основная идея заключается в создании расширяющего или дополнительного прецедента, в котором описывается, где и при каких условиях он расширяет некоторый основной прецедент.

Рассмотрим диаграмму прецедентов “Интернет-магазин”, которая приведена на рис.5.

Рисунок 5 – Диаграмма прецедентов “Интернет-магазин”

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

Основные прецеденты включают в себя:

• Управление аккаунтом. Он расширяется прецедентами “Авторизация” – процесс прохождения авторизации на сайте, “Регистрация” – регистрация клиента на сайте, ”Управление аккаунтом” – редактирование профиля пользователя, это может быть изменение личных данных, пароля доступа, адреса доставки и другое.
• Просмотр каталога – просмотр клиентом магазина товаров доступных в продаже. Прецедент связан отношением расширения с прецедентами “Получить консультацию” – связаться с менеджером и узнать дополнительную информацию о продукте, “Оценить продукт” – возможность поставить оценку просматриваемому продукту, “Оставить отзыв” – возможность оставить комментарий к продукту и “Искать продукт” – возможность поиска продукта по ассортименту магазина.
• Оформление заказа. Этот прецедент включает в себя прецеденты “Добавление товара в корзину” (тип связи “include”), “Оплатить” – непосредственно проведение транзакции через платежную систему и “Управлять корзиной” – возможность просмотра товаров находящихся в корзине и управление ими (изменение количества, удаление конкретного товара из корзины).
• Консультировать клиента. Клиент может получать консультации как на веб-сайте, так и с помощью систем обратной связи, например форма обратной связи, консультации через системы мгновенного обмена сообщениями и т.д. Консультацию осуществляет менеджер.
• Управление каталогом. Менеджер может управлять каталогом, добавлять новые категории товаров, новые товары, управлять информацией о товарах, редактировать их описание и другое.
• Обработать заказ. Менеджер управляет статусом заказа и указывает номер почтового отправления. В случае если клиент хочет что-либо изменить в заказе, менеджер может это сделать в интерфейсе управления заказами.
• Администрирование сайта. Веб-сайт нуждается в постоянном администрировании, так как малейший простой в случае сбоя может негативно сказаться на рейтинге магазина. Прецедент включает в себя добавление новостей на сайт, управление аккаунтами пользователей и сотрудников магазина.

Идеальные прецеденты — это развернутые прецеденты, выражающие общую сущность процесса без детализации их реализации. Проектные решения, особенно связанные с интерфейсом пользователя, при этом опускаются. Идеальный прецедент описывает процесс в терминах наиболее существенных видов деятельности и обоснований. Степень абстракции идеальных прецедентов может варьироваться, т.е. прецедент может быть идеальным в большей или меньшей степени.

Реальный прецедент описывает конкретное проектное решение по реализации идеального прецедента в терминах выбранной технологии. Описание реальных прецедентов аналогично описанию идеальных прецедентов.

Таблица 1

Описание прецедента регистрации пользователя

Название прецедента	Зарегистрироваться
Исполнитель	Клиент
Цель	Пройти процедуру регистрации на сайте
Основной успешный сценарий	Клиент переходит на веб-сайт магазина. Кликает кнопку зарегистрироваться. Вводит данные в регистрационную форму и нажимает кнопку отправить данные. На указанный адрес электронной почты поступает письмо содержащее информацию о регистрационных данных
Тип	Идеальный
Ссылки	Добавление нового пользователя, Авторизация, Отправка письма

Таблица 2

Описание прецедента регистрации пользователя

Название прецедента	Управление аккаунтом
Исполнитель	Клиент
Цель	Изменить данные профиля
Основной успешный сценарий	Клиент переходит на веб-сайт магазина, регистрируется. Осуществляет процедуру авторизации на сайте. Управляет данными в своем профиле. Система, взаимодействуя с БД, осуществляет изменение данных пользователя
Тип	Идеальный
Ссылки	Отправить на email уведомление о успешном изменении пароля, изменение данных пользователя в БД

Таблица 3

Описание прецедента Оформление заказа

Название прецедента	Оформление заказа
Исполнитель	Клиент
Цель	Оформить заказ
Основной успешный сценарий	Выбрать товары, которые нужно приобрести, нажать напротив товаров кнопку “добавить в корзину”. Повторять действия до тех пор, пока не будет укомплектован заказ. Затем нажать кнопку “Оформить заказ”. Пройти процедуру оплаты.
Тип	Идеальный
Ссылки	Обновить корзину, Авторизация платежа, Отправка данных о оплаченном заказе на email клиента и в почтовый отдел

2.2 Диаграмма последовательности

Диаграмма последовательности – диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML, является частной разновидностью диаграмм взаимодействий.

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

На рис. 6. изображена диаграмма последовательностей для прецедента просмотра продукта (расширение прецедента просмотра каталога).

Опишем, что на ней изображено. Пользователь с помощью клиента, в качестве которого выступает веб-браузер, переходит по ссылке на продукт, его браузер выполняет HTTP запрос типа GET. Обработчик URL адресов Django проверяет, что ссылка соответствует регулярному выражению, указанному в конфигурационном файле (urls.py). Если ссылка удовлетворяет заданному шаблону, обработчик URL вызывает функцию представления, передавая в качестве параметров имя представления и словарь GET запроса. В функции представления совершается запрос к классу модели на выборку продукта с id, указанным в URL. На выходе генерируется словарь (тип данных языка python) содержащий данные о запрашиваемом продукте. Далее в функции представления осуществляется операция визуализации (render) шаблона и пользователь получает ответ от сайта в виде страницы с продуктом.

На рис. 7. изображена диаграмма последовательностей для прецедента «Оформление заказа».

Рисунок 6 – Диаграмма последовательностей для прецедента “Просмотр продукта”

Покупатель после того как он сформировал виртуальную корзину нажимает на кнопку оформить заказ, веб-браузер отправляет HTTP запрос типа POST, содержащий данные о том какие товары находятся в корзине и их количество. После обработки запроса контроллером и обработчиком URL функция представления вызывает метод makeCheckout экземпляра класса Checkout (обработчик платежей). Экземпляр класса обработчика платежей вызывает метод createOrder класса Order (заказ). Затем этот класс вызывает метод класса OrderItem (отдельный экземпляр содержащийся в заказе) в который добавляются данные для каждого продукта содержащегося в виртуальной корзине (id продукта, количество, цена и id экземпляра класса Order), после того как все экземпляры класса созданы, класс Order вычисляет сумму заказа. Затем класс Order возвращает пользователю страницу предварительного просмотра заказа, после того как пользователь нажимает кнопку подтвердить вызывается метод makeCheckoutPayment, класс Checkout еще раз запрашивает данные заказа у класса Order, затем вызывается метод makePayment который создает класс Payment System API взаимодействующий с платежной системой. Далее этот класс возвращает результат оплаты классу обработчику платежей. Если платежная транзакция завершена успешно, то статус заказа меняется на “оплачен” (с этого момента в отделе доставки начинают формировать посылку для отправления). Пользователю возвращается страница с информацией об успешной оплате заказа.

Рисунок 7 – Диаграмма последовательностей для прецедента «Оформление заказа»

2.3 Диаграмма состояний

Описать поведение отдельно взятого объекта помогает диаграмма состояний. 

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

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

Рисунок 8 – Проверка заказа

Рисунок 9 – Диаграмма состояний заказа

Рисунок 10 – Ожидание проверки заказа

Рисунок 11 – Подтверждение заказа

2.4 Диаграмма деятельности

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

Если варианты использования ставят перед Системой цель, то диаграмма  деятельности показывает последовательность действий, необходимых для ее достижения.  Действия (action) это элементарные шаги, которые не предполагают дальнейшую декомпозицию.    

Рисунок 12 – Диаграмма деятельности для оформления заказа

Рисунок 13 – Диаграмма деятельности для оформления доставки

2.5 Диаграмма классов

На рис. 14 приведена концептуальная диаграмма классов, основанная на анализе предметной области. Она описывает структуру системы, показывая её классы, их атрибуты и методы, а также отношения между классами (их тип и кратность).

Основные типы связи:

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

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

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

Рисунок 14 – Концептуальная диаграмма классов

Экземпляры класса отзыв не могут существовать без продукта, к которому отзыв был оставлен, поэтому тип связи композиция.

Классы “Типы характеристик” и “Статусы заказа” словарные, в программном продукте будут использоваться в соответствии с шаблоном проектирования “Одиночка”, то есть во время работы приложения будет существовать единственный экземпляр каждого из этих классов. Класс “типы характеристик” будет хранить только названия характеристик, например: ширина, тип, размер, вес, цвет и т.д. Класс “Статусы заказа” хранит возможные статусы заказа, например: отправлен, обрабатывается, получен и т.д. На диаграмме представлены как перечисления.

Заключение

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

Работа состоит из введения, аналитической и практической части, заключения.

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

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

Для интернет- магазина приводятся диаграммы последовательности, деятельности, состояний, классов. При проектировании было использовано следующее программное обеспечение: средства построения UML диаграмм Enterprise Architect и AllFusion Process Modeler BPWin .

Список использованной литературы

1. Маклаков С.В. Создание информационных систем с ALLFusionModelingSuite 2003 / С.В. Маклаков – Москва.: ДИАЛОГ МИФИ – Москва, 2003. – 432 с.
2. Ларман К. Применение UML 2.0 и шаблонов проектирования / К. Ларман: пер. с англ. – Москва.: ООО «И. Д. Вильямс», 2007. – 736 с.
3. Буч Г. Язык UML. Руководство пользователя / Г. Буч, Д. Рамбо, А. Джекобсон: пер. с англ. – Москва.: ДМК, 2000. – 432 с.
4. Вендоров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: учеб. Пособие / А.М. Вендоров – Москва.:Финансы и статистика, 2002. – 192 с.
5. Проскурин Д.К. Проектирование информационных систем: учеб. Пособие / Д.К. Проскурин, М.В. Шитикова – Воронеж.: Государственный архитектурно- строительный университет – Воронеж, 2003. – 198 с.
6. Django. Разработка веб-приложений на Python / Д. Форсье [и др.].; пер. с англ.– СПб. : Символ-Плюс, 2010. – 456 с.
7. Django. Подробное руководство. 2-е издание / А. Головатый, Д. Каплан-Мосс.; пер. с англ.– СПб. : Символ-Плюс, 2010. – 560 с.
8. Dive into Python / Mark Pilgrim.; United States, New York.: Apress, 2010. – 495 с.
9. Beginning Django E-Commerce / Jim McGaw.; United States, New York.: Apress, 2009. – 409 с.
10. Django 1.2 E-Commerce / Jesse Legg.; England, Birmingham.: PACKT Publishing, 2010. – 244 с.
11. Django 1.1 Testing and Debugging / Karen M. Tracey.; England, Birmingham.: PACKT Publishing, 2010. – 436 с.
12. Лутс М. Изучаем Python. 4-е издание / М. Лутс.; пер. с англ.– СПб. : Символ-Плюс, 2011. – 1280 с.
13. Фаулер. М. Архитектура корпоративных программных приложений / М. Фаулер.; пер. с англ.– М. : Издательский дом Вильямс, 2006. – 544 с.
14. Флэнаган Д. JavaScript. Подробное руководство, 5-е издание / Д. Флэнаган.; пер. с англ.– СПб. : Символ-Плюс, 2008. – 992 с.
15. Мартин Р. Чистый код. Создание, анализ и рефакторинг / Р. Мартин.; пер. с англ. Библиотека программиста – СПб. : Питер, 2010. – 464 с.
16. Макконелл С. Совершенный код. Мастер класс / С. Макконелл.; пер. с англ. Издательско-торговый дом «Русская Редакция» – СПб. : Питер, 2005. – 896 с.

Соглашение о конфиденциальности

и обработке персональных данных

1.Общие положения

1.1.Настоящее соглашение о конфиденциальности и обработке персональных данных (далее – Соглашение) принято свободно и своей волей, действует в отношении всей информации, которую ООО «Инсейлс Рус» и/или его аффилированные лица, включая все лица, входящие в одну группу с ООО «Инсейлс Рус» (в том числе ООО «ЕКАМ сервис»), могут получить о Пользователе во время использования им любого из сайтов, сервисов, служб, программ для ЭВМ, продуктов или услуг ООО «Инсейлс Рус» (далее – Сервисы) и в ходе исполнения ООО «Инсейлс Рус» любых соглашений и договоров с Пользователем. Согласие Пользователя с Соглашением, выраженное им в рамках отношений с одним из перечисленных лиц, распространяется на все остальные перечисленные лица.

1.2.Использование Сервисов означает согласие Пользователя с настоящим Соглашением и указанными в нем условиями; в случае несогласия с этими условиями Пользователь должен воздержаться от использования Сервисов.

1.3.Сторонами (далее – «Стороны) настоящего Соглашения являются:

«Инсейлс» – Общество с ограниченной ответственностью «Инсейлс Рус», ОГРН 1117746506514, ИНН 7714843760, КПП  771401001, зарегистрированное по адресу: 125319, г.Москва, ул.Академика Ильюшина, д.4, корп.1, офис 11 (далее — «Инсейлс»), с одной стороны, и

«Пользователь» –

либо физическое лицо, обладающее дееспособностью и признаваемое участником гражданских правоотношений в соответствии с законодательством Российской Федерации;

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

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

которое приняло условия настоящего Соглашения.

1.4.Для целей настоящего Соглашения Стороны определили, что конфиденциальная информация – это сведения любого характера (производственные, технические, экономические, организационные и другие), в том числе о результатах интеллектуальной деятельности, а также сведения о способах осуществления профессиональной деятельности (включая, но не ограничиваясь: информацию о продукции, работах и услугах; сведения о технологиях и научно-исследовательских работах; данные о технических системах и оборудовании, включая элементы программного обеспечения; деловые прогнозы и сведения о предполагаемых покупках; требования и спецификации конкретных партнеров и потенциальных партнеров; информацию, относящуюся к интеллектуальной собственности, а также планы и технологии, относящиеся ко всему перечисленному выше), сообщаемые одной стороной другой стороне в письменной и/или электронной форме, явно обозначенные Стороной как ее конфиденциальная информация.

1.5.Целью настоящего Соглашения является защита конфиденциальной информации, которой Стороны будут обмениваться в ходе переговоров, заключения договоров и исполнения обязательств, а равно любого иного взаимодействия (включая, но не ограничиваясь, консультирование, запрос и предоставление информации, и выполнение иных поручений).

2.Обязанности Сторон

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

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

2.3.Обязательство по сохранению в тайне конфиденциальной информации действительно в пределах срока действия настоящего Соглашения, лицензионного договора на программы для ЭВМ от 01.12.2016г., договора присоединения к лицензионному договору на программы для ЭВМ, агентских и иных договоров и в течение пяти лет после прекращения их действия, если Сторонами отдельно не будет оговорено иное.

2.4.Не будут считаться нарушением настоящего Соглашения следующие случаи:

(а)если предоставленная информация стала общедоступной без нарушения обязательств одной из Сторон; 

(б)если предоставленная информация стала известна Стороне в результате ее собственных исследований, систематических наблюдений или иной деятельности, осуществленной без использования конфиденциальной информации, полученной от другой Стороны;

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

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

(д)если информация предоставлена третьему лицу с согласия той Стороны, информация о которой передается.

2.5.Инсейлс не проверяет достоверность информации, предоставляемой Пользователем, и не имеет возможности оценивать его дееспособность.

2.6.Информация, которую Пользователь предоставляет Инсейлс при регистрации в Сервисах, не является персональными данными, как они определены в Федеральном законе РФ №152-ФЗ от 27.07.2006г. «О персональных данных».

2.7.Инсейлс имеет право вносить изменения в настоящее Соглашение. При внесении изменений в актуальной редакции указывается дата последнего обновления. Новая редакция Соглашения вступает в силу с момента ее размещения, если иное не предусмотрено новой редакцией Соглашения.

2.8.Принимая данное Соглашение Пользователь осознает и соглашается с тем, что Инсейлс может отправлять Пользователю персонализированные сообщения и информацию (включая, но не ограничиваясь) для повышения качества Сервисов, для разработки новых продуктов, для создания и отправки Пользователю персональных предложений, для информирования Пользователя об изменениях в Тарифных планах и обновлениях, для направления Пользователю маркетинговых материалов по тематике Сервисов, для защиты Сервисов и Пользователей и в других целях.

Пользователь имеет право отказаться от получения вышеуказанной информации, сообщив об этом письменно на адрес электронной почты Инсейлс — contact@ekam.ru.

2.9.Принимая данное Соглашение, Пользователь осознает и соглашается с тем, что Сервисами Инсейлс для обеспечения работоспособности Сервисов в целом или их отдельных функций в частности могут использоваться файлы cookie, счетчики, иные технологии и Пользователь не имеет претензий к Инсейлс в связи с этим.

2.10.Пользователь осознает, что оборудование и программное обеспечение, используемые им для посещения сайтов в сети интернет могут обладать функцией запрещения операций с файлами cookie (для любых сайтов или для определенных сайтов), а также удаления ранее полученных файлов cookie.

Инсейлс вправе установить, что предоставление определенного Сервиса возможно лишь при условии, что прием и получение файлов cookie разрешены Пользователем.

2.11.Пользователь самостоятельно несет ответственность за безопасность выбранных им средств для доступа к учетной записи, а также самостоятельно обеспечивает их конфиденциальность. Пользователь самостоятельно несет ответственность за все действия (а также их последствия) в рамках или с использованием Сервисов под учетной записью Пользователя, включая случаи добровольной передачи Пользователем данных для доступа к учетной записи Пользователя третьим лицам на любых условиях (в том числе по договорам или соглашениям). При этом все действия в рамках или с использованием Сервисов под учетной записью Пользователя считаются произведенными самим Пользователем, за исключением случаев, когда Пользователь уведомил Инсейлс о несанкционированном доступе к Сервисам с использованием учетной записи Пользователя и/или о любом нарушении (подозрениях о нарушении) конфиденциальности своих средств доступа к учетной записи.

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

3.Ответственность Сторон

3.1.Сторона, нарушившая предусмотренные Соглашением обязательства в отношении охраны конфиденциальной информации, переданной по Соглашению, обязана возместить по требованию пострадавшей Стороны реальный ущерб, причиненный таким нарушением условий Соглашения в соответствии с действующим законодательством Российской Федерации.

3.2.Возмещение ущерба не прекращают обязанности нарушившей Стороны по надлежащему исполнению обязательств по Соглашению.

4.Иные положения

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

4.2.Если одно или несколько положений (условий) настоящего Соглашения являются либо становятся недействительными, то это не может служить причиной для прекращения действия других положений (условий).

4.3.К настоящему Соглашению и отношениям между Пользователем и Инсейлс, возникающим в связи с применением Соглашения, подлежит применению право Российской Федерации.

4.3.Все предложения или вопросы по поводу настоящего Соглашения Пользователь вправе направлять в Службу поддержки пользователей Инсейлс www.ekam.ru либо по почтовому адресу: 107078, г. Москва, ул. Новорязанская, 18, стр.11-12 БЦ «Stendhal» ООО «Инсейлс Рус».

Дата публикации: 01.12.2016г.

Полное наименование на русском языке:

Общество с ограниченной ответственностью «Инсейлс Рус»

Сокращенное наименование на русском языке:

ООО «Инсейлс Рус»

Наименование на английском языке:

InSales Rus Limited Liability Company (InSales Rus LLC)

Юридический адрес:

125319, г. Москва, ул. Академика Ильюшина, д. 4, корп.1, офис 11

Почтовый адрес:

107078, г. Москва, ул. Новорязанская, 18, стр.11-12, БЦ «Stendhal»

ИНН: 7714843760 КПП: 771401001

Банковские реквизиты:

Р/с 40702810600001004854

В ИНГ БАНК (ЕВРАЗИЯ) АО, г.Москва,
к/с 30101810500000000222, БИК 044525222

Электронная почта: contact@ekam.ru

Контактный телефон: +7(495)133-20-43

ФЕДЕРАЛЬНОЕ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ

ВЫСШЕГО
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ГОСУДАРСТВЕННЫЙ
УНИВЕРСИТЕТ МИНИСТЕРСТВА ФИНАНСОВ
РОССИЙСКОЙ ФЕДЕРАЦИИ»

ОМСКИЙ
ФИЛИАЛ

Кафедра

«Автоматизированная
обработка экономической информации»

Домашняя работа

По
дисциплине:

«Информационные
системы в экономике»

На
тему:

Моделирование деятельности интернет-магазина бытовой техники в Bpwin

Студентки
Павлюковской
Лилии

Группы
3ФК1

Вариант: 9

Факультет:
финансово-учётный

Специальность: финансы
и кредит

Отделение: очное

Научный
руководитель: Лебедев
Виктор Михайлович

___________________
____________________ ___________________

Дата поступления
Допуск к защите
Защита работы

работы в деканат
Подпись преподавателя
Оценка

Подпись
преподавателя

Омск
– 2011/2012уч. год.

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

Задачи:

1. представить
   деятельность интернет – магазина в
   виде поэтапного процесса;

2. рассмотреть
   механизмы распределения затрат;

3. сделать
   выводы.

Объект
–
интернет- магазин.

Интернет
– магазин специализируется на продаже
бытовой техники.

Для
осуществления этого бизнес-процесса
рассмотрим модель с помощью программы
Bpwin.

1. Создание контекстной диаграммы

В
проекте деятельность интернет – магазина
состоит из этапов:

• обработка
  заявки клиента;

• сборка
  товара на складе;

• подготовка
  документации;

• доставка;

• реклама.

При
создании контекстной диаграммы,
присваиваем ей имя «Интернет- магазин»»
(рис.1). Целью разработки данной модели:
«Моделирование
текущих (AS-IS)
бизнес-процессов предприятия».

Рис.
1
Контекстная диаграмма «ИНТЕРНЕТ-МАГАЗИН»

Описание
стрелок контекстной диаграммы приведено
в таблице 1.

Таблица
1

Стрелки
контекстной диаграммы

Название стрелки (Arrow Name)	Определение стрелки (Arrow Definition)	Тип стрелки (Arrow Type)
Заявка клиента	Поступившие заявки по интернету	Input
Правила и процедуры	Правила продаж, инструкции по сборке, процедуры тестирования, критерии производительности и т. д.	Control
Наличие товаров на складе	Информация о наличии требуемых товаров на складе	Control
Доставка товара и чека клиенту	Получение товара непосредственно клиентом	Output
Реклама	Проведена рекламная компания для привлечения клиентов	Output
Система складского учета	Работа с заказами	Mechanism

2. Создание диаграммы декомпозиции

Декомпозируем
контекстную модель на пять этапов
(рис.2). Типом данной диаграммы является
IDEF0.

Рис.2
Диаграмма А0 декомпозиции «Интернет-магазин»

Описание
работ и стрелок приведены в таблицах 2
и 3 соответственно.

Таблица 2

Работы
диаграммы декомпозиции «Интернет-магазин»

Название работы (Activity Name)	Определение работы (Activity Definition)
Обработка заявки клиента	Принятие заказов, их сортировка
Сборка товара на складе	Сборка требуемого товара, его тестирование
Подготовка документации	Формирование заявок, чеков и маршрутных листов
Доставка	Осуществление доставки собранной техники непосредственно клиенту
Разработка рекламы	Привлечение клиентов

Таблица
3

Стрелки
диаграммы декомпозиции

Наименование стрелки (Arrow Name)	Источник стрелки (Arrow Source)	Тип стрелки источника (Arrow Source Type)	Приемник стрелки (Arrow Dest.)	Тип стрелки приемника (Arrow Dest. Type)
Заявка клиента	Граница диаграммы	Input	Обработка заявки клиента	Input
Система складского учета	Граница диаграммы	Mechanism	Обработка заявки клиента	Mechanism
Персонал магазина	Граница диаграммы	Mechanism	Обработка заявки клиента	Mechanism
Сборка товара на складе
Подготовка документации
Реклама
Наличие товаров на складе	Граница диаграммы	Control	Обработка заявки клиента	Control
Доставка
Реклама
Правила и процедуры	Граница диаграммы	Control	Обработка заявки клиента	Control
Сборка товара на складе
Подготовка документации
Заказы клиента	Обработка заявки клиента	Output	Сборка товара на складе	Mechanism
Готовые заказы	Сборка товара на складе	Output	Подготовка документации	Mechanism
Результаты сборки и тестирования	Сборка товара на складе	Output	Обработка заявки клиента	Mechanism
Сформированные заявки	Сборка товара на складе	Output	Доставка	Input
Чеки	Подготовка документации	Output	Доставка	Input
Маршрутный лист	Подготовка документации	Output	Доставка	Input
Подтверждение заказа по телефону	Обработка заявки клиента	Output	Граница диаграммы	Output
Доставка товара и чека клиенту	Доставка	Output	Граница диаграммы	Output
Реклама	Разработка рекламы	Output	Граница диаграммы	Output

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

Вы работаете 24 часа 7 дней в неделю, всё завязано на вас, даже если вы делегировали часть своих полномочий, некоторые решения можете принять только вы. И даже находясь на отдыхе, будьте готовы к звонку с вопросом «Что делать?».

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

Основные блоки.

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

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

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

Объединим эти два блока в блок продаж: Сюда же мы отнесем маркетинг (скидки, скидки за возврат клиента, то есть продолжение оформления брошенных корзины/заказа и т.д.), рекламу и т.д…

Пока не забыл, ещё одно правило, которое берем за аксиому: Сделка (заказ) считается выполненной только тогда, когда клиент получил товар и дал обратную связь (то есть остался доволен и не требует возврат) о завершении сделки.

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

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

Закупки: непосредственная закупка товара, и организация доставки на склад.

Планирование самой закупки идет на основании просчитанной потребности (предзаказ и пополнение склада взамен реализованного). Также сравнение цен, проверка соблюдения поставщиком условий и т.д. Это всё делает наша ERP. Выбор же поставщика с наиболее приятными ценами, расширение ассортимента и т.д. оставим пока за вами.

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

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

Контроль или ревизионный отдел: Тоже без него никак. (Даже если контролировать и проверять нужно свою работу).

Согласитесь, странно будет если отдел продаж проверяет и оценивает свою же работу, например, проводит звонки клиентам и собирает статус «довольности клиента» (а ведь во многих компаниях именно так). Или кладовщик сам проводит инвентаризации и списывает бой, брак и т.д.

На всех этапах цепочек мы ставим контрольные точки, которые собирают информацию о качестве работы.

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

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

В чем рисовать модель

Сейчас вы, наверное, ждете, что я укажу ссылки на мега крутой, навороченный и специализированный софт, и, естественно, также мега дорогой. Нет, модель можно не менее качественно нарисовать на мега обычной бумаге, простым карандашом. Но всё-таки мы живем в век компьютера. Возьмем доступные программы и по возможности бесплатные. Для любителей linux (таких как я) вполне подойдет LibreOffice Draw или входящий в OpenOffice аналог, для винды Visio аналогичный. Но лучше всего подойдет Bizagi Modeler, хоть и под Linux нет пакета, в wine его можно запустить, да и он бесплатен, нагляден, прост и удобен. Так как большинство использует Windows я буду рисовать в Visio и потом мы будем, что-то перекладывать в Bizagi

(Лирика: хотя с выходом Windows 10 которая только в штаны вам не заглядывает пришло время отказываться от Windows и переходить на Linux).

Итак, приступим к модели, начнем с общей и будем постепенно её усложнять, детализировать. Смотрим по тексту выше и рисуем основные блоки:

Детализируем блоки, начнем с продажи:

Общая детализация:

Получаем основные этапы работы с заказом:

Сам заказ, оплата, доставка (логистика в которую входит упаковка и т.д.), завершение сделки и контроль прохождения сделки.

Этапы работы с обращениями:

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

Детализируем дальше

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

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

Расчетная стоимость времени работника:

Зарплатамесяц 15тр.

Стоимость часа 20 дней (среднее рабочих дней в месяце) = 15000 20 = 750рдень

1 день = 8 рабочим часам. = 1ч = 750р 8ч = 93,75р

Стоимость минуты = 1ч 60м = 93.75р 60м = 1,5625р

Тел. И смс:

Стоимость 1смс = 0.5р

Стоимость 1 минуты разговора = 1.5р

Ну и возьмем средние цифры:

Упаковка заказа = 10 минут (идет в стоимость доставки)

Обработка заказа 2 минуты

Подтверждение заказа 2 минуты

Контроль 2 минуты (звонок)

И того на один заказ

2 смс = 1р

4 минуты тел. = 6р

2 минуты обработка = 3р

Зарплата 4 минуты тел. + 2 минуты обработка = 6м*1,5625р = 9,375р

100 заказов = 937,5р

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

Теперь рисуем логическую схему с максимальной детализацией:

Продолжение следует…

Схемы в Visio на Яндекс диске

PS

Так как материал получается объемистый, а читать длинные статьи мало кто любит, буду делить их на части. Постараюсь за выходные сделать пару выпусков.

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

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

Разбираемся, как работает управление бизнес-процессами в интернет-продажах.

Операционные процессы

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

Операционные бизнес-процессы интернет-магазина:

• маркетинговая активность (от планирования до рекламы);
• приобретение товаров у поставщиков (входящая логистика);
• продажи товаров клиентам на сайте (от оформления заказа до передачи на склад);
• доставка со склада до пункта выдачи заказа (исходящая логистика);
• постпродажное обслуживание (работа с возвратами).

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

Простой пример. Заказ уже формируется на складе, но клиент решает отменить доставку. Если компания продумала сценарий отмены заказа, и выстроила соответствующую модель взаимодействия между отделом продаж и складом, то потери будут минимальными.

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

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

Проектирование процессов интернет-магазина — теория

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

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

Проектирование эффективных процессов — это искусство, осваивать его приходится постепенно. Для начала стоит спроектировать процесс «как есть», причем модель должна учитывать действия клиента (т.н. методология Outside-IN).

Некоторые советы по проектированию:

• стандартизация действий — люди должны понимать, что от них требуется сделать в каждой ситуации. Это уменьшает степень свободы каждого сотрудника, но упрощает задачи контроля и дает более предсказуемый результат;
• минимизация числа участников — чем меньше в процессе участвует людей, тем лучше. Добиться этого можно за счет автоматизации или укрупнения рабочих заданий, когда один человек совершает наибольшее количество возможных действий;
• общий источник данных — данные должны вводиться один раз. Никаких повторных вводов, сверок и дублирования. Если менеджер вручную переносит данные заказа в заявку на склад, то работа уже выстроена нерационально;
• минимальное время ожидания — никто не любит ждать, особенно в очереди. Чем быстрее клиент получит заказ, тем лучше. На деле добиться этого очень тяжело, так как связано с оптимизацией логистики, а в России, с ее огромными пространства, и сложной дорожной системой, наладить логистику непросто;
• единое контактное лицо — клиент всегда должен понимать, с кем он должен связаться при появлении проблем или вопросов. Желательно, чтобы клиента всегда вел один менеджер от первого контакта до закрытия сделки;
• сценарии — чем больше вариантов развития событий предусмотрено, тем более предсказуемым будет результат. Всего предусмотреть невозможно, но можно учиться на собственных ошибках.

Проектирование процессов ИМ — практика

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

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

Типичные проблемы интернет-торговли:

• тяжело отследить эффективность маркетинговой компании из-за большого количества каналов продвижения — социальные сети, SEO, контекстная реклама, баннерная реклама, публикации в интернет-СМИ и блогах;
• менеджеры забывают связаться с клиентами на разных этапах продаж;
• постоянная путаница с документами, не всегда получается собрать пакет документов для покупателя;
• проблемы с выставлением счета и подтверждением платежа;
• товары на складе не совпадают с тем, что указано на витрине сайта;
• контент-менеджеры не успевают вовремя обновлять цены, характеристики товаров и товарные позиции в каталоге;
• складские работники медленно и с ошибками собирают заказы;
• клиент не может отследить статус своего заказа в реальном времени;
• закупки никто не контролирует, каталоги поставщиков обрабатываются вручную.

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

Признаки низкого уровня автоматизации:

• нет единого канала для анализа маркетинговых кампаний;
• коммуникации между сотрудниками ведутся с почтовых сервисах;
• учет ведется в таблицах Excel;
• попытка управлять задачами в CMS;
• документы заполняются вручную;
• ручной перенос данных из одной системы в другую;
• отчеты составляются вручную или вообще не составляются;
• не внедрена CRM;
• нет процесса работы с повторными клиентами.

Как с этим бороться? Очевидно, что придется расширять пул систем. Внедрять программы для складского учета и бухгалтерского учета, CRM для управления продажами, транзакционные системы, маркетинговые платформы и BI, логистические системы, СЭД — так называемый зоопарк систем. Если бизнес достаточно большой, то внедрение себя окупит при условии, что модель оптимизации рассчитана верно. 

Компании Ozon, Wildberries и Lamoda располагают большим штатом бизнес-аналитиков для работы с процессами на всех уровнях организации. Гиганты интернет-торговли прекрасно понимают, как важно описывать, управлять и автоматизировать процессы.

От проектирования к автоматизации — BPMS и Low-code

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

Такие системы называются Business Process Management Systems (BPMS). Они позволяют проектировать управляемые процессы. Создаются задачи, связанные друг с другом в исполняемую последовательность, затем эту последовательность можно постепенно автоматизировать: создавать сценарии, бизнес-правила, точки обмена данными, внедрять внешние сервисы и так далее.

Если говорить о Low-code BPMS платформах, то они нужны для проектирования бизнес-приложений. У Low-code платформ, таких как Comindware Business Platform Application, есть инструменты для проектирования бизнес-процессов, разработки интерфейсов, создания бизнес-правил, настройки экспорта/импорта данных, таблицы и доски.

С помощью таких инструментов можно быстро разработать бизнес-приложение с функциональными возможностями большого количества систем автоматизации интернет-магазина —  CRM, HR, ITSM, СЭД, SCM, систем управления заказами. При этом не потребуется нанимать в штат дополнительных программистов, так как большинство задач по разработке и сопровождению системы можно закрыть, не внося изменений на уровне кода.

Примеры решений для интернет-магазина на платформе Comindware
Автоматизация маркетинга	выгрузка данных метрики; отслеживание лидов; SEO-трекер; отслеживание затрат на маркетинг; отчеты по рекламным кампаниям; публикация контента; контроль изменений сайта; проведение акций.
Автоматизация продаж	управление заказами; управление клиентами; отчеты по трудозатратам; контроль счетов; интеграция каналов коммуникации; отчеты по продажам; управление продуктами; контроль задолженности; KPI-менеджеров по продажам.
Работа с поставщиками	согласование плана закупок; порталы для поставщиков; выгрузка данных из коммерческих предложений; проверка поставщика; контроль оплаты.

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

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

ВВЕДЕНИЕ

Интернет магазин
является одним из выгодных бизнесов в
глобальной сети. Сегодня в Интернете
существует тысячи различных по тематике
и функциональным особенностям порталов,
специализирующиеся на предоставление
торговых услуг [13].

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

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

В мире, а в частности
в России, огромными темпами растет
количество пользователей Интернет, и
как следствие, количество «электронных»
покупателей и потенциальных «электронных»
покупателей. [16]

Объектом
исследования
является заказ товаров.

Предметом
исследования
служит процесс заказа товаров через
глобальную сеть Интернет.

Целью работы
является имитационное моделирование
процесса заказа товаров через глобальную
сеть Интернет и сравнение процесса
заказа товаров в разных интернет
магазинах.

Для достижения
поставленной цели необходимо выполнить
ряд задач:

• построить
  функциональную модель процесса
  в нотации IDEF0 с помощью программы BPWin;

• разработать
  процессную модель, которая описывает
  взаимодействие информационных и
  материальных потоков данных процесса
  заказа товаров по методологии IDEF3;

• построить
  имитационную модель процесса
  для исследования с помощью среды
  AnyLogic;

• проанализировать
  полученные результаты, сделать
  соответствующие выводы.

В качестве
программных продуктов выбраны BPwin
и AnyLogic.
Методологиями
моделирования, описывающие процессы
системы, являются нотации IDEF0
и IDEF3.

Логика исследования
обусловила структуру курсового проекта,
состоящего из введения, трех глав,
заключения и библиографического списка.

Глава 1 посвящена
конкретному и полному описанию предметной
области и ее структуризации. Здесь
раскрываются основные понятия и этапы
анализируемого процесса.

Глава 2 рассматривает
общую характеристику процесса и ее
взаимосвязь с другими процессами. Для
визуального представления бизнес-процесса
используется модель, созданная в нотации
IDEF0
и IDEF3.

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

---

1. Постановка
   задачи и построение структурно-функциональной
   модели процесса
   

1. Описание
   предметной области
   

В настоящее время
Интернет становиться все более развитой
средой для осуществления коммуникаций
с потребителями [15]. В тоже время, очень
важным фактом является то, что интернет
становиться удобной и достаточно дешевой
торговой площадкой.

Сегодня спектр
онлайн торговли настолько обширен, что
уже сложно представить, чего только
нельзя купить через Интернет [20]. Огромное
разнообразие представленных продуктов
способно удовлетворить даже самого
искушенного пользователя. 

Интернет-магазин
— сайт, торгующий товарами посредством
сети Интернет. Позволяет пользователям
онлайн, в своём браузере, сформировать
заказ на покупку, выбрать способ оплаты
и доставки заказа [20].

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

Покупатель, опираясь
на регламент интернет магазина,
регистрируется и авторизируется на
сайте. Далее выбирает понравившуюся
продукцию и складывает ее в корзину.
После из корзины можно будет удалить
тот товар, который не нужен. Когда
покупатель закончит с выбором товара,
он начинает его оформлять согласно
Федеральному закону «Об электронной
торговле».

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

После того как
покупатель подтвердил оформление
заказа, ему выставляется счет на оплату.
Оплату счет он может провести 2 способами:
через карту или через QIWI
кошелек. Как только оплата произвелась,
покупателю выдадут квитанцию об оплате.

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

Продавец обязан
передать товар покупателю в порядке и
сроки, которые установлены в договоре
[1].

1. Структуризация
   предметной области
   

Для
того чтобы отобразить и систематизировать
изученную информацию о предметной
области – построим ментальную карту.
Ментальные карты — это техника
визуализации мышления [19].

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

---

Процесс заказа
товаров через глобальную сеть Интернет
проходит в 4 основных этапа (рисунок 1).

Рисунок
1 — Ментальная карта процесса заказа
товаров через глобальную сеть Интернет

Каждый этап в свою
очередь подразделяется еще на несколько
этапов.

Рисунок
2 — Этап «Регистрация и вход на сайт»

Рисунок
3 — Этап «Оформление заказа»

Рисунок
4 — Этап «Оплата и подготовка к отгрузке»

Рисунок
5 — Этап «Доставка заказа»

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

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

1. Вербальное
   описание бизнес-процесса
   

Бизнес-процесс
«Процесс заказа товаров через глобальную
сеть Интернет» содержит 4 основные
функции. Каждая из этих функций
декомпозируется еще на несколько
процессов:

1. Регистрация
   и вход на сайт:

• регистрация;

• подтверждение
  регистрации;

• авторизация.

1. Оформление
   заказа:

• выбор
  продукции;

• оформление;

• подтверждение
  заказа.

1. Оплата
   и подготовка к отгрузке:

• оформление
  счета;

• оплата
  счета;

• подготовка
  заказа к отгрузке.

1. Доставка
   и получение заказа:

• отгрузка
  заказа;

• доставка
  заказа;

• получение
  заказа.

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

Процесс заказа
товаров через глобальную сеть Интернет
руководствуется регламентами предприятия
и Законами РФ.

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

1. Представление
   бизнес-процесса в нотации IDEF0
   

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

Основная цель
контекстной диаграммы – выявить главную
задачу, единственную и неповторимую
функцию, которую решает выполнение
бизнес-процесса[6].

Бизнес-процесс
заказ товаров через глобальную сеть
Интернет построен в нотации IDEF0 и состоит
из контекстной диаграммы (рисунок 6), и
дальнейшей декомпозиции контекстной
диаграммы до нужного уровня детализации
процесса.

На рисунке 6
представлена контекстная диаграмма
процесса заказа товаров через глобальную
сеть Интернет. Входными данными процесса
являются данные о покупателе. Результатом
процесса является полученный заказ.
Весь процесс при выполнении руководствуется
регламентами и законам РФ. Контролирует
данный процесс директор интернет
магазина.

Рисунок
6 — Контекстная диаграмма процесса
«Заказа товаров через глобальную сеть
Интернет (интернет магазин)»

---

Далее процесс
декомпозируется на 4 блока: регистрация
и вход на сайт, оформление заказа, оплата
и подготовка к отгрузке, доставка заказа.

В блок «Регистрация
и вход на сайт» поступают данные о
покупателе. Все данные обрабатываются,
происходит регистрация и вход на сайт.
После того как покупатель вошел на сайт
издается сигнал, подтверждающий вход.
Далее происходит оформление заказа.
После того как покупатель завершил
оформление заказа и ему приходит
сообщение подтверждающее заказ. После
происходит процесс оплаты и подготовки
к отгрузке, который завершается отметкой
в журнале. Завершающий процесс – это
доставка заказа, результатом является
полученный заказ покупателем. На этом
процесс «Процесс заказа товаров через
глобальную сеть Интернет» заканчивается.
Данная декомпозиция представлена на
рисунке
7.

Рисунок
7 – Декомпозиция основного блока «Заказ
товаров через глобальную сеть Интернет
(интернет магазин)»

После того как мы
декомпозировали контекстную диаграмму
– мы начинает декомпозицию каждого
блока.

На рисунке 8
представлена декомпозиция блока
«Регистрация и вход на сайт», которая
содержит 3 блока: регистрация, подтверждение
регистрации, авторизация.

Рисунок
8 – Декомпозиция блока «Регистрация и
вход на сайт»

На рисунке 9
представлена декомпозиция блока
«Оформление заказа», которая содержит
3 блока: выбор продукции, оформление,
подтверждение заказа.

Рисунок
9 – Декомпозиция блока «Оформление
заказа»

На рисунке 10
представлена декомпозиция блока «Оплата
и подготовка к отгрузке», которая
содержит 3 блока: оформление счета,
оплата счета, подготовка заказа к
отгрузке.

Рисунок
10 — Декомпозиция блока «Оплата и подготовка
к отгрузке»

На рисунке 11
представлена декомпозиция блока
«Доставка заказа», которая содержит 3
блока: отгрузка заказа, доставка заказа,
получение заказа.

Рисунок
11 — Декомпозиция блока «Доставка и
получение заказа»

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

Диаграммы нотации
IDEF0 раскрывают полное и глубокое
представление, как о функциональности
исследуемого бизнес процесса, так и обо
всех имеющих в нем место потоках
информации и материалов [12].

1. Представление
   бизнес-процесса в нотации IDEF3
   

Для описания
взаимодействия информационных потоков
процесса заказа товаров через глобальную
сеть Интернет была использована нотация
IDEF3
средства BPWin.
IDEF3 – это
методология моделирования и стандарт
документирования процессов, происходящих
в системе [17].

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

---

IDEF3 показывает
причинно-следственные связи между
ситуациями и событиями в понятной
эксперту форме, используя структурный
метод выражения знаний о том, как
функционирует система, процесс или
предприятие [10].

Нотация
IDEF3
является второй важнейшей нотацией
(после IDEF0) и предназначена для описания
потоков работ [11].

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

На рисунке 12
показана контекстная диаграмма процесса
заказа товаров через глобальную сеть
Интернет. Процесс начинается с обращения
покупателя. Покупатель должен или
сначала зарегистрироваться на сайте
или если у него уже есть аккаунт просто
зайти. После чего он оформляет и
подтверждает заказ. Затем оформляется
счет. После того как оформлен счет его
надо оплатить и подготовить товар к
отгрузке. Оплатить можно или картой или
через Qiwi
кошелек. Далее выполняется отгрузка и
доставка заказа до покупателя.

Рисунок
12 — Контекстная диаграмма процесса
«Заказа товаров через глобальную сеть
Интернет (интернет магазин)»

Модель декомпозиции
процесса «Заказа товаров через глобальную
сеть Интернет (интернет магазин)»
представлена на рисунке 13.

Рисунок
13 — Декомпозиции процесса «Заказа товаров
через глобальную сеть Интернет (интернет
магазин)»

1. Проведение
   экспериментов в среде Anylogic
   

1. Описание
   объектов модели
   

Благодаря
интенсивному развитию информатики и
компьютерных технологий стало намного
проще решать сложные задачи, требующие
больших временных и финансовых затрат.
Намного упростить их решение возможно
с использованием моделирования [9].

AnyLogic
— единственный инструмент имитационного
моделирования (ИМ), который поддерживает
все подходы к созданию имитационных
моделей: процессно-ориентированный
(дискретно-событийный), системно
динамический и агентный,
а также любую их комбинацию[21].

Модель представляет
собой пользовательское описание проблемы
в терминах языка моделирования AnyLogic .

С помощью диаграмм
AnyLogic позволяет динамически визуализировать
данные, собираемые в результате работы
модели[7].

Диаграммы нотаций
IDEF0 и IDEF3 легли в основу создания
имитационной модели «Процесс заказа
товаров через глобальную сеть Интернет».
Имитационная модель построена с
использованием основной библиотеки
инструментов, системной динамики,
статистики, а также с помощью объектов
агентного моделирования [8].

На рисунке 14
представлена имитационная модель
«Процесса заказа товаров через глобальную
сеть Интернет».

Рисунок
14 — Имитационная модель «Процесса заказа
товаров через глобальную сеть Интернет»

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

---