НОВ БЪЛГАРСКИ УНИВЕРСИТЕТ

Магистърска програма „Управление на проекти по

информационни технологии“

Курс: “MITM320 Бизнес Анализ в ИТ проекти”

Задание 2: “Управление на
документ от доставки към
клиент”

Изготвили:
Христина Петкова F98400
Мартин Маринов F98432
Камен Кънчев, F98438

София,
февруари 2021 г.

1
Съдържание
СЪДЪРЖАНИЕ 2

АНАЛИЗ НА ТЕКУЩОТО СЪСТОЯНИЕ 3

Описание на процеса 3
Диаграма на процеса 3
Случай на употреба 4
Use Case Диаграма 5

АНАЛИЗ НА ИЗИСКВАНИЯТА И ДЕФИНИРАНЕ НА ДИЗАЙНА НА РЕШЕНИЕ 5

Вариант 1 5

Описание на процеса: 5
Диаграма на процеса 7
Smart contract process flow 8
Таблица на състоянията 8
Случай на употреба 9
Use Case Диаграма 10
Функционални изисквания 11

Вариант 2 12
Описание на процеса: 12
Диаграма на процеса 13
Случай на употреба 14
Use Case Диаграма 16
Функционални изисквания 16

Вариант 3 17
Описание на процеса: 17
Диаграма на процеса 19
Случай на употреба 20
Use Case Диаграма 22
Функционални изисквания 22

АНАЛИЗ НА ПРЕДЛОЖЕНИТЕ РЕШЕНИЯ 24

Финансов анализ 24

Сравнителен анализ 28

Предложение за избор на вариант 28

ОЦЕНКА НА РЕШЕНИЕТО 29

Ключови показатели за ефективност на операциите 29

2
Анализ на текущото състояние
Описание на процеса
При доставка на оборудване, резервни части и консумативи по проект или договор за
обслужване на клиент се подписва приемо-предавателен протокол, който става
неразделна част от проектната документация или документацията по към договора.

1. Протоколите се издават от ERP системата и се отпечатват от координатор

обслужване на клиенти.
2. Изпълнителят на съответната заявка за обслужване (сервизен инженер или
представител на отдел логистика) се грижи протоколът да бъде подписан от
представител на клиента по време на доставката.
3. В края на деня, след като са изпълнили всичките си заявки за този ден, сервизните
инженери и представителите на отдел логистика предават подписаните от
клиентите протоколи на координатор обслужване на клиенти.
4. Координаторът обслужване на клиенти прибира подписаните протоколи в архива
при съответния договор.
5. При нужда, търговеца по съответния договор или служител отговорен за
фактурирането търси протоколите в архива.

Случва се служителите, които извършват доставките да не предадат веднага протоколите

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

Диаграма на процеса

Фиг. 1. Workflow диаграма на текущия процес

Чрез Фигура 1, по-горе, настоящият модел на примерния процес е представен
графично. За целта е използвана диаграма на работния поток. Определят се 5 различни
3
звена, през които протоколът преминава в процеса на обработка - ERP системата,
координатор, изпълнител, клиент, търговски представител. Процесът започва в ERP
системата и завършва при координатора.
За целите на анализа настоящият модел на примерния процес е визуализиран и с
помощта на таблично описание (Таблица 1) и диаграма на случаите на употреба (Фигура
2). С тяхна помощ могат да се определят функционалните изисквания и да се търсят
допълнителни възможности за оптимизация в текущия процес, чрез разработка на
софтуер, ако самият процес позволява такава оптимизация.

Случай на употреба
Случай на Управление на документ от доставки към клиент – настоящ
употреба: процес

Обхват: Издаване на протокол, отпечатване на протокол, подпис на

протокол, предаване на протокол, архивиране на протокол,
търсене на протокол в архив

Основни Координатор обслужване на клиенти; Изпълнител на заявка

действащи лица:

Условия: Трябва да има създадена заявка за обслужване в сервизната

система.

Иницииране: Създаване на протокол в система (ERP).

Основен сценарий 1. Протоколът се издава от ERP системата

за успех: 2. Отпечатва се от координатор обслужване на клиенти.
3. Изпълнителят на съответната заявка за обслужване
(сервизен инженер или представител на отдел логистика)
се грижи протоколът да бъде подписан от представител на
клиента по време на доставката.
4. В края на деня, след като са изпълнили всичките си заявки
за този ден, сервизните инженери и представителите на
отдел логистика предават подписаните от клиентите
протоколи на координатор обслужване на клиенти.
5. Координаторът обслужване на клиенти прибира
подписаните протоколи в архива при съответния договор.

Разширения: 3а. След посещението на изпълнителя, заявката се затваря

(приключва)

5а. При нужда, търговеца по съответния договор или служител

отговорен за фактурирането търси протоколите в архива.

Резултат: Подписаният от клиента протокол е архивиран

4
 Таблица 1 - Описание на случай на употреба при настоящия процес

Use Case Диаграма

Фигура 2 - UML Use Case диаграма при настоящия процес

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

Анализ на изискванията и дефиниране

на дизайна на решение
Вариант 1

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

1. Протоколът се създава от ERP системата в електронен вид и автоматично се

изпраща към ECM системата
2. Съдържанието на протокола се разпознава (OCR) от системата и файлът се
записва в Searchable PDF формат, като използва транзакционен протокол(Smart
Contract)
3. Системата автоматично извлича необходимите метаданни и индексира въведения
протокол
5
 4. След доставката до клиента изпълнителят на съответната заявка за обслужване
през мобилното приложение на ECM системата извършва:
4.1 Вход в системата чрез идентификация на потребителя с неговите domain
credentials (Single Sign On)
4.2 Намира съответния протокол по номер на заявка
4.3 Зарежда електронния протокол.
5. Изисква подпис с електронна писалка от страна на клиента на електронното
устройство.
6. Изпълнителят на съответната заявка за обслужване запазва документа
7. Системата прави автоматична проверка дали има положен подпис в полето за
подпис
8. Системата изпраща автоматично съобщение до изпълнителят на съответната
заявка за успешно запазен протокол.
9. Системата презаписва файла в Searchable PDF формат и маркира протокола като
предаден, , като използва транзакционен протокол(Smart Contract)
10. Системата изпраща автоматично на имейл на клиента подписания протокол
11. Системата изпраща съобщение за предаден протокол към ERP системата, като
използва транзакционен протокол(Smart Contract)
12. ERP системата има връзка със сервизната система, където автоматично се
приключва заявката за обслужване
13. ERP системата не позволява приключване на заявката за обслужване докато не
получи съобщение за предаден протокол
14. При нужда, търговеца по съответния договор или служител отговорен за
фактурирането търси протоколите в електронния архив.

6
Диаграма на процеса

Фиг. 3. Workflow диаграма на Вариант 1 на оптимизирания процес

7
Smart contract process flow

Фиг. 4. Диаграма на транзакционния протокол на Smart Contract

Таблица на състоянията

Фиг. 5. Таблица на състоянията за Вариант 1

8
Случай на употреба

Случай на Управление на документ от доставки към клиент - Вариант 1

употреба:

Обхват: Постъпване; подпис; проверка; запис; архивиране; търсене;

приключване на заявка в ERP

Основни лица: Изпълнител на заявка

Условия: Трябва да има създадени протокол в система ERP и заявка за

обслужване в SMS.

Иницииране: Получаване на протокол в система ECM.

Основен сценарий 1. Протоколът се създава от ERP системата в електронен вид

за успех: и автоматично се изпраща към ECM системата
2. Съдържанието на протокола се разпознава (OCR) от
системата и файлът се записва в Searchable PDF формат
със статус “Инициализиран”, като използва транзакционен
протокол(Smart Contract)
3. Системата автоматично извлича необходимите метаданни
и индексира въведения протокол
4. След доставката до клиента изпълнителят на съответната
заявка за обслужване през мобилното приложение на ECM
системата извършва:
4.1 Вход в системата чрез идентификация на потребителя
с неговите domain credentials (Single Sign On)
4.2 Намира съответния протокол по номер на заявка
4.3 Зарежда електронния протокол.
5. Изисква подпис с електронна писалка от страна на клиента
на електронното устройство.
6. Изпълнителят на съответната заявка за обслужване
запазва документа
7. Системата прави автоматична проверка дали има положен
подпис в полето за подпис
8. Системата изпраща автоматично съобщение до
изпълнителят на съответната заявка за успешно запазен
протокол
9. Системата презаписва файла в Searchable PDF формат и
маркира протокола със статус “Подписан”, като използва
транзакционен протокол(Smart Contract)
10. Системата изпраща автоматично на имейл на клиента
подписания протокол
11. Системата маркира протокола със статус “Предаден” и
изпраща съобщение за предаден протокол към ERP
системата, като използва транзакционен протокол(Smart
Contract)
12. ERP системата има връзка със сервизната система, където
автоматично се приключва заявката за обслужване

9
 Разширения: 7а. Ако няма положен подпис, системата връща съобщение до
изпълнителя на съответната заявка за обслужване
7b. Иницииране на процеса от точка 5
9а. При нужда, търговеца по съответния договор или служител
отговорен за фактурирането търси протоколите в електронния
архив.
12а. Сервизната система не позволява приключване на заявката
за обслужване докато не получи съобщение за предаден протокол

Резултат: Подписаният от клиента протокол е архивиран и заявката е

приключена.

Таблица 2 - Описание на случай на употреба при Вариант 1 на решението

Use Case Диаграма

Фигура 6 - UML Use Case диаграма при Вариант 2 на решението

10
Функционални изисквания
Едно от основните изисквания за Вариант номер едно е това да се дигитализира подписа на
клиента, тъй като във варианта не се използват хартиени протоколи. Това трябва да става
по начин по който това не застрашава сигурността на клиента. Изискването е разписано
подробно по-долу в таблица 2.

Идентификационен F-0167 (Функционално изискване)

номер:

Име: Дигитализиране на подпис

Продукт: мобилно приложение на ECM система

Източник: Мениджър услуги (Service Manager)

Собственик: Мениджър услуги (Service Manager)

Приоритет: Висок

Заинтересовани лица: Изпълнител на заявка, Мениджър услуги, Търговец или

служител отговорен за фактурирането, Клиент

Тип на изискването: Нова функционалност

Описание: Дигитализиране на подпис и визуално представяне на

подписа в полето за подпис в документа

Критерий за приемане на Системата трябва да дигитализира положения от клиент

изпълнението: подпис и да постави изображението на определеното за
подпис мястото в документа

Уточнение: Възложителят изисква функционалността, тъй

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

Свързани документи: Записки от срещата на заинтересованите

страни

Свързани изисквания: F-0168 (Всички подписи трябва да се прикрепят към

документа по надежден начин и да не се съхраняват
отделно)
F-0169 (Подписаните документи трябва да се съхраняват в
защитена с криптиране среда)

Доставка: Версия 1.0

Коментари: Документите ще бъдат само в PDF формат

Таблица 3 - Описание на изискването в каталога на изискванията

Това изискване е основно за предложения вариант на решение, тъй като без него
клиентите няма да могат да подписват приемо-предавателни протоколи в електронен
вариант, а без тях цялостното решение се обезсмисля.
11
Вариант 2

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

1. Протоколът се създава от ERP системата в електронен вид,с баркод съдържащ

уникален номер на протокола и връзка към съответните договор и заявка и
автоматично се изпраща към ECM системата
2. Съдържанието на протокола се разпознава (OCR) от системата и файлът се записва
в Searchable PDF формат и статус “Иницииран”.
3. Системата автоматично извлича необходимите метаданни и индексира въведения
протокол.
4. Системата изпраща автоматично съобщение до координатор обслужване за
записания протокол.
5. Координатор обслужване преглежда дали протоколът е коректно индексиран и
потвърждава неговото въвеждане
6. Координатор обслужване на клиенти разпечатва протокола
7. Изпълнителят на съответната заявка за обслужване (сервизен инженер или
представител на отдел логистика) се грижи протоколът да бъде подписан от
представител на клиента по време на доставката.
8. В края на деня, след като са изпълнили всичките си заявки за този ден, сервизните
инженери и представителите на отдел логистика предават подписаните от клиентите
протоколи на координатор обслужване на клиенти
9. Хартиеният протокол се сканира чрез МФУ клиента на ECM системата (координатор
обслужване на клиенти) – вход в системата чрез идентификация на потребителя през
интерфейса на МФУ клиента (идентификация с карта или PIN)
9.1 При сканирането системата разчита баркода и индексира сканирания документ с
уникалния номер.
9.2 След сканирането оригиналният хартиен протокол се поставя в архива, където
при нужда може да бъде открит по баркода с уникалния пореден номер.
10. Системата презаписва файла в Searchable PDF формат и маркира протокола със
статус “Подписан”
11. Системата изпраща автоматично съобщение до координатор обслужване за
записания протокол.
12. Системата изпраща съобщение до ERP системата за предаден протокол и маркира
протокола със статус “Предаден”
13. ERP системата има връзка със сервизната система, където автоматично се
приключва заявката за обслужване
14. Сервизната система не позволява приключване на заявката за обслужване докато не
получи съобщение за предаден протокол
15. След края на работния ден ECM системата автоматично проверява за непредадени
протоколи от заявките за деня (със статус “Иницииран”)
16. Ако има заявки с липсващи протоколи автоматично ги изпраща към ERP
17. ERP системата автоматично изпраща нотификация до съответния изпълнител на
заявката за липсващ протокол.
18. При нужда, търговеца по съответния договор или служител отговорен за
фактурирането търси протоколите в електронния архив

12
Диаграма на процеса

Фиг. 7. Workflow диаграма на Вариант 2 на оптимизирания процес

13
Случай на употреба

Случай на употреба: Управление на документ от доставки към клиент - Вариант 2

Обхват: Отпечатване; постъпване; архивиране; търсене; приключване на

заявка за обслужване в ERP; проверка

Основни действащи Координатор обслужване на клиенти; Изпълнител на заявка

лица:

Условия: Трябва да има създадени протокол в система (ERP) и заявка за

обслужване в SMS .

Иницииране: Създаване на протокол от система (ERP).

Основен сценарий 1. Протоколът се създава от ERP системата в електронен

за успех: вид,с баркод съдържащ уникален номер на протокола и
връзка към съответните договор и заявка и автоматично
се изпраща към ECM системата
2. Съдържанието на протокола се разпознава (OCR) от
системата и файлът се записва в Searchable PDF формат
и статус “Иницииран”.
3. Системата автоматично извлича необходимите
метаданни и индексира въведения протокол.
4. Системата изпраща автоматично съобщение до
координатор обслужване за записания протокол.
5. Координатор обслужване преглежда дали протоколът е
коректно индексиран и потвърждава неговото въвеждане
6. Координатор обслужване на клиенти разпечатва
протокола
7. Изпълнителят на съответната заявка за обслужване
(сервизен инженер или представител на отдел логистика)
се грижи протоколът да бъде подписан от представител
на клиента по време на доставката.
8. В края на деня, след като са изпълнили всичките си
заявки за този ден, сервизните инженери и
представителите на отдел логистика предават
подписаните от клиентите протоколи на координатор
обслужване на клиенти
9. Хартиеният протокол се сканира чрез МФУ клиента на
ECM системата (координатор обслужване на клиенти) –
вход в системата чрез идентификация на потребителя
през интерфейса на МФУ клиента (идентификация с карта
или PIN)
9.1 При сканирането системата разчита баркода и
индексира сканирания документ с уникалния номер.
9.2 След сканирането оригиналният хартиен протокол се
поставя в архива, където при нужда може да бъде открит
по баркода с уникалния пореден номер.

14
 10. Системата презаписва файла в Searchable PDF формат и
маркира протокола със статус “Подписан”
11. Системата изпраща автоматично съобщение до
координатор обслужване за записания протокол.
12. Системата изпраща съобщение до ERP системата за
предаден протокол и маркира протокола със статус
“Предаден”
13. ERP системата има връзка със сервизната система,
където автоматично се приключва заявката за обслужване
14. След края на работния ден ECM системата автоматично
проверява за непредадени протоколи от заявките за деня

Разширения: 10а. При нужда, търговеца по съответния договор или служител

отговорен за фактурирането търси протоколите в електронния
архив.
13а. Сервизната система не позволява приключване на заявката за
обслужване докато не получи съобщение за предаден протокол
14a. Ако има заявки с липсващи протоколи автоматично ги
изпраща към ERP
14b. ERP системата автоматично изпраща нотификация до
съответния изпълнител на заявката за липсващ протокол.
14c. При предоставяне на липсващия протокол от изпълнителя на
заявката сценарият се инициира от точка 9

Резултат: Подписаният от клиента протокол е архивиран и заявката е

приключена.

Таблица 4 - Описание на случай на употреба при Вариант 2 на решението

15
Use Case Диаграма

Фигура 8 - UML Use Case диаграма при Вариант 2 на решението

Функционални изисквания

В таблица 5 е подробно представено подробно изискването което е специфично за Вариант

2, а именно автоматично извличане на данните от протокол. Това изискване води до
намаляване на ръчния труд и е от съществена важност, тъй като чрез автоматизация на
процеса се постига намаляване на количеството на грешките.

Идентификационен F-035 (Функционално изискване)

номер:

Име: Автоматично извличане на данните от протокол

Продукт: ECM система

Източник: Търговец

16
Собственик: Мениджър обслужване на клиенти

Приоритет: Среден

Заинтересовани лица: Координатор обслужване на клиенти, Мениджър обслужване на

клиенти, Търговец или служител отговорен за фактурирането

Тип на изискването: Нова функционалност

Описание: Автоматично извличане на необходимите

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

Критерий за приемане Системата трябва да намери, разпознае,

на изпълнението: попълни и индексира набор от предварително зададени типове
данни от протокол

Уточнение: Възложителят изисква функционалността, тъй като тя ще спести

време, ще улесни търсенето в архива и ще отстрани риска от
човешки грешки при архивирането

Свързани документи: Записки от срещата на заинтересованите

страни

Свързани изисквания: F-036 (Системата трябва да може да обработва по описания

начин различно изглеждащи протоколи)

Доставка: Версия 1.0

Коментари:

Таблица 5 - Описание на изискването в каталога на изискванията

Вариант 3

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

1. Протоколът се създава от ERP системата в електронен вид,с баркод съдържащ

уникален номер на протокола и връзка към съответните договор и заявка и
автоматично се изпраща към ECM системата
2. Съдържанието на протокола се разпознава (OCR) от системата и файлът се записва
в Searchable PDF формат и статус “Иницииран”.
3. Системата изпраща автоматично съобщение до координатор обслужване за
записания протокол.
4. Координатор обслужване въвежда в системата (чрез уеб интерфейса) необходимите
индекси (метаданни), копирайки ги от визуализирания протокол в задължителните
полета.
5. Координатор обслужване на клиенти разпечатва протокола
6. Изпълнителят на съответната заявка за обслужване (сервизен инженер или
представител на отдел логистика) се грижи протоколът да бъде подписан от
представител на клиента по време на доставката.

17
 7. В края на деня, след като са изпълнили всичките си заявки за този ден, сервизните
инженери и представителите на отдел логистика предават подписаните от клиентите
протоколи на координатор обслужване на клиенти
8. Хартиеният протокол се сканира чрез МФУ клиента на ECM системата (координатор
обслужване на клиенти) – вход в системата чрез идентификация на потребителя през
интерфейса на МФУ клиента (идентификация с карта или PIN)
8.1 При сканирането системата разчита баркода и индексира сканирания
документ с уникалния номер
8.2 След сканирането оригиналният хартиен протокол се поставя в архива, където
при нужда може да бъде открит по баркода с уникалния пореден номер.
9. Системата презаписва файла в Searchable PDF формат и маркира протокола със
статус “Подписан”
10. Системата изпраща автоматично съобщение до координатор обслужване за
записания протокол.
11. Системата изпраща съобщение до ERP системата за предаден протокол и маркира
протокола със статус “Предаден”
12. ERP системата има връзка със сервизната система, където автоматично се
приключва заявката за обслужване
13. Сервизната система не позволява приключване на заявката за обслужване докато не
получи съобщение за предаден протокол
14. След въвеждане на всички предадени протоколи координатор обслужване проверява
за непредадени протоколи от заявките за деня (със статус “Иницииран”)
15. Маркира заявките с липсващи протоколи и ги изпраща към ERP
16. ERP системата автоматично изпраща нотификация до съответния изпълнител на
заявката за липсващ протокол.
17. При нужда, търговеца по съответния договор или служител отговорен за
фактурирането търси протоколите в електронния архив

18
Диаграма на процеса

Фиг. 9. Workflow диаграма на Вариант 3 на оптимизирания процес

19
Случай на употреба
Случай на употреба: Управление на документ от доставки към клиент - Вариант 3

Обхват: Отпечатване; постъпване; архивиране; търсене; приключване на

заявка за обслужване; проверка

Основни действащи Координатор обслужване на клиенти; Изпълнител на заявка

лица:

Условия: Трябва да има създадени протокол в система (ERP) и заявка за

обслужване в SMS .

Иницииране: Създаване на протокол от система (ERP).

Основен сценарий 1. Протоколът се създава от ERP системата в електронен

за успех: вид,с баркод съдържащ уникален номер на протокола и
връзка към съответните договор и заявка и автоматично се
изпраща към ECM системата
2. Съдържанието на протокола се разпознава (OCR) от
системата и файлът се записва в Searchable PDF формат и
статус “Иницииран”.
3. Системата изпраща автоматично съобщение до
координатор обслужване за записания протокол.
4. Координатор обслужване въвежда в системата (чрез уеб
интерфейса) необходимите индекси (метаданни),
копирайки ги от визуализирания протокол в
задължителните полета.
5. Координатор обслужване на клиенти разпечатва протокола
6. Изпълнителят на съответната заявка за обслужване
(сервизен инженер или представител на отдел логистика)
се грижи протоколът да бъде подписан от представител на
клиента по време на доставката.
7. В края на деня, след като са изпълнили всичките си заявки
за този ден, сервизните инженери и представителите на
отдел логистика предават подписаните от клиентите
протоколи на координатор обслужване на клиенти
8. Хартиеният протокол се сканира чрез МФУ клиента на
ECM системата (координатор обслужване на клиенти) –
вход в системата чрез идентификация на потребителя през
интерфейса на МФУ клиента (идентификация с карта или
PIN)
8.1 При сканирането системата разчита баркода и
индексира сканирания документ с уникалния номер
8.2 След сканирането оригиналният хартиен протокол
се поставя в архива, където при нужда може да бъде
открит по баркода с уникалния пореден номер.
9. Системата презаписва файла в Searchable PDF формат и
маркира протокола със статус “Подписан”
10. Системата изпраща автоматично съобщение до

20
 координатор обслужване за записания протокол.
11. Системата изпраща съобщение до ERP системата за
предаден протокол и маркира протокола със статус
“Предаден”
12. ERP системата има връзка със сервизната система, където
автоматично се приключва заявката за обслужване
13. След въвеждане на всички предадени протоколи
координатор обслужване проверява за непредадени
протоколи от заявките за деня (със статус “Иницииран”)

Разширения: 9а. При нужда, търговеца по съответния договор или служител

отговорен за фактурирането търси протоколите в електронния
архив.
12а. Сервизната система не позволява приключване на заявката за
обслужване докато не получи съобщение за предаден протокол
13a. Ако има заявки с липсващи протоколи ги маркира и ги изпраща
към ERP
13b. ERP системата автоматично изпраща нотификация до
съответния изпълнител на заявката за липсващ протокол.
13c. При предоставяне на липсващия протокол сценарият се
инициира от точка 8

Резултат: Подписаният от клиента протокол е архивиран и заявката е

приключена.

Таблица 6 - Описание на случай на употреба при Вариант 3 на решението

21
Use Case Диаграма

Фигура 10 - UML Use Case диаграма при Вариант 3 на решението

Функционални изисквания

Една от основните функционалности на Вариант 3 за процеса за обработка на приемо-

предавателни протоколи е възможността за извършване на автоматична проверка за
непредадени протоколи за даден времеви период. Подробно описание на изискването е
представено в Таблица 7.

Идентификационен F-0120 (Функционално изискване)

22
 номер:

Име: Проверка за непредаден протокол

Продукт: ECM система

Източник: Координатор обслужване на клиенти

Собственик: Мениджър обслужване на клиенти

Приоритет: Среден

Заинтересовани Изпълнител на заявка, Координатор обслужване на клиенти,

лица: Мениджър услуги, Изпълнителен директор

Тип на изискването: Нова функционалност

Описание: Системата проверява за протоколи със статус “Иницииран” за

конкретен ден или период и визуализира на екрана
предварително зададена информация за тях

Критерий за Системата трябва да намери всички протоколи със статус

приемане на “Иницииран” за конкретен ден или период и да визуализира на
изпълнението: екрана списък с техните уникални номера и съответните номер и
дата на заявка, номер на договор и име на изпълнител на
заявка.

Уточнение: Възложителят изисква функционалността, тъй като тя ще даде

яснота за броя на непредадените протоколи и ще намали
възможността за грешка при архивиране

Свързани Записки от срещата на заинтересованите страни

документи:

Свързани F-0121 (Системата трябва да позволява сортиране на списъка

изисквания: с непредадени протоколи по дата на заявка и по име на
изпълнител на заявка)

Доставка: Версия 1.0

Коментари:

Таблица 7 - Описание на изискването в каталога на изискванията

Предложен е и подробен сравнителен анализ на настоящия процес и предложените

решения с цел да се определи най-подходящия подход за подобряване на процеса.

Анализ на предложените решения

Финансов анализ

23
С цел правилна оценка на предложените варианти за промяна на текущия процес е
направен подробен финансов анализ на всяко от предложенията. По този начин ще може
да се извърши оценка и да се определи дали дадена промяна в текущия процес би била
финансово оправдана.

Настоящ Вариант 1 Вариант 2 Вариант 3

процес

Брой поръчки за които 1500

трябва да се издаде
протокол месечно

Брой търсения в архива 250

месечно

Разходи за материали, консумативи, режийни на месец

Разходи за печат на
100 лв. 0 лв. 100 лв. 100 лв.
хартиени фактури на
месец в лв.

Разходи за физически 75 лв. 0 лв. 75 лв. 75 лв.

архив

Разходи за хостинг на 0 лв. 200 лв 200 лв. 200 лв.

софтуерни системи

Разходи за дигитален 0 лв. 150 лв. 150 лв. 150 лв.

архив

Разходи за офис издръжка 100 лв. 0 лв. 100 лв. 100 лв.
на координатор

Разходи за поддръжка на 0 лв. 600 лв. 500 лв 400 лв.

софтуерни системи

Общо оперативни разходи 275 лв. 950 лв. 1125 лв. 1025 лв.
за месец

Разходи за труд за издаване и обработка на 1 протокол

Труд в човекочасове за
0,2ч 0ч. 0.1 ч. 0.1 ч.
издаване на 1 протокол

Труд в човекочасове за
0.2 ч. 0.05 ч. 0.1 ч. 0.15 ч.
обработка на 1 протокол

24
Труд в човекочасове за
0,2 ч 0 ч. 0.2 ч. 0.2 ч.
архивиране на 1
протокол

Труд в човекочасове за
0,5 ч 0,1 ч. 0,2 ч. 0,2 ч.
търсене в архив на 1
протокол

Себестойност на
10 лв. 10 лв. 10 лв. 10 лв.
човекочас труд за
координатор

Общо количество работа

900 ч. 0 ч. 600 ч. 675 ч.
издаване на протоколи
за месец

Общо количество работа

125 ч. 25 ч. 50 ч. 50 ч.
за търсене на протоколи
в архив на месец

Обща стойност на
9 000 лв 75 лв. 6 000 лв. 6 750 лв.
разходите за издаване
на протоколи на месец

Обща стойност на
1 250 лв. 325 лв. 500 лв. 500 лв.
разходите за архивиране
на протоколи на месец

Обща стойност на
10 250 лв. 325 лв. 6 500 лв. 7 250 лв.
разходите за труд на
месец

Разходи за разработка и внедряване на процеса

Разходи за обработка на
0 лв. 5 000 лв. 5 000 лв. 5 000 лв.
текущия архив

Време в човекочасове за
0 ч. 1 500 ч. 1000 ч. 800 ч.
разработка на
допълнителен софтуер.

Време в човекочасове за
0 ч. 150 ч. 100 ч. 80 ч.
тестване на
допълнителен софтуер.

Време в човекочасове за
0 ч. 100 ч. 50 ч. 50 ч.
внедряване на
допълнителен софтуер.

Време в човекочасове за
0 ч. 150 ч. 100 ч. 120 ч.
обучение на
служителите в новия

25
процес

Закупуване на
0 лв. 500 лв. 500 лв. 500 лв.
софтуерни компоненти

Закупуване на хардуер
0 лв 0 лв 200 лв. 200 лв.

Себестойност на
40 лв. 40 лв. 40 лв. 40 лв.
човекочас труд за
софтуерен специалист
за разработка, тестване
и внедряване

Себестойност на
10 лв. 10 лв. 10 лв. 10 лв.
човекочас труд за
обучение

Обща стойност на
0 лв. 60 000 лв 40 000 лв. 32 000 лв.
разходите за разработка

Обща стойност на
0 лв. 6 000 лв 4 000 лв. 3 200 лв.
разходите за тестване

Обща стойност на
0 лв. 4 000 лв. 2 000 лв. 2 000 лв.
разходите за внедряване

Обща стойност на
0 лв. 1 500 лв. 1 000 лв. 1 200 лв.
разходите за обучение

Обща стойност на
0 лв. 77 000 лв. 52 700 лв. 38 400 лв.
разходите за разработка
и внедряване

Общи разходи:

Първоначална инвестиция
0 лв. 77 000 лв. 52 700 лв. 38 400 лв.
за разработка и
внедряване

Общо оперативни разходи

10 475 лв. 1 275 лв. 7 625 лв. 8 275 лв.
за месец

Общо разходи след 12 125 700 лв. 92 300 лв. 144 200 лв. 137 700 лв.
месеца от внедряването

Общо разходи след 24 251 400 лв. 107 600 лв. 235 700 лв. 237 000 лв.
месеца от внедряването

Общо разходи след 36 377 100 лв. 122 900 лв. 327 200 лв. 336 300 лв.
месеца от внедряването

26
Общо разходи след 48 502 800 лв. 138 200 лв. 418 700 лв. 435 600 лв.
месеца от внедряването

Общо разходи след 60 628 500 лв. 153 500 лв. 510 200 лв. 534 900 лв.
месеца от внедряването(5
години)

Таблица 8 - Анализ на решенията (алтернативите) на база на финансов анализ

Фигура 11 - Анализ на решенията (алтернативите) на база на финансов анализ

От Таблица 8 и Фиг. 11 се вижда, че всички предложени варианти водят до значителен

спад в разходите след внедряване на решението и значително спестяване на средства,
въпреки по-високата първоначална инвестиция.

Вижда се, че текущият процес няма нужда от начална инвестиция, но оперативните

разходи за него са твърде високи и всички останали варианти на процес за обработка на
протоколи с течение на времето генерират по-малко общи разходи, заради по-голямата
автоматизация

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

Вариант 2 и 3 имат по малки начални разходи от вариант 1, но по-големи оперативни. За

това и в дългосрочен план вариант 1 е по-изгоден финансово

Разликата между вариант 2 и 3 е минимална. Вариант 3 автоматизира по-малка част от

процеса и съответно началната му стойност е по-ниска, но оперативните разходи са по-
високи.

27
Сравнителен анализ
Очевидно, текущият процес има няколко основни слабости, а именно ниската
автоматизация, многото човешки и монотонен труд, възможността от загуба на хартиените
документи, трудността на търсене в хартиения архив и нарастващия обем на архива.

Предложените 3 варианта решават всички тези проблеми чрез въвеждане на различни нива
на дигитализация.

Вариант 1 включва най-високо ниво на дигитализация и практически почти елиминира

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

Вариант 2 запазва ролята на координатора, но неговата работа се променя и той трябва да

приема хартиените протоколи и да ги дигитализира посредством МФУ и Софтуер за
разпознаване на текст. Това намалява монотонното въвеждане на данни и предпазва от
грешка. Предимство на този вариант е, че поддържа и хартиен и електронен вариант, което
дава допълнителна сигурност.

Вариант 3 е много близък с вариант 2, но намалява автоматизацията в процеса на

извличане на метаданните от протокол. Те се въвеждат ръчно от оператор. По-малката
функционалност води до по-ниски разходи за внедряване, но по-високи оперативни.

Предложение за избор на вариант

Въз основа на направения финансов и сравнителен анализ препоръчваме да се осъществи
Вариант 1. Основната причина за това решение е максималната стойност на автоматизация,
която води до минимизиране на разходите в краткосрочен и дългосрочен план. Вариант 1
премахва нуждата от хартиени протоколи, което намалява времето за обработка до
получаване на подписа на клиента и предпазва от грешки и забавяния, както и възможно
унищожаване на протокола. Това решение е и по-устойчиво от екологична гледна точка,
като намалява използването на хартия и печатни консумативи. Вариант 1 разрешава
напълно проблема с възможната загуба на протоколи. При вариант 1 търсенето на
протоколи е сведено до търсене в електронен архив по определени категории, което прави
търсенето почти моментално.

Оценка на решението
Ключови показатели за ефективност на операциите

За да се оцени резултата след въвеждането на решение е необходимо да се определят

показатели за ефективност, чрез които да се направи сравнение на настоящия и
28
предишния процес използван при обработката на приемо-предавателни протоколи.
Показателите за ефективност са описани в Таблица 9.

Бизнес процес Обработка на приемо-предавателни протоколи

Описание на процеса Генериране, отпечатване, предаване към изпълнител,

приемане, обработка, архивиране

Заложени параметри Всички издадени приемно-предавателни протоколи

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

Очакване 100% от издадените приемно-предавателни протоколи да

бъдат успешно архивирани
Всички протоколи да бъдат архивирани до 8 часа след
издаването им

Цели ECM системата да осигури навременно и надеждно

архивиране на 100% от издадените приемно-
предавателни протоколи.

Мерки и показатели Брой издадени протоколи

Брой брой изгубени протоколи
% успешно архивирани протоколи = (Брой
издадени протоколи – Брой изгубени протоколи /
Брой издадени протоколи
% изпълнение на целта = % обработени навреме /
100%
Време от издаване до архивиране = Дата и час на
архивиране на протокола - Дата и час на създаване

Източници на информация ECM системата; ERP системата; Архив с протоколи

Наблюдение Седмични отчети

Таблица 9 - Определяне на мерки и показатели за ефективност при работа с протоколи

Следенето и контролът на тези показатели гарантира осигуряването на бизнес

стойност от новата информационна система, разработена и внедрена в резултат от
бизнес анализа.

29