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

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

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

1. Это применимо только для компаний, которые видят применение ITSM в обозримом будущем (12 мес) шире, чем только INC.

2. Организуется только обработка проблем, выявленных в рамках поддержки пользователей и эксплуатации ИС. Т.е. ни выявление проблем, ни тем более проактивный PRB конечно сразу не организуется.

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

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

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

Более того (готов — кидайте помидоры!) я убеждён, что процесс управления проблемами имеет смысл организовывать _одновременно_ с процессом устранения инцидентами (разумеется, не в полном объёме).

Жили бы в раю с стопроцентным SLA, нет же яблок захотелось...

корень проблем — человек, все остальное — последствия

:о)))))

«Этот процесс придумали для того, чтобы унять беспокойство тех сотрудников,...» — блин, точно! они много где уже есть, а занять их нечем

как говорил один наш заказчик: «чего там проектировать, давайте макет делать...».

Но я понимаю что противоречие не дает покоя — поэтому предложил менее мудреный и прямой путь — анализ слова «корневая»

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

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

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

Как только определитесь что есть корневая причина, а что просто причина — там и пройдет «великий водораздел» процессов

Проблемы должны решаться в рамках процесса управления инцидентами иначе все инциденты решаются обходными решениями.

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

Поэтому я размышляя у себя в блоге на эту тему pasol-711.livejournal.com/8832.html предложил несколько иной подход:

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

И соответственно задача процесса управления инцидентами: устранять причины первого порядка (как минимум, устранить причину более высокого порядка не возбраняется), а процесса управления проблемами — выявлять и устранять причины 2-го и более высокого порядка.

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

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

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

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

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

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

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

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

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

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

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

Вариантов, видимо, три:

1. брать под контроль, расширяя охват процесса;

2. передавать тем, у кого есть контроль — другим процессам и/или организациям;

3. смириться («это вне нашей власти») и терпеть.

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

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

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