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

Координатор проблем в слабой матрице

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

Например, время от времени начинает тормозить приложение. Вполне логично координатором данной проблемы становится один из ведущих специалистов app-саппорта. Далее, предположим, в результате диагностики он выясняет, что тормоза возникают на СХД. Почему? Причин может быть множество, способов решения еще больше. А наш координатор проблемы в СХД не специалист. Как быть? Кто теперь станет координатором проблемы? Передать ее координатору по СХД? Оставить на app-саппорте?

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

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

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

(*) Про сильные и слабые матрицы можно почитать, например, здесь: http://www.inform-it.org/wp-content/uploads/2015/01/PMM-The-Process-Management-Matrix-article-Global-Best-Practice-Vol-I-2008.pdf

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Сергей

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

    • Сергей, во-первых, спасибо за ответ, я уж думал, что говорю сам с собой 🙂

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

  • Андрей

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

    Решение было следующее: ответственным за инцидент назначалось подразделение, которое отвечает за услугу по которой был подан запрос. Оно через систему нарядов привлекало другие подразделения. 

    Думаю, что с проблемами схожая ситуация, только (гипотетически) сроки на владельца (ответственное подразделение) проблемы не давят

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

      • Андрей

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

  • Алексей

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

    Для сохранения мотивации обоих подразделений, можно зарегистрировать как минимум 2 (или более) инцидента связанных с этой проблемой: первый инцидент – на прикладные системы, второй – на поддержку ИТ-инфраструктуры. Важно отслеживать, чтобы инциденты не были закрыты до восстановления согласованного уровня сервиса.

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM