Что нужно знать руководителю IT подразделения?

    Мы тут потихоньку строим наш образовательный маршрут по brand new для нас местам в виде нового курса: "Руководитель IT подразделения". В отличие от обычных программерских курсов, тут мы решили затронуть достаточно широкий спектр задач связанных не столько с софтом и прочим, сколько управлением, финансами и прочим. Данные заметки-вопросы являются, скорее, кратким изложением программы курса, чем ответом на вопрос в топик, но нам было бы интересно охватывают ли они, а точнее сама программа, в каком-либо приближении такую штуку как руководство IT: всё ли нужно и всего ли хватает?


    Операционное управление ИТ


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

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

    Проведение изменений


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

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

    Взаимодействие с заказчиками (бизнес-подразделениями)


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

    Нужно чётко договориться о том, что от нас, от ИТ, хотят. Разумеется, не забыть уточнить, а можем ли мы сделать то и так, что и как от нас хотят. Но как определить и описать то, что является результатом работы ИТ? Как сделать так, чтобы это описание было понятным для заказчика?
    Более того, даже если бы нам удалось договориться, достаточно ли только выполнять договорённости, чтобы заказчик был счастлив?

    Почти всегда это не так. И не только потому, что желания и потребности заказчика меняются.
    Что ещё помимо выполнения контрактных обязательств нужно делать ИТ, чтобы отношения с бизнесом/заказчиком были хорошими? И как это делать?

    Управление и финансы


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

    THE END

    Как всегда ждём мнений, тапков и предложений.
    Отус 267,17
    Профессиональные онлайн-курсы для разработчиков
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 8
    • 0
      ITIL нужно знать.
      • 0
        Логично, но мы предполагаем, что базовые знания уже должны быть к этому моменту, хотя на курсе этот вопрос, конечно, должен затрагиваться.
      • +2
        Не понял, и что же в итоге нужно знать руководителю IT подразделения?
        • –1
          Ну вот на наш взгляд получается, что помимо базовых знаний (не стали копипастить условия целиком) требуются знания в вышеуказанных областях
        • +2
          Я, наверное, не понял формата вашего изложения, но эта статья (если её можно назвать) вообще ни о чём. И очень диссонирует с довольно смелым заголовком.
          • –1
            Иногда сны — это просто сны. В смысле заголовок в данном случае полностью отражает его суть — это вопрос, который чуть более подробно раскрывается в первом абзаце. На большое откровение заметка не претендует :)
          • +1

            Нужно написать в заголовке, что это опрос)

            • 0
              Ну тогда это надо было бы и делать опросом, но это не опрос, а вопрос в формате рассуждения забазированный на нашу программу.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое