Стоит ли внедрять ITIL? [закрыто]

Я вижу из вопроса «Тест Джоэля для заданий сисадмина» на ServerFault, что никто не говорил, что компании лучше использовать ITIL, иначе они не будут там работать. На самом деле никто не упомянул ITIL вообще.

ITIL - это причуда? Это слишком громоздко, чтобы быть практичным? Вы должны быть определенного размера, чтобы ITIL работал хорошо?

Определения ITIL «инцидент» и «проблема» интересны, но действительно ли организации, находящиеся в быстроразвивающейся среде службы поддержки, сочли полезным провести различие между этими двумя понятиями?

Абсолютно. ITIL - это не набор в камне 10 заповедей, которые должны соблюдаться до буквы.

Это просто фундамент или основа для работы.

Настоящая проблема заключается в интерпретации. Если вы возьмете ITIL на уровень, когда обход станет легче, чем внедрение, оно никогда не сработает. Но при правильном внедрении уровень ИТ-услуг повышается, а стресс сисадмина становится ОГРОМНЫМ!

Любой, кто внедряет ITIL догматично, - дурак (и они сказали мне это на «официальном» курсе ITIL).

Вы можете / должны адаптировать и адаптировать его части к вашим потребностям. Очевидно, что для одного ИТ-специалиста просто глупо попытаться внедрить ITIL, когда большинство разговоров между различными «областями» управления изменениями, управления выпусками и т. Д. На самом деле происходит внутри мозга одного человека, но, сказав, что на с другой стороны, если вам только что предложили стать внутренним менеджером службы поддержки для Microsoft, HP, Apple или кого-либо еще, с пользователями и центрами поддержки клиентов по всему миру, как вы вообще могли бы выполнить эту работу без ITIL или что-то похожее в качестве ориентира?

Я действительно хотел бы добавить в этот момент , что мы реализовали управление проблемами инцидента против нашей службы поддержки , и это было очень полезно.

ITIL не является включением / выключением, вы постепенно внедряете вещи, которые имеют отношение к вашей среде, и решаете проблемы, которые вызывают наибольшее трение / боль в вашей организации.

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

На самом деле это просто набор лучших общих практик и правил, которые зарекомендовали себя в организациях.

Что мне больше всего нравится в ITIL, так это то, что он определяет общий язык для общения с профессионалами из других компаний, особенно в европейской многоязычной многокультурной среде. ...

управление проблемами, управление проблемами ... и т. д. понимаются и имеют одинаковое значение.

Кроме того, я согласен с Робертом Моиром: любой, кто догоняет ITIL догматично, глуп

ITIL - это инструмент ... не ваше спасение.

По моему опыту, ITIL также была основой, которая позволяет вспомогательному персоналу и ИТ-персоналу противостоять необоснованным требованиям со стороны бизнеса и реализовывать реальные решения технологических проблем, а не «быстрых решений» и «МЫ ХОТИМ СЕЙЧАС, ЧТО ЭТО ОХЛАЖДАЕТСЯ! " требует.

Я работал в организации, которая использовала «изменения, служащие бизнесу», в качестве предлога для уничтожения, обхода или переопределения почти каждого стандарта, который пытался внедрить ИТ (аппаратное обеспечение, программное обеспечение, системы аутентификации, системы хранения и т. Д.). Эта компания потерпела неудачу и была куплена компанией, которая живет и дышит ITIL в модели поддержки.

Я перешел в новую компанию, и не только жизнь ИТ-специалистов стала лучше, но в долгосрочной перспективе БИЗНЕС стал счастливее, потому что у них стабильная среда, и они на самом деле получают лучшую поддержку и новые технологии быстрее, потому что существуют определенные стандарты для поддержка, которая вписывается в определенные стандарты технологии. Когда стандарт обновляется, мы знаем, каков наш путь обновления, и мы знаем, что его можно применить к очень широкому кругу наших развернутых систем. Это позволяет нам двигаться по этому пути намного быстрее.

Мы ЗАПРЕЩАЕТСЯ до сих пор proess для разрешения бизнес - единиц и различные приложения УБС для запроса «специального» оборудования или услуг, но так как мы делаем отзывать это очень «дорогой» бюджет-мудрый для тех , кто просил об этом. Структура ITIL дает вам

Да, но в то время как вы решаете, почему бы вам не хорошенько взглянуть на процедуры вашей организации и требования к поддержке, поговорите с менеджерами и пользователями, какой уровень поддержки они ожидают, если им придется сделать компромисс между деньгами. Затем запишите это и процедуры, используемые для выполнения вашей работы. То, что вы на самом деле сделали, - это то же самое, что и все эти вещи ITIL / ISO.

Знание таких стандартов, как ITIL, облегчает вышеуказанную задачу, потому что у вас есть структура, которая приводит к правильным вопросам, которые нужно задать, чтобы полностью покрыть задачу, но самое главное - это документация о:

• Что требуется
• Почему это требуется
• Для кого это требуется
• Когда это требуется
• Какой человек владеет требованием (отвечает)

Разделение документации на низшую сущность (например, на одну задачу) - это огромный объем работы, но как только вы это сделаете, вы, вероятно, обнаружите, что большое количество задач, выполняемых сейчас вручную, либо не нужно, либо может быть автоматизировано и / или может быть делегировано. ,

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

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

Идея ITIL имеет большой смысл, к сожалению, по моему опыту, это часто инструмент, позволяющий персоналу поддержки / оперативному персоналу преодолевать трудности и замедлять бизнес-изменения.