У процесі бере участь два актори - касир і платник. На діаграмі касир зображений як пул, але подробиць роботи касира діаграма не розкриває. Процес починається з того, як платник, прийшовши в пункт прийому платежів, дізнається, чи працює цей пункт взагалі. Ця дія платника показано на діаграмі у вигляді діяльності.
У разі позитивної відповіді платник переходить до наступного кроку. Випадок, коли каса не працює, показаний у вигляді проміжного події, прикріпленого до діяльності «Дізнатися, чи працює каса», яке призводить до завершення процесу, зображеного у вигляді
Наступна дія платника - це надання касиру квитанції на оплату. Квитанція, надана касирові, показана на діаграмі у вигляді.
Далі, платник дізнається, чи можливо провести оплату по цій квитанції. Якщо можливо, то касиру передається необхідна сума грошей, а він, у свою чергу, віддає платнику надрукований чек і здачу. Дана діаграма описує хід процесу прийому платежу, однак вона не надає повної картини процесу. На ній не видно ні дій касира, ні процесів, що відбуваються з ККМ і ЦБД. Дана діаграма не є інформативною ні для бізнес-аналітика, ні тим більше для ІТ-фахівця, який надалі буде будувати архітектуру системи.
При розгляді діаграми, зображеної на малюнку 1.11, можна побачити, що КАССИР є єдиним актором процесу, на якому «замикаються» дії всіх інших акторів. Тому й діаграму процесу необхідно будувати сточки зору діяльності касира.
Малюнок 1.12 - Процес з погляду касира
На малюнку 1.12 видно чотирьох пулу, які відповідають «акторам» процесу. Центральне місце тут займає доріжка описом процесу, за який відповідає касир. Будь-яка помилка, що відбулася при роботі касира, будь то збій зв'язку з центральною базою даних, або перебій зі світлом, призводить до дії «Відмовити у прийомі платежу». Для того щоб не захаращувати діаграму зайвими зв'язками, перехід на дію «Відмовити у прийомі платежу» здійснюється за допомогою події посилання.
Всі актори, крім касира, зображені на діаграмі у вигляді так званих «чорних ящиків». Це означає, що на діаграмі не розкриваються деталі реалізації процесів, хоча сама нотація не забороняє цього. Тут рішення про доцільність відображення деталей - завдання проектувальника.
Дана діаграма виявиться корисною і зрозумілою бізнес аналітику - на ній прозоро показаний весь бізнес-процес прийому платежу, причому діаграма позбавлена ??деталей конкретної реалізації, які часто тільки заважають зрозуміти суть процесу. Також діаграма виявиться корисною та інформативною для ІТ-спеціаліста. Дана діаграма дозволить архітекторам і проектувальникам інформаційної системи правильно спроектувати її, проаналізувати навантаження, яка може бути надана на систему і виявити «вузькі місця». Наприклад, оскільки касир працює з Центральною Базою Даних і ККМ, то можна відразу сказати, що одним з найбільш вузьких місць системи буде забезпечення транзакції проведення платежу в ЦБД і на ККМ. Виходячи з такого аналізу, можна далі приймати рішення про технічної реалізації процесу.
Отже, в роботі представлений підхід до проектування систем масового обслуговування. Для побудови інформаційної моделі системи прийому комунальних платежів спочатку був використаний підхід, заснований на діаграмах прецедентів.
Таким чином, можна виділити основні кроки при проектуванні систем масового обслуговування:
1) Визначення основних елементів моделі і опис взаємодій між цими елементами допомогою Use Case діаграм мови UML.
2) Визначення потоку дій, набору подій системи і опис їх в нотації BPMN.
Чітке визначення, який процес буде працювати центральним при описі всієї системи в цілому.
1.4 Аналіз існуючих розробок і обгрунтування вибору
При виборі способів власної автоматизації робочого місця касира-операціоніста існують наступні альтернативи:
1) Придбати готове рішення.
Плюсами такого рішення можна вважати: низьку вартість АРМ, універсальний набір пов'язаних бізнес процесів, високу надійність. В якості мінусів слід зазначити: необхідність перебудови власної діяльності під придбану модель, відсутність специфічною звітності.
2) Придбати адаптується рішення і послуги з настроювання.
При такому підході отримуємо універсальне програмне забезпечення, адаптоване під специфіку нашого підприємства. Якість адаптації дуже сильно залежить від вартості додаткової настройки. Таке рішення буде враховувати специфіку організації, як в плані процесів, так і звітності. Надійність даного рішення буде менше, тому що в ході налаштування неминуче буде внесено якусь кількість помилок. Вартість володіння буде істотно вище, ніж у першому випадку.
3) Найняти власних фахівців, які створять рішення.
