Это, я думаю, последняя заметка в серии "Первые шаги начальника ИТ-службы". В первой части я говорил о внимании к терминам, во второй - о понимании специфики пользователей, в третьей - о внутреннем аудите и о том, какие процессы нужно увидеть и оптимизировать в первую очередь. А здесь, в заключительной заметке, мы поговорим об ИТ-зрелости предприятия и о профиле взаимоотношений с потребителями ИТ-услуг.
Сначала скажу, почему я заканчиваю эту серию именно сейчас и таким образом.
Дорога начальника ИТ-отдела (или ИТ-службы) не заканчивается четвертым шагом, и это очевидно для всех. Просто дальше, после того, что я напишу, начинается уже нечто совершенно непредсказуемое и нетипичное. А те шаги, о которых я написал - они совершенно предсказуемые и, по моему мнению, неизбежные.
Более того. Написанные мноей "четыре шага" многие начальники выполняют одновременно еще в период испытательного срока. Ничего нового в них нет, и каждый, кто зарабатывал на хлеб подобным образом, может к моим четырем шагам добавить еще столько же своих, по его мнению, типичных и более важных, чем написанные мной. Мой выбор основывался только на своем опыте и на опыте тех организаций, где я присутствовал как внешний консультант.
Почему о ИТ-зрелости предприятия мы говорим только сейчас, хотя вполне логично было бы говорить об этом на втором шаге, когда выясняются потребности и профиль пользователей? Это правильный и закономерный вопрос. Ответ на него прост: первые три шага нужно делать как можно быстрее (хотя и осмысленно), именно они - кратчайший путь к результатам, пусть скромным, пусть первым, но положительным и необходимым. Поэтому заниматься глубоким анализом на этом этапе, хотя и хочется, но не обязательно. Кроме того, для анализа ИТ-зрелости предприятия нужно хоть немного на этом предприятии поработать. Для этого и нужны первые три этапа! А вот когда разобрались, как что на предприятии называется, кого обслуживаете и как работают (или НЕ работают!) самые главные процессы, пообщались со своими подчиненными, начальниками, поняли, как и что делается, тогда и можно приступить к более-менее оперативно-значимому анализу.
А дальше мой инструментарий следующий.
Почему нужно именно три шкалы? Потому что мы решаем три задачи: насколько зрелое само предприятие, насколько зрелая ИТ-служба, и как бизнес относится к ИТ.
Вот вроде бы тривиальные вещи пишу, но удивительно, как много ошибок совершается из-за того, что выпадает решение одной из трех задач! ИТ-руководители глубоко вникают и понимают, на каком предприятии работают, хорошо представляют, как работает их служба, но совершенно не отдают себе отчет, что бизнес видит в них лишь commodity (товар) и режет издержки при первом удобном случае, в то время, как руководитель ИТ пребывает в уверенности, что к ИТ относятся, как к utility (ресурс). И начинаются на стыке этих непониманий постоянные распри, недофинансирование и взаимные обвинения.
Дело в том, что даже требования бизнеса к ИТ на разных уровнях не только сами по себе разные, но и понимаются по разному. На начальном уровне зрелости предприятия более зрелая проактивная ИТ-служба может быть просто избыточной (если не мешающей). И, например, необоснованное требование бизнеса внедрить тот или иной программный комплекс приведет к потере ресурсов, а не реальным преимуществам в работе.
И еще. Думаете, не бывает, что ИТ-служба находится на более высоком уровне зрелости, чем само предприятие? Еще как бывает. При требовательных инициативных начальниках ИТ, достаточных ресурсах и некоторой бесконтрольности - запросто. Не говоря уже о случаях корпоративных слияний, когда ИТ-служба покупается (или получается в подарок) от другой организации.
Я еще раз подчеркну: в инструментарии начальника ИТ-отдела (или службы) обязательно должен быть инструмент, оценивающий не только степень зрелости каждого участника отношений "ИТ+бизнес", но и отношения бизнеса к ИТ! В идеале, конечно, и отношение ИТ к бизнесу надо оценивать, но это можно сделать в виде притязаний по той же IBM-овской шкале.
А после оценки начинать тяжелый ежедневный труд по улучшению своей службы и предприятия в целом.
Сначала скажу, почему я заканчиваю эту серию именно сейчас и таким образом.
Дорога начальника ИТ-отдела (или ИТ-службы) не заканчивается четвертым шагом, и это очевидно для всех. Просто дальше, после того, что я напишу, начинается уже нечто совершенно непредсказуемое и нетипичное. А те шаги, о которых я написал - они совершенно предсказуемые и, по моему мнению, неизбежные.
Более того. Написанные мноей "четыре шага" многие начальники выполняют одновременно еще в период испытательного срока. Ничего нового в них нет, и каждый, кто зарабатывал на хлеб подобным образом, может к моим четырем шагам добавить еще столько же своих, по его мнению, типичных и более важных, чем написанные мной. Мой выбор основывался только на своем опыте и на опыте тех организаций, где я присутствовал как внешний консультант.
Почему о ИТ-зрелости предприятия мы говорим только сейчас, хотя вполне логично было бы говорить об этом на втором шаге, когда выясняются потребности и профиль пользователей? Это правильный и закономерный вопрос. Ответ на него прост: первые три шага нужно делать как можно быстрее (хотя и осмысленно), именно они - кратчайший путь к результатам, пусть скромным, пусть первым, но положительным и необходимым. Поэтому заниматься глубоким анализом на этом этапе, хотя и хочется, но не обязательно. Кроме того, для анализа ИТ-зрелости предприятия нужно хоть немного на этом предприятии поработать. Для этого и нужны первые три этапа! А вот когда разобрались, как что на предприятии называется, кого обслуживаете и как работают (или НЕ работают!) самые главные процессы, пообщались со своими подчиненными, начальниками, поняли, как и что делается, тогда и можно приступить к более-менее оперативно-значимому анализу.
А дальше мой инструментарий следующий.
- Оценка "на глазок" зрелости предприятия по CMM/CMMI (начальный-повторяемый-определенный-управляемый-оптимизирующий);
- Оценка зрелости ИТ-службы по Gartner (хаотичный-реактивный-проактивный-сервис-польза);
- Оценка отношения бизнеса к ИТ-службе по IBM (commodity (товар)-utility (ресурс)-partner (партнер)-enabler (ключевое условие возможности, поддержка)).
Почему нужно именно три шкалы? Потому что мы решаем три задачи: насколько зрелое само предприятие, насколько зрелая ИТ-служба, и как бизнес относится к ИТ.
Вот вроде бы тривиальные вещи пишу, но удивительно, как много ошибок совершается из-за того, что выпадает решение одной из трех задач! ИТ-руководители глубоко вникают и понимают, на каком предприятии работают, хорошо представляют, как работает их служба, но совершенно не отдают себе отчет, что бизнес видит в них лишь commodity (товар) и режет издержки при первом удобном случае, в то время, как руководитель ИТ пребывает в уверенности, что к ИТ относятся, как к utility (ресурс). И начинаются на стыке этих непониманий постоянные распри, недофинансирование и взаимные обвинения.
Дело в том, что даже требования бизнеса к ИТ на разных уровнях не только сами по себе разные, но и понимаются по разному. На начальном уровне зрелости предприятия более зрелая проактивная ИТ-служба может быть просто избыточной (если не мешающей). И, например, необоснованное требование бизнеса внедрить тот или иной программный комплекс приведет к потере ресурсов, а не реальным преимуществам в работе.
И еще. Думаете, не бывает, что ИТ-служба находится на более высоком уровне зрелости, чем само предприятие? Еще как бывает. При требовательных инициативных начальниках ИТ, достаточных ресурсах и некоторой бесконтрольности - запросто. Не говоря уже о случаях корпоративных слияний, когда ИТ-служба покупается (или получается в подарок) от другой организации.
Я еще раз подчеркну: в инструментарии начальника ИТ-отдела (или службы) обязательно должен быть инструмент, оценивающий не только степень зрелости каждого участника отношений "ИТ+бизнес", но и отношения бизнеса к ИТ! В идеале, конечно, и отношение ИТ к бизнесу надо оценивать, но это можно сделать в виде притязаний по той же IBM-овской шкале.
А после оценки начинать тяжелый ежедневный труд по улучшению своей службы и предприятия в целом.
