Уперше скористатися системою “Телебанк - 24” та оцінити її переваги клієнти змогли у жовтні 2000 року, це були клієнти “Укрінбанку”, коли почала функціонувати автоматична довідкова система. Вона дає змогу отримати оперативну інформацію щодо всіх видів діяльності банку, офіційних та комерційних курсів іноземних валют на поточну дату. На час її впровадження проектна група вже підготувала до роботи платіжну систему, яка почала функціонувати у пілотному режимі з листопада 2000 року.

Із 1 лютого 2001 року система “Телебанк - 24” доступна для всіх бажаючих. Схему здійснення “Телебанк - 24” див. на додатку Т.

Як же працює ця система? Уклавши угоду на обслуговування клієнт отримує номер у системі та ПІН-код. Зателефонувавши до “Телебанку” він переключає телефон у режим тонованого набору, вводить свій номер та кілька цифр із ПІН-коду. Від шахрайства з боку будь-яких третіх осіб клієнта забезпечує багаторівневий захист, а саме:

1 рівень - лише клієнт та працівники банку знають номер договору в системі “Телебанк - 24”;

2 рівень - лише клієнт знає свій особистий ПІН-код;

3 рівень - клієнт сплачує лише обумовлені угодою платежі (навіть знаючи пароль або його номер у системі), ніхто не зможете переказати кошти на свій рахунок;

4 рівень - сума платежу не перевищує встановленого клієнтом ліміту;

5 рівень - завдяки роботі в автоматичному режимі конфіденційну інформацію клієнта не може отримати жоден співробітник банку, чи інша особа;

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

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

Щомісяця безпосередньо в банку або поштою за вказаною в договорі адресою клієнт може отримати докладну виписку і проконтролювати стан свого рахунку та платежі.

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

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

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

Приблизно, кожна операція триває дві хвилини.

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

Завдяки автоматичній обробці заявок можна обслужити більше клієнтів за тієї ж чисельності персоналу. Відтак зменшується собівартість операції, вплив “людського фактора”, тобто робота банку з клієнтом стає безперебійною і надійнішою [48].

Головна перевага для банку - залучення через систему “Телебанк - 24” нових клієнтів, збільшення обсягів продажу банківських продуктів і послуг.

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

3.3 Використання технічних можливостей в управлінні процесом безготівкових розрахунків

На сучасному етапі розвитку України загальновизнаним методом вивчення систем, які характеризуються випадковими процесами, є імітаційне моделювання. За його допомогою можна віднайти такі шляхи вдосконалення системи, які не потребують капіталовкладень. Розглянемо імітаційну модель для аналізу та оптимізації роботи Харківської філій АБ “Експрес-банк”, як учасника системи електронних платежів.

Комерційний банк - учасник системи електронних платежів (СЕП) НБУ - протягом дня надсилає інформацію в СЕП та отримує її. Найважливішою і най значущішою складовою цієї інформації є файли платежів, які банк формує в міру надходження платіжних доручень від клієнтів. За чинним регламентом СЕП кожний такий файл може містити від 1 до 1000 платежів. Скільки платежів слід помістити в ньому, вирішує сам банк. Очевидно, що чим менше їх заплановано помістити у файлі, тим швидше банківська установа його сформує та відправить, а отже, платежі швидше дійдуть до адресатів. З іншого боку, чим менше у файлі документів, тим більше самих файлів, а це підвищує навантаження на систему (кожний файл платежів супроводжується ще й файлом-квітанцією). Щоб допомогти банку з'ясувати, яку кількість платіжних документів доцільно поміщати в один файл, розроблено математичну модель.

Слід зазначити, в моделі розглядається ефективність функціонування банку в системі з огляду на ефективність роботи СЕП в цілому. Розглядаючи ефективність діяльності банку з його власної позиції, можна констатувати, що, дбаючи про своїх клієнтів, він зацікавлений насамперед у швидкому проходженні платежів і не вельми переймається проблемою загального навантаження на систему. Зазвичай банківська установа просто прагне надсилати багато файлів із невеликою кількістю документів у кожному з них, аби в самому банку платежі затримувалися якомога менше. Ця стратегія виправдовує себе з двох причин: по-перше, зменшується затримка платежів усередині банку, а по-друге, перші з дрібних файлів мають шанс бути опрацьованими раніше на наступному етапі (тобто на регіональному рівні), а отже, платежі швидше надійдуть до адресатів. Отож, якщо банк ставить за мету прискорення платежів і не бере до уваги проблеми завантаженості системи в цілому, йому справді вигідніше надсилати документи дрібними відправленнями.

Але є ряд банків, які працюючи за моделями консолідованого коррахунку 4, 5, 6 та 7 (що передбачають розташування філій на всій території України), належать до віртуальних банківських регіонів. Такі банки, сплачуючи за послуги СЕП, платять, серед іншого, й за обсяг інформації, надісланої у платіжних файлах. Оскільки кожний із них, окрім власне платіжних документів, містить певну кількість службової і технологічної інформації, загальний обсяг переданих даних зростатиме зі збільшенням кількості файлів, хоча число переданих платіжних документів залишатиметься незмінним. Зрозуміло, для банку такого типу не байдуже, у скількох файлах розміщувати документи, що надсилаються. Інтереси банків, які працюють за цією моделлю, полягають у зменшенні кількості файлів і відтак збігаються з інтересами пропускної спроможності СЕП у цілому. Адже зменшення кількості файлів, які банк надсилає у СЕП, означає послаблення навантаження на систему і водночас - зменшення витрат установи. Нині налічується близько 300 банківських установ такого типу - це приблизно п'ята частина усіх банків - учасників СЕП.

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

Стосовно оплати послуг СЕП зазначимо, що, крім уже згаданої плати за обсяг надісланої платіжної інформації, дійсної лише для частини банків, усі без винятку банки-учасники оплачують ще й кожний надісланий чи отриманий платіжний документ. Плата за отриманий документ - фіксована і становить 15 копійок, а за надісланий залежить від часу (табл.3.5).

Таблиця 3.5 Плата банку за надіслані платіжні документи

Час надходження документів до розрахункової палати	Плата, коп.
Із 8.00 до 16.00	15 * Кількість документів
Із 16.00 до 19.00	1,45 * 15 * Кількість документів
Із 19.00 до кінця банківського дня	2, 925 * 15 * Кількість документів

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

Перейдемо до конкретного складання моделі, як вже зазначалось, на прикладі ХФ АБ “Експрес-банк”. Мету моделювання можна сформулювати так:

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

- визначити, яка кількість документів у файлі забезпечить задану швидкість проходження платежів (тобто час очікування платежів не перевищить вказаний).

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

Для опису математичної моделі зробимо такі позначення:

t - номер хвилини. Відповідно до чинного регламенту СЕП банк надсилає початкові платежі до системи з 8.00 до 20.00. Тоді t = 1720;

- математичне очікування документів, які надходять від клієнтів банку в хвилину t (параметр розподілу Пуассона, дійсного на цей час);

At - кількість платіжних документів, що надійшли від клієнтів банку за хвилину t;

Ft - загальна кількість платіжних документів, які знаходяться в банку і чекають відправки у хвилину t;

m_i - порядковий номер хвилини, коли був сформований i-й (останній) файл;

St - середній час очікування документів, відправлених у хвилину t;

Qt - середній час очікування документів, відправлених із початку дня до хвилини t;

D - кількість документів у одному файлі;

V - загальний обсяг інформації, надісланої банком у СЕП протягом робочого дня;

C - загальна сума, витрачена банком на оплату надісланих у СЕП файлів.

Тоді модель можна описати такими співвідношеннями:

(3.5)

де p_k - рівномірно розподілена на [0.1] випадкова величина;

m_t = t, якщо Ft D; i N;

; t = 1720;

; t = 1720

де n - кількість файлів, відправлених до хвилини t;

; (3.6)

(3.7)

Як відомо, генератор випадкових чисел ЕОМ спроможний генерувати лише рівномірно розподілені на [0.1] числа. Тому для отримання чисел, розподілених за законом Пуассона, використовується формула (1).

Обсяг технологічної інформації, яка передається у кожному файлі платежів, становить 298 байт, а один платіж містить 594 байти інформації. Ці дані й використано у формулі (2) для підрахунку загального обсягу надісланої інформації. Формулу ж (3), яка дає змогу підрахувати загальні витрати, складено за показниками, наведеними у табл. 3.6.

Якщо шукаємо середній час очікування документів, то величина D є константою, Q₇₂₀ (чи S_t) - шуканим показником. Якщо ж визначається оптимальна кількість документів, то, навпаки Q₇₂₀ (S_t) буде заданою константою, а D - змінною. При цьому до моделі додається додаткове обмеження: DDD, де D , D - відповідно мінімальна та максимальна кількість документів у файлі. Загальний обсяг надісланої інформації V та загальні витрати C можна розрахувати за будь-якої мети моделювання. Ми кажемо “можна”, оскільки ці показники не є чинниками обмеження моделі, а становлять суто інформативні показники діяльності банку.

Перш ніж перейти до моделювання, необхідно визначити параметри моделі . Розбивши весь інтервал роботи банку в СЕП на години. (табл. 3.6)

Таблиця 3.6 Середня кількість початкових платежів, які надходять до банку

Час надходження	Кількість платежів
8.00 - 9.00	0
9.01 - 10.00	1
10.01 - 11.00	49
11.01 - 12.00	110
12.01 - 13.00	18
13.01 - 14.00	80
14.01 - 15.00	97
15.01 - 16.00	125
16.01 - 17.00	137
17.01 - 18.00	105
18.01 - 19.00	58
19.01 - 20.00	2

Як зазначалося, перша мета моделювання полягала у визначенні середнього часу очікування платежів за відомої кількості документів у файлі. Реально досліджуваний банк надсилає по 20-25 платежів у файлі. Змоделюємо його діяльність, задаючи по 10, 20, 30 платежів. Для всіх підсумкових показників моделі підраховано середні значення та стандартні відхилення, подані в табл.3.7 й позначені відповідно символами та .

Таблиця 3.7 Результати обчислення середнього часу очікування в банку при відомій кількості платежів у файлі

Показники	Кількість платежів у файлі
	10	20	30
Середній час очікування, хвилин	2,04	0,33	4,26	0,65	6,57	1,10
Обсяг надісланої інформації, байт	890943	126132	867018	124318	863384	134440
Загальні витрати копійок	26592	3837	24420	3370	21885	3646

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

Друга мета моделювання полягала в пошуку оптимальної кількості платежів у файлі для забезпечення заданого часу очікування платежів. Із попередніх результатів видно, що коли файл містить 10, 20 і 30 платежів, то середній час очікування становить відповідно 2,04; 4,26 та 6, 57 хвилини.

Тепер можна знайти таку кількість документів у файлі, за якої цей час не перевищуватиме 2, 3 і 5 хвилини. Для цього також було проведено ряд експериментів, у результаті яких одержано значення: відповідно 9, 14 та 23 документи. При цьому досягнуто мінімального стандартного відхилення - 1 документ, що свідчить про достатню точність моделі.

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

Для того, щоб модель виявилась адекватною, доведеться, по-перше, вивчити характер потоку початкових документів для банку ( тобто визначити тип випадкового розподілу та оцінити його параметри), а по-друге. адаптувати формулу (3.5). Узагальнено процес надходження платежів можна описувати різноманітними розподілами у різні інтервали часу. Тому може бути і вхідних параметрів моделі значно більше, і формула (3.5) - значно складнішою. Але, звичайно, чим ретельніше вивчено вхідний потік платежів, тим кращими будуть результати моделювання.

Шукаючи оптимальну кількість платежів у файлі, обмежуємо середній час очікування за весь день (задаючи значення Q₇₂₀). Узагалі ж на показники S_t та Q_t можна накладати й інші обмеження. Наприклад, шукати таку кількість документів у файлі, щоб до 13.00 середнє очікування платежів не перевищувало двох хвилин. Крім того, передбачалося, що кількість документів у файлі обирається раз на день - на початку дня. Загалом же цю кількість можна змінювати і кілька разів на день, у заздалегідь визначені моменти часу.

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

Одержані результати моделювання мають практичну цінність насамперед для Харківської філії АБ „Експрес-банк”, тому що модель будувалась на даних цього банку. Та водночас ми пересвідчилися, що вона дає досить точні результати, а отже, може використовуватися для аналізу та оптимізації роботи банку у СЕП.

4.ОХОРОНА ПРАЦІ

4.1 Аналіз санітарно-гігієнічних умов праці Харківської філії АБ “Експрес - Банк”

Дана філія Акціонерного банку “Експрес - Банк” знаходиться в Жовтневому районі міста Харкова. Воно розташоване в чотириповерховому житловому будинку та займає його перший поверх. Будинок є цегельним.

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

Проведемо аналіз санітарно-гігієнічних умов праці у відділі бухгалтерії. Загальна площа і висота даного відділу складають: площа = 52,35м², висота = 3,4 м. У відділі працюють 3 чоловіка, на кожного з яких доводиться 17,45 м² площі помешкання і 44,50 м³ його об'єму. Відповідно до СНІП 11-90-81 найменше припустиме значення площі і об'єму службового приміщення на одного працівника складає відповідно 4,5 м² і 15 м³. Тобто фактичне значення площі помешкання і об'єму на одного працюючого вище за нормальне. Тому цей показних можна вважати позитивним фактором у разі евакуації людей у випадку пожежі, тому що ширина проходу між столами достатня, труднощі може визвати те, що у кабінеті лише один прохід.

Розглядаючи питання промислової естетики, можна відзначити, що філія почала свою діяльність у серпні 2000 року, перед її відкриттям було зроблено капітальний ремонт приміщення. Стіни кабінету обклеєно новими шпалерами, підвісні стелі, приміщення обставлене кімнатними рослинами. Інтер'єр було зроблено в білих кольорах: що сприяє діловій атмосфері у відділу, настроює на повноцінну працю і не відволікає працівників на зайві думки. Крім того, керівництвом було закуплено нові сучасні меблі, яка є зручною та мінімізує нагромадження паперу, канцелярських приналежностей та інших речей. Зайві документи було віднесено в сховище. За таких умов звичайно ж пожежобезпечність кабінету значно було зменшено.

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

Згідно СН 245-71 на кожного працівника відділу повинно приходитись 30 м³ приточного повітря. Але об'єм приміщення на кожну людину перевищує нормативне значення тому можна сказати, що виконується відповідність приточного повітря необхідному в даному відділенні. Крім того, більша частина вікон виходить на внутрішній двір, що сприяє притоку свіжого повітря. Підлога в кабінетах кафель для підлог. В банку встановлено кондиціонери Samsung та система загального кондиціонування провітрення приміщень.

Для підтримання кращого мікроклімату в банку використовується центральна система опалення (водяна).

Природного освітлення достатньо для нормальної роботи, тому що вікна досить широкі, а будинок не знаходиться у затінку висотних будинків. В відділу знаходиться 4 вікна площею застеклення 1,6 м 1,85 м.

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

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

освітлення (лампи денного світла) для ефективної роботи відділу ввечері.

В кабінеті маємо три комп'ютери ІВМ що є джерелом електромагнітного випромінювання, лазерний принтер Hewlett Packard ^(h_p) LaserJet 1200. Проте з метою захисту працівників на комп'ютери встановлено захисні екрани, що знижують негативну дію електромагнітного випромінювання. Також у відділку використовуються монітори Sony 200P з захистом працівників від радіації MRP-2.

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

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

Таблиця 4.1 Значення параметрів, що характеризують санітарно-гігієнічні умови праці в відділі бухгалтерії АБ “Експрес-банк”

№ п/п	Параметр	Фактичне значення	Норматив по ДСТУ 12.100588, Сніп 2.04.05-9 та інші державні стандарти	Відповідність фактичного значення нормативу
1.	Температура повітря у перехідний період, С	23	22-24	відповідає
2.	Відносна вологість, %	41	40-60	відповідає
3.	Швидкість руху повітря, м/с	0,04	до 0,1	відповідає
4.	Освітленість, лк	450	400	відповідає
5.	Рівень шуму, дБА	50	50-65	відповідає

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

4.2 Техніка безпеки

Приміщення комерційного банку відноситься по класу електробезпеки до приміщень без підвищеної небезпечності. У кабінеті маються в наявності три комп'ютери виробництва фірми ІВМ, лазерний принтер Hewlett Packard ^(h_p) LaserJet 1200, що працюють від мережі 220V перемінного струму. Схеми комп'ютерів застраховані від короткого замикання і мають вбудовані датчики системи перевантаження, тобто при незначних неполадках з електрикою вся мережа комп'ютерів автоматично відключається. Крім того, два комп'ютери працюють у автономному режимі тобто мають акумулятори APC SMART UPS-700I NET на випадок непередбаченого відключення електрики, що дає можливість працювати ще дві години без якої б то не було втрати даних. Для захисту працівників від поразки електричним струмом передбачений тип захисту - заземлення. На екранах моніторів встановлено екрани, що захищають користувача від електромагнітного випромінювання. Також у відділку використовуються монітори Sony 200P з захистом працівників від радіації MRP-2. Для того, щоб скористуватися цими приладами було встановлено 8 розеток.

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

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

4.3 Пожежна безпека

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

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

Для запобігання пожежі необхідно провести ряд заходів:

Навчити службовців правилам пожежної безпеки;

Передбачити правильну експлуатацію систем опалення і кондиціонування;

Заборонити застосування відкритого вогню тощо.

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

На випадок пожежі у відділенні передбачені спеціальні пристосування для її гасіння: при невеликих загоряннях використовуються шухляда з піском, порошкові вогнегасники та азбестові покривала. В кабінетах встановлена спринклерна система пожежегасіння (мережа водопровідних труб, у яких постійно знаходиться вода під тиском). Для захисту від електричного струму у відділенні знаходяться спеціальні діелектричні гумові рукавички, гумові коврики та спеціальні огородження.

Розрахунок шляхів і часу евакуації людей.

Проведемо розрахунок шляхів і часу евакуації людей із відділу бухгалтерії банку. Відділ бухгалтерії філії знаходиться на першому поверсі. Категорія виробництва Д. Ступінь вогнестійкості будинку 3. Максимальна відстань від найбільш віддаленого місця у відділі до евакуаційного виходу складає 21,1 м, що відповідає встановленій нормі. Для розрахунку весь шлях руху потоку розділимо на 4 ділянки довжиною L_i і шириною _i, де і - окремі ділянки шляху. Зведемо ці дані в табл. 4.2.

Таблиця 4.2 Ділянки руху людського потоку

№ ділянки шляху	Ділянка руху людського потоку	Довжина Li, м	Ширина i, м
1	Прохід між робітниками місцями в приміщенні відділу	9,0	1,3
2	Коридор	2	1,2
3	Коридор-хол	10,0	2,5
4	Дверний проріз	1,1	1,5

Швидкість руху людського потоку на першій ділянці шляху визначається в залежності від щільності людського потоку D₁:

чол/м²,

де N₁ -- число людей у кредитному відділі, f -- середня площа горизонтальної проекції людини, м² (у зимовий час f = 0,125 м², у літню пору f = 0,1 м²) приймаємо f = 0,1 м², L₁=9,0 м - довжина першої ділянки шляху, м, ₁ = 1,3 м -- ширина першої ділянки шляху, м.

чол/м².

По отриманому значенню D₁ по додатку 28 (розрахункові параметри евакуації людей) визначаємо швидкість руху людського потоку V₁ (м/хв) і інтенсивність руху людського потоку q₁ (м/хв). Одержуємо V₁ = 100 м/хв, q₁ = 3 м/хв.

Підрахуємо час руху людського потоку на першій ділянці:

хвилини.

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

де _i, _і-1 - ширини розглянутого i-ї і попередній їй (i-1)-ї ділянок шляху в м, q_i, q_i-1 - інтенсивності руху людського потоку по розглянутим i-ї і попередній їй (i-1)-ї ділянкам шляху в м/хв.

У даному випадку друга ділянка шляху - дверний прохід, тоді

м/хв.

По додатку знаходимо V₂=100 м/хв.

Швидкість руху по другій ділянці (дверний прохід):

хв.

Інші дані розрахунків зведені в табл. 4.3.

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

Таблиця 4.3 Розрахункові дані

№ ділянки шляху	Інтенсивність руху qi, м/хв..	Швидкість руху Vi, м/хв	Час руху Ti
1	2	3	4
1	3,0	100	0,09
2	3,25	100	0,02
3	1,56	100	0,1
4	2,6	100	0,01

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

Т_розр == T_i = 0,09+0,02+0,1+0,01 =0,22 хв.

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

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

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

РОЗДІЛ 4 ВИКОРИСТАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ І ТЕХНОЛОГІЙ У БАНКІВСЬКІЙ СФЕРІ

4.1 Створення та перспективи розвитку банківської інформаційної системи “Грант”

БІС “Грант” - система, що забезпечує автоматизацію технологічного циклу Банку «Грант».

Банківська інформаційна система "ГРАНТ" є інтегрованою системою, призначеною для забезпечення повного технологічного циклу комерційного банку. У її основу покладені промислові рішення, які широко застосовуються у світовій практиці побудови інформаційних систем подібного класу, такі, як:

- відкритість системи;

- масштабність;

- використання технології "клієнт - сервер";

- використання ліцензійних базових засобів ведучих виробників;

- високий рівень захищеності системи;

- надійність збереження і вірогідність інформації.

У якості базових програмних засобів була обрана багатозадачна високонадійна операційна система UNIX і реляційна СУБД ORACLE. Використання цих продуктів дозволило розроблювачам системи практично цілком зняти із себе рішення питань захисту інформації на рівні БД і ОС, резервного копіювання і відновлення після збоїв, оскільки всі ці операції гарантовано забезпечуються базовими програмними засобами. Слід зазначити, що використовуване нами базове ПО має клас захисту С2.

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

При цьому на робочі місця покладаються тільки функції відображення і введення, а обробка інформації відбувається на серверах БИ й АРР.

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

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

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

- система працює в реальному режимі часу. У кожний момент інформація в системі відображає реальний стан справ банку;

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

Централізоване збереження і єдність механізмів обробки інформації дозволяють:

- уникнути дублювання даних, що підвищує їхню вірогідність і гарантує цілісність;

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

- полегшити процес нарощування функціональності системи.

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

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

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

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

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

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

Існуючий механізм "коригувальних" проводок дозволяє окремо враховувати бухгалтерські (оперативні) і фінансові залишки на рахунках. Це особливо важливо при вирішенні задач оподатковування.

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

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

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

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

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

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

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

Інтерфейс для користувача системи реалізований засобами ORACLE Developer 2000 і являє собою багаторівневе меню, яке динамічно змінюється, з якого викликаються екранні форми, формуються звіти, обробляються файли СЕП.

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

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

Головне меню системи налагоджується за допомогою спеціального "дизайнера меню", що дозволяє:

- вводити, видаляти, переміщати пункти меню

- створювати нові підменю

- керувати умовами доступності пунктів меню

- налагоджувати параметри виклику екранних форм і інших модулів

Крім того, у системі широко застосовуються контекстні "перехресні посилання" між екранними формами. Наприклад, з форми роботи з особовими рахунками можна викликати перегляд:

- руху по рахунку за довільний період

- оперативних документів по цьому рахунку

- черги до рахунка

- стану бронювання й арешту рахунка

- інформації про клієнта - власнику рахунка

- графіка нарахувань відсотків

Єдина архітектура побудови системи визначає й умови ліцензування і підтримки системи. Систему не ділиться на окремі Арми - вона являє собою єдиний інтегрований програмний продукт. Система постійно розвивається, розширюється її функціональність. У БІС “ГРАНТ” реалізована більшість операцій, необхідних для функціонування українського комерційного банку.

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

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

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

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

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

Такими подіями є відкриття і закриття дня, закриття різних видів введення, формування і прийом файлів СЕП.

Технічно процеси реалізовані у виді процедур сервера бази даних, виклик яких задовольняє описаної специфікації.

При бажанні користувач може створити власний процес і зв'язати його з визначеними подіями. Наприклад, якщо вам потрібно передавати залишки на балансових рахунках на вечір кожного дня в зовнішню аналітичну систему, то цю операцію можна автоматизувати, написавши відповідний процес і зв'язавши його з повним введення чи закриттям дня. З кожною подією може бути зв'язане довільне число процесів, а той самий процес може викликатися при настанні декількох подій. Результати виконання процесів протоколюються і зберігаються в системних таблицях протягом часу, зазначеного технологом ОДБ.

Головне меню системи є таблично керованим і дозволяє легко підключати до системи нові програми. Меню підтримує виконання екранних форм ORACLE Forms, SQL скриптів і файлів операційної системи, що виконуються, сервера додатків. Для модифікації і настроювання меню розроблений спеціальний дизайнер меню. За допомогою дизайнера меню створюється новий пункт меню, що зв'язується з програмою, що виконується. При цьому можуть бути визначені параметри виклику програми з даного пункту меню. Програма, що підключається, реєструється в централізованій системі розмежування доступу. Доступ до пункту меню може визначатися як правами доступу до програми, що виконується, так і прямо. Крім цього, приступність пункту меню можна поставити в залежність від стану банківського дня.

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

Набір вихідних документів системи і їхніх параметрів налагоджуються таблично. Для реєстрації вихідного документа досить указати його найменування, ім'я програми, що формує документ, і ім'я вихідного файлу. Також варто визначити права на формування документа в рамках єдиної системи контролю доступу. Системою підтримуються три типи програм формування вихідних документів: SQL скрипти, виконувані програмою SQL Plus, звіти ORACLE Reports і виконуючі файли операційної системи сервера додатків.

На сьогоднішній день існує безліч систем розробки додатків, що надають можливість роботи із сервером бази даних ORACLE (Delphi, Visual Basic, Power Builder, SQL Windows...).

4.2 «ELPay» - система оперативного управління банківським рахунком через Internet

Система ELPay являє собою якісно нове рішення в класі продуктів «Клієнт-Банк», націлених на надання послуг Банку віддаленому Клієнту за допомогою мережі Internet. Клієнт банку, використовуючи стандартний веб-браузер і традиційні способи виходу в Internet, одержує захищений доступ до свого рахунка в банку і можливість управління фінансами з будь-якої точки світу. Дана технологія має розповсюджену назву Internet Banking і дозволяє одержати нові принципові якості:

- доступ клієнта до свого рахунка за допомогою Internet з будь-якої точки світу без використання спеціального програмного забезпечення;

- оперативність відстеження стану свого рахунка і проведення операцій за рахунок онлайнової технології;

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

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

Система складається з наступних елементів:

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

- веб-сервера, що забезпечує надання списку послуг;

- сервера додатків, розташованого в банку й обробляючого дані запитів клієнта й забезпечуючого взаємодію з автоматизованою банківською системою (АБС);

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

Спрощено технологію роботи системи можна описати в такий спосіб.

Клієнт системи одержує доступ до свого рахунка за допомогою веб-браузера з будь-якого комп'ютера, що має доступ у мережу Internet. Про це піклується веб-сервер, на якому розміщаються Java-апплети з програмним забезпеченням (ПО). З веб-сервера на робочу станцію клієнта доставляється ПО реєстрації клієнта чи управління рахунком, реалізуючи так називану технологію «тонкого клієнта». При цьому веб-сервер може бути розміщений у будь-якому придатному для цього місці (у провайдера послуг Internet, безпосередньо в Банку, на вэб-ресурсі http://www.elpay.com). Java-апплет, завантажений з веб-сервера, забезпечує безпосереднє (минаючи веб-сервер) взаємодію клієнта із серверами додатків і баз даних, що розташовуються в банку.

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

Сервер Додатків обробляє всі запити клієнта до сервера баз даних, забезпечує надійність мережного з'єднання, вирішує питання безпеки, а також строго контролює взаємодію Клієнта із Сервером Баз Даних на всіх його етапах.

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

Интерфейсний модуль з АБС реалізує взаємодію з АБС відповідно до необхідних протоколів і форматів повідомлень. Можливість перебудови даного модуля визначає гнучкість системи стосовно різних типів АБС.

Специфіка обміну даними в рамках системи змусила розроблювачів порушити питання безпеки передачі даних на перше місце. Чутливість переданих по каналах мережі Internet даних до розкриття і модифікації, визначила методи і засоби захисту, використовувані в системі.

У системі використовуються наступні методи захисту:

- цифровий підпис платіжного доручення (два підписи на документі);

- шифрування даних на прикладному рівні, переданих на ділянці «клієнт-сервер додатків»;

- використання автентифікації і шифрування на ділянці «клієнт - веб-сервер» з використанням протоколу SSL (при необхідності);

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

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

У системі використовуються сертифіковані засоби криптографічного захисту інформації „Шифр”, зареєстровані 15 червня 2001р. у реєстрі Укрсепро № UA-1.112.14243-01, що реалізують:

- шифрування на основі алгоритму криптографічного перетворення за ДЕСТ 28147-89;

- процедури вироблення і перевірки електронного цифрового підпису на базі асиметричного криптографічного алгоритму ДЕСТ 34.310-95;

- процедури хешування інформації з ДЕСТ 34.311-95;

- процедури генерації і управління ключами відповідно до затвердженого технічного завдання (UA/23154898/00001-01 90 01-ЛУ).

У роботі системи беруть участь наступні елементи, для яких визначається політика безпеки :

- Сегмент мережі з Автоматизованою Банківською Системою (АБС). Даний елемент системи є найбільш важливим, що не допускає ніяких вхідних мережних з'єднань, ініціалізованих поза сегментом АБС.

- Сервери ELPAY (сервер додатків і сервер баз даних). Інформація, що міститься на цих серверах, також вимагає відповідних технічних і організаційних заходів безпеки. Тут також неприпустимі ніякі вхідні з'єднання, крім передбачених регламентом роботи сервера додатків.

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

Мережні сегменти в банку, відображені на малюнку, фізично розділяються за допомогою міжмережевого екрана (Firewall) чи прикордонного маршрутизатора. Базу правил доступу для кожного елементу системи створюється окремо.

Загальна політика безпеки може бути представлена наступним набором правил:

- дозволяється доступ у сегмент ELPAY з Internet тільки на сервер Додатків і тільки на визначений порт сервера;

- дозволяється доступ у сегмент ELPAY з боку сегмента АБС (для відновлення даних сервера ELPAY інтерфейсним модулем);

- все інше забороняється (забороняється будь-який доступ у сегмент АБС).

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