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

Нетехнические проблемы

Опубликовано 26 ноября 2011
Рубрики: Процессы, Управление проблемами
Комментарии

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

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

Встречается редко. Собственно, рабочее управление проблемами вообще встречается редко, а уж это вообще высший пилотаж 🙂

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

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

  • Peshkov Alexander

    Да 100500 раз! Но есть определение процесса и есть практика. В процессе – устранение проблем в инфраструктуре, а на практике, заодно еще и решение проблемы парковки.
    Я не стал бы смешивать мух с котлетами, потому что там и методы разные и вообще, одно следует из другого. Вобщем, проблема проблеме волк. То, о чем идет речь в жалостливой части – это плохой chg – такое общее впечатление оставляет данное сочинение.

    • Дмитрий Исайченко

      Александр, поясните, пжл, Вашу мысль. Не догнал.

      • Олег Скрынник

        Позволю себе догадку: “плохо работающий PRB плохо работает наверняка из-за CHG, который не внедряет улучшения”.

        Продолжу мысль: “CHG плохо работает из-за CFG, который ничего нужного не учитывает”.

        Вопрос: ну а CFG-то почему плохо работает? кто из процессов ему мешает? 🙂

  • Вадим

    поправочка
    …устранением и предотвращением причин которых…

  • Роман Журавлёв

    Мне кажется, ошибки в организации работ и подобные им – лишь частный случай. В целом же вопрос стоит так: что делать в процессе управления проблемами, если ошибка найдена в не контролируемой нами области – поведении пользователей, погоде, инфраструктуре заказчика, политиках компании или организации труда. Причём “не контролируемой нами” можно читать как “не контролируемой в рамках системы управления услугами” и как “не контролируемой в принципе”.
    Вариантов, видимо, три:
    1. брать под контроль, расширяя охват процесса;
    2. передавать тем, у кого есть контроль – другим процессам и/или организациям;
    3. смириться (“это вне нашей власти”) и терпеть.

    Вариант 1 – действительно “высший пилотаж”, да и вариант 2 в жизни встречается нечасто. Вариант 1 применяется по умолчанию и даже в книгах встречается как рекомендованный.

  • Георгий

    Дим, ты в принципе прав, кроме маленькой детали.
    Мое искреннее мнение, что процесс управления проблемами только тогда рабочий, когда он “берет в себя” нетехнические проблемы. Собственно поэтому тут две градации, или “высший пилотаж, он же работающий процесс”, или собственно незачем огород городить, оставьте процесс в покое )

    • Дмитрий Исайченко

      Я конечно согласен и с тобой, и с собой :).
      Но нужно небольшое уточнение: есть смысл городить огород с процессом управления проблемами, если оргпроблемы планируется включить в его охват, но не обязательно с первого дня работы. Считаю возможным сначала обрабатывать только технические проблемы, потому что так проще “привыкнуть” и втянуться в процесс. Оргпроблемы подключить через полгода-год (процесс обычно приживается не быстро).

      • Олег Скрынник

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

        Сама идея такого процесса и разделения инцидентов и проблем – замечательна. В живой природе работающий заметное время процесс управления проблемами не встречается ввиду отсутствия сколько-нибудь серьёзной и продолжительной мотивации для такой деятельности как для исполнителей, так и для возможного заказчика означенного процесса.

        Поэтому “жалостливую часть” можно перефразировать: управление проблемами – это фантазия, а управление орг.проблемами – фантазия в квадрате.

        (надеюсь, идиллия теперь нарушена и консенсус ушёл 🙂 )

        • Георгий

          Олег, я одного не пойму, что за страсть, выдавать все тайны сразу…
          Если прямо сейчас все поймут, что в книгах ITIL есть всего две стоящие идеи, а все остальное дикие фантазии авторов, то что мы обсуждать будем в дальнейшем? 🙂

          Давай так – вот тебе как ответ. Этот процесс придумали для того, чтобы унять беспокойство тех сотрудников (с обеих сторон баррикад), которые есть в любом коллективе и которым жизненно необходимо докопаться до истины, до истинной причины всех бед. Ну вот они такие 🙂 и им ну никак не ужиться “под одним большим процессом” с той частью сотрудников, которым пофигу, почему оно сломалось, так как “я уже починил, клиент доволен, я пошел пить пиво” 😀

          • Олег Скрынник

            “что мы обсуждать будем в дальнейшем?” – это да, согласен, всё свалится к котикам и анекдотам…

            “Этот процесс придумали для того, чтобы унять беспокойство тех сотрудников,…” – блин, точно! они много где уже есть, а занять их нечем 🙂

      • Олег Скрынник

        А вот ещё одна точка зрения, имеющая (на мой взгляд) право на существование: любая проблема в инфраструктуре после надлежащего анализа сводится к человеческому фактору.

        Перефразирую словами тов. Джугашвили: у каждой проблемы есть фамилия, имя и отчество.

        Часть фамилий находится под контролем организации, часть – вне.

        Таким образом, процесс управления проблемами должен всегда быть направлен на организационные сложности, где под организационными сложностями понимаются не только и не столько сложности работы каких-нибудь процессов, а организация любых работ.

      • Георгий

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

        • Олег Скрынник

          “я не так много видел внедрений этого процесса” – вот! вот именно! где он, этот процесс? никто его не видел, все только читают да друг другу пересказывают…

          • Дмитрий Исайченко

            На моей памяти PRB хорошо работал в одной компании, с трудом, но все же работал и хотя бы немного помогал – ещё в трёх. Во всех четырёх случаях отсутствие PRB было бы для компании хуже, чем осознание того факта, что процесс работает неидеально. Так что не надо про то что “вот! вот именно! где он, этот процесс? никто его не видел” 🙂
            Более того (готов – кидайте помидоры!) я убеждён, что процесс управления проблемами имеет смысл организовывать _одновременно_ с процессом устранения инцидентами (разумеется, не в полном объёме).

            • Георгий

              Кидаю. это не то чтобы невозможно (в нашем мире все бывает) но неэффективно ни разу

              • Дмитрий Исайченко

                “это … неэффективно ни разу”

                Очень зависит. Два уточнения от меня:

                1. Это применимо только для компаний, которые видят применение ITSM в обозримом будущем (12 мес) шире, чем только INC.
                2. Организуется только обработка проблем, выявленных в рамках поддержки пользователей и эксплуатации ИС. Т.е. ни выявление проблем, ни тем более проактивный PRB конечно сразу не организуется.

                С такими условиями PRB может быть весьма полезен, поскольку:

                1. Даёт ответ на вопрос, что делать с инцидентом, если всем (или кому-то конкретно) надоело его повторение. А такие инциденты есть всегда и появляются после внедрения INC довольно быстро.
                2. Изначально система управления начинает закладываться, как набор взаимосвязанных процессов, польза которых не только быстро тушить пожары. Изначально у линейных руководителей появляются сбалансированные метрики, которые стимулируют их управлять, чтобы обеспечивать не только тушение пожаров, но и выполнение плановой работы.

                • Георгий

                  Ну, т.е. делаем только реактивный PRB, заточенный на то, чтобы помогать INC, т.е. фактически добавляем в INC пару процедур, плюс заранее продумываем заполнение и контроль заполнения правильных полей в записях об инцидентах, чтобы это работало на “будущий PRB”

                  Здравый смысл в этом есть, согласен

                  Насчет линейных руководителей уверен меньше, но может быть тоже да…

                • Игорь Белый

                  кому-то?

                  хм…  современному заказчику услуг очень быстро надоедает "обходное решение" – "перезагрузите ПК", даже странно… ведь работает же в 51% инцидентов.
                   

  • Pavel Solopov

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

    Тут конечно можно возразить, что корневая причина это нечто более глубокое, нежели та причина, что привела непосредственно к инциденту, но это как-то больно уж неопределённо.

    Поэтому я размышляя у себя в блоге на эту тему http://pasol-711.livejournal.com/8832.html предложил несколько иной подход:
    С точки зрения причинно-следственных связей инцидент – следствие некой причины (назовём её причиной первого порядка), которая в свою очередь является следствием другой причны (второго порядка), которая является следствием ещё одной (третьего порядка) и так далее (возможно до бесконечности).
    И соответственно задача процесса управления инцидентами: устранять причины первого порядка (как минимум, устранить причину более высокого порядка не возбраняется), а процесса управления проблемами – выявлять и устранять причины 2-го и более высокого порядка.
    Ну а уже вопрос о том, сможет ли управление проблемами устранять причины организационного, управленческого, человеческого характера это вопрос полномочий, которые организация на этот процесс возложит. Как минимум, процесс может выдавать свои рекомендации по этим причинам.

    • Георгий

      Павел, по-моему, вам для разрешения проблемы, надо сосредоточиться на определении слова “корневая”, не переходя на “порядки” причин.
      Как только определитесь что есть корневая причина, а что просто причина – там и пройдет “великий водораздел” процессов

      • Pavel Solopov

        Это не мне, Георгий, надо, это тем, кто этот термин придумал надо определиться что они имели в виду. 🙂

        Есть короткое, ясное и однозначное определение, которое позволит отличить корневую причину от некорневой?

        • Георгий

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

          • Pavel Solopov

            Ну это да, в современный век системный подход не в чести, чего там раскладывать по полочкам. По быстрому хватать и делать. 🙂
            как говорил один наш заказчик: “чего там проектировать, давайте макет делать…”.

            • Георгий

              ну наконец то мы пришли к здоровому юмору 🙂 значит решение близко 🙂

        • Вадим

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

          :о)))))

          • Pavel Solopov

            Да это давно всем известно, что корень всех наш проблем один человек по имени Ева…
            Жили бы в раю с стопроцентным SLA, нет же яблок захотелось…

          • Pavel Solopov

            “нет человека, нет проблемы”,-сказал проблем менеджер, выходя из бухгалтери и аккуратно вытирая свой самурйский мечь отчётом об инцидентах за месяц.

    • Игорь Белый

      задача процесса управления инцидентами – восстановить работу ит-сервисов как можно быстрее.

      управление проблемами – выявление причин (если они неизвестны или не становятся известны за допустимое время сканирования "баз знанийи" самых разных) – далее перевод в управление изменениями, а там уже решается Комиссией и согласуется "уровень костыльности"

      "корневая причина" – это реально термин "чтобы запутать"  – не надо практикам на него вестись

Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.