Чем больше компания, тем более уникально ее лицо, тем более уникальной становится ее ИТ-система. И управление этой системой тоже требует особых подходов.
Именно уникальность, необходимость формирования и реализации нетиповых стратегических шагов требует появления ИТ-директора.
ИТ-директор – это человек, который работает на другом уровне управления. Он отвечает за то, чтобы ИТ-система отвечала стратегическим вызовам, стоящими перед конкретным бизнесом, конкретной организацией.
Меня всегда умиляет, когда люди осуществляющие подбор на позицию ИТ-директора задают вопросы: а вы умеете программировать на JavaScript? а вы знаете, как администрировать Microsoft Exchange?
Я в таких случаях задаю встречный вопрос: А вы уверены, что вам нужен Директор по ИТ? может вам нужен Руководитель ИТ-отдела? или Руководитель отдела системного администрирования?
Чтобы стать хорошим ИТ-Директором нужно очень хорошо знать отрасль в которой работаешь, но совершенно не обязательно уметь программировать и администрировать. Нужно иметь хороший уровень представления как это делается. Командующий не обязан уметь стрелять из всех видова оружия, он должен знать его характеристики.
Можно ли мигрировать между отраслями? Можно. Это тяжело, затратно – но вполне реально. Речь не идет об универсальности ИТ-директоров. Дело в другом. Сама позиция ИТ-директора требует определенного специфического набора компетенций.
И одна из основных компетенций – это системный анализ. Невозможно стать хорошим ИТ-директором не умея анализировать системы. Наличие же этой компетенции при определенном желании, настойчивости и временном ресурсе позволяет разобраться практически в любой области.
Итак.
Старший компьютерщик – Руководитель ИТ-отдела – Директор по ИТ – вот он путь ИТ-менеджера.
Но есть ли что-то дальше?
Есть.
В современном мире ИТ уже не является вспомогательным инструментом в бизнесе. Часто ИТ-это и есть сам бизнес.
Директор по развитию бизнеса, Директор по инновациям, Директор по управлению изменениями – это те позиции, в направлении которых идет путь. ИТ-менеджеры – это разрабы для бизнеса – люди, которые ответят на вопрос “зачем?”.
Мир меняется. Если раньше требование к ИТ-менеджеру было: “Обеспечить, чтобы было сделано как говорит бизнес”, то теперь “сказать бизнесу что и как делать, чтобы достигнуть целей”.
Глава 7
Как организовать ИТ-структуру компании
Как структурировать ИТ в компании? Какие должны быть ИТ-подразделения? Кому они должны подчиняться?
В этой главе мы попробуем рассмотреть подходы к получению адекватных ответов на эти вопросы. Данный материал достаточно скучный, но тем кто думает о карьере ИТ-менеджера надеюсь он будет полезен.
Я не встречал каких-либо универсальных рецептов формирования структуры ИТ-подразделений, да и сомневаюсь, что они могут быть.
Структура должна обеспечить эффективное исполнение функций, а их состав и объем могут быть достаточно различными на разных стадиях жизненного цикла Компании.
Какие-то функции могут быть централизованы, какие-то лучше децентрализовать. Что-то можно отдать на аутсорсинг. Где-то сейчас и одного человека много, а где-то нужно иметь 20 человек и там явно нужно строить дополнительные уровни управления.
Разрабатывая структуру нужно ориентироваться не только на стоящие задачи, но и на текущую обстановку, наличие ресурсов, включая возможности размещения и осуществления коммуникаций.
Хорошая структура проста и понятна. Глядя на нее легко увидеть кто за что отвечает. Важным является наименование подразделений и должностей. Они должны отражать основную суть деятельности.
Структура должна соответствовать основным цепочкам коммуникаций. Именно на уровне структуры закладывается определенный объем противоречий, который согласно законом диалектики будет нас либо развивать, если противоречия будут конструктивными, либо приведут к катастрофе, если перейдут в ранг антагонистических.
Следует помнить об управляемости, которую необходимо обеспечить и поддержать. Нормальным является, когда управление осуществляется не более, чем 10 объектами. Оптимально от 6 до 8. Меньше 4 – это уже расточительство и нужно думать, чем бы еще таким нагрузить такого менеджера.
Есть несколько моментов, по которым всегда ведутся священные войны. Один из них: нужно ли при разработке структуры учитывать персоналии? Или нужно разрабатывать не глядя на тех кто имеется в резерве, а дальше просто наполнять то, что получилось?
Мой опыт говорит, что истина, как всегда, где-то посерединке. Безусловно, идеальная структура не должна быть привязана к конкретным персонажам. Но практика говорит, что иногда на рынке мы не можем найти, тот профиль, который мы заложили в систему, а иногда у нас есть человек набор компетенций которого не накладывается на наше структурное видение и попытка его вписать приведет к прямому разбазариванию ценного ресурса.