Погляд ITSM-консультанта на основні проблеми реалізації проектів по побудові звітності на прикладі процесу управління інцидентами c допомогою Business Objects

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

Оцінка ефективності IT-підрозділів може проводитися на основі даних, що збираються системою автоматизації процесів ITSM (IT Service Management). Але далеко не в кожній сучасній системі автоматизації присут ствует вбудований механізм генерації і надання аналітичної інформації.

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

У даній статті розглянуті основні проблеми, що виникають в проектах по побудові звітності, реалізованих засобами спеціалізованих програмних продуктів Business Objects XI і Crystal Reports XI, а також наведено можливі варіанти вирішення виникаючих проблем, вироблені у відповідності з практичним досвідом реалізації проектів з побудови звітності для процесу управління інцидентами, автоматизованого за допомогою програмного забезпечення HP OV Service Desk.

Інформативність звіту – результат раціонального підбору KPI (ключових показників)

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

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

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

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


Рис. 1. Діаграма виконання заявок

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

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

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

Наприклад, формула для розрахунку показника «середній час самостійного виконання заявок IT-фахівцем» може змінюватися в залежності від критеріїв, що позначають факт початку і закінчення обробки заявки. В одному випадку фактом початку обробки заявки може бути прийнята дата і час призначення її відповідного фахівця, в іншому – початком обробки може стати момент першого відкриття заявки фахівцем в інтерфейсі системи HP OV Service Desk.

За рахунок неоднозначності формулювань і формул розрахунку показників ефективності може виникнути ситуація, коли той чи інший звіт, вже реалізований виконавцем, виводить «помилкові», на думку замовника, значення. Тобто реалізовані в звіті критерії та формули розрахунку показників розходяться з критеріями, УЯВНОЮ замовником.

Добре, якщо даний факт вдалося встановити до підписання актів про прийом / здачі робіт за проектом, тоді виконавець своєчасно виправить формулу розрахунку відповідного показника. Але як бути, якщо факт «Помилкового» розрахунку показника з’ясовується через тиждень або місяць після закінчення проекту по звітності?

Узгоджена концепція – основа успішного проекту

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

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

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

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


Рис. 2. Форма звіту

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

Кожна форма створюється на основі вимог користувача звіту (форма на рис. 2 створена виходячи з вимог «Менеджера інцидентів») і містить набір таких елементів: заголовок, найменування полів, приклади результуючих і обчислюваних значень.

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

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

Такий підхід дозволяє ознайомити замовника з основними можливостями програмних продуктів Crystal Reports XI і Business Objects XI, з перспективою розробки додаткових звітів, в рамках нового договору.

Плюси


Мінуси


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

Плюси


Мінуси


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

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

Точність оцінки трудовитрат характеризує рівень компетентності консультантів

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

Одним з варіантів вирішення такого завдання може стати формування детального технічного завдання (ТЗ) на створення звіту по кожній з увійшли в концепцію форм. Наприклад, в ТЗ на створення звіту в середовищі Crystal Reports XI докладно розписуються всі формули, вхідні параметри, фільтри, елементи, що створюють основне наповнення звіту. Таким чином, формування ТЗ не тільки виключає неоднозначність трактування формулювань або формул розрахунку KPI, але й надає можливість максимально збільшити точність оцінки трудовитрат. Для того щоб оцінити трудовитрати, виконавець аналізує створене ТЗ, послідовно розглядаючи чотири основні чинники, що впливають на трудовитрати при реалізації звіту:
1. Спосіб реалізації звіту з використанням продуктів Crystal Reports XI і Business Objects XI. При спільному використанні продуктів Crystal Reports XI і Business Objects XI з’являється можливість реалізувати звіти як мінімум трьома різними способами (див. рис. 3):


Рис. 3. Способи реалізації звітів

У кожному звіті, реалізованому першим способом, потрібно окремо вказувати джерело даних, формувати необхідну структуру табличних зв’язків або писати sql-запит. До того ж при розміщенні звітів на веб-сервер Business Objects XI також знадобиться вказати джерело даних для кожного розташовуваного звіту. Все це робить даний спосіб не дуже зручним і не дуже актуальним при наявності можливості використання бізнес-моделі або «Юніверс», що знімають такого роду незручності.

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

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

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

2. Сумарна складність реалізації звіту в редакторі Crystal Reports XI. Практика реалізації звітів в редакторі Crystal Reports XI показує, що найбільш трудомістким є програмування формул.

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

Кожній формулі присвоюється певне фіксоване значення в балах. Після градації всіх формул підраховується сумарна кількість балів у звіті. Бали визначають кількість робочих годин, яке витратить виконавець на реалізацію формул. Відповідність годин роботи балам встановлюється на основі досвіду реалізації звітів та може змінюватися в залежності від рівня компетентності програміста. В випадку якщо звіт повністю реалізується в редакторі Crystal Reports XI, потрібно виставити додаткові бали на створення sql-запиту до бази даних системи HP OV Service Desk.

Фактично виконавець визначає трудовитрати на реалізацію всіх елементів (формул, параметрів, елементів дизайну, угруповань та фільтрів), описаних в ТЗ і входять до складу звіту, в середовищі Crystal Reports XI на основі своєї експертної оцінки.

3. Специфіка реалізації процесу управління інцидентами на базі системи HP OV Service Desk. Даний пункт передбачає оцінку трудомісткості робіт з розрахунку певних показників ефективності або отриманню певних даних на основі інформації, що зберігається в базі даних системи HP OV Service Desk.

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

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

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

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

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

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

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

Замість висновку

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

Необхідно додати, що крім порушених вище проблем, при виконанні подібних проектів актуальна проблематика безпосередньої реалізації висунутих та зафіксованих у ТЗ вимог замовника засобами продуктів Business Objects XI і Crystal Reports XI. Дана проблема виникає через функціональних обмежень розглянутих продуктів. Вона призводить до збільшення трудовитрат на пошуки обхідних рішень і, як наслідок, до зрушення встановлених проектних термінів.

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*