Как стать автором
Обновить

Комментарии 86

И получается, что админ только грустнее становится от таких знаний.
Зачастую именно так…
Знания преумножают скорбь. Скорбь ведет к ненависти. Ненависть приводит к Темной стороне.
… а темная сторона к печенькам.
Как перейти на темную сторону?
изучить ITSM…
А еще грустнее ему станет, когда попробует организовать рабочие процессы «по науке» а в ответ получит по шапке.
Ой, да блин…
Сертификаты нужны чтобы:
— если хочешь сам знать немного больше + всегда красивая бумажка на стенке есть )
— никто не знает что будет завтра — авось эта бумажка принесет работу.
— с сертификатоми в снг Вы нужны как зайцу стоп-сигнал. ЗА пределами снг — без сертификата Вы нормальному работодателю нужны, как зайцу стоп-сигнал.
А обязательно прямо все процессы внедрять?

У нас вот в гос. конторе минимум 400 компов (никто не считал) и нет даже Service Desk. Т.е. пользователи предоставлены сами себе.
Когда я заикнулся про то, что надо бы сделать хоть какой-нибудь саппорт, выяснилось, что лишний геморрой никому не нужен, пусть все остается как есть.
Я подумал: ведь и правда, там наверняка клоака, нелицензионный софт, ни у кого нет антивируса и т.д. Денег никто не даст. Нафиг надо «поднимать целину»?
А вы говорите ITSM :D
Нафиг? Расскажу в следующей публикации если хотите :)

Как раз история из жизни виндового админа подоспела.
Мне почему-то кажется, что внедрить управление инцидентами, сервис-деск и управления конфигурацией — уже очень неплохо. Сразу будет эффект.
Т.е. почему бы не внедрить ITSM частично? Это ведь не священное писание, которое надо выполнить от корки до корки, а просто рекомендации.
Я где-то читал, что наибольший экономический эффект дает как раз управление инцидентами.

Есть такое понятие SLA. Это внутренний договор о качестве, скорости и других характеричтиках предосталяемых услуг.
Без этого самого SLA пользователи никогда не могут быть уверены в IT сервисе, и, соответственно, надежность их работы падает.
Падает надежность — падает качество. Падает качество — падает прибыль. Падает прибыль — людей увольняют…
ITSM прочитал как BDSM после ваших слов.
при неумелом подходе первое часто превращается во второе :)
Нафиг? 8-0
Для скилла же.
После того как наша контора перешла на ITIL, я выучил очень много новых ругательств исключительно для именования этой замечательной концепции из четырехвеселых букв. К каждой задаче добавилась довольно существенная подзадача по айтилизации изначальной задачи. Причем эта подзадача часто требует больше времени и сил. Рабочий процесс по сути не изменился вообще, а только лишь усложнился и оброс десятками мелких препятствий, которые только и делают что мешают работать.
Вы знаете, когда я пришел работать в Philps, у меня таких проблем не возникло и ни у кого их не было. Просто надо мыслить категориями ITIL. И отказаться от мышления другими категориями. Иначе внедрять ITIL вообще бессмыссленно
есть подозрение что в нашем случае злую шутку сыграл конкретный инструмент (тикетная система), который оказался совершенно непригодным для работы и который мало пригоден для работы по принципам ITIL
Очевидно, что в Philips тоже есть такая система.
Но там крутейший (хоть и работающий только на Microsoft Java) HP Open View. НО ЗАТО ТАМ ЕСТЬ СРАЗУ И CHANGE-менеджмент, и все остальное. Есть также системы, ориентированные на ITIL, но бесплатные. Если мне не изменяет память, такой системой является Naumen Service Desk, например.

Все эти системы включают в себя полезные для пользователей плюшки типа составления заявки онлайн, что весьма экономит время сервис деска и положительно влияет на лояльность пользователей.
Одна ремарка — Филипс это нерусская компания ;)
В ОСАО Россия тоже начали внедрять ITIL, но меня сократили до конца интеграции (точнее в ее начале)
Часто сокращение кадров — эффект внедрения ITIL. Как ни грустно, это не ошибка в подпрограмме внедренцев, а реальная выгода от внедрения. Выход один — перепрофилироваться внутри новых процессов, а не оставаться со старыми скиллами.
Внедрял его в том числе я… так что вряд ли ))
Реальная проблема была в том, что компания и так разваливалась на глазах (кстати, так и ропдолжает разваливаться), а еще был кризис и сменилось руководство…

Мне хоть выходное заплатили, а тем кого уволили через неделю (в том числе начальству) — не заплатили ничего ))
Naumen Service Desk ни разу не бесплатная система.

Не знаю, как сейчас, а лет 5-6 назад HP Open View Service Desk (версии 4.5) был сильно ограниченной системой. Да, там есть много компонентов для СCMDB (за отдельные деньги правда), но попытка внедрения его приводила к необходимости переделывания части бизнес-процессов к тому варианту, который этот HP OV SD мог переварить. Назвать систему гибкой язык не поворачивается. Тот же Naumen'овский софт превосходил HP'шный по функциональности, а по цене так и подавно.
Ну сейчас он уже гораздо круче и гибче )))
Спасибо, что поправили про наумен, буду знать.

Но бесплатные системы, заточенные под ITIL точно есть
К моему счастью и счастью моих коллег на смену недовредренному из-за врожденных недостатков SD пришла сначала одна чудо-поделка от товарищей из CTI, а после нее Remedy, но этот момент я уже не заставл, так как сменил место работы.

Но хранение всех текстовых полей в базе данных SD в виде нечитабельных (но, обратимых) хэшей надолго осталось в моей памяти :)

Про наличие бесплатных систем не спорю.
На фоне стоимости HP OV SD или Remedy Наумен с его 150к рублей кажется почти бесплатным :)
HPOV у себя внедряют только очень мощные организации, которым не сложно заплатить интегратору за полное внедрение ))
Я собственно и работал в системном интеграторе, и мы сами себе его внедряли :)
Вернее программировали в нем костыли, чтобы этот SD работал хотя бы на 50% так, как нам было нужно (и как было описано в требованиях к case tracking system для сертификации на золотого партнера Cisco).

Насчет мощности организации тут вопрос спорный. На тот моменты компания насчитывала около 100 человек, но мы были одним из очень быстро растущих системных интеграторов на рынке.
Есть, например, otrs — имеет вебморду и сертифицирован под ITIL v.3
freshmeat.net/projects/otrs/
Упс, ссылку не ту вставил :)
otrs.org/download/
сорри за капс — случайно нажалось
На элегантность технических решения им там плевать — вот именно потому я не хочу больше никогда работать админом в не-ИТшной компании. В ИТ-шной компании элеганость решений ценят. А за пределами, дай бог, если денег на диски в софтовый RAID1 для сервера дадут.
Самое забавное во всем этом то, что люди, зачастую, изучают это не потому, что это им нужно, а потому что это нужно HR-ам, эдакое красивое четырехбуквенное сокращение на забугорском, да еще и вроде чего-то крутое значит.

Не работает этот ITIL/ITSM в нашем государстве. Не применим он практически нигде, так как это многоуровневая методика управления процессами, по сути, нацеленная на постоянное повышение уровня сервиса, а у нас сервиса в помине не было и нет, и не будет, пока однажы утром у всего Русского народа в голове не перемкнет единовременно в определенном направлении. Об управлении чем мы тогда тут говорим? На кой нам этот пласт знаний, если применить его негде? Изучать и продавать себя за бугром только — там может и оценят.
Сам пытался внедрять эти практики в трех разных компаниях, разной сферы деятельности — везде результат один — не нужно. Нет понимания данных методик и их полезности на уровне руководителей предприятия, собственников бизнеса.

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

Полезное для себя я вынес и руководствуюсь для себя некоторыми моделями, сертефикаты на стенку мне не нужны, Пикассо мне болше нравится. Будет необходимось — пойду сертифицироваться, а пока — пойду я лучше скрипт напишу, да спать лягу.
Вы так говорите, как будто за бугром в каждой конторе внедрен ITIL, летают феи и приносят админам пиво.
Может оно действительно не нужно небольшим предприятиям? Тем более, внедрение всех процессов. Затраты ведь большие.
Ок. Ставь планку — сколько есть денег? ;)
Я распишу, что за это можно получить.
Только мне нужны зарплаты админов и их зоны ответственности. Там для расчета окупаемости надо показывать высвобождение одних работ в профиле админа и появление других (часто более дорогих, но краткосрочных).
Я уже писал выше, что в нашей гос. конторе нет и не будет поддержки пользователей.
За ИТ отвечают 4 разных отдела, зарплата админов около 30к, квалификация у нас невысокая.
Может лет через 10 что-то изменится? :)

Вот на предыдущей работе (ИТ-корпорация) был внедрен BMC Remedy. И поддержка работала четко.
Ага. То есть вариант один: опенсорс и собственная инициатива?
Инициатива-то у народа есть?
Я думаю можно раскачать народ.
Проблема в том, что когда придет ОБЭП, увидит нелицензионную винду и спросит «кто компьютерщик?», то покажут пальцем в нас :)
Денег на замену ПО ясное дело никто не даст, потому что ИТ-бюджета нет.
Может стоит взять под крыло только тех пользователей, у которых винда лицензионная?
Проблема в том, что когда придет ОБЭП, увидит нелицензионную винду и спросит «кто компьютерщик?», то покажут пальцем в нас :)
Денег на замену ПО ясное дело никто не даст, потому что ИТ-бюджета нет.


Это к делу не относится. Хотя в ITIL и есть подпроцессы управления ИТ-ресурсами, отдельно за эту тему отвечает очень непопулярный (и на Хабре тоже) Software Asset management.

Если даже знать, сколько у тебя вареза — это лучше, чем просто пустить ОБЭП на делянку. Достанешь список, покажешь главному и он оценит, что дешевле — потерять должность или пробить бабок на закупку. К тому же, для госучреждений можно получить колоссальные скидки от Microsoft.
Ну у нас нет главного ИТшника. Пока пользователи «ничейные», то и ответственности за их варез нет.
Как только возьмем под крыло, все это станет нашей головной болью.
Все закупки подписывает лично Директор. Ну и зачем ему покупать нам лицензионную Windows? Его же за нее не посадят, посадят админа.
Такие вот ужасы бюджетного учреждения :)
Админа не посадят никогда, не сцы. Ты наемный работник, с тебя должностную инструкцию выполнять и всё.

За все отвечает именно ГД. Ну еще материально ответственное лицо.

Это ЕГО головная боль.
Ладно, спасибо, попробую обсудить завтра с коллегами.
А в должностной инструкции админа написано, что ему разрешено ставить нелицензионный софт и нарушать законы?
Если следовать Вашей логике, то можно в должностной инструкции прописать разрешение убивать людей и тогда это станет только головной болью директора предприятия.
Это головная боль прежде всего того, кто это непосредственно делает.
Нет. В должностной инструкции быть не может качественных признаков объектов, над которыми специалист производит умело и сертифицировано. То есть «ставить и апдейтить» — может быть, а «ставить, апдейтить, но только если не варез» — нет. За этим делом отдельно внутренний аудит следит и закущики, должны подавать лицензию на софтину по заявке, вести учет их расхода. В общем, этот процесс выполняется другими службами.

Директор же должен организовать все процессы так, чтобы не придрались извне. Ну и фирма не сдохла.
Вот почему головная боль — директора, а не админа.
Да — есть риск, что конфискуют технику с нелицензионным софтом, есть риск, что будут неприятности с органами у админа (ведь это его руками нарушался закон). Конечно, все эти риски должен взять на себя директор. :)
Думаю тут проблема больше не в особенностях русского человека, а полном непонимании в на малых и средних предприятиях процессорного подхода, который заложен в западные стандарты и рекомендации ITIL.
Спросите руководителя любого не IT-предприятия до 200 чел. что такое бизнес процесс, кто такой владелец процесса? Сомневаюсь, что он вам скажет что-то определенное.
А внедрить ITSM на голом энтузиазме ИТ-отдела — гиблое дело.
Данный подход предполагает наличие:
1. первой линии поддержки
2. менеджера тикетов, который отслеживает нагрузку на специалистов, соблюдение SLA и т.п.
3. ИТ специалистов, которым достаются только задачи достойного их внимания.
Как правило, все хотят быть последними. Вопрос в том откуда взяться службе, которая будет обрабатывать и контролировать заявки? И насколько эта служба будет эффективна для предприятия такого масштаба?
Ответ прост — надо либо убедить директора предприятия так, чтобы он думал что он сам этого хочет, либо вырасти предприятию хотя бы до 500 человек, когда данное решение просто будет очевидным.
Сам не админ ни в ком разе. Но как я понял проблема в том, что знания полученные при сдачи ITIL/ITSM никому не нужны, кроме как HR. А если просто подойти к начальнику и попробовать объяснить выгоды, преимущества, сэкономленные деньги при внедрении. На месте руководства, я бы тоже не стал бы внедрять какую-нибудь систему, если не понимал зачем она вообще нужна.
Я тоже не админ. Но проблема глубже — стоит ли разбираться админу в этой теме, если она не заточена под склад его ума.
Интересно есть ли смысл внедрять ITIL в ограниченных рамках (управление инцидентами, проблемами, изменениями, конфигурациями) в небольших компаниях 100-200 сотрудников, штат ИТ 2-3 человека. Или это удел только крупных компаний?
В очень урезанном виде. Чтобы порядок был. Например, управление обращения и инцидентами, + управление конфигурациями совсем не помешают. И с бухгалтерией будете дружить.

Управление изменениями очень помогают получить уважение от бизнеса и грамотно планировать и защищать бюджеты.

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

Но есть одно большое но. В таких компаниях, насколько я понимаю, роли айтишников часто смешиваются.
Так вот — их придется разделить хоть сколько-нибудь четко.
В таких компания вводить SLA бессмысленно.
Оно будет регулярно нарушаться из-за малого количества персонала.
Это лишний камень на дороге будет.

А то о чем говорят выше вполне применимо.
Очевидно, что SLA должен быть составлен, так. чтобы он не нарушался ))

На устранение неисправности наименьшего приоритета в московской части филипс уходило до 12 дней. И все это знали, и это было прописано в СЛА
Можно конечно написать что все проблему устраняются в термин 365 дней, либо на них просто забивают, тогда SLA нарушатся не будет.
Не сравнивайте Филипс с небольшим предприятием работающим по стандартам СНГ.
Пока предприятие не зарабатывает на SLA деньги, этот документ будет оставаться формальным.
Нет, конечно, если сла никому не нужен — то не надо внедрять. А вот если чувствуете, что не хватает порядка и есть проблемы, которые не решаются месяцами, хотя на их решение нужно несколько часов — то может быть и стоит подумать над внедрением.
SLA тогда ни при чем. Это же документ, фиксирующий ответственность провайдера услуги перед ее потребителями. Внутренние проблемы решают OLA — operatoin level agreements. Чертятся процессы, оттуда вынимаются точки их соприкосновения и по ним пишутся регламенты, кто кому что должен и почему.
О чем говорить, если любые методологии, библиотеки, описывающие какую либо стандартизацию, правила игры, так называемое понятие «по хорошему надо так», ещё долго не смогут войти в наш обиход, ИТ бизнес и подобные сферы (Единицы компаний где «всё хорошо» не имею ввиду). Я даже не говорю о таких серьёзных вещах как ITIL или ITSM, я скажу даже проще, мною в свое время были произведены попытки внедрения хоть каких то методологий разработки ПО, или хотя бы их части, на разных местах разные, где-то пробовал RUP, где то пробовал MSF — ответы были, «А зачем?, А у нас gui дизайнер нарисовал, мы в общем-то знаем что каждая кнопка будет делать!, Делаем этот функционал, если что, по пути проблемы решим!» И никакой архитектуры, никакого UML, никакого плана, я уже не говорю о каких то графиках, диаграммах, всё на словах, даже ТЗ то бывало редко, и то больше смахивало на бриф. Все отметали хоть какие либо варианты, а всё потому, что: «Это долго схемы там рисовать всякие!»,«А у нас мало кто понимает этот ваш UML!», «Это же сколько людей умных иметь надо». Правильно, зачем нам умных людей уметь, это ведь дорого. А то что время сдачи проектов откладывалось на неизвестный период, из за какого-то «косяка, который мы думали не будет», это ничего страшного. Нам деньги пилить надо, да побыстрее, без заморочек, и требования уточнять не надо, а то мало ли что… Всё это внедрение чего либо, только на бумажке, чтоб звучало модно, и нолик в стоимость прибавляло…
В конце своего топика я написал, почему это все так:

Потому что нет крупного бизнеса. Потому что нет свободного рынка. Потому что всё большое у государства, а как там любят ИТ мы все знаем. Только опилки летят.


А так-то UML всем нужен, вон индусы фигачат. Плохенько, но зато по учебнику :)
Жаль только что индусы (((
Некоторые евреи типа меня этим тоже занимаются ))
Что вам только в плюс
Ну скажем так, что методики разработки тоже нужно под конкретные задачи выбирать. Где-то нужен RUP, а где-то (может в вашем случае это именно так), где в силу специфики проекта требования в ТЗ так просто не распишешь — применимы методики, подобные Scrum, где модель разработки скорее итеративная. Во втором случае достаточно иметь приличного менеджера проекта, который будет раздавать задания из очередного спринта, если все друг на друга переваливают то или иное задание. Тут особых навыков непосредственно от разработчиков не требуется.
Ну вот сразу прям и надоело быть честным админом? А может, он просто всего вышенаписанного со слов и текстов не понял, и хочет понять только на своей шкуре? Такое тоже часто бывает.
Ага, есть такой чудный фильм на эту тему. Назвается «Солдаты неудачи» в русском переводе. Можно за полтора часа увидеть всю его жизнь, если он и правда так решил, как вы сказали.
> Где каждый участник несет персональную ответственность.

И при этом огромная часть российских организаций сертифицированы чуть ли не по ISO 9001:2008. Метод получения, конечно, загадкой не является, но от этого становится лишь грустнее.

Хотя компания (офшор немецкой компании), в которой работаю я, вполне имеет право вешать такой сертификат на своих стенах, так как по крайней мере на первый взгляд нет описанного в топике бардака, присущего исконно российским компаниям.

Что касается «козла-консалтера» — так этим людям по должности сволочами быть положено. По тому как одна из наиболее весомых причин срыва внедрения новых технологий — человеческий фактор и толстые тётьки из бухгалтерии, которые никуда дальше двигаться не хотят. А зачем им? Они и так сидят и деньги получают, чай с крендельками пьют (ничего личного к бухгалтерам в целом, просто как пример).
Внедрение ITIL в части управления инцидентами приведет в первую очередь к росту недовольства пользователей, так как любой рядовой сотрудник считает себя единственным и неповторимым, а SLA к сожалению невозможно настроить на конкретную Машу Пупкину, если она рядовой бухгалтер, то её заявка будет обработана за обговоренные в SLA 4 часа в независимости от размера бюста.
А в этой стране никто не хочет быть винтиком в огромной машине, менталитет другой, или жизненная позиция. Все построено на «если бы не я», «да вы без меня», и подобных высказываниях, а всё это из-за 2-ух причин.(Опять же не беру единицы Идеальных компаний)
     1. Оплата труда.
У нас специалисты получают на порядки меньше забугорных аналогов, вот и приходиться какие то бонусы с начальства вытребовать, к примеру особое отношение, так как есть мысли «да за такие гроши я для компании слишком много чего делаю, а вот там за это платят...». Да и начальству в некоторой степени приходиться считаться, так как, кто же за такие гроши будет работать, а больше мы и дать не можем, хотя даже если есть бюджет, и деньги, и большие зарплаты сталкиваемся со 2 причиной.
    2. Недостаток квалифицированных кадров.
А на фоне этого недостатка кадров, у людей и увеличивается ЭГО до солнечных размеров. Что видите ли найдите такого же умного как я. Отсюда опять особое отношение. И начальству приходиться действительно мириться, так как кадров увы практически нет.(Сам провел сотни собеседований, в основном знаний нет, одни амбиции).
И как же мы тогда будем использовать методы основанные на стандартизации, если у нас все нестандартные?
P.S. Незаменимых людей не бывает, бывает мало времени на их поиски…
itil просто набор букв и свод правил стандартизации. не в itile дело, дело в кадрах, если у вас нормальные вменяемые работники и прописанные регламенты (кто, что, когда делает) + плюс к этому нормальный начальник и в коллективе нормальные взаимоотношение (а не «не я это делать не буду иди к васе хоть у него и запара но это его работа»), о все эти itilы идут лесом. На западе культура производства совсем на другом уровне как автор описал, там уже перешли к стратегическому планированию на уровне сейчас вложим 10 млн через год получим отдачу в прибыль в 0.5%.
Когда есть сплоченная командная работа ITIL и не нужен.
Ок. На днях покажу, что это не так. Ждите обновлений в публикациях.
Я работаю инженером в одной корпорации (Москва). Вся работа построена через SD, руководство стремится к организации работы по ITIL. Вот только один отдел компании никак не может научиться работать через SD — администраторы. Плевательское отношение к заявкам, срокам, комментариям.
На последнем собрании руководитель группы администраторов обратился с просьбой предоставить что-то вроде презентации-пособия по работе с SD. Мне же на освоение HP SD потребовался день.
И тут дело даже не в сервисдеске, не в ITIL, а в отсутствии коллективности.
Вам помочь с презентацией?

Уже и проблема озвучена, а вы все про коллективность…

Админ учится быстрее среднестатистического юзера раза в три. Если ему интересно.
Сделать интересно — не проблема.
Спасибо за минус, вы очень милы)
Мне презентация не нужна, да и админам нашим я не желаю работать по ITIL.
Оценка качества нашей работы производится по положению в SD. Месяц назад я решил поднять это самое качество, педантично заполняя каждую форму. 40 процентов моего времени теперь уходит на писанину.
Не люблю бюрократию, поэтому в этой компании задержусь не на долго, если что то не изменится к лучшему.
Ларс Расмуссен о работе в Google: «Недавно меня попросили обосновать свою точку зрения по поводу того, какой ширины должна быть рамка: 3, 4 или 5 точек. Я не могу работать в такой среде».
Это минус не от меня, я никогда не ставлю отрицательных оценок.

А про временную волокиту – просто архитектор процесса не умеет его готовить. У меня админы закрывают наряды за 10 секунд, еще минуту тратят на пометку галочками нужных изменений и всё. Остальное достается аналитикой из систем при необходимости.
Во-вторых: когда его инфраструктура становится частью сервиса, нужно огромное влияние уделять не изучению интересных новинок или шлифовке мастерства ваяния конфигов, а доступности, непрерывности и производительности. Иными словами, следить за состоянием устройств, проводить рутинные техосмотры, планировать простои и ремонты. В общем, тухляк сплошной. Скукота. Рутина. Буэ.

А у кого-то есть иллюзии насчет работы системным администратором? Мол, это так весело: летать по трехмерным лабиринтам за «хакирами», как это в фильмах показывают? Вообще дико слышать, что админам, оказывается, похер на непрерывную доступность и производительность. А для чего же он еще нужен тогда?
Добро пожаловать в Real ITSM :) недавно прочитал эту книгу, очень созвучна статье.
Сертификаты нужны для ускорения процедуры вашего приема на работу.

Я, например, пробовался на должность в одну контору, предварительно связался с уже работающим там парнишкой. Он мне рассказал, что при приеме нужно будет пройти три психологических теста, тест на IQ и пару тестов по специальности, что в общей сложности занимает до 2-3 часов времени.

Терять столько времени никак не хотелось, поэтому я попросил его выудить формы психотестов из шары кадровички и заранее их просмотрел на предмет подводных камней, значение IQ вписал в резюме и присовокупил к нему тройку быстрых сертификатов из интернета. В итоге процесс моего общения с рекрутером занял 25 минут и увенчался приглашением, но работать к ним я не пошел :)
Прикольно, а пять лет назад тут вообще бы не было комментов :-)
Просто ITIL изначально начали продавать монстрам ГазМяса, а реальному рынку услуг даже сегодня он вдиковинку. Но уже не так, как пять лет назад, ага.
Так как в Песочнице появился товарищ, задающий вопросы по теме настоящей публикации, считаю своим долгом ответить.

Сначала общее: коллега, когда я учился этой штуке, я тоже был полон надежд и уверенностей. Сейчас я пишу об опыте, а не о теории. Это знание в разы важнее.

Потом совет-какашка:
в данный момент оканчиваю прохождение курса по SO


Ваш курс называется Service Offerings and Agreements. К сожалению, Offer'ы это очень малая часть этого курса и самая вкуснотища для архитектора именно в Agreement'ах. Обратите внимание на последнюю «А» и гарантирую — цена Вашей головы удвоится, если сумеете владеть этим кун-фу в достаточной мере.

Потом по сути ответа (лишее вырезано мной, полная версия — выше по ссылке):
одно из самых важных утверждений во всех практиках: каждый сотрудник вовлеченный в процесс должен полностью осознавать его необходимость, быть заинтересованным в его успешном внедрении и стабильном развитии. Посмотрев на то, что было написано в посте и в большинстве комментариях… свидетельствуют о том что авторы комментариев весьма плохо представляет себе что же такое «набор практик ITIL» и зачем он вообще нужен.


Конечно, читатели — не специалисты. Писал бы я для коллег, они и так в курсе :)
Проблема, как Вы потом несомненно убедитесь, не в том, что айтишники не заинтересованы или замотивированы, а в том, что для внедрения ITIL требуется поддержка не только айтишников, а вот с этим глухо практически везде, где нет иностранного владельца.

Далее конструктивных вопросов в посте я не увидел, скипаю.

Уважаемый автор — похоже на то что Вы можете предложить более эффективный метод построения IT-инфраструктуры а так же ее поддержания и предоставления сервисов. Может вам стоит написать собственную библиотеку?


Смысл в едином языке для общения, в общей шине передачи данных и стандартах связи. Все водители знают, в чем неправ гаишник, но ПДД — едины для всех вне зависимости от мнения участников. ITIL = ПДД, но с оговоркой, что это не правила, а советы.

Зачем писать новое, если про существующее почти никто не слышал? ;)
Вы не правы.
SO — Service Operations. Совсем другой курс.
Признаюсь, поторопился.
Я поленился проверить, проводятся ли в России курсы по теоретической ветке ITIL 3, последний раз (месяца три назад) были только курсы из ветки «практиков». Ближайшее место обучения — Голландия. Соответственно, засомневавшись и не подумав, что можно, например, учиться удаленно на теоретика (где курсы идентичны книгам ITIL v3), и начал выделываться.

Сдаюсь :)

P.S. Автор топика из песочницы просит вытащить его (топик) на Хабр. Я не умею (или не вижу как). Если читателям интересно увидеть нашу битву тут — помогите автору.
несколько ближе чем в Голландии есть курсы в Киеве: nt.ua/courses/itil/index.shtml
Смотря какой автор. Автор топика — да — он собственно про него и написал. Автор топика в Песочнице — именно Service Operation.
Тема ITSM, которую вы затронули, мне очень близка по роду занятий.
Именно ИТ аутсорсинг в первую очередь должен быть заинтересован в оказании услуг согласно ITIL, ибо 95% аутсорсеров для малого и среднего бизнеса исповедуют «ремонтный подход», то есть тот, при котором побежали туда где поломалось, однако этот подход приводит к совершенно немасштабируемому ИТ бизнесу. И этому действительно есть очевидные объяснения. Так как именно спрос рождает предложение, в данном случае это бизнес, который заказывает услуги у аутсорсера и не требует/не готов/не понимает как понять/посчитать качество получаемой услуги, то и соответствующего предложения от аутсорсера не будет.

А теперь о практике. Среднестатистический клиент не привык мыслить в терминах «получаемых услуг и SLA», пока что клиент понимает только «у меня 15 компьютеров и 3 сервера, сколько это будет стоить?». На переговорах бывает очень нелегко донести саму мысль об ITSM, получаемых услугах и стандартах качества руководителю предприятия.

К счастью, мыслящие руководители/директора явление нередкое. К слову, очень люблю переговоры с различными директорами/учредителями, как правило это люди умные и интересные.

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

Публикации