Модель діяльності кафе-піцерия "Celentano"

Примітка: так як вартість процесу управління складає майже половину від собівартості піци, ми заложили в цей пункт часові затрати допоміжного персоналу. Тому в рамках їх тривалості в кафе-піцерії здійснюється контроль не тільки за од. піци.  Було розраховано по пункту витрат на управління виготовлення 4 од. для здійснення більш ефективної роботи.

Фактично, собівартість одиниці готового продукту складатиме 28,6 грн.

В меню за од. піци буде вказано ціну, рівна 40 грн., яка складатиметься з собівартості продукту(28,6 грн.), чистого прибутку(20% від собівартості) та ПДВ(20%).

 

Розділ 4. МОДЕЛЮВАННЯ ПОТОКІВ ДАНИХ DFD

4.1. Основні поняття DFD-моделювання

DFD (Data Flow Diagramming) – це стандарт моделювання, в якому система представляється у вигляді мережі робіт, сполучених між собою об'єктами, що взаємодіють з результатами даних робіт. Сфера застосування DFD знаходиться в області моделювання інформаційних потоків організації. У цій нотації моделюється не послідовність робіт, а саме потоки інформації (даних) між роботами і об'єктами, які використовують, зберігають або "народжують" ці дані.

Відповідно до DFD (Data Flow Diagram) методології, модель системи визначається як ієрархія діаграм потоків даних, що описують процеси перетворення інформації від моменту її введення в систему до видачі кінцевому користувачеві. Діаграми верхніх рівнів ієрархії – контекстні діаграми, задають межі моделі, визначаючи її оточення (зовнішні входи і виходи) і основні дані процеси. Контекстні діаграми деталізують за допомогою діаграм наступних рівнів. Подальша декомпозиція також може бути схожа на IDEF0–модель, або навпаки може сильно відрізнятися, тому що бизнес–процеси розглядаються вже не з точки зору функцій, а з точки зору даних.

Основними елементами діаграм  потоків даних є:

- зовнішня суть;

- процеси;

- накопичувачі даних;

- потоки даних.

Під зовнішньою суттю (External Entity) розуміється матеріальний об'єкт, що є джерелом або приймачем інформації. Як зовнішня суть на DFD діаграмі можуть виступати замовники, постачальники, клієнти, склад, банк та інші. На жаль, DFD методологія не оформлена як стандарт. З цієї причини в діаграмах потоків даних використовуються різні умовні позначення – нотації Йордана-Де-Марко («Yourdon and Coad Process Notation») і Гейна-Сарсона («Gane and Sarson Process Notation»). Остання і реалізована в AllFusion Process Modeler, у якому і буде побудована діаграма.

Визначення деякого  об'єкту як зовнішня суть указує на те, що він знаходиться за межами аналізованої інформаційної системи.

Процеси є перетворенням вхідних потоків даних у вихідні відповідно до певного алгоритму. У реальному житті процес може виконуватися деяким підрозділом організації, що виконує обробку вхідних документів і випуск звітів, окремим співробітником, програмою, встановленою на комп'ютері, спеціальним логічним пристроєм і тому подібне.

Номер процесу служить  для його ідентифікації. У поле імені  вводиться найменування процесу  у вигляді пропозиції з дієсловом  в невизначеній формі (обчислити, розрахувати, перевірити, визначити, створити, отримати) і пояснюючими іменниками, наприклад: «Надрукувати адресу одержувача», «Акцептувати рахунок». Інформація в нижньому полі символу процесу указує, який підрозділ організації, співробітник, програма або апаратний пристрій виконує даний процес. Якщо таке поле відсутнє, то подібна інформація може бути вказана в текстовій примітці. На відміну від IDEF0 діаграм, в DFD діаграмах не використовуються стрілки управління для позначення правил виконання дії і стрілки механізмів для позначення необхідних ресурсів.

Накопичувачі даних призначені для зображення якихось абстрактних пристроїв для зберігання інформації, яку можна туди у будь-який момент часу помістити або витягувати, безвідносно до їх конкретної фізичної реалізації. Накопичувачі даних є деяким прообразом бази даних інформаційної системи організації. Усередині символу указується його унікальне в рамках даної моделі ім'я, найточніше, з погляду аналітика, що відображає інформаційну суть вмісту, наприклад, «Постачальники», «Замовники», «Рахунки–фактури», «Накладні». Символи накопичувачів даних як додаткові елементи ідентифікації можуть містити порядкові номери.

Потік даних визначає інформацію, передавану через деяке з'єднання (кабель, поштовий зв'язок, кур'єр) від джерела до приймача. На DFD діаграмах потоки даних зображуються лініями із стрілками, що показують їх напрям. Кожному потоку даних привласнюється ім'я, зміст, що відображає його.

4.2. Побудова діаграм потоків даних

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

Була побудована модель потоків даних кафе-піцерії «Chelentano», контекстна діаграма якої наведена на Pис. 4.1.

Рис. 4.1. Контекстна діаграма моделі потоків даних

 

Для побудови контекстної  моделі покажемо основну функцію даної системи і зовнішні по відношенню до неї сутності, а також взаємозв'язки між зовнішньою сутністю і функцією системи.

На діаграмі, сутність Кухня є зовнішньою по відношенню до системи оскільки дана система не виконує операцій пов’язаних з нею. Тобто вона лише отримує необхідну для роботи інформацію від даної сутності.

Клієнти подають замовлення на приготування страв і отримують готову страву, що зображено у вигляді стрілок з відповідними найменуваннями.

Двонаправлена стрілка  «Рахунок» є аналогом двох стрілок направлених від сутностіі Клієнти до функції Виконання (Обробка) замовлення і навпаки.

Це означає, що Клієнт отримує інформацію про рахунки  і статуси своїх замовлень, і може передавати в систему інформацію про платежі. Даний принцип ефективно діє і під час обслуговування фізичних та юридичних осіб.

Так як дане підприємство орієнтоване на надання послуг своїм  клієнтам, то основними функціями  системи будуть:

• обробка замовлення;
• доставка замовлення;
• виписка рахунку клієнтові;
• прийом оплати від клієнта.

Для деталізації бізнес–процесу проведемо декомпозицію – побудуємо  більш детальну діаграму, де процес буде представлений у вигляді  підпроцесів, при цьому бажано, щоб основні сутності та накопичувачі залишалися тими, що описані в контекстній діаграмі. Це одне з правил моделювання DFD. Нижче, на Рис. 4.2, наведена декомпозиція А0.

Рис. 4.2. Декомпозиція моделі потоків даних А0

Наведемо мініспецифікацію побудованої діаграми А0. Зазначимо, що мініспецифікація наводиться в кінці, коли більш детальна декомпозиція не має сенсу. Критерієм закінчення розбиття підпроцесів є наявність в середньому двох-трьох інформаційних потоків між елементами діаграми. Мініспецифікацією називають ще логікою процесу, яка полегшує сприйняття діаграми та дозволяє сторонньому користувачу інформації більш детально ознайомитися з бізнес-процесами.

На діаграмі, окрім чотирьох функцій системи представлено три сховища, які призначені для зберігання даних про замовлення, рахунок і клієнтів.

Слід звернути увагу  на те, що не зважаючи на наявність на контекстній діаграмі сутності Клієнти, діаграма деталізації містить сховище  Клієнти.

Це пов'язано з необхідністю використання інформації про клієнтів у всіх чотирьох функціях системи, створивши для цього сховище даних.

Якби цього створено не було, інформація про клієнтів все  одно використовувалася б в роботі функцій системи, проте це не було би так наочно зображено на діаграмі.

Функція Доставки замовлення має інформаційні потоки вхідний і вихідний з одним найменуванням – Готова страва.

Це пов'язано з тим, що при роботі саме цієї функції  використовується інформація про заказану страву, що поступили від клієнту та з кухні і доставки клієнтам. Це легко прослідкувати по стрілках, розташованих на контекстній діаграмі. Таким чином, не дивлячись на співпадаючі найменування, ці потоки мають різне логічне значення.

Процес «Обробка замовлення». Процес починається з замовлення клієнта  і є основною складовою розглянутого нами бізнес–процесу, адже він містить в собі не тільки прийняття замовлення, а й подальшу роботу з клієнтом, впродовж до видачі рахунку йому та прийняття оплати. Як видно з розробленої діаграми, замовлення передається системою в підрозділ «Приготування страви».

Процес «Приготування страви». Даний процес направлений на виробництво  готової страви і безпосередньо  зв’язаний з процесом «Доставки  замовлення».

Процес «Доставка замовлення». Цей процес зв’язаний і з Клієнтом і з зовнішньою сутністю Кухнею, що приймає безпосередню участь. На даному етапі проходить процес обслуговування: для фізичний осіб в межах споруди кафе-піцерії, а для юридичних осіб є послуга доставки по наданому адресу. Інформаційна система забезпечує даний процес, внесенням необхідних даних, серед яких П.І.Б, паспортні дані, назва підприємства, адреса, номер рахунку  і ін. Внесення даних до реєстру БД розмежовується між клієнтами фізичними та юридичними особами. Докладна декомпозиція даного процесу представлена на Рис. 4.3.

Рис. 4.3. Декомпозиція процесу «Доставки замовлення»

 

Процес «Прийняття оплати». Процес забезпечує не тільки чітке регламентування  цінових категорій за надані послуги, а й реалізує систему обліку грошових надходжень суб’єкту господарювання. В системі даний процес може приймати наступний вигляд: якщо клієнт вперше обслуговується в закладі кафе-піцерії «Chelentano» йому надається «Картка нового клієнта».

Послідовність даного процесу:

• надання послуг;
• надання клієнту звіту у вигляді рахунку за надані послуги;
• інформація про доставку, розпис клієнта (для юридичних осіб);
• перевірка наявності персональної карти (реєстр БД);
• розрахунок (може здійснюватися як за готівкою так і банківською карткою Visa, MasterCard).

Повна декомпозиція бізнес-процесу  «Прийняття оплати» представлена на Рис. 4.4.

Рис. 4.4. Декомпозиція процесу «Прийняття оплати»

 

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

Дерево вузлів бізнес-процесу «Виконання замовлення в кафе-піцерії «Chelentano» представлена нижче (Рис. 4.5).

 

Рис. 4.5. Дерево вузлів

 

Побудовані діаграми потоків даних  загального процесу «Виконання замовлення»  найкраще описують даний процес і служать для створення ІС з налагодженою БД на підприємстві.

 

ВИСНОВКИ

Кожен поважаючий себе підприємець  прагне підвищити рівень свого прибутку за мінімальних затрат на виробництво  доступного на ринок товару або на обслуговування своїх клієнтів, якщо суб’єкт господарювання належить до сфери обслуговування.

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

При виконанні курсової роботи були розглянуті основні теоретичні аспекти бізнес–моделювання. Зокрема, ми визначили та описали основні  терміни, поняття та методологію IDEF–моделювання, що сьогодні стає все більш популярним для дослідження бізнес-процесів підприємства. Зупинилися також на функціонально-вартісному аналізі, який дозволяє визначити джерела витрат по кожній з функцій бізнес-процесу, таким чином більш точно дозволяє прослідити формування собівартості. Ще одним з підходів до моделювання є DFD–моделі, теоретико-методологічні засади яких було також розглянуто у роботі.

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

Кожний із видів дослідження  підприємства (IDEF, ABC, DFD) був закріплений  у практичній частині, де ми власне будували діаграми та робили дослідження з приводу ефективності побудови інформаційної моделі підприємства. Такий структурний підхід властивий дійсно серйозному аналізу, який поки що не набув широкого використання для більшості підприємств України.

Тепер перейдемо до результатів праці. В процесі дослідження була розроблена модель діяльності підприємства кафе-піцерії «Chelentano», яка складається з декількох модулів, серед яких:

1. Формування та опис організаційної структури діяльності підприємства, а саме адміністративної та функціональної організаційних діаграм, правильне створення яких дозволило мати представлення всіх посадових одиниць з їх обов’язками та усунути можливі недоліки для досконалої роботи та мінімізувати затрати на персонал. В ході дослідження було виділено такі посадові одиниці: генеральний директор, бухгалтер, менеджер по закупівлях, адміністратор–технолог, шеф–кухар, кухарі, бармен, старший офіціант, офіціанти, прибиральниця, водій. Усунено замісника директора, обов’язки якого можуть виконувати інші особи. Також було описано бізнес–процес роботи з клієнтом із зазначенням посадових інструкцій відповідного персоналу, що приймає в ньому участь.
2. Функціональне моделювання за стандартом IDEF0 послужило для проектування моделі усієї діяльності кафе-піцерії, за допомого якого її можна ефективно відображати та аналізувати. Схематично вона подається у вигляді набору взаємопов’язаних функцій (блоків). Було розбито весь бізнес–процес діяльності підприємства по етапах, починаючи від замовлення клієнтом і до оплати за рахунком. Додатково було розділено на декомпозиції процесів «Приготування страви(піци)» та «Обслуговування клієнтів». Доречною пропозицією є зміна процесу обслуговування клієнтів, об’єднавши зустріч клієнта, розміщення та ознайомлення з меню в один процес, – прийом замовлення, а наступним етапом уже буде – виконання замовлення та подальший розрахунок. Це дозволить оптимізувати роботу з клієнтами.
3. Було проведено функціонально–вартісний аналіз АВС по вартості та тривалості на приготування одиниці готової страви (піци) і визначено, що ціна з вкладеною собівартістю в готовий продукт, начисленням ПДВ (20%) та прибутку становитиме 40 грн. Ефективно буде проходити цей процес за безпосередньої участі кухаря та наглядом, а саме контролем за цим процесом шеф-кухаря та адміністратора-технолога. Тривалість роботи на виготовлення піци складає 1,2 години. Звісно, що клієнт не буде чекати після здійснення заказу такий довгий час. Тому, для ефективного виконання замовлення на підприємстві необхідно запровадити завчасну методику виготовлення форм для піци, що зменшить очікування заказу лише до тривалості випікання, а саме 30 хв.
4. Створення ієрархічної DFD–моделі дозволило продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити співвідношення між цими процесами. Процес виконання замовлення в кафе-піцерії складається з 4-ох етапів, серед яких: обробка замовлення, приготування страви, доставка замовлення та прийняття оплати. Моделювання даних процесів здійснено з урахуванням певних критеріїв. Наприклад: є 2 типи розрахунків, – для фізичних та юридичних осіб, вони можуть розплачуватись як готівкою так і банківськими картками, рахунками. Також здійснюється внесення інформація про клієнтів до БД з оформленням карт постійних та нових клієнтів, що дозволить мати певні привілегії.