о блоку для Правління. Для використання цієї можливості необхідно просто одного разу сформувати новий тип звіту і потім запускати його при необхідності отримання інформації, наприклад, про кількість виконаних проектів за період, про кількість нових звернень, що надійшли і про кількість закритих звернень.
Третьою сильною стороною є інтегрованість програмного забезпечення: наприклад, КонсультантПлюс вбудовується в контекстне меню продуктів пакету MS Office, а Redmine уміє відправляти оповіщення в пошту і вивантажувати дані в Excel. Тут відкриваються можливості, наприклад, по оперативному автоматичному інформуванню замовників про хід роботи з їх зверненням: можна повідомляти ключові етапи роботи (задача надійшла в роботу, завдання закрита і зміна вступила в силу), що підвищить задоволеність замовника роботою блоку.
У наявному програмному забезпеченні є кілька слабких місць, в порядку убування важливості: знижений швидкодію пошуку в інформаційній системі, ведення комунікацій за заявками в пошті, дублювання інформації про факт закриття інцидентів.
Загроза повільного пошуку полягає в тому, що невелике уповільнення кожної операції пошуку при великій кількості таких операцій скорочує продуктивність роботи співробітника. Для підвищення швидкодії пошуку необхідно більш часто архівувати виконані проекти і завдання, інформацію по яких, очевидно, користувачі системи запитують рідше середнього. Пропускна здатність технологічного блоку становить 50 проектів (у середньому по 8 завдань у кожному) і 250 самостійних завдань у квартал, знімаються замовником або йдуть у відмову в середньому 20 заявок на квартал. Відповідно, кожен квартал закриваються 320 заявок і 650 завдань, по кожній з яких зберігається історія дій і листування користувачів інформаційної системи, прикріплені документи. Зараз закриті завдання, яких близько 1000, архівуються раз на квартал при підведенні підсумків роботи блоку. До архівації вони беруть участь у швидкому пої?? ке, який через велику кількість оброблюваних об'єктів бази даних працює не так швидко, як хотілося б. А адже це позначається на продуктивності роботи всіх співробітників блоку, збільшуючи витрати їх робочого часу на отримання інформації.
Слабка сторона, яка полягає у веденні комунікації за заявками в електронній пошті, а не в системі обліку заявок, обумовлена ??тим, що замовникам звичніше задавати питання співробітникам технологічного блоку поштою, адже саме так замовники спілкуються з багатьма іншими підрозділами. Розрізненість інформації за заявкою створює загрозу того, що частина відомостей може бути не врахована і у випадку, якщо будуть втрачені зміни у вимогах до доопрацювання, робота буде виконана невірно. На жаль, змусити всі інші підрозділи Банку використовувати особливий підхід до комунікацій зі співробітниками технологічного блоку можна. Це неоптимально, тому з погляду бізнес-процесу спілкування підрозділів всього Банку, має бути єдине засіб зв'язку. Усувати цю загрозу потрібно вручну - силами працівників блоку, яким у посадові інструкції треба включити пункт, щоб вони в відповідних листах за заявками змінювали тему листа на номер заявки (тоді листи по одній заявці будуть групуватися для легкості пошуку потім). Коли співробітник завершує свою частину роботи над завданням і передає її колезі, співробітник повинен переглянути листи, що відносяться до цієї заявки і відобразити ключові, на його погляд, моменти в коментарях до електронної заявці в системі управління проектами і завданнями.
Подвійний введення інформації про факт виправлення інциденту відбувається тому, що звернень від користувачів АБС реєструються в системі технічної підтримки (ServiceDesk), там же ведеться облік динаміки виправлення помилок, а перед виконавцями завдання виправленню несправностей ставляться в системі управління проектами і завданнями (Redmine). Виконавець відписується про завершення завдання і перенесенні виправлених налаштувань в ІС Redmine, і ця інформація повинна бути ще окремо вручну продубльована в ІС ServiceDesk. Притому у виконавця (розробника, технолога) немає прав доступу до ІС ServiceDesk, і закривати інцидент там повинен адміністратор. Це не займає багато часу співробітника, але створює ризик несвоєчасного оновлення інформації, оскільки між закриттям завдання виконавцем і реакцією адміністратора на це закриття завжди є затримка. Виправити затримку можна інтеграцією ІС ServiceDesk і ІС Redmine. На даний момент в ІС Redmine для кожної виконуваної завдання вказується батьківська заявка/помилка. Можна зробити автоматичне закриття інциденту в ІС ServiceDesk, унікальний ідентифікатор якого відповідає номеру батьківського інциденту біля закривається завдання в ІС Redmine.
банківський інформаційний менеджмент
2.2 Технічне забезпечення
Технічне забезпечення - компле...
