Минуле і майбутнє Управління ІТ-Послугами (ITSM)

imageУявляю переклад статті Стюарта Рейнса «Минуле і майбутнє Управління ІТ-Послугами» («The Past and Future of IT Service Management by Stuart Rance), опубліковану в блозі ITSM.Tools.

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

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

(Тут і далі курсивом примітки перекладача.)


Я беру участь в управлінні ІТ-услугамі (IT service management, ITSM) починаючи з 1970-х і став свідком безлічі змін з тих пір. Це короткий збірник моїх думок і спостережень, ніж ITSM був і чим, мені здається, буде в подальшому.

Виключно технічний фокус в 1970-х

Моя робота в ІТ почалася в кінці 70-х. Я займався підтримкою, відновлюючи обладнання, і досить довго розвивався в напрямку вирішення інцидентів і проблем широкого спектру апаратного та програмного забезпечення. Як і решта, хто займався схожими роботами в ІТ, я ходив на безліч навчальних курсів, де вивчав різні апаратні і програмні продукти та їх відновлювати, але серед них не було програм, процесів, послуг або роботі з замовниками. Якщо хтось запитував, чим я займаюся «за життя», я відповідав щось на кшталт: «Лагоджу комп'ютери» або «Вирішую проблеми з комп'ютерами». У той час я жодного разу навіть не чув про ITSM і, звичайно ж, не думав, що я роблю такі речі, як Управління Інцидентами (Incident Management) або Управління Проблемами (Рroblem Management).

ITIL в 1990-х

В середині 1990-х, я натрапив на ITIL (провідний набір кращих практик для реалізації ITSM), і це стало для мене одкровенням. Це було, як виявити сім'ю, яку я ніколи не знав. Я відкрив для себе ідеї для своєї діяльності, такі як Управління Доступністю (availability management), Управління Безперервністю Послуг (service continuity management), Управління Змінами (change management) і Управління Проблемами (problem management). Тепер я мав набір шаблонів, які міг використати, щоб додати свою роботу більше послідовності і строгості. Також у мене тепер був сленг, полегшує спілкування з колегами та замовниками.Я пішов курси ITIL Foundation і ITIL Service Manager, а в кінцевому підсумку став ITIL інструктором, передає ці великі ідеї іншим людям, щоб допомогти їм досягати кар'єрні цілі.

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

ITIL 2007 edition

У 2007 році вийшов новий реліз ITIL. Найбільшою зміною стала нова структура, побудована навколо життєвого циклу послуг. Тепер стало простіше зрозуміти, чим є послуги, і більше став фокус на їх значущості для користувачів. Найбільший акцент робився на Стратегію (Service Strategy, SS) і Розроблення Послуг (Service Design) і з'явилася ціла книга про Безперервному Поліпшенні Послуг (Continual Service Improvement, CSI). Також стало матися на увазі, що дотримання SLA може не бути самим важливим, що робить ІТ в організації. Так було звичайним для нас постачати SLA поки наші замовники сумували, розчаровувалися або скаженіли. Фокус на послуги і було тим у чому ми за фактом потребували. Нам довелося зрозуміти наших замовників з користувачами і забезпечити їм дійсну цінність від наших сервісів.

Так я змінив свій підхід до роботи.

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

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

Що далі?

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

Agile

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

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

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

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

Lean

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

У контексті ITSM найбільш важливі аспекти Lean:

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

Автоматизація

Автоматизація завжди була частиною управління ІТ. Навіть коли я починав (наприкінці 1970-х), ми автоматизували завдання скрізь, де тільки могли. Що ж змінилося змінилося? Стали більш доступні інструменти, що забезпечують і полегшують автоматизацію. Тепер ви можете автоматизувати майже все що завгодно, якщо вирішите це робити.

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

DevOps

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

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

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

Корпоративне Управління Послугами (Enterprise Service Management)

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

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

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

ITIL Practitioner

Останні поповнення ITIL це Керівництво Практика ITIL (ITIL Practitioner Guidance), що вийшло в січні 2016 року. Ця публікація підтримує безліч ідей, описаних в даному блозі.

ITIL Practitioner викладає дев'ять керівних принципів:

  1. Концентруватися на цінності (Focus on value)
  2. Працювати на людей (Design for experience)
  3. Відштовхуватися від того, як є зараз (Start where you are)
  4. Працювати системно (Work holistically)
  5. Рухатися маленькими кроками (Progress iteratively)
  6. Спостерігати в місці використання (Observe directly)
  7. Бути зрозумілим (Be transparent)
  8. Співпрацювати (Collaborate)
  9. Робити простіше (Keep it simple)
Також обговорюються три кореневі компетенції:

  • Метрики і процес вимірювання
  • Комунікації
  • Організація Управління Змінами
І все це описується в контексті Безперервного Поліпшення ІТ Послуг. Якщо Ви хочете дізнатися більше про ITIL Practitioner, я рекомендую прочитати керівництво по ITIL Practitioner і піти навчальний курс. Також можете ознайомитися з рев'ю ITIL Practitioner від мого хорошого друга Стефена Манна (Stephen Mann).

В ув'язненні

ITSM допоміг ІТ організаціям перетворитися з провайдера технологій у провайдера створюють цінність послуг. І не можна зупинятися, якщо ми будемо вирішувати проблеми 21 століття методами 1990-х, то швидко станемо неадекватні.

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

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

Мені дуже подобаються:

  • Канбан — метод управління розробкою/виробництвом, заснований на принципі «точно в строк»,
  • Cobit 5 — збірник практик/рекомендацій по Керівництву ІТ для створення цінності Бізнесу,
  • Resilia — збірник практик і система сертифікації фахівців з управління інформаційною безпекою від AXELOS
Ви можете дізнатися більше поточних обговорень цих тем в соцмережах:

Ну, і відвідуйте заходи, організовувані:

Від себе додам пару посилань на російськомовні ресурси на тему ITSM:

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

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.