ITIL для разработчиков



    “… british scientists proved…”


    Привет, Хабр. Меня зовут Сергей Сапегин, я работаю PHP-разработчиком в DataArt. Но сегодня я хочу поговорить не о PHP.

    Работники IТ, вне зависимости от области специализации, в последнее время все чаще сталкиваются с интересным феноменом мира ПО — ITIL. Поскольку общемировая тенденция не миновала и DataArt, мы предприняли небольшое исследование, дабы понять, что и как следует знать нашим разработчикам, чтобы некоторые процессы заказчиков не ставили в тупик всю команду. Представляем вам, что из этого получилось…

    Куда девается софт?

    Производя разнообразные фичи и исправляя многочисленные баги, доводя разрабатываемые компоненты до уровня релиза мы, как правило, не задумываемся, куда это все потом девается. Фактически, софт для нас — нечто, лежащее на операционном рабочем столе, то, что надо препарировать, доделать, переделать, вылечить и заставить работать.

    Большинство методик и приемов, направленных на достижение качества ПО, вытекают из этого взгляда на мир. Безусловно, стройная архитектура, объектный подход, MVC, соглашения об оформлении кода и комментарии… Мы так много уделяем этому внимания, что совершенно непонятно, откуда вылезают очередные уродливые чудовища, которые так дороги пользователям, что обязательно надо привести их в порядок. Красота должна была давно уже править миром.

    И, говоря откровенно, она правит. В мире существуют миллионы разновидностей прекрасного, очаровательного, вдохновляющего ПО! Другое дело, что мы, разработчики, оцениваем красоту программных изделий по большей части со своей профессиональной точки зрения, примерно также, как паталогоанатом хирург может оценивать красоту людей, исходя из состояния их внутренних органов. В то время, как весь остальной мир рукоплещет фигуристым блондинкам с подиумов.

    Как же нам прикоснуться к этому непростому взгляду всего мира? Мир уже нашел способ привести красоту IT к стандарту — он предлагает нам ITIL!

    Идея британской короны

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

    Собралась группа экспертов (предварительно пообещав всем раздачу розовых слонов), тщательно обработала статистику — и возникла библиотека ITIL. Сейчас она становится все популярнее, пережила уже третью инкарнацию (самая свежая и популярная версия — ITIL V3), а самое главное — она, по сути, объясняет, что пользователю нужно, как ему организовать эксплуатацию всей его IT-инфраструктуры, как оценить, что приносит пользу, что вредно, а что бесполезно. Самое пикантное, что оценка работает вне зависимости от того, действительно ли пользователь знает свои реальные желания, может или нет их сформулировать. Если он, конечно, вообще заинтересован в использовании IT в своем бизнесе.

    Основа ITIL

    Первое, с чего начинается знакомство с ITIL, — общие понятия и термины, которые могут весьма отличаться от ожиданий. Сама ITIL — библиотека (сборник) рецептов, применимых для организации процесса эксплуатации IT. Способ управления организацией IT-услуг на основе рецептов этой библиотеки называется ITSM (IT Service Management). Библиотека 3-й версии (ITIL v3) состоит из нескольких основополагающих книг, освещающих последовательно вопросы организации различных сфер работы с IT-инфраструктурой предприятия.

    Ключевое понятие ITIL, на базе которого разворачивается вся остальная идеология, — понятие сервиса. В ITIL v3 сервисом называется «способ предоставления заказчику ценностей (values), очищенных от рисков и затрат, присущих действиям, по получению этих результатов» (A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks). Обратите внимание, что под ценностями в контексте работы организации, как правило, подразумевается достижение работником каких-либо промежуточных целей в процессе выполнения своих профессиональных обязанностей. Это определение достаточно сильно отличается от того интуитивного понятия «сервиса», которое присуще разработчикам. (Имеется в виду «развернутый в сети набор функциональности, который можно использовать»).

    Сервис ITIL — это:
    1. Не только и не обязательно набор программной функциональности. Грубо говоря, мы постоянно считаем новую модель ружья способом охоты. Хотя на деле, чтобы оно было способом, его надо распаковать, пристрелять, зарядить, доставить на место, направить на цель и дать в руки охотнику. Все это, с точки зрения ITIL, — составные части сервиса.
    2. Способ предоставления заказчику ценностей. Разработанный софт используется пользователем не потому, что его легко и удобно использовать, он имеет тщательно продуманную архитектуру и т. д., а потому, что он доставляет пользователю ценности, причем набор этих ценностей ограничен рамками производственного процесса, категориями которого и мыслит пользователь. Проверьте себя, ответьте, какой алгоритм сортировки лучше — традиционный «пузырек» или Quicksort? А если речь идет не более чем о десяти элементах? А если он нужен вообще чтобы объяснить человеку принцип сортировки?
    3. «…очищенных от рисков и затрат» — тоже важное дополнение. Всю производительность разработчиков, которую так трудно определить и нормировать с точки зрения процесса разработки, пользователь оценивает со своей точки зрения по одной простой и безотказной шкале — очищенности своего рабочего процесса от рисков и трудозатрат. Давно ли вы сами писали гневные сообщения на форумах об отсутствии кнопки «Пуск» в новой версии Windows? Задумывались ли тогда о несомненных улучшениях в функциональности и надежности этой ОС? Часто ли вы входите в положение сервисных служб, когда у вас падает интернет или отключают электричество?

    Получается, как у поэта: мы говорим «ITIL» — подразумеваем «сервисы», говорим «сервисы» — подразумеваем «доставленные ценности, очищенные от рисков и затрат».

    Структура и место ITIL

    В качестве иллюстрации той области, которую охватывают методики ITIL (а конкретнее — ITIL 3), можно посмотреть на следующую картинку:



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

    Структура ITIL в 3-й редакции состоит из пяти основополагающих книг и выглядит таким образом:



    Рассмотрим их содержание подробнее…

    Service Design

    Книга, посвященная проектированию сервисов, детализирует принципы, которые должны использоваться при грамотном развитии IТ-инфраструктуры. В процессе проектирования сервисов, помимо всего прочего, определяется потребность в новом ПО, определяется набор первоначальных требований к нему, выбирается исполнитель — и тут уже в дело вступают разработчики. Выбор исполнителя и характер проекта обычно определяется путем нахождения баланса между:

    1. функциональностью сервиса (бизнес- и системной);
    2. его стоимостью (включая финансовые, производственные и кадровые ресурсы);
    3. временем, за которое надо запустить сервис в эксплуатацию.


    Кроме требований к ПО, при проектировании сервиса обычно прорабатываются вопросы запуска его в эксплуатацию, дальнейшего управления и т. д. Сам процесс проектирования обычно организуется на основе матрицы RACI (Responsible, Accountable, Consulted, Informed), согласно методу которой, участие каждого участника в задаче может быть следующих типов:

    • Responsible – участник может участвовать в работе над задачей.
    • Accountable — ответственный за задачу (только один на каждую).
    • Consulted — участвует в работе в качестве консультанта.
    • Informed — должен следить за ходом работ и получать информацию о прогрессе.


    В более специфичных случаях используют расширенную матрицу RACI-VS, в которой добавляются следующие роли:

    • Verifies — человек или группа людей, проверяющих соответствие результатов работы заданным критериям.
    • Signs off — человек, фиксирующий достижение цели и принимающий решение о выпуске продукта (роль совместима с ролью A).


    Существует еще одна вариация этой матрицы, т. н. RASCI, в которой предусмотрено наличие роли Supportive — для людей, обеспечивающих поддержку основного потока работ.

    Service Transition

    Собственно говоря, обычно мы достаточно мало знаем об ITIL еще и потому, что библиотека никак не формализует сам процесс разработки. Для нас он предстает в виде Agile, водопада или еще чего похитрее, а с точки зрения пользователей это — черный ящик, куда кладутся требования, что-то там внутри шуршит и работает – и на выходе выезжает конфетка готовое ПО. Однако, тому, что дальше делать с выехавшим из черного ящика ПО, посвящена очередная книга — «Передача сервисов».

    Основная цель процесса передачи сервисов — развертывание и введение в эксплуатацию новых версий сервисов в общей информационной среде предприятия. Основа процесса — обычно формальное соглашение, составленное в документальном виде и используемое во всех случаях ввода сервиса в эксплуатацию. Важность этого связана, прежде всего, с тем, что процесс некорретного ввода сервиса в эксплуатацию может принести серьезные убытки эксплуатирующему его предприятию. Почему я подчеркиваю этот факт? Для нас обычно ценна именно функциональность ПО, то, что мы делаем: алгоритмы, структуры таблиц БД. А для пользователя наибольшую ценность представляют ДАННЫЕ. В руках у пользователя структуры данных заполняются не абстрактными “123”, “test”, “privet”, “helloworld”, “test again”, а вполне конкретными фактами из реальной жизни, имеющими значение (выражаемое в деньгах!) для деятельности компании. А поскольку, как я уже говорил выше, софт всегда приходит на смену чему-либо, проблемам адаптации старых данных под новые модели следует уделять самое пристальное внимание. По возможности – с самого начала разработки, а не когда уже сделали готовое изделие.

    Когда разработанное ПО запускается в эксплуатацию, интересы пользователя уязвимы больше всего: он доверяет вашему продукту самое ценное, что у него есть – ИНФОРМАЦИЮ.

    Передача ПО в эксплуатацию обычно сопряжена с несколькими этапами тестирования, часто связана с использованием каких-либо технических средств, регламентирующих процесс (CI – continuous Integration), а результат ее… тут де-факто есть небольшое расхождение результатов.

    Для разработчика конечные результаты — подписанный акт о передаче и финальный платеж.

    Для заказчика конечный результат — факт использования программного средства по назначению. Совместное достижение этих результатов и есть желаемый итог проекта. Многие сейчас подумали о вариантах, когда «разработчик сдал программу и исчез, а пользователь с ней мучается и не может толком работать» — справедливости ради, есть и другие варианты, когда «пользователь поставил старую версию и работает, а всякие левые баги не замечает, от новых фич отказывается». Оптимум — где-то посередине.

    Главная задача организации процесса передачи сервисов — избежание затяжных антагонистических конфликтов между командами, причины которых — непонимание и, скорее всего, различные корпоративные интересы. Для предотвращения и решения конфликтов используются и формальные документы (SLA, ТЗ и т.д.), и неформальные инициативы, направленные на устранение непонимания и расширение общего понятийного контекста между группами разработки и эксплуатации сервисов.

    Service Operation

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

    Continual Service Improvement

    Последняя книжка ITIL 3-й версии посвящена организации саморефлексии — отслеживания, какие процессы идут в организации, попыток улучшения качества используемых сервисов. Самый главный постулат книги — процесс усовершенствования корпоративной ИС должен проходить постоянно и непрерывно. Ну, а методики, используемые для этого, могут быть чрезвычайно разнообразны.
    Например, широко используются различные способы измерения технической производительности IТ-сервисов, эффективности их работы во взаимодействии с пользователем, способы общей оценки работы сервисов, фазы их жизненного цикла и т. д. (цикл Деминга и матрица SWOT).
    Знание принципов CSI позволяет анализировать, что происходит в IТ-инфраструктуре наших клиентов, подсказывать им решения, завоевывать доверие и делать предложения, от которых трудно отказаться. Естественно, если организация-заказчик регулярно делится данными постоянного мониторинга своей IТ-инфраструктуры.

    В итоге?

    Все это, конечно, занятно (хотя и несколько умозрительно), но зачем разработчику-практику знать об этих низменных, юзерских концепциях? Наше дело — заботиться о качестве кода!

    Может быть, оно так и должно быть, но практика показывает иное. Большинство холиваров о «прямых руках» и «кривых архитектурах» пользователю безразличны. Более того, между пользователями и разработчиками, оказывается, существует действительно большое пространство, успешно пересечь которое под силу не каждому программному продукту. И, как мне кажется, пора задуматься, как дать своему программному детищу больше шансов стать полезным для конечного пользователя. А помочь в этом может взгляд на разработку с позиции ITIL.
    DataArt
    175,00
    Технологический консалтинг и разработка ПО
    Поделиться публикацией

    Похожие публикации

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

      +2
      Простите, а Вы уже ведете разработку по этим книжкам или пока только послушали великолепные курсы? Просто в организации техподдержки (на что эти рекомендации изначально и были направлены) слово «айтил» обычно встречается в составе выражения «на### айтил!». В чистом виде это отличный способ парализовать работу предприятия в стиле итальянской забастовки. Может использоваться, когда с процессами полнейший швах и никто на предприятии не знает, что делать и куда бежать.
        +1
        Ровно так-же можно сказать:
        Version Control? — на### version control!
        Continuos Integration? — на### continuos integration!
        Continuos Delivery? на### continuos delivery

        не говоря уже о более простых «на### объекты», или «на### функциональщину», «на### реляционные базы данных», «на### всякий noSQL» и так далее.

        Организация тех.поддержки, как замечено в статье — это ITSM.

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

        Если же у кого «процессы известны, все бегают в правильную сторону и результат устраивает», то конечно чего дергаться-то?
          0
          >О каком «в чистом виде» идет речь, если это по сути «сборник рецептов»?
          Открываем книгу, видим «для внесения изменений их должен утвердить консультационный комитет, который собирается раз в месяц». Говорим, что 10 начальников будут теперь CAB`ом, собираться они будут 4го числа и утверждать список изменений. Работы можно проводить только после утверждения.
          Это не утрированный пример из головы, это реальный пример. Что интересно — в применение к одной системе на предприятии оно работает отлично, в применении к другой ломает работу полностью.
          >Если же у кого «процессы известны, все бегают в правильную сторону и результат устраивает», то конечно чего дергаться-то?
          Потому что «у нас не по айтилу!!!!1111одинодин Надо переделывать!!!!111одинодин». Приходилось слышать на совещаниях предложения сломать рабочую схему и сделать «как в книжке» или как «нам на курсах говорили». Оно бы привело к увеличению времени решения инцидента часов на 10.
            0
            Для продолжения рассмотрения примера, нужно больше деталей. Интересно, например, как определяется «консультационный комитет» — сколько человек туда должны входить, какие у них роли. Что значит «собирается» — обязательно встречаться лично или устроит скайп, e-mail, еще как-то?

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

            сюрприз: какие из пожеланий заказчиков и в каком виде войдут в следующую версию, решают (по сути) эти трое.
            Они собираются, или «примитивно» в e-mail, или «продвинуто», в task-трекере, и решают, или «срочно» — по телефону.
            Раз в месяц — это бы мы умерли давно, реже чем раз в неделю физически не получается, иногда по несколько раз в день приходится «собираться» — заказчиков много, все разные, хотят порой кардинально противоположных вещей.

            Истерики «у нас не по ZZZZ» — я воспринимаю нормально. Мой личный опыт показывает, что люди кричащие «у нас не по ZZZZ, нужно переделать», скорее всего не понимают ту самую фразу про «добавление ценности».
            Разве что за исключением реплик «горизонт завален» — это чаще таки говорят по приколу :)))

            Вот со слов «оно бы привело к увеличению времени решения» можно дальше развить. И, взять да применить ITIL ко внедрению ITIL'я, элементарно проверить добавляет ли его внедрение ценность? Снижает риски? И так далее.
              0
              >Приведу наш реальный пример (у нас ни разу не ITIL, кстати):

              Вот! На чём я настаиваю — так это на том, что нельзя брать ITIL как религиозную догму. Можно брать какие-то идеи и адаптировать их к имеющейся реальности. Вы так и сделали, как я понимаю.

              >Истерики «у нас не по ZZZZ» — я воспринимаю нормально.

              Да я уже тоже нормально. Просто объясняю, почему в данной ситуации ITIL «на### идет».

              >Мой личный опыт показывает, что люди кричащие «у нас не по ZZZZ, нужно переделать», скорее всего не понимают ту самую фразу про «добавление ценности»

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

                «Сказать что-то умное» тоже бывает, да. Но потом ведь всё равно разбираться, и обосновывать ценность.
        0
        Работать по ITIL можно, но она часто упирается в бюрократию. А Бюрократия очень изменчива.
          0
          у вас спрошу иначе:

          1. Source Version Control — это бюрократия? Это же как же можно заставлять программиста, регулярно фиксировать результат своего труда, сопровождая комментарием? От этой бюрократии программа лучше не становится.
          2. task tracking — это бюрократия? Это же как же можно, заставлять писать задачи, работать по задачам, при коммите ставить ссылку на задачу? От этой бюрократии тоже программа ну улучшается.

            0
            1. Осознанная необходимость. Если еще не осознана — то либо везунчик, либо пофигист.
            2. Аналогично п.1, как я полагаю.
              0
              Ну так и лучшие практики из ITIL — тоже осознанная (теми, кто их применял) необходимость. А если ещё не осознана — то либо везунчик, либо «IT-ники ни хрена не делают, гнать их всех в шею» :)
                0
                Эти «лучшие практики» надо допиливать напильником под обстоятельства. Проблема в том, что часто их пытаются копировать вслепую. Это уже 4й комментарий в этой теме, где я пишу одно и то же :(
              0
              Регулярно записывать для отчёта для меня и есть бюрократия. По сути врач записывающий карты пациента на отлично лучше лечить не станет. И не понимаю зачем мне этот вопрос.
                0
                Врач, читающий карты пациента, станет лечить лучше. Узнает, что у него аллергия на одну групп антибиотиков и что другой группой его уже кормили месяц назад.
                  0
                  если врач не будет регулярно вести историю болезни, пациента мало кто эффективно вылечить сможет. елси мы, конечно, не говорим о простуде, которая или за неделю сама проходит, или за семь дней её можно вылечить.

                  Вопрос к вам потому, что слово «бюрократия» обросло очень разными смыслами.

                  Заметьте, я ни разу не сказал «для отчета». Комментарии при коммите нужны
                  — коллеге, который делает Code Review
                  — руководителю (team lead), который следит за ходом решения задачи
                  — PM'у, который следит за развитием проекта в целом, если вдруг какая-то задача по срокам начинает пролетать.
                  — разработчику, который через пару лет в этом коде будет править ошибку

                  Я слабо представляю, кому в современном мире нужно что-то «для отчета», как и отчеты сами по себе.
                    0
                    >Я слабо представляю, кому в современном мире нужно что-то «для отчета», как и отчеты сами по себе.

                    Вас познакомить?
                    У меня в служебный обязанности входила подготовка отчета. Раз в неделю. В силу ряда причин на это уходило полдня. И у нас была возможность проверить, открывал ли кто-нибудь файл с отчетом. За полгода — никто. За вопрос «а может, ну его?» получили ответ «это очень нужный отчет!!!!». Чуть не бизнес без него встанет.

                    С другим еженедельным отчетом (тоже очень важном) бывали косяки. Каждую неделю новый отчет с одними и теми же данными — свежие не поступали. Получатель отчета заметил это через 2 месяца. Даже не бизнес-получатель, а «промежуточное звено» в длинной цепи передачи отчета.
                      0
                      спасибо, специально знакомить не нужно :)

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

                      Момент «фиксации информации», должен быть частью процесса, должен «естественно проистекать» из самого процесса, и самое главное (и сложное) — человеку должно быть понятно с какой целью его заставляют «заниматься фигнёй».
                      0
                      Мой первый комментарий:
                      Работать по ITIL можно, но она часто упирается в бюрократию. А Бюрократия очень изменчива.

                      Вот это и имелось ввиду. К примеру у меня сломался принтер. Исправил, записал. Ещё раз, исправил, записал. Написал что ресурс изношен. Заключение. Техника на списание. Руководство говорит принтер списать, но нового не будет. Смысл записей? Если принтер изначально было известно что выработал ресурс.

                      Врач, пишет одну карту для больницы, потом карту для страховой, потом для статистов края\области. Данный процесс не вписан в рабочий график, в результате на него просто нет времени. Падает качество заполнения? При этом почему бы нельзя сделать всё в одной базе. Кстати карта из одной больницы в другую отправляется по запросу, и того может быть потеряна.

                      Задумка хорошая, реализация хромает.

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

                        Если зафиксировали два раза поломку принтера, и записали что ресурс закончился — отлично. На этом этапе (в этой части) работы выполнены правильно и хорошо. А то, что нового не будет — это проблема уже дальше по цепочке управления.
                        Сравнивать эту ситуацию нужно не с «пофиг, пиши не пиши — как работает полу-мертвый принтер пока не развалится так и будет», а с ситуацией, когда есть деньги на новый принтер, а люди мучаются с развалюхой, носят его в ремонт, теряя время, нервы и так далее. Просто потому, что никто не записал, что принтер давно пора менять.

                        Про врачей, так получилось, я знаю чуть больше. И там, куда приходим мы, врачи работу два раза не делают. А многие «записи» вообще сразу получаются, автоматически. Именно потому, что реально можно всё сделать «в одной базе», и так далее.

                        И вопрос с автоматизацией в медицине, как и с внедрением ITIL — в целях руководства. Если нужно, что бы врачи занимались лечением — ищут способы, как снять с них не профильную рутину. Если нужно тупо бумажки заполнять — заставляют заполнять бумажки.
                          0
                          вот вы сами говорите, что проблема не в требованиях записывать, а в том, что происходит дальше, и как эти требований встроены в процесс.

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

                          Про врачей всё зависит от региона, и это у вас может полуавтоматически у меня в глубинке всё по старинке. И вот так получилось, что я отработал в медицине с информационными системами и знаю как работает. Но движется, надеюсь со временем всё наладится.
                +2
                  0
                  В ITIL одних ролей 26 штук, это больше чем людей в некоторых организациях =)
                  Всякие change manager, risk manager, facility manager, security manager, deployment manager, service desk manager, finance manager, incident manager, relationships manager, их там целая толпа.
                  Хотя может быть для организаций уровня газпрома можно просто взять и внедрить.
                    0
                    ITIL часто используют аутсорсинговые компании.
                      +2
                      В организациях уровня Газпрома никогда и ничего нельзя
                      просто взять и внедрить
                      !!!
                      Что касается ITIL/ITSM — подход к внедрению этих практик всегда определяется исходя из специфики конкретной организации. Нельзя просто взять и внедрить все рекомендации ITIL и сделать все по Cobit. Всегда должна быть взаимная адаптация рекомендаций (ITIL) или стандартов (Cobit) и текущей деятельности компании.
                        0
                        Роли могут сочетаться, но сути это не меняет, — ITIL это методология прогона умняка при собеседовании на должность CIO.
                        +2
                        Звучит как реклама новой модной религии.
                          +1
                          Да если б новой.
                          0
                          Если «сервисы» заменить на «услуги», а «доставляет ценности» — на «приносит пользу», то становится намного понятнее, имхо.
                          И на картинке книг пять, а написали вы про четыре, забыв про самую главную — Service Strategy.
                            +1
                            В статье рассказано какой классный ITIL и что он умеет, но не написано ничего о том что это такое. Да же определния нет, расшифровки абревиатуры, краткой аннотации. Одна вода какая то, извините. Я толком ничего не понял что это и зачем.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое