Портал №1 по управлению цифровыми
и информационными технологиями

Качество ИТ-сервисов. При чем тут процессы?

Тема для обсуждения предложена читателем нашего портала. (См. раздел "Задать вопрос").

"Как с помощью ITSM-процессов улучшить качество ИТ-услуг? Есть несколько процессов. Все эти процессы, конечно, косвенно влияют на качество сервисов, инциденты решаются своевременно, проблемы не остаются без внимания, изменения не приводят к новым инцидентам. Однако, если взглянуть на статистику, то оказывается, что количество инцидентов не только не уменьшается, но даже потихоньку растет, соответственно можно сказать, что качество сервисов по основному показателю ухудшается. Корень проблемы видится в том, что имеющиеся метрики и построенная на них система мотивации нацелены исключительно на качество работы процессов (своевременная и упорядоченная обработка инцидентов, проблем и т.п.). В итоге получился скорее менеджмент ITIL-процессов, а не сервисов, так как за сами сервисы никто как бы и не отвечает."

Давайте разберемся по порядку. Начнем с того, что есть качество. Обычно под "качеством" мы понимаем степень соответствия определенным стандартам или договоренностям. Например, продукт питания качественный, если он вкусно пахнет, сделан из понятных ингредиентов и не сокращает продолжительность жизни.

С ИТ-сервисами примерно такая же история. Говорить о снижении качества ИТ-сервиса мы сможем после того как определим показатели, по которым мы этот сервис оцениваем, и зафиксируем ожидания от значений этих показателей. Например, по ИТ-сервису "Электронная почта" важен показатель доступность. Определим его целевое значение как 95%. Тогда сможем говорить, что в декабре доступность была 98%, а в ноябре 80%, значит в декабре ИТ-сервис был качественным, а в ноябре нет. Естественно возникает вопрос, откуда мы возьмем перечень показателей и их целевые значения. Ответ в разных ситуациях может быть разным, например, это может быть процесс SLM или некая деятельность на него похожая. В идеале, показатели и их целевые значения должны исходить от потребителей.

Поэтому в отношении такого показателя как "количество инцидентов" возникает вопрос, интересен ли он потребителям? Скорее всего нет, ведь 2 крупных инцидента за месяц могут остановить работу ИТ-сервиса на более продолжительное время, чем 10 мелких. К тому же рост числа инцидентов может быть продиктован объективными причинами, которые не связаны с качеством ИТ-сервиса. Например, выросло число пользователей, многие из которых видят ИТ-систему впервые, или вышло обновление ИТ-системы и пользователям стали доступны новые функции. 

Теперь давайте разберемся с тем, чем нам могут помочь ITSM процессы. Исходя из сказанного выше, разматывать клубок качества ИТ-сервисов удобно от требований заказчиков (потребителей) ИТ-сервисов. Т.е.

  1. Поняли какие ИТ-сервисы мы предоставляем (например, "Электронная почтв").
  2. Поняли какие параметры ИТ-сервисов важны заказчикам (например, "Доступность").
  3. Поняли как на эти параметры можно повлиять (например, обработка обращений пользователей, контроль компонент инфраструктуры, аккуратное изменение инфраструктуры и т.д.).
  4. Поняли как организовать свою деятельность (например, в виде процессов управления инцидентам, событиями, изменениями) так, чтобы она решала задачи п.3. Деятельность можно выдумывать самостоятельно, а можно обратиться к ITIL, ISO и т.п.

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

Поэтому в идеальной картинке наряду с деятельностью по оперативной работе с ИТ-сервисами и компонентами инфраструктуры, должна быть еще деятельность (менее оперативная) по выявлению изменений в требованиях, выяснению причин нарушения договоренностей, разработке предложений по совершенствованию ИТ-сервисов и процессов, обеспечивающих их работу, поддержку и т.д. Иными словами в списке из 4х пунктов должен появиться 5й: "Контроль качества ИТ-сервисов и формирование предложений по совершенствованию ИТ-сервисов и процессов." тогда вы получите уже не только "менеджмент процессов", но и "менеджмент ИТ-сервисов".

А вы что думаете?

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

Комментариев: 27

  • old fuddy-duddy

    В таких ситуациях, как описана в вопросе, обычно говорят: «вот внедрите SLM и тогда…». А что тогда? Процессы группы SLM у нас обычно внедряют в последнюю очередь, но ведь к первоначальному решению о внедрении СУИС приходят уже с определенным набором целей. И одна из главных целей обычно повышение стабильности работы ИТ, то есть, например, уменьшение количества инцидентов и времени простоев. При этом существующий уровень качества работы ИТ априори следует считать неудовлетворительным.
    Я считаю, что процессы ITIL всего лишь инструменты необходимые для достижения требуемого качества ИТ-сервисов. Но кто должен этими инструментами пользоваться? На практике вместо СУИС зачастую получается набор айтиловских процессов, к тому же совершенно не связанных между собой, где есть роли, отвечающие за работу процесса, но нет людей отвечающих за решение основных целей СУИС, а значит, нет и взаимодействия процессов, нет системы. Думаю, тему данной статьи можно конкретизировать: «кто и как должен отвечать за качество ИТ-сервисов?».

  • “Думаю, тему данной статьи можно конкретизировать: «кто и как должен отвечать за качество ИТ-сервисов?»”

    Уберите “ИТ-сервисы”. Спросите себя: “Кто и как должен отвечать за ИТ?”. ИТ-директор. Как? По-возможности не личным героизмом, а системно. Что для этого нужно: зафиксировать требования к ИТ, организовать их выполнение, управлять рисками, контролировать результат. Для фиксации требований могут использоваться ИТ-сервисы. Для остального – процессы управления деятельностью по предоставлению и поддержке ИТ-сервисов.

    Метрики по процессам, а не по сервисам, говорят о том, что вашей ИТ-организации пока актуальнее управлять своей внутренней работой. Потому что спрашивают с вас не по цифрам, а по понятиям. Для того, чтобы это изменить нужен не SLM, нужно чтобы были со стороны бизнеса люди, которые готовы спрашивать по-другому. SLM может лишь помочь обеспечить ответ на поставленный вопрос. Вопрос поставлен?

  • old fuddy-duddy

    «Метрики по процессам, а не по сервисам, говорят о том, что вашей ИТ-организации пока актуальнее управлять своей внутренней работой.»
    Это верно, однако хотелось бы двигаться дальше.
    «Потому что спрашивают с вас не по цифрам, а по понятиям. Для того чтобы это изменить нужен не SLM, нужно чтобы были со стороны бизнеса люди, которые готовы спрашивать по-другому.»
    Думаю, что бизнес как раз созрел, но что ему предъявить? – Наведение порядка в ИТ-службе и улучшение удовлетворенности пользователей как-то не очень греют бизнес, ему бы стабильность сервисов получше, да чтобы за вменяемые деньги, а вот этим пока порадовать и не удается.
    «Вопрос поставлен?»
    Вопрос то поставлен, уже упомянут в тексте курсивом в заметке Евгения, если кратко звучит так: «Почему по метрикам процессы СУИС работают хорошо, а инцидентов меньше не становиться?» (за время работы процессов состав сервисов и число пользователей не изменилось).
    Был опыт в 2 других проектах, начиная также с инцидентов, проблем, изменений и т.п., сразу определяли ответственных за сервисы, это были не сервис-менеджеры из SLM, а те же специалисты что ранее отвечали за «системы», однако теперь с них спрашивали не за работу отдельных компонентов, а за результат получаемый пользователями, и инструментом достижения результата были те самые «процессы управления деятельностью по предоставлению и поддержке ИТ-сервисов». Вполне допускаю, что этот вариант может быть не самый лучший, тем более что в обсуждаемом случае он уже отвергнут, хотелось бы узнать альтернативные варианты решений: как улучшить качество ИТ при уже хорошо работающих некоторых itil-процессах, но без ответственных за сервис и без SLM.

  • “Вопрос то поставлен, уже упомянут в тексте курсивом в заметке Евгения, если кратко звучит так: «Почему по метрикам процессы СУИС работают хорошо, а инцидентов меньше не становиться?» (за время работы процессов состав сервисов и число пользователей не изменилось).”

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

    Я бы подумал вот о чем:

    1. Сокращается ли время решения инцидентов? Например, один из наших заказчиков за четыре года работы процессов существенно (примерно в четыре раза) сократил среднее время решения инцидентов. Это очень понятная бизнесу польза. Опять же доступность систем при том же количестве инцидентов повышается при сокращении времени их решения.
    2. Повышается ли доля сервисных запросов в общем количестве обращений? Снижается ли доля инцидентов, вызванных системынми сбоями в сравнении с инцидентами, вызванными ошибками пользователей?
    3. Повышается ли удовлетовренность пользователей? Уверен, этот показатель не напрямую связан с количеством инцидентов. И это один из сосновных показателей успешности работы ДИТ как поставщика услуг.

    Думаю надо также понять насколько работает процесс управления проблемами. Сокращение количества инцидентов – это туда.

  • И еще один важный момент. К теме “как связаны процессы и услуги”. Процесс сам по себе ничего не улучшает, но дает возможность, инструмент. Процесс управления в первую очередь обеспечивает следующие инструменты: контроль, оценка, совершенствование (целепостановка).

    Начинать надо именно с постановки целей. Давайте на примере:

    1. Поставить _цель_ – сократить среднее время решения инцидента за год на 20% (то есть провести определенное усовершенствование). Без процесса поставить такую цель существенно сложнее, т.к. не определено что такое инцидент, не ясно как мерять время его решения, инциденты не регистрируются, а текущее время решения неизвестно.
    2. Обеспечить текущий _контроль_ работ, направленных на достижение цели. Т.е. следить за потерями времени на передаче инцидентов между группами, за соблюдением приоритетов, за текущим отклонением от сроков, за конфликтами ресурсов и прочее.
    3. По итогам года _оценить_, насколько цель реализована. По итогам оценки поставить новую цель (go to п. 1).

    Выводы:

    1. Если Вы ожидаете тех или иных изменений в качестве услуг, ставьте соответствующие цели. Причинно следственная связь такова: цель -> инструмент -> результат. В нашем случае инструмент может иметь форму процесса. Но процесс не может заменить цель или результат.
    2. Как правило, процесс позволяет ставить текущие цели в измеримой форме “увеличить / сократить то-то на столько-то”.

    Вопрос: какие текущие цели по повышению качества услуг определены?

    • old fuddy-duddy

      «Процесс сам по себе ничего не улучшает, но дает возможность, инструмент»
      С данным утверждением и дальнейшими рассуждениями согласен на все 100%. Однако, в качестве примера Вы привели цель (задачу) конкретного процесса – процесса управления инцидентами, тут все понятно. А давайте возьмем в качестве примера то о чем говорил я, например: сократить количество инцидентов на 20%». На кого руководство может возложить такую задачу?

      • “А давайте возьмем в качестве примера то о чем говорил я, например: сократить количество инцидентов на 20%». На кого руководство может возложить такую задачу?”

        Как Вы будете действовать, если Вам поставят задачу сократить на 20% расходы? Естественно, начнете с анализа того, какие статьи расходов максимальны. Там и надо копать в первую очередь.

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

        Ответил?

      • old fuddy-duddy

        «Ответил?»
        Неа;)
        «То есть задача получается более комплексная, чем границы одного процесса.»
        С этого то и начинался разговор!
        «Надо разобраться каковы основные причины инцидентов.»
        Вы понятно и правильно объясняете, что нужно делать, а мне-то не совсем понятно, кто должен это делать. Из Вашего примера следует, что основная работа за управлением проблемами (УП). Хорошо, рассмотрим внимательнее этот процесс. В теории все хорошо, однако на практике получается следующее:
        Ресурсов на разбор причин всех инцидентов нет, и в УП регистрируются только проблемы по глобальным инцидентам и то, что наанализируют аналитики проблем на основе личных экспертных оценок.
        1) Аналитики, будучи специалистами в определенных областях, обычно оказываются и исполнителями по решению найденной ими же проблемы, соответственно они стремятся находить не важные, а легкие проблемы и большой пользы от этого нет.
        2) Глобальные инциденты относительно редки, и причины их обычно трудно найти и еще труднее устранить. В итоге обычно ограничиваются обходным решением – инциденты продолжаются. Но даже если глобальная проблема и якобы решена, почему-то вновь возникают очень похожие инциденты, но ответственные специалисты убедительно объясняют что проблема в чем-то другом.
        Итого: В УП нет ответственного за общий конечный результат, сам по себе процесс работает отлично, количество инцидентов не снижается.

        • «Ответил?»

          Неа;)”

          Ну тогда я попробую. Управление проблемами “подчищает” ошибки, попавшие в продуктивную среду вопреки усилиям процессов планирования, проектирования, разработки, построения, тестирования-и-развертывания (или благодаря отсутствию этих процессов и/или этих усилий). При относительно высоком уровне качества услуг управление проблемами может существенно влиять на снижение числа ошибок в операционной среде и как следствие – числа инцидентов там же. Если вышеперечисленные процессы не работают, число ошибок в этой среде таково, что управление проблемами теряет смысл. (Вот Тойота время от времени отзывает свои машины из продуктивной среды и исправляет там какие-то ошибки. Если такую практику реализует АвтоВАЗ, все автомобили все время будут на АвтоВАЗе).
          Но при этом в обоих случаях управление проблемами поможет выявить наиболее активные источники ошибок: плохое планирование, или тестирование, или разработка… И помочь найти ответ на вопрос о том, как сократить число инцидентов. Правда, практическая польза от этого ответа будет только там, где перечисленные процессы хоть как-то управляются.

          • …ну и про “на кого возложить ответственность”.
            За качество конкретных услуг отвечают владельцы этих услуг (есть теперь и в ITIL такая роль). Они выступают как потребители в отношении процессов управления этими услугами. Структура процессов в идеальном случае направлена на управление качеством услуг, на то они и процессы _управления услугами_.
            Поэтому если число инцидентов надо сократить на 20% по конкретному критичному сервису, такая задача ставится владельцу этого сервиса. Он привлекает инструмент под названием “управление проблемами” и определяет основные источники ошибок – и инцидентов. Как я писал выше, эти источники – в зоне ответственности каких-то еще процессов, и владелец услуги теперь привлекает их: “а почему это от вас к нам такое все некачественное падает?”.
            Если владельцы многих сервисов выясняют, что их беды – в основном от некачественного, скажем, тестирования, они инициируют улучшения процесса тестирования (или того процесса, который отвечает за тестирование – неважно, как он называется).
            Для выявления общих для разных сервисов, а потому общих для всей СУИС, проблемных областей используются какие-нибудь service review meetings, где показания владельцев разных сервисов и владельцев разных процессов синхронизируются и планируется улучшение системы в целом, и как следствие – отдельных услуг.

            Вот такая модель.

            • “За качество конкретных услуг отвечают владельцы этих услуг (есть теперь и в ITIL такая роль).”

              1. У коллег, задавших вопрос, таких людей нет. Пока? Не знаю, может быть и не будет в обозримом будущем.
              2. Это только один из вариантов ответа. И я хотел бы уточнить, что он не единственно возможный.

        • “Вы понятно и правильно объясняете, что нужно делать, а мне-то не совсем понятно, кто должен это делать”

          В Вашем случае я думаю, что за анализ источников инцидентов (и следовательно возможностей по сокращению их количества) непосредственно отвечают технологи СУИС. Ответственные за реализацию задачи сокращения определяются по итогам анализа.

          “Из Вашего примера следует, что основная работа за управлением проблемами (УП).”

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

          Теперь ответил? 🙂

          • old fuddy-duddy

            Нет, Дмитрий, такой вариант мне совсем не нравиться.
            Технологи СУИС занимаются процессами и их автоматизацией, а не непосредственно сервисами. Конечно, работа технологов влияет на качество сервисов, но только в том, что связано с процессами. Разбираться же, например, в технических проблемах конкретного сервиса у технологов нет ни времени, ни знаний, да и не нужно им это ведь есть соответствующие технические специалисты, их начальники и т.д. (функциональная организационная структура). Суть проблемы, наверное, в том, что нет точек пересечения функциональной и процессной структуры. В том варианте, что описал Роман, такой точкой пересечения является владелец услуги. В моей практике в подобных случаях эта процессная роль в функциональной структуре доставалась начальнику отдела или руководителю рабочей группы, ранее отвечавшему за определенную ключевую систему. Вы правильно написали, Дмитрий, что в обсуждаемом случае владельцев услуг в обозримом будущем не предвидеться, но и возлагать их обязанности на технологов СУИС я считаю неправильно, так как технологи (если бы и обладали необходимым временем и компетенцией) в таком случае должны будут перетягивать на себя ряд полномочий и обязанностей функциональных руководителей технических специалистов, что породит конфликты, а делу не поможет.
            Вопрос с альтернативой владельцам услуг остается открытым.

            • Коллеги, складывается впечатление, что владельцев услуг мы настойчиво воспринимаем как отдельных специальных людей, которых к тому же сложно встретить в живой природе. Почему так?
              Это ведь роль, исполнители которой должны обладать определенными навыками-знаниями-компетенциями и за это получают определенные обязанности. И действительно, требуемые знания-навыки-компетенции близки тем, которыми обычно обладают специалисты, отвечающие за ту прикладную систему (или те системы), что лежит (лежат) в основе соответствующего сервиса. И часто они оказываются по совместительству руководителями рабочих групп.

              В чем сложность? Почему эти люди не могут выполнять роль владельцев услуг?

              • Тут может сложиться интересная ситуация. Если система сложная и в своей работе опирается на ряд других подсистем, то мы невольно заставим людей, которые раньше сопровождали только основную систему, а теперь стали “владельцами ИТ-сервиса на ее основе”, вникать самостоятельно, а то и выступать в роли заказчиков по отношению к людям, которые сопровождают подсистемы. Проходили это на практике, весьма незаурядная задачка.

                • Т.е. получается, что у нас нет человека, который имеет представление о технологической цепочке Сервиса в целом, все знают только свой огород, а к соседу не заглядывает? О каких сервисах и ITSM тогда вообще речь вести?
                  Давайте тогда будем честными и будем снижать количество инцидентов не по Сервисам, а по еденицам оборудования или функциональным областям.

                  Я уже потерял нить рассуждений в этом топике, больно всё запутано было выше, в чём задача-то? Снизить количество инцидентов или свести задачу к заурядной? Задача снижения числа инцидентов интересует руководство (хотя бы ИТ-ишное) или нужно решение, которое не требует вовлечённости_руководства?

                • old fuddy-duddy

                  to Евгений Шилов
                  «…выступать в роли заказчиков по отношению к людям, которые сопровождают подсистемы. Проходили это на практике, весьма незаурядная задачка»
                  Так ведь в жизни все так и работает, системы не находятся в вакууме и ответственные за них вынуждены договариваться с ответственными за смежные системы, и они делают это сообразно с собственным представлением о прекрасном. Только вот при отсутствии ответственного за конечный результат (качество услуги) велик соблазн не договариваться со смежниками, а в случае чего просто валить все на сетивиков, админов, контрагентов и т.п.

                  to Павел Солопов
                  «Давайте тогда будем честными и будем снижать количество инцидентов не по Сервисам, а по единицам оборудования или функциональным областям…»
                  Это значит, что через процесс управления проблемами придется пропускать вообще все инциденты, что само по себе нереально, но главное, без внимания останутся вопросы взаимодействия подсистем, а самые большие неприятности обычно связаны именно с недостатками взаимодействия.

                  • Не спорю, может быть и криво всё будет, а может и нет. Но вы вырвали фразу из контекста.

                    Если нет возможности доехать на автобусе, надо идти пешком, а не стоять на воображаемой остановке и рассуждать о том, какой должен быть автобус, как он приедет, как повезёт…

            • old fuddy-duddy

              «В чем сложность? Почему эти люди не могут выполнять роль владельцев услуг?»
              А это часть условия задачи.;) В исходном вопросе этот нюанс не упомянут, так как не хотелось сразу исключать из рассмотрения такой вариант, но по ходу обсуждения и я и Дмитрий упоминали, что в рассматриваемом случае вариант с «владельцем услуг» исключен, по крайней мере, до внедрения процессов SLM, а это еще очень не скоро. Вот и ищется альтернативный вариант: кто в уже существующих процессах (инциденты, проблемы, конфигурации, изменения) должен лично отвечать за качество сервисов?

              • SLM нет и будет не скоро. Значит и каталога нет? А нет каталога, то, следовательно, нет и услуг, как таковых.
                Но нужен кто-то, кто будет отвечать за качество услуг.
                Откуда качество у того, чего нет? Услуг нет, а качество есть. Может быть это качество чего-то другого?

              • old fuddy-duddy

                «Значит и каталога нет? …»
                Не угадали, Павел. Есть список сервисов с указанием режимов предоставления, критичности, времени реакции и т.п., можно назвать это и каталогом, для внутреннего употребления сойдет. Система автоматизации позволяет, например, посмотреть инциденты по конкретным сервисам. Есть задача уменьшить количество инцидентов. Кому поручить задачу снизить количество инцидентов по конкретному сервису?

                • Если есть каталог, значит есть и SLM, пусть и простенький совсем. 🙂

                  А поручите снизить инциденты ТЕХНОЛОГУ сервиса, а ТЕХНОЛОГОМ сервиса назначьте самого крупного по данному сервису специалиста, и чтобы у него было время заниматься снижением количества инцидентов освободите от всяких задач по поддержке, разработке и т.д.

                • Да, забыл дописать, что это фактически и получится некий проблем менеджмент, не помню у вас там выше с проблемом какие-то нестыковки кажется были?
                  Не осилю уже всё перечитать.

            • “Нет, Дмитрий, такой вариант мне совсем не нравиться.”

              Ну что ж, так бывает, когда отвечают не совсем то, что хотелось бы услышать. Роман выше Вам ответил как это “правильно” делать с точки зрения первоисточников. Я дал ответ гораздо более приземленный – как с моей точки зрения это можно сдвинуть с места в Вашей организации. Вам не понравился ни один из ответов 🙂 Ваши предложения?

              • old fuddy-duddy

                “Вам не понравился ни один из ответов Ваши предложения?”
                Я имел в виду, что тот вариант показался мне наименее подходящим и объяснил почему. Сами же ответы, да и вся дискуссия, мне как раз понравились, точнее, считаю для себя полезными все высказанные тут идеи. Спасибо всем! P.S. Возможно, когда-нибудь напишу, что в итоге получилось.

  • Sinan

    “Думаю, что бизнес как раз созрел, но что ему предъявить? – Наведение порядка в ИТ-службе и улучшение удовлетворенности пользователей как-то не очень греют бизнес,”

    Если честно я не совсем понимаю что это за бизнес которому не интересен уровень удовлетворённости пользователей.
    В основном ИТ-услугами пользуются пользователи, а не бизнес менеджмент, и про бунт узнают от уст пользователей. Если пользователь удовлетворён, то и менеджменту спокойно. Нет?

    “ему бы стабильность сервисов получше, да чтобы за вменяемые деньги, а вот этим пока порадовать и не удается.”

    “Поэтому в отношении такого показателя как “количество инцидентов” возникает вопрос, интересен ли он потребителям? Скорее всего нет, ведь 2 крупных инцидента за месяц могут остановить работу ИТ-сервиса на более продолжительное время, чем 10 мелких.” или это может быть такой инцидент, что подорвёт репутацию шустрого решения 100 инцидентов.

    Стабильность сервисов, это доступность, безопасность, вообщем все те аспекты которые описывают гарантию услуги. Но каждая критерия имеет особую ценность в особое время.
    Например, доступность в разгар рабочего дня, или в субботний день это разные вещи.
    Бешенное сокращение времени решения всех инцидентов не всегда успех.
    SLM разрабатывает SLA, а без SLA никак. Если это можно переложить на какой то другой процесс, то проблем нет. ITIL не обязывает всё внедрять как в книжках. Сценарии могут быть разными. Разношёрстными.
    Разработайте SLA, предоставьте на подпись руководителям ведущих департаментов, далее утвердите лицом топ-менеджмента.
    Если возникнет вопрос что такой уровень не удовлетворяет бизнес, предоставьте реальное соотношение ресурсов и потребления, альтернативные решения с инвестициями, начиная от малых,временных до крупных, долгосрочных. Решение и возмущения в головах пользователей и бизнеса. Не всегда они требуют инвестиций. Иногда, уведомить, объяснить, чётко начерчить свою позицию хватает.
    Станьте посредником между пользователями и бизнесом, не говорите что это нужно Вам. Скажите что это нужно им, бизнесу.

  • Sinan

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

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


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM