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

ITSM-процессы и организационная структура

Опубликовано 21 мая 2010
Рубрики: ITSM, Всё это - ЛЮДИ, Мероприятия, Обо всём на свете, Практический опыт, Проекты, Процессы
Комментарии

Вчера на конференции ОСП с громким названием ITSM-2010 сделал короткий доклад про совмещение процессного и функционального управления. Сам доклад разместили на сайте компании (и видео, и презентацию), а вот обсуждение можно сделать здесь.

Как я рассказал в самом начале доклада, тема появилась из дискуссии с одним из заказчиков (весьма известный в ITSM-кругах банк 🙂 ), и, пока обсуждали, я, наконец-то, в ней разобрался. То, что раньше казалось сложным, разложилось по полочкам и стало довольно стройной картиной. Картина получила "боевое крещение" ещё в нескольких дискуссиях, и теперь я готов рассказать любому как же совместить несовместимое. Более того, в обсуждении с Димой Исайченко мы вспомнили несколько примеров как (возможно, не осознавая того) уже решали вопросы запуска спроектированных ИТ-процессов в соответствии с этой картинкой.

Апдейт от 11 июня:

Пришёл очередной "дилберт", ну прямо в точку:

— Уолли, ты не мог бы...

— Нет. Я занят важной задачей для менеджера по интеграции брендов.

— Тогда, может быть, после этого...

— Затем я делаю срочную работу для директора обеспечения постоянства

— Это всё хоть реальные люди?

— Добро пожаловать в матричное управление, Нео.

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

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

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

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

    См. апдейт. Дилберт рулит 🙂

  • Николай

    Картина и правда стройная, непротиворечивая и ... в реально жизни абсолютно неприменимая, как и большинство «коней в вакууме» последователей TQM & Co. А жаль...

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

      Отчего же неприменимая? Мне на минутку показалось, что наконец-то я для себя всё по полочкам разложил, и могу использовать не по умным книжкам, а по собственному разумению.

      • Николай

        Отвечу-таки вопросом на вопрос: а это у кого-то РЕАЛЬНО работает? 😉

        Думаю, нет и причины тому следующие:

        — в «подходе» отсутствуют ответы на фундаментальные вопросы, например кто расставляет приоритеты при нехватке ресурсов, кто принимает решения по объему необходимого ресурса и т.п.

        — подход нелогичен — какого чёрта в этой схеме линеного менеджера должны волновать процессные KPI?! Он же просто «поставщик ресурса»...

        — нет ни звука про проектную деятельность, а её как минимум половина

        — четыре последних «необходимых условия» на предпоследнем слайде — H2O, дистилированная :))

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

        — отдельное «хи-хи» про «бюджет процесса» — до этого кажется даже голладцы еще недокурились 😉

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

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

          Вот правда относительно того, что там сказано: некоторые (многие?) представленные идеи мы действительно применяли в ряде компаний, и некоторые из них действительно могут работать 🙂 В том числе (но не только) мотивация руководителей структурных подразделений по процессным метрикам. Я думаю, в этом нет ничего удивительного — ведь процессы, в которых участвуют подчиненные сотрудники, «не придумывают» для них новой работы, а просто организуют ту деятельность, которая является частью их обязанностей, не важно есть процесс или нет.

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

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

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

          • Николай

            Спасибо за поддержку моей позиции 🙂

            Фраза «я бы не стал позиционировать этот доклад как целостный подход» как я понимаю опровергает слова Олега о том, что он «для себя всё по полочкам разложил». Точнее, для себя-то наверно разложил, но разложенное на подход не тянет 🙂

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

          • Николай

            Дмитрий, и ещё.

            Фразы:

            — «...фундаментальность и вечность конфликта между функциональным и процессным управлением слегка преувеличивается...» и

            — «Есть конкретные проблемы в конкретных организациях. Их и надо решать, не занимаясь излишней глобализацией и академизацией»

            попахивают болтологией, sorry...

            Конфликт есть — и точка. Его фундаментальность и вечность не требуют преувеличения или преуменьшения — эти понятия не количественные, а качественные.

            Поясню:

            фундаментальность — обозначает системную сущность

            вечность — обозначает неразрешимость на сколь угодно долгом промежутке времени. Вечность — следствие фундаментальности.

            Суть конфликта надеюсь ясна — конкуренция за ресурс.

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

            Похоже, у вас разные позиции 🙂

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

            «Заниматься ли при этом «излишней глобализацией и академизацией» (читай — какой бы то ни было теорией) — дело ваше. Мне казалось, вы именно ей и занимаетесь»

            Я так не думаю (про теорию). Мы не изобретаем ни глобальных процессных моделей, ни универсальных подходов. Сказанное Олегом есть исключительно обобщение некоторого проектного опыта.

            «Похоже, у вас разные позиции»

            Это возможно и у меня это тревоги не вызывает — мы ведь разные люди 🙂 Но в данном конкретном случае я думаю, что мы говорим про одно и то же. Хотя возможно со мной не согласитесь, ни Вы, ни Олег.

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

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

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

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

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

          Не, ну про «хи-хи» с бюджетом процесса, это просто:

          «The process owner can acquire power through his position in the

          organisation, through his expertise, through his relationships/contacts or through his own budget.»

          «...The process owner does have a budget, however, and he will submit a request to the line manager for resources.»

          Авторы: Richard van Bavel и Jeroen Bronkhorst. По мне — так голландцы 🙂

          • Николай

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

            Тем не менее, «хи-хи» не снимается — хотел бы я посмотреть на PnL со строкой «расходы на инциденты» или «инвестиции в SLA» 🙂

            Повторюсь — как _теория_ это может быть симпатично, как _отдельные_, кое-где и кое-как применимые практики — полезно, но на употребимую в жизни модель (подход, методологию) не тянет ничуть. Sorry.

  • Александр Жилинский

    Олег,

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

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

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

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

      • Александр Жилинский

        Дима, да серебрянных пуль пожалуй нигде и нет. Однако самые смышленые из этих ребят не разводят спец-секций и конференций для обсуждения столь живых вопросов, а просто напросто их решают: сначала по-ходу, а по мере роста проблемы пишут процедуры управления, развития ресурсами, выделения и пр. Которые рано или поздно начинают работать. На мой взгляд, в разработке эта часть развита в среднем на порядок лучше, чем у «сервисников». Просто опыт ближе к реальным деньгам 8)

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

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

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