Як бачимо з "Тесту Джоеля для роботи з системою адміністратора" на ServerFault , ніхто не сказав, що компанія краще використовувати ITIL або вони там не працюватимуть. Насправді ніхто не згадував ITIL.
ІТІЛ пристрасть? Це занадто громіздко, щоб бути практичним? Ви повинні мати певний розмір, щоб ITIL працював добре?
Визначення ITIL "інцидент" проти "проблеми" цікаві, але чи в умовах швидкого темпу служб довідки організації дійсно вважають корисним розмежувати це?
Відповіді:
Абсолютно. ITIL не є набором з каменю 10 заповідей, яких потрібно дотримуватися в листі.
Це просто фундамент або рамки, з яких можна діяти.
Справжня проблема виникає в інтерпретації. Якщо взяти ITIL до рівня, який обійдеться легше, ніж реалізація, він ніколи не вийде. Але при належному впровадженні рівень ІТ-сервісу підвищується, а стрес Sysadmin знижується WAAAAY!
Кожен, хто реалізує ITIL догматично, є дурнем (і вони мені це сказали на "офіційному" курсі ITIL).
Ви можете / повинні вважати, що вони можуть адаптувати та приймати його частини до ваших потреб. Очевидно, що для одного ІТ-магазину намагається спробувати впровадити ITIL, коли більшість розмов між різними "областями" управління змінами, управління випусками тощо відбуватиметься всередині мозку однієї людини, але сказав це, на іншому кінці шкали, якщо вам щойно запропонували багатство бути внутрішнім менеджером служб довідки для Microsoft чи HP або Apple або ким завгодно, з користувачами та центрами телефонів служби підтримки, як ви могли взагалі виконати цю роботу без ITIL або щось подібне як настанова?
Я дійсно хотів би додати в цей момент , що ми реалізували управління проблемами інциденту проти нашої служби підтримки , і це було дуже корисно.
ITIL не є рішенням увімкнення / вимкнення, ви поступово розгортаєте речі, що стосуються вашого оточення, і вирішуєте сфери, які викликають найбільше тертя / болю у вашій організації.
Наприклад: Якщо ваша служба технічної допомоги переповнена запитами, вона допомагає почати їх класифікувати, аналізуючи джерела та приймати рішення щодо дій щодо полегшення ситуації.
Це справді лише набір найкращих загальних практик та правил, які зарекомендували себе в організаціях.
Що мені найбільше подобається в ITIL, це те, що він визначає загальну мову, яку слід використовувати під час спілкування з ІТ-профі від інших компаній, тим більше, що в європейському багатомовному багатокультурному середовищі. ...
управління питаннями, управління проблемами .. тощо розуміються і означають те саме.
Крім того, я погоджуюся з Робертом Муаром: той, хто реалізує ITIL догматично, є дурнем
ITIL - це інструмент .. не ваш порятунок.
На моєму досвіді ITIL також створив основу, яка дозволяє обслуговуючим персоналам та ІТ-персоналу підтримувати свою позицію проти необґрунтованих вимог бізнесу та впроваджувати реальні рішення технологічних проблем на відміну від «швидких виправлень» та «МОЙ ХОЧЕМО, ЩО ЗАРАЗ КУЗАЄТЬСЯ! " вимоги.
Я працював в організації, яка використовувала "зміни, що обслуговують бізнес", як привід знищити, обійти або змінити майже всі стандартні ІТ, які намагалися реалізувати (апаратне, програмне забезпечення, системи аутентифікації, системи зберігання даних тощо). Ця компанія зазнала невдачі і її придбала компанія, яка живе і дихає ITIL в моделі підтримки.
Я здійснив перехід до нової компанії і не тільки покращує життя ІТ-персоналу, але, зрештою, БІЗНЕС щасливіший, оскільки вони отримують стабільне середовище, і вони насправді отримують кращу підтримку та нові технології Швидше, тому що визначені стандарти для підтримка, яка відповідає визначеним стандартам технології. Коли стандарт оновлюється, ми знаємо, що таке наш шлях оновлення, і ми знаємо, що його можна застосувати до дуже широкого кола наших розгорнутих систем. Це дозволяє нам рухатися цим шляхом набагато швидше.
Ми ЗАБОРОНЯЄТЬСЯ до сих пір proess для вирішення бізнес - одиниць і різні додатки УБС для запиту «спеціального» обладнання або послуг, але так як ми робимо відкликати це дуже «дорогий» бюджет-мудрий для тих , хто просив про це. Рамка ITIL дає вам це
Так, але хоча ви не приділяєте себе уважно процедурам і вимогам підтримки своїх організацій, поговоріть з менеджерами та користувачами, який рівень підтримки вони очікують, якщо їм доведеться здійснювати торгівлю між грошима. Потім задокументуйте це та процедури, які використовуються для вашої роботи. Те, що ви насправді зробили, те саме, що і про всі ці речі ITIL / ISO.
Знання таких стандартів, як ITIL, полегшує вищезазначене завдання, оскільки у вас є рамка, в результаті якої можна задати правильні питання, щоб повністю покрити завдання, але найголовніше - це документація про:
Розбиття документації на найнижчу сутність (як-от одне завдання) - це величезна кількість роботи, але як тільки ви це зробите, ви, ймовірно, виявите, що велика кількість завдань, виконаних зараз вручну, або непотрібна, може бути автоматизована та / або делегована .
Поглиблений ретельний погляд на вашу організацію ніколи не є популярним або простим, але це призведе до кращого розуміння компанії та допоможе вам бути більш прибутковим, просто перестаньте робити непотрібні речі та делегуючи завдання до меншої оплати праці рівень.
Те, що насправді зробить вас непопулярними, це те, що ви робите такі стандартизації, - це те, що часто ви ненавмисно описуєте, що багато шарів управління є лише завдяки собі, і що їх вирізання, швидше за все, покращить спілкування та ефективність.
Ідея ITIL має багато сенсу, на жаль, на моєму досвіді, це часто інструмент, який дозволяє персоналу підтримки / операцій подолати та уповільнити зміни, що обслуговують бізнес.