Построение модели деятельности предприятия «как есть» и «как должно быть»
В первой главе данной работы было сформулировано назначение информационной системы для ресторана «Maxs». Рассмотрим, какие бизнес-процессы должен автоматизировать веб-сайт, с каких сотрудников будет снята часть рутинной нагрузки.
Для начала рассмотрим основные бизнес-процессы, действующие в ресторане. Для этого воспользуется одной из формализованных нотаций. Для этого определим:
объекты информационной системы (сущности в концептуальной модели);
их свойства (атрибуты);
взаимодействие объектов (связи) и информационные потоки внутри и между ними [11].
Нужно также обратить особое внимание на существующий опыт реализации информационных процессов и нормативной информации (законов, постановлений правительства, отраслевых стандартов), определяющих необходимый объем и формат хранения и передачи информации (рисунок 7).
Рисунок 7 – Схема формирования информационной модели
Концептуальная модель отображает информационные объекты, их свойства и связи между ними без указания способов физического хранения информации (модель предметной области, иногда ее также называют информационно-логической или инфологической моделью). Информационными объектами обычно являются сущности– обособленные объекты или события, информацию о которых необходимо сохранять, имеющие определенные наборы свойств - атрибутов. Физическая модель– отражает все свойства (атрибуты) информационных объектов базы и связи между ними с учетом способа их хранения - используемой СУБД. Внутренняя модель– база данных, соответствующая определенной физической модели. Внешняя модель - комплекс программных и аппаратных средств для работы с базой данных, обеспечивающий процессы создания, хранения, редактирования, удаления и поиска информации, а также решающий задачи выполнения необходимых расчетов и создания выходных печатных форм.
Для решения задач проектирования сложных систем существуют специальные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF (IcamDEFinition, ICAM –IntegratedComputer-AidedManufacturing– первоначально разработанная в конце 70-х гг. программа ВВС США интегрированной компьютерной поддержки производства). С их помощью можно эффективно проектировать, отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. Стандарты IDEF0- IDEF1X описывают приемы изображения компонентов информационной системы, связей между ними и построения модели данных информационной системы.
В IDEF0 различают пять типов дуг:
вход (Input)– материал или информация, которые используются или преобразуются блоком для получения результата (выхода). Блок может не иметь ни одной входной дуги. Данный вид дуги поступает на левую сторону блока;
управление (Сontrol)– условия, правила, стратегии, стандарты, которые влияют на выполнение функции. Каждый блок должен иметь хотя бы одну дугу управления. Данный вид дуг поступает на верхнюю сторону блока;
выход (Output)– результат выполнения функции (материал или информация). Каждая функция должна иметь хотя бы одну выходную дугу. Данный вид дуг выходит из правой стороны блока;
механизм (Mechanism) – ресурсы, с помощью которых выполняется работа. Это могут быть, например, денежные средства, персонал предприятия, оборудование, программное обеспечение. Данный вид дуг поступает на нижнюю сторону блока;
вызов (Call) – специальная дуга, указывающая на другую модель предметной области. Данный вид дуги выходит из нижней стороны блока. Дуга вызова не является компонентом собственно методологии SADT. Она является расширением IDEF0-методологии и предназначена для организации коллективной работы над моделью, разделения модели на независимые модели и объединения различных моделей предметной области в одну модель [16].
На рисунке 8 показана контекстная диаграмма производственного процесса ресторана «Maxs».
Рисунок 8 – Контекстная диаграмма процесса производства и продажи продукции ресторана «Maxs»
Процесс производства и продажи продукции ресторана состоят из нескольких подпроцессов. Так как основные процессы, требующий автоматизации, это заказ продукции и доставка, бронирование столов, то рассмотрим контекстные диаграммы этих процессов «Как есть» (рисунок 9).
Рисунок 9 – Контекстная диаграмма «Как есть» процесса
заказа и доставки продукции
Контекстная диаграмма бронирования столов «Как есть» на входе имеет желания клиентов и занятость ресторана. На выходе – бронирование стола (информация в текстовом виде). Управление осуществляется на основе имеющегося плана расположения столов, близости к бару, выходу. Стрелка «механизм» диаграммы IDF0 представлена блоком управления в лице администратора ресторана и иного персонала (кухни, обслуживания). Контекстная диаграмма процесса бронирования столов показана на рисунке 11.
Недостатком такой организации процесса является то, что сведения о заказе должны передаваться от сотрудника к сотруднику (от администратора работникам кухни, от администратора в отдел доставки). Вручную заполнять бланк заказа – отнимается масса времени у администратора. Да и бланки с заказами часто теряются на кухне.
Также, немаловажное условие задержки формирования заявки является то, что приходится администратору согласовывать с клиентов блюда из меню (имеются они в наличии или нет, какова стоимость блюд и пр.).
Учитывая указанные недостатки построена контекстная диаграмма «Как должно быть» (рисунок 10).
Рисунок 10 – Декомпозиция процесса заказа и доставки товаров
в нотации «Как должно быть»
В данной контекстной диаграмме в качестве механизма выступает информационная система. Она позволяет снизить человеческий фактор при взаимодействии персонала ресторана с клиентами. Предоставляет информацию только о тех блюдах, которые готовятся на кухне ресторана в данный временной период. Информационная система снижает нагрузку на администратора за счет автоматизации приема заказов напрямую от клиента через сайт. Причем, администратор может забыть уточнить контактную информацию, а вот информационная система без контактной информации просто не сформирует заявку.
Контекстная диаграмма процесса бронирования столов представлена на рисунке 11.
Рисунок 11 – Контекстная диаграмма «Как есть» A0 процесса бронирования
Проведем детализацию этого бизнес процесса. IDEF0 требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.
Блоки в IDEF0 размещаются по степени важности. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие.
Детализированная диаграмма процесса бронирования (A1) показана на рисунке 12.
Рисунок 12 – Контекстная диаграмма «Как есть» A1 процесса бронирования
На контекстной диаграмме видно, что основным «механизмом» данного процесса является администратор, на которого ложится ответственность по телефонному или очному взаимодействию с клиентами, анализу журнала занятости зала. На эти процессы тратится много времени, т.к. необходимо проанализировать журнал, прежде чем сообщать посетителю, может он сделать заказ или нет. Также администратор в момент телефонного звонка может быть занят и тогда неизбежны потери клиента. Подобные звонки категорически нельзя пропускать, т.к. ресторан еще только завоевывает свою популярность у жителей города.
Решением данной проблемы является автоматизация процесса бронирования. На сайте могла бы быть реализована схема размещения столов в зале ресторана, и пользователь мог бы посмотреть ее и сам оставить заявку на бронирование через сайт. Конечно, при таком подходе избавиться вообще от телефонных звонков нельзя, но сократить их количество (при этом сохранив каждого клиента) вполне можно.
На рисунке 13 представлена декомпозиция контекстной диаграммы для процесса бронирования в нотации «Как должно быть».
Рисунок 13 – Декомпозиция контекстной диаграммы «Как должно быть»
A1 процесса бронирования
На этом рисунке в качестве механизма указывается информационная система, в которой будет осуществляться учет информации. Т.к. совсем без бумажной записи бронирования не обойтись, то альтернативой может являться выгрузка информации из базы данных в Excel файл.
В дальнейшем, в случае успеха разработанной информационной системы, планируется реализовать комплексную систему управления базой данных ресторана «Maxs», которая бы отвечала функционалу и требованиям персонала ресторана, была бы интегрирована с сайтом и полностью заменила систему R-keeper.
|
