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

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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT