Мы тут потихоньку строим наш образовательный маршрут по brand new для нас местам в виде нового курса: "Руководитель IT подразделения". В отличие от обычных программерских курсов, тут мы решили затронуть достаточно широкий спектр задач связанных не столько с софтом и прочим, сколько управлением, финансами и прочим. Данные заметки-вопросы являются, скорее, кратким изложением программы курса, чем ответом на вопрос в топик, но нам было бы интересно охватывают ли они, а точнее сама программа, в каком-либо приближении такую штуку как руководство IT: всё ли нужно и всего ли хватает?
Поток пользовательских обращений, вызванных сбоями в предоставлении ИТ-услуг может быть очень большим. Вы, кстати, знаете, что существует довольно узкий диапазон чисел, в котором находится среднее количество обращение одного корпоративного пользователя в месяц (с усреднением по году)? Разумеется, эта величина зависит от стабильности и качества ИТ-инфраструктуры, уровня компетенции пользователей и многого другого. Но численная оценка, сделанная аналитиками, тем не менее, существует. И при заметном количестве пользователей даже в стабильной инфраструктуре поток обращений будет достаточно большим. А если к инцидентам добавить ещё и обращения, обусловленные не сбоями на стороне ИТ, а, например, потребностью пользователей в консультации, или в сбросе пароля и т.п., то поток обычно возрастает кратно.
Очевидно, что для обеспечения предсказуемой обработки этого потока, да ещё и с учётом различной степени влияния тех или иных сбоев, важности тех или иных обращений, недостаточно, чтобы ИТ-специалисты «просто хорошо работали». Нужны дополнительные управленческие усилия, чтобы с этой нагрузкой справляться. Причём справляться так, чтобы это соответствовало ожиданиям бизнеса.
Любая даже самая совершенная ИТ-инфраструктура вынуждена изменяться. Меняются требования заказчика и потребителей, меняются технологии и способности ИТ-службы. Бизнес, развиваясь, нередко хотел бы проверить практике те или иные гипотезы, чтобы понимать, куда двигаться дальше. Что требует новых ИТ-услуг и/или изменения существующих. В некоторых компаниях запросы на изменения идут почти непрерывным потоком. Для ИТ же (если рассматривать не только подразделения, занимающиеся разработкой и внедрением, но и подразделения, обеспечивающие эксплуатацию и поддержку, т.е. если рассматривать всю службу целиком) такие запросы – не только повышение нагрузки на разработчиков (а также аналитиков, тестировщиков и внедренцев), но и повышения рисков нарушения работоспособности уже существующих услуг. Ведь взаимосвязи различных компонентов ИТ-инфраструктуре в реальной организации довольно сложные. И внесение каких-либо изменений лишь увеличивает вероятность того, что что-то может пойти не так (не зря ведь, наверное, говорят: «если работает, не трогай» ).
В целом, как построить работу ИТ таким образом, чтобы реализовывать изменения быстро, в соответствии с потребностями бизнеса, вовремя и при этом избегая или минимизируя до приемлемого уровня то негативное влияние на потребление ИТ-услуг, которое могу оказывать эти изменения.
Как сделать так, чтобы бизнес (или внешний заказчик, если мы коммерческий системный интегратор, оказывающий ИТ-услуги другим организациям) был доволен тем, как работает ИТ (и был готов платить за эту работу)?
Нужно чётко договориться о том, что от нас, от ИТ, хотят. Разумеется, не забыть уточнить, а можем ли мы сделать то и так, что и как от нас хотят. Но как определить и описать то, что является результатом работы ИТ? Как сделать так, чтобы это описание было понятным для заказчика?
Более того, даже если бы нам удалось договориться, достаточно ли только выполнять договорённости, чтобы заказчик был счастлив?
Почти всегда это не так. И не только потому, что желания и потребности заказчика меняются.
Что ещё помимо выполнения контрактных обязательств нужно делать ИТ, чтобы отношения с бизнесом/заказчиком были хорошими? И как это делать?
Как в управлении операционной деятельностью ИТ, так и при определении договорённостей с бизнесом/заказчиком поставщику ИТ-услуг приходится действовать с оглядкой на свои финансовые возможности. Кроме того, в некоторых случаях вопросы о том, почему на ИТ тратится столько денег, и почему нельзя дешевле, бизнес задаёт довольно настойчиво. Поэтому было бы неплохо иметь возможность оценить, как те или иные вложения в ИТ проявляются в виде результатов, которые важны для бизнеса. Чтобы можно было обоснованно говорить об ИТ-бюджете, о стоимости ИТ-услуг для заказчика, а также определять планы по развитию ИТ.
Для этого необходимо построить модель, в соответствии с которой можно было бы определять «сколько стоит ИТ» для каждого конкретного закачка (например, бизнес-подразделения).
Вторая важная группа вопросов управления ИТ-службой – постановка целей и определение их достижения. Как цели организации определяют цели ИТ-службы? Как цели всей ИТ-службы определяют цели для каждого ИТ-подразделения, из которых состоит ИТ? Или цели каждого процесса, в рамках которого сотрудники ИТ выполняют свою работу?
THE END
Как всегда ждём мнений, тапков и предложений.
Операционное управление ИТ
Поток пользовательских обращений, вызванных сбоями в предоставлении ИТ-услуг может быть очень большим. Вы, кстати, знаете, что существует довольно узкий диапазон чисел, в котором находится среднее количество обращение одного корпоративного пользователя в месяц (с усреднением по году)? Разумеется, эта величина зависит от стабильности и качества ИТ-инфраструктуры, уровня компетенции пользователей и многого другого. Но численная оценка, сделанная аналитиками, тем не менее, существует. И при заметном количестве пользователей даже в стабильной инфраструктуре поток обращений будет достаточно большим. А если к инцидентам добавить ещё и обращения, обусловленные не сбоями на стороне ИТ, а, например, потребностью пользователей в консультации, или в сбросе пароля и т.п., то поток обычно возрастает кратно.
Очевидно, что для обеспечения предсказуемой обработки этого потока, да ещё и с учётом различной степени влияния тех или иных сбоев, важности тех или иных обращений, недостаточно, чтобы ИТ-специалисты «просто хорошо работали». Нужны дополнительные управленческие усилия, чтобы с этой нагрузкой справляться. Причём справляться так, чтобы это соответствовало ожиданиям бизнеса.
Проведение изменений
Любая даже самая совершенная ИТ-инфраструктура вынуждена изменяться. Меняются требования заказчика и потребителей, меняются технологии и способности ИТ-службы. Бизнес, развиваясь, нередко хотел бы проверить практике те или иные гипотезы, чтобы понимать, куда двигаться дальше. Что требует новых ИТ-услуг и/или изменения существующих. В некоторых компаниях запросы на изменения идут почти непрерывным потоком. Для ИТ же (если рассматривать не только подразделения, занимающиеся разработкой и внедрением, но и подразделения, обеспечивающие эксплуатацию и поддержку, т.е. если рассматривать всю службу целиком) такие запросы – не только повышение нагрузки на разработчиков (а также аналитиков, тестировщиков и внедренцев), но и повышения рисков нарушения работоспособности уже существующих услуг. Ведь взаимосвязи различных компонентов ИТ-инфраструктуре в реальной организации довольно сложные. И внесение каких-либо изменений лишь увеличивает вероятность того, что что-то может пойти не так (не зря ведь, наверное, говорят: «если работает, не трогай» ).
В целом, как построить работу ИТ таким образом, чтобы реализовывать изменения быстро, в соответствии с потребностями бизнеса, вовремя и при этом избегая или минимизируя до приемлемого уровня то негативное влияние на потребление ИТ-услуг, которое могу оказывать эти изменения.
Взаимодействие с заказчиками (бизнес-подразделениями)
Как сделать так, чтобы бизнес (или внешний заказчик, если мы коммерческий системный интегратор, оказывающий ИТ-услуги другим организациям) был доволен тем, как работает ИТ (и был готов платить за эту работу)?
Нужно чётко договориться о том, что от нас, от ИТ, хотят. Разумеется, не забыть уточнить, а можем ли мы сделать то и так, что и как от нас хотят. Но как определить и описать то, что является результатом работы ИТ? Как сделать так, чтобы это описание было понятным для заказчика?
Более того, даже если бы нам удалось договориться, достаточно ли только выполнять договорённости, чтобы заказчик был счастлив?
Почти всегда это не так. И не только потому, что желания и потребности заказчика меняются.
Что ещё помимо выполнения контрактных обязательств нужно делать ИТ, чтобы отношения с бизнесом/заказчиком были хорошими? И как это делать?
Управление и финансы
Как в управлении операционной деятельностью ИТ, так и при определении договорённостей с бизнесом/заказчиком поставщику ИТ-услуг приходится действовать с оглядкой на свои финансовые возможности. Кроме того, в некоторых случаях вопросы о том, почему на ИТ тратится столько денег, и почему нельзя дешевле, бизнес задаёт довольно настойчиво. Поэтому было бы неплохо иметь возможность оценить, как те или иные вложения в ИТ проявляются в виде результатов, которые важны для бизнеса. Чтобы можно было обоснованно говорить об ИТ-бюджете, о стоимости ИТ-услуг для заказчика, а также определять планы по развитию ИТ.
Для этого необходимо построить модель, в соответствии с которой можно было бы определять «сколько стоит ИТ» для каждого конкретного закачка (например, бизнес-подразделения).
Вторая важная группа вопросов управления ИТ-службой – постановка целей и определение их достижения. Как цели организации определяют цели ИТ-службы? Как цели всей ИТ-службы определяют цели для каждого ИТ-подразделения, из которых состоит ИТ? Или цели каждого процесса, в рамках которого сотрудники ИТ выполняют свою работу?
THE END
Как всегда ждём мнений, тапков и предложений.
Комментарии (8)
diamond_nsk
17.10.2017 19:13Не понял, и что же в итоге нужно знать руководителю IT подразделения?
MaxRokatansky Автор
17.10.2017 19:14Ну вот на наш взгляд получается, что помимо базовых знаний (не стали копипастить условия целиком) требуются знания в вышеуказанных областях
lovermann
18.10.2017 00:05Я, наверное, не понял формата вашего изложения, но эта статья (если её можно назвать) вообще ни о чём. И очень диссонирует с довольно смелым заголовком.
MaxRokatansky Автор
18.10.2017 01:19Иногда сны — это просто сны. В смысле заголовок в данном случае полностью отражает его суть — это вопрос, который чуть более подробно раскрывается в первом абзаце. На большое откровение заметка не претендует :)
cleaner_it
18.10.2017 08:59+1Нужно написать в заголовке, что это опрос)
MaxRokatansky Автор
19.10.2017 18:10Ну тогда это надо было бы и делать опросом, но это не опрос, а вопрос в формате рассуждения забазированный на нашу программу.
soomrack
ITIL нужно знать.
MaxRokatansky Автор
Логично, но мы предполагаем, что базовые знания уже должны быть к этому моменту, хотя на курсе этот вопрос, конечно, должен затрагиваться.