На головну

Процеси і організаційні підрозділи

  1.  VI. Основні фонетичні процеси.
  2.  VI. ПОЛІТИЧНІ ВІДНОСИНИ І ПРОЦЕСИ - ІСТОРИЧНИЙ І СУЧАСНИЙ АСПЕКТИ.
  3.  VII. Інші фонетичні процеси.
  4.  Автоволнових процеси в активних середовищах
  5.  Адміністративно-організаційні функції консула щодо фізичних і юридичних осіб Республіки Білорусь
  6.  Анодні процеси у водних розчинах
  7.  Асинхронні паралельні процеси.

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

Як правило, в наданні ІТ-послуг (сервісів) беруть участь одночасно кілька відділів і зачіпаються кілька областей знань (див. Рис).

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

У частині взаємодії бізнес-підрозділів та ІТ-департаменту в процессной моделі ITIL® можна виділити три рівні:

O операційний (взаємодія з користувачами),

O тактичний (взаємодія з замовниками) та

O стратегічний (узгодження цілей бізнесу та ІТ).

Мал. дає уявлення не тільки про горизонтальних і вертикальних зв'язках, а й про горизонті планування процесів.

У узгодження на стратегічному рівні горизонт планування складає кілька років. Управління Рівнем Послуг пов'язано з Угодами на тактичному рівні, де горизонт планування дорівнює приблизно одному році. Управління Змінами, Управління інцидентами і Служба Service Desk займається оперативними питаннями з горизонтом планування в кілька місяців, тижнів, днів або навіть годин.

3. Навчальний питання 3. Процеси підтримки ІТ-сервісів

3.1. Блок процесів підтримки ІТ-сервісів включає наступні процеси:

- Управління інцидентами;

- Управління проблемами;

- Управління конфігураціями;

- управління змінами;

- Управління релізами.

Процес управління інцидентами призначений для забезпечення швидкого відновлення ІТ-сервісу.

При цьому інцидентом вважається будь-яка подія не є частиною нормального функціонування ІТ-сервісу.

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

Показниками якості реалізації процесу є:

- Тимчасова тривалість інцидентів;

- Число зареєстрованих інцидентів.

При реалізації процесу повинні виконуватися наступні функції:

- Прийом запитів користувачів;

- Реєстрація інцидентів;

- Категоризація інцидентів;

- Пріоритизація інцидентів;

- Відстеження розвитку інциденту;

- Дозвіл інцидентів;

- Повідомлення клієнтів;

- Закриття інцидентів.

Необхідною елементом забезпечення ефективного функціонування процесу є створення служби підтримки користувачів (Help Desk), єдиної точки звернення з приводу різних ситуацій в ІТ-інфраструктурі, обробки та вирішенні призначених для користувача запитів.

Слід зазначити, що роль служби підтримки користувачів останнім часом зростає, що відбивається в її модифікованому назві - Service Desk.

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

На рис. 1 приведена діаграма активності для процесу Управління інцидентами. Користувач ІТ-сервісу виявляє порушення режиму надання сервісу і звертається в Service Desk ІТ-служби.

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

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

Якщо необхідно спеціалізоване обслуговування, то інформація щодо інциденту передається до підрозділу супроводу ІТ сервісів.

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

У цьому случаеоператівний персонал реалізує раніше документовану процедуру відновлення ІТ-сервісу.

Малюнок 1 - Діаграма активності процесу управління інцидентами

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

Після закриття інциденту для користувача надається можливість доступу до ІТ-сервісу з необхідними показниками якості. Момент закриття інциденту фіксується в журналі служби Service Desk.

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

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

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

При реалізації процесу повинні виконуватися наступні функції:

- Аналіз тенденцій інцидентів;

- Реєстрація проблем;

- Ідентифікація кореневих причин інцидентів;

- Виявлення відомих помилок;

- Управління відомими помилками;

- вирішення проблем;

- Закриття проблем.

Проблема закрита, коли виявлена ??відома помилка і узгоджений порядок її усунення.

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

На рис. 2 приведена діаграма активності для процесу Управління проблемами.

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

Це реалізується шляхом ідентифікації, моніторингу, контролінгу та забезпечення інформації про конфігураційних одиницях (CI - Configuration Item) і їх версіях.

Конфігураційні одиниці описують системні компоненти з їх конфігураційними атрибутами.

 Малюнок 2 - Діаграма активності процесу управління проблемами

Процес Управління конфігураціями відповідає за підтримання інформації про взаємини між CI і за стандартизацію CI, моніторинг інформації про статус CI (від «замовлена» до «списана»), їх місцезнаходження і всі зміни CI.

Інформація про CI зберігається в базі даних конфігураційних одиниць (Configuration Management Data Base - CMDB).

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

Елементи конфігурації представляють компоненти, які є:

- Матеріальними сутностями (серверна стійка, комп'ютер, маршрутизатор, модем, сегмент лінії зв'язку);

- Системними або прикладними програмними продуктами і компонентами;

- Реалізаціями баз даних;

- Файлами;

- Потоками даних;

- Нормативними або технічними документами;

- Логічними або віртуальними сутностями (віртуальний сервер, серверний кластер, пул дискової пам'яті, група пристроїв);

- Співробітниками.

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

Атрибути CI, як правило, відображають їх специфічні властивості і можуть включати:

- Ідентифікатори;

- Марки і назви моделей;

- Серійні номери;

- Мережеві адреси;

- технічні характеристики;

- Операційні характеристики.

Взаємозв'язку CI представляють відносини, які існують або можуть виникнути між двома і більше CI.

Як правило, мова специфікації моделі CMDB - XML.

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

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

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

При специфікації процесу важливими поняттями є:

- Сфера охоплення;

- Глибина деталізації;

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

Глибина деталізації (Level of Detail) - важливий аспект, що визначає в подальшому відносини між CI і атрибутику CI.

Процес управління змінами призначений для планування і узгодження змін. Даних процес передбачає:

· Реєстрацію всіх істотні змін в середовищі ІС підприємства,

· Дозволяє зміни,

· Розробляє графік робіт щодо змін і

· Організовує взаємодію ресурсів,

· Оцінює вплив зміни на середу ІС і пов'язані з ним ризики.

Діаграма активності процесу управління змінами приведена на рис. 4.

Основне завдання даного процесу - проведення тільки обґрунтованих змін в ІТ-інфраструктурі і відсів непродуманих або потенційно ризикованих змін.

Для цього кожна зміна конфігурації ІС організації в обов'язковому порядку оформляється запитом на зміну.

Повідомлення про порушення проходить стандартну процедуру схвалення.

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

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

Всі зміни в обов'язковому порядку реєструються процесом управління конфігурацією.

 Малюнок 4 - Діаграма активності процесу управління змінами

Процес управління змінами виконує наступні функції:

- Обробляє запити на зміни;

- Оцінює наслідки змін;

- Затверджує зміни;

- Розробляє графік проведення змін, включаючи відновлення при збої;

- Встановлює процедуру обробки запиту на зміну;

- Встановлює категорії і пріоритети змін;

- Управляє проектами змін.

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

В інших випадках зміна може бути прийнято.

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

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

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

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

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

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

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

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

- Розробка;

- Тестування;

- Поширення та впровадження.

Етап розробки не є обов'язковим для всіх підприємств (може бути переданий на аутсорсинг).

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

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

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

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

Процес управління релізами виконує наступні функції:

- Планування релізу;

- Проектування, розробка, тестування і конфігурація релізу;

- Підписання релізу в розгортання;

- Підготовка релізу і навчання користувачів;

- Аудит устаткування до початку впровадження змін

- Розміщення еталонних копій ПЗ в DSL;

Для оцінки якості діяльності процесу важливо ретельно вибирати метрики.

За масштабом релізи поділяються на три види:

- Великий реліз ПО і / або оновлення обладнання - зазвичай містить значний обсяг нової функціональності;

- Малий реліз ПО і / або оновлення обладнання - зазвичай містить незначні поліпшення, частина з яких могли бути виконані раніше як надзвичайні релізи .;

- Надзвичайний реліз ПО і / або оновлення обладнання - зазвичай містить виправлення деякого числа відомих помилок.

За способом реалізації релізи поділяються також на три види:

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

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

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

Особливою сферою відповідальності процесу управління релізами є бібліотека еталонного ПО (Definitive Software Library - DSL).

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

4. Навчальний питання 4. Процеси надання ІТ-сервісів

Блок процесів надання ІТ-сервісів відповідно до ITIL включає наступні процеси:

- Процес управління рівнем сервісу;

- Процес управління потужністю;

- Процес управління доступністю;

- Процес управління безперервністю;

- Процес управління фінансами;

- Процес управління безпекою.

Процес управління рівнем сервісу (Service Level Management - SLM) визначає, погоджує і контролює параметри ІТ-сервісу (ЯКІ?)

Ключова роль менеджера процесу - здійснення балансу між вимогами бізнесу та можливостями ІТ.

На основі каталогу ІТ-сервісів даний процес розробляє, погоджує та документує угоду про рівень сервісу (SLA - Service Level Agreement) між менеджментом ІС-служби і бізнес-користувачами.

Даний процес здійснює такі функції:

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

- Погоджує і документує SLA;

- Організовує контроль результативності каталогу сервісів в цілому і рівня окремих сервісів;

- Визначає пріоритетність сервісів;

- Здійснює управління версіями SLA;

- Готує плани підвищення якості сервісу, спрямовані на підвищення якості існуючих сервісів, або включення в SLA нових сервісів;

Діаграма активності процесу управління рівнем сервісу наведена на рис. 5.

Бізнес-користувач формулює вимоги до ІТ-послуги (встановити підтримку електронної пошти в режимі 24 х 7).

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

Малюнок 5 - Діаграма активності процесу управління рівнем сервісу

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

Процес управління потужностями (Capacity Management - CAP) призначений для оптимізації використання ресурсів ІТ-інфраструктури відповідно до вимог бізнесу до рівня обслуговування і тенденціями розвитку інфраструктури.

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

Процес управління потужностями повинен забезпечувати:

· Оптимізацію витрат,

· Часу придбання і розміщення ІТ-ресурсів з метою забезпечення виконання умов SLA.

фунции:

· Управління ресурсами, продуктивністю,

· Моделювання, планування потужностей,

· Управління навантаженням і

· Визначення необхідного обсягу технічних засобів для роботи додатків.

· Інвентаризація ІТ-ресурси;

· Картографування завантаження ІТ-сервісів;

· Аналіз проблем;

· Надання рекомендацій щодо аутсорсингу (в області пропускної здатності);

· Аналіз продуктивності в умовах реального завантаження;

Процес управління потужностями дозволяє аналізувати і прогнозувати розвиток ІТ-інфраструктури підприємства за рахунок наступного:

- Формування в централізованому сховищі даних про продуктивність ІТ-ресурсів для аналізу тенденцій, змін потреб і планування інвестицій в ІТ-інфраструктуру;

- Моделювання та планування сценаріїв оптимізації ІТ-інфраструктури для визначення вимог до продуктивності ІТ-ресурсів при змінах і розвитку бізнесу;

- Автоматизації динамічного перерозподілу ІТ-потужностей;

- Оцінки можливостей віртуалізації ІТ-ресурсів.

Процес управління доступністю (НАДІЙНІСТЮ) (Availability Management - AVM) контролює здатність служби ІТ забезпечити економічно ефективний і стійкий рівень доступності ІТ-сервісів, що задовольняє вимогам бізнесу.

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

Під доступністю розуміється здатність ІТ-сервісу виконувати потрібну опцію у встановлений момент або за встановлений період часу.

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

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

Процес управління доступністю здійснює такі функції:

- Інвентаризація ресурсів ІТ;

- Визначення вузьких місць ІТ-сервісів з точки зору доступності;

- Аналіз доступності ІТ-сервісів, в тому числі при відмові обладнання, ПЗ, каналів зв'язку і т. Д .;

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

Можливий варіант діаграми активності процесу управління доступністю наведено на рис. 2.6.

На рівні процесу управління проблемами виявлена ??відома помилка. В рамках процесу управління доступністю співробітник ІС-служби аналізує вплив компонентів ІТ-інфраструктури на доступність різних сервісів і ризик невиконання SLA по цих сервісів при виникненні помилки. На основі аналізу готуються пропозиції щодо змін ІТ-інфраструктури. Якщо пропозиції приймаються, то готується графік проведення змін.

Процес управління безперервністю надання ІТ-сервісів (форс-мажор) (IT Service Continuity Management - ITSCM) забезпечує виконання вимог до стійкості сервісів, в першу чергу необхідних для функціонування критичних бізнес-процесів.

 Малюнок 6 - Діаграма активності процесу управління доступністю

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

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

Мета процесу управління безперервністю надання ІТ-послуг - підтримка безперервності бізнесу в цілому.

Така підтримка означає:

· Що інфраструктура та ІТ-послуги, в тому числі послуги з підтримки (служба Service Desk), повинні бути відновлені за заданий період часу після виникнення надзвичайної ситуації.

· На час відновлення надання ІТ-послуг повинно підтримуватися на «аварійному» рівні, прийнятному для ведення бізнесу, тобто на рівні, мінімально необхідному для функціонування бізнесу.

Згідно ITIL процес відповідає за вирішення таких основних завдань:

- Оцінка впливу порушень в наданні ІТ-послуг при виникненні надзвичайної ситуації;

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

- Визначення періоду, протягом якого надання ІТ послуги повинно бути відновлено;

- Визначення загального підходу до відновлення ІТ-послуги;

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

Процес управління фінансами ІТ-служби (Financial Management) відстежує фактичні витрати в розрізі замовників, ІТ-сервісів і користувачів і на цій основі розраховує внутрішні ціни на послуги ІТ-служби.

Процес взаємодіє з процесом управління рівнем сервісу для визначення цін сервісів.

Основна мета процесу полягає в наступному:

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

- Упорядкувати поведінку клієнтів, надаючи їм інформацію про дійсну вартість ІТ-сервісів;

- Забезпечити повернення витрат на надання ІТ-сервісів.

Основне завдання процесу управління витратами - розрахунок витрат, пов'язаних з ІТ-сервісами, цін сервісів для бізнес-користувачів і пошук шляхів зниження витрат.

Функціями даного процесу є:

- Прогноз витрат і виручки (остання визначається на підставі внутрішніх цін на послуги);

- Розробка бюджету сервісів;

- Аналіз використання сервісів і пов'язаних з цим витрат, пошук шляхів їх зниження;

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

- Встановлення системи ціноутворення і

- Розробка системи виставлення рахунків за послуги;

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

Процес управління безпекою (Security Management) забезпечує впровадження, контроль та технічну підтримку інфраструктури безпеки, а також розробку і контроль дотримання стандартів безпеки існуючих, що розробляються і планованих ІТ-сервісів. У ряді випадків він розглядається поза рамками процесів надання ІТ-сервісів

Основне завдання процесу управління безпекою - планування і моніторинг безпеки ІТ-сервісів.

Функції процесу управління безпекою такі:

- Розробка корпоративної політики безпеки в частині ІС, забезпечення необхідного рівня безпеки в цій галузі;

- Аналіз проблем безпеки і ризиків в цій області;

- Аудит безпеки і оцінка інцидентів в цій області;

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

- Вибір систем і інструментів підтримки безпеки;

5. Навчальний питання 5. Угода про рівень сервісу

Основним документом, що регламентує відносини ІС служби та бізнес-підрозділів підприємства, є угода про рівень сервісу (Service Level Agreement - SLA). В даному документі дається якісний і кількісний опис ІТ-сервісів, як з точки зору служби ІС, так і з точки зору бізнес-підрозділів.

Угода про рівень сервісу визначає взаємні відповідальності постачальника ІТ-сервісу і користувачів цього сервісу.

Типова модель SLA має включати такі розділи:

- Визначення сервісу, сторони, залучені в угоду, і терміни дії угоди;

- Доступність ІТ-сервісу;

- Число і розміщення користувачів і / або обладнання, що використовують даний ІТ-сервіс;

- Опис процедури звітів про проблеми;

- Опис процедури запитів на зміну.

Специфікації цільових рівнів якості сервісу, включаючи:

- Середня доступність, виражена як середнє число збоїв на період надання сервісу;

- Мінімальна доступність для кожного користувача;

- Середній час відгуку сервісу;

- Максимальний час відгуку для кожного користувача;

- Середня пропускна здатність;

- Опису розрахунку наведених вище метрик і частоти звітів;

- Опис платежів, пов'язаних з сервісом;

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

- Процедура вирішення спорів, пов'язаних з наданням сервісу.

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

Як правило, в описує частини міститься наступна інформація:

- Ім'я сервісу;

- Посилання на пов'язані послуги;

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

- Підтримувані платформи або інфраструктури;

- Характеристики доступності, продуктивності;

- Процедури підтримки;

- Метрики;

- Процедури моніторингу.

В операційній частини призводять:

- Ім'я власник сервісу;

- Профіль клієнта;

- Залежно від інших сервісів;

- Модель Operations Level Agreement (OLA);

- Детальна інформація про технічну інфраструктуру, необхідної для забезпечення сервісу;

- Одиниці інфраструктури, що розглядаються як активи;

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

- Результати аудиту;

- Інформація про ціни.

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

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

- Потрібен певний рівень розвитку управління процесами і сервісами ІТ-служби підприємства, який передбачає, що процеси і ІТ-сервіси є вимірні;

- Бізнес повинен бути готовий сприймати деякі «стандартні послуги» ІТ-служби як набір керованих сервісів, висувати адекватні вимоги до рівня якості їх надання, брати участь в підвищенні їх якості;

- Забезпечення прозорості ціноутворення ІТ-сервісів, при якій ІТ-служба повинна обґрунтовувати формування ціни ІТ- сервісу та можливі шляхи її зниження;

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

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

Слід зазначити, що модель ITSM може застосовуватися для підприємств з ІТ-службами різного розміру: від 1 - 5 співробітників до декількох десятків співробітників.

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

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

Висновок - до 5 хв.

Зміст і методичні рекомендації:

- Узагальнити найбільш важливі, істотні питання лекції.

- Сформулювати загальні висновки.

- Поставити завдання для самостійної роботи.

- Відповісти на запитання студентів.

Лекція розроблена «___» ________ 2011 р

_______________________ (Єжов С. м.)

(Підпис, прізвище та ініціали автора)

 



© um.co.ua - учбові матеріали та реферати