ИТ-Стайер

Глава 6
Путь ИТ-менеджера

ИТ-отдел, Управление автоматизации, ДИТ или Департамент информационных технологий, Служба технической поддержки информационных систем.. В различных организациях ИТ-подразделения сводятся в различные структуры. Об их составе и наполнени мы поговорим в следующей главе.

Сейчас мы поговорим об ИТ-структуре и управлении ей в целом.

Каких-то особых стандартов я не встречал, но со временем я выработал для себя некоторые подходы, которые сейчас и постараюсь изложить.

Понятно, что все начинается с количества ИТ-шников в Компании. Если группируем 3-4 человека – это группа, если 10 – отдел, до 40 – управление, больше – Департамент. Это достаточно условно, но в целом такой подход вполне себе понятен.

Есть еще вариант. Когда структура строится в расчете на то, что сотрудники будут в двойном подчинении, то для себя я такому подразделению даю название Службы. Например Служба системного администрирования или Служба технической поддержки. Есть куча системных администраторов, которые сидят по своим объектам, административно могут подчиняться их руководителям, но при этом их функциональным руководителем будем сотрудник, возглавляющий соответствующую Службу.

В главе 3 мы уже знакомились с тем какие бывают ИТ-шники. В целом ИТ-структура объединяет весь зоопарк: различные администраторы, программисты, специалисты по офисной технике и пр. Что-то они делают сами, какие-то функции вынесены на аутсорсинг.

Изначально, все это вообще может быть свернуто в одном “изначальном компьютерщике”, который является человеком-оркестром и он даже может не находиться в штате, а прибегать по заявкам секретаря или главбуха. Все что касается ИТ замыкается на него. Директор с ним советуется. Он принимает участие в выработке решений, закупает и настраивает компьютерную технику, заключает договора и даже вносит какие-то изменения в конфигурацию информационной системы или пишет какие-нибудь макросы и программулинки облегчающие жизнью. Поскольку человек один, то если он не шизофреник – никаких проблем взаимодействия не возникает.

Но, рано или поздно, если компания развивается, то компьютерщика становится два. А там где есть двое, возникают отношения подчиненности. Кто-то становится старшим. Так появляется зародыш ИТ-менеджера.

Старший наделен властью. Он принимает решение и несет ответственность. Он становится фильтром между руководством и своим подчиненным.

Но он только старший. Он сам выполняет часть функциональных работ. Фактически у него есть только помощник, который разгрузил “изначального компьютерщика”.

Дальше появляется еще один помощник, еще один и еще…

И у старшего становится все меньше и меньше времени, чтобы что-то делать непосредственно самому. Его время начинает уходить на администрирование, на организацию взаимодействия, на поддержание единого надежного канала коммуникаций между группой своих помощников и другими подразделениями компании.

И тут выясняется, что компетенций чисто ИТ-шника перестает хватать. И они вообще уходят для него на другой план. А на первый план выходят компетенции менеджера.

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

К сожалению, случаи когда такой менеджер появляется из зародыша сформировавшегося внутри достаточно редкие. Подобная метаморфоза требует серьезных изменений как в самом человеке, так и в его восприятии со стороны других сотрудников, руководителей.

Я практически не встречал случаев, когда допустим ИТ-отдел реорганизуется в ИТ-департамент и Руководитель отдела становится Директором Департамента.

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

У меня обычно складывалось так, что я с предшественниками нормально договаривался и они становились фактически моей правой рукой. Никого из них я не потерял, со всеми мы находимся в прекрасных отношениях до сих пор и, я надеюсь, что если у них на каком-то этапе и присутствовала какая-то обида, то она достаточно быстро уходила.

В качестве примера можно привести реорганизацию, которую мы провели в Магните в 2004 году. Отдел автоматизации был преобразован в Департамент. При этом бывший руководитель отдела был назначен Руководителем Управления развития информационных систем (что по уровню выше руководителя отдела) – заместителем Директора Департамента.

Возможно у кого-то есть другое мнение, но в моем понимании такое решение было очень грамотным. Компания сделала шаг вперед, сохранила ценного специалиста, который еще долго и успешно работал. После моего ухода он руководил Департаментом, но руководство компании так и не признало, что он совершил скачок. Ему меняли руководителей, но ничем хорошим это не заканчивалось. В конце концов человек ушел и продолжил карьеру ИТ-руководителя в другой торговой сети. Должен сказать вполне успешно.

Вообще, ситуация перехода в статус менеджера (не только в ИТ) скорее всего для достижения успеха должна сопровождаться сменой места работы. Так процесс происходит менее болезненно. Другой вопрос, перед тем как дергаться возможно стоит здраво оценить свою готовность. Не нужно торопиться. Очень хорошей практикой является сравнение себя и своего руководителя. Задайте себе вопрос: а могу ли я научиться чему-то у своего руководителя. И речь не идет о каких-то сугубо специфических профессиональных знаниях. Скорее стоит смотреть на жизненный опыт.

Иногда полезно оценить себя: насколько я хорош как руководитель? Получить ответ на такой вопрос задача достаточно нетривиальная. Можно провести опрос, можно посмотреть на KPI своего подразделения. можно пройти какой-нибудь профессиональный тест. Но я, со временем, для себя вывел несколько другой критерий. Все очень просто. За чем вам ходят сотрудники? Я считаю, что к хорошему руководителю сотрудники ходят за его мнением. Именно его мнение, основанное на его опыте, знаниях и интуиции является наиболее ценным. Совет – он намного лучше чем приказ. Если к вам ходят за советом, а не за нагоняями и распоряжениями – скорее всего вы хороший руководитель.

Должен ли руководитель быть лучшим в своей специальности? Должен ли он сам выполнять какую-то работу? А должен ли командир мотострелкового полка лучше всех бегать кросс, стрелять и водить БМП?

Если командиру полка приходится стрелять самому – значит он плохой командир. Значит он где-то ошибся, он не справился с управлением.

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

Когда менеджер берет на себя выполнение какой-то частной задачи, в большинстве случаев мы его теряем как управленца. Нужно ли такую инициативу пресекать? Если это происходит не регулярно, то я бы не рекомендовал. Мой заместитель по Магниту периодически мог сесть за написание какой-нибудь программки и тогда управление разработки переходило в режим аналогичный его отпуску, т.е. команды разработки работали на свое усмотрение, обращаясь к нему только в самых крайних случаях, как если бы нужно было совершить звонок по телефону на пляж в Тайланд. К счастью, процессы у нас были поставлены достаточно хорошо и это не было критичным. Такое переключение шло даже скорее на пользу, поскольку после такого творческого запоя он возвращался, обозревал все свежим и вполне отдохнувшим взглядом и принимался рулить разработкой с особым вдохновением.

Менеджмент – это отдельная наука. Бывают ли универсальные менеджеры? Это очень сложный вопрос. Есть общие принципы управления. Используя их, наверное действительно можно управлять чем угодно. Единственное, встанет вопрос с качеством управления.

Нужно понимать, что часто хоть какое-то управление лучше, чем его отсутствие и тогда универсальный менеджер будет плюсом. Но любое универсальное решение проигрывает мало-мальски специализированному.

В ИТ-менеджменте малой специализацией обойтись очень сложно. Очень специфичная сфера, имеющая еще и свои отраслевые уклоны. Ну практически не взлетают ИТ-директора ритейловых компаний из ИТ-менеджеров телекома или региональных топ-менеджеров продавцов торгового оборудования.

Именно с отраслевой специализаций я бы связал необходимость еще одного скачка в эволюции ИТ-менеджера.

Когда мы говорим об ИТ-отделе – это еще нечто достаточно универсальное. Это уровень потребностей средненькой компании, которая вполне может сидеть на типовых решениях.

Чем больше компания, тем более уникально ее лицо, тем более уникальной становится ее ИТ-система. И управление этой системой тоже требует особых подходов.

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

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

Меня всегда умиляет, когда люди осуществляющие подбор на позицию ИТ-директора задают вопросы: а вы умеете программировать на JavaScript? а вы знаете, как администрировать Microsoft Exchange?

Я в таких случаях задаю встречный вопрос: А вы уверены, что вам нужен Директор по ИТ? может вам нужен Руководитель ИТ-отдела? или Руководитель отдела системного администрирования?

Чтобы стать хорошим ИТ-Директором нужно очень хорошо знать отрасль в которой работаешь, но совершенно не обязательно уметь программировать и администрировать. Нужно иметь хороший уровень представления как это делается. Командующий не обязан уметь стрелять из всех видова оружия, он должен знать его характеристики.

Можно ли мигрировать между отраслями? Можно. Это тяжело, затратно – но вполне реально. Речь не идет об универсальности ИТ-директоров. Дело в другом. Сама позиция ИТ-директора требует определенного специфического набора компетенций.

И одна из основных компетенций – это системный анализ. Невозможно стать хорошим ИТ-директором не умея анализировать системы. Наличие же этой компетенции при определенном желании, настойчивости и временном ресурсе позволяет разобраться практически в любой области.

Итак.

Старший компьютерщик – Руководитель ИТ-отдела – Директор по ИТ – вот он путь ИТ-менеджера.

Но есть ли что-то дальше?

Есть.

В современном мире ИТ уже не является вспомогательным инструментом в бизнесе. Часто ИТ-это и есть сам бизнес.

Директор по развитию бизнеса, Директор по инновациям, Директор по управлению изменениями – это те позиции, в направлении которых идет путь. ИТ-менеджеры – это разрабы для бизнеса – люди, которые ответят на вопрос “зачем?”.

Мир меняется. Если раньше требование к ИТ-менеджеру было: “Обеспечить, чтобы было сделано как говорит бизнес”, то теперь “сказать бизнесу что и как делать, чтобы достигнуть целей”.

Глава 7
Как организовать ИТ-структуру компании

Как структурировать ИТ в компании? Какие должны быть ИТ-подразделения? Кому они должны подчиняться?

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

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

Структура должна обеспечить эффективное исполнение функций, а их состав и объем могут быть достаточно различными на разных стадиях жизненного цикла Компании.

Какие-то функции могут быть централизованы, какие-то лучше децентрализовать. Что-то можно отдать на аутсорсинг. Где-то сейчас и одного человека много, а где-то нужно иметь 20 человек и там явно нужно строить дополнительные уровни управления.

Разрабатывая структуру нужно ориентироваться не только на стоящие задачи, но и на текущую обстановку, наличие ресурсов, включая возможности размещения и осуществления коммуникаций.

Хорошая структура проста и понятна. Глядя на нее легко увидеть кто за что отвечает. Важным является наименование подразделений и должностей. Они должны отражать основную суть деятельности.

Структура должна соответствовать основным цепочкам коммуникаций. Именно на уровне структуры закладывается определенный объем противоречий, который согласно законом диалектики будет нас либо развивать, если противоречия будут конструктивными, либо приведут к катастрофе, если перейдут в ранг антагонистических.

Следует помнить об управляемости, которую необходимо обеспечить и поддержать. Нормальным является, когда управление осуществляется не более, чем 10 объектами. Оптимально от 6 до 8. Меньше 4 – это уже расточительство и нужно думать, чем бы еще таким нагрузить такого менеджера.

Есть несколько моментов, по которым всегда ведутся священные войны. Один из них: нужно ли при разработке структуры учитывать персоналии? Или нужно разрабатывать не глядя на тех кто имеется в резерве, а дальше просто наполнять то, что получилось?

Мой опыт говорит, что истина, как всегда, где-то посерединке. Безусловно, идеальная структура не должна быть привязана к конкретным персонажам. Но практика говорит, что иногда на рынке мы не можем найти, тот профиль, который мы заложили в систему, а иногда у нас есть человек набор компетенций которого не накладывается на наше структурное видение и попытка его вписать приведет к прямому разбазариванию ценного ресурса.

Нужно отметить, что чем дальше, тем ценность человеческих ресурсов возрастает. Поиск, подготовка, адаптация – это время и деньги. Относиться к ним нужно бережно и использовать максимально эффективно. Место каждого в структуре должно соответствовать не только его текущим возможностям, но и потенциалу, который в идеале мы должны развивать.

Если человек хороший, то сделать под него должность – это отличная мысль. Всегда нужно помнить, что вписать человека в систему – это не та задача, которую стоит решать без особой на то необходимости. Если вы можете подстроить систему под человека – подстройте. Система она бездушная и спасибо говорить не умеет, а человек будет благодарен и это когда-нибудь может сыграть ключевую роль.

Я не призываю к перегибам, когда нужно идти на поводу у каждого. Но, если человек хочет называться системным архитектором, а не суперадминистратором баз данных почему его не удовлетворить? Нам не тяжело, а ему приятно.

Мы иногда не придаем этому должного внимания, а для кого-то это может быть важным и мотивирующим. У меня был случай, когда один из инженеров службы связи сказал, что ему не нужно денег повышать, а лучше поменяйте должность в трудовой на старшего инженера.

В основу структуры подразделений целесообразно положить разделение ответственности. Это жесткое правило. Не может у какой-то функции, у какого-то процесса быть несколько ответственных.

Ответственность, не означает, что нужно делать самому или досконально контролировать процесс. И не нужно воспринимать, что ответственность обязательно определяется ключевыми показателями деятельности, то есть если я за отвечаю за какие-то показатели, то за них меня обязательно будут наказывать рублем.

Ответственность – это право принять решение, которое другие должны будут воспринять и исполнить.

В нормальной компании взаимоотношения должны основываться на взаимном уважении и доверии и это позволяет выстраивать структуры ответственности и полномочий таким образом, чтобы получить здоровый рабочий корпоративный механизм.

Очень полезно на эту тему познакомиться с материалами института Адизеса. В них очень хорошо проработана методика формирования корпоративных структур. Соревноваться с ними нет никакого смысла. Я и не буду. Просто рекомендую взять на вооружение. Есть еще достаточное количество рекомендаций от других специалистов в этой области, но по большому счету все сводится к нескольким принципам, которые я сформулировал для себя и которыми могу поделиться.

Развитие и эксплуатация (сопровождение/поддержка) требуют разных стилей управления. Совмещение их в одном человеке очень редкий случай. Есть люди предрасположенные к одному или к другому. Это формируется на уровне психотипа. Идеальный менеджер проекта практически никогда не сможет работать в технической поддержке и наоборот. Да, можно напрячь и человек какое-то время будет справляться, но в конце концов диссонанс даст себя знать и произойдет нехорошее.

Разделять и дополнять – это хорошее решение.

Я человек, направленный на проектную деятельность, на развитие и заниматься эксплуатацией для меня всегда было обузой. Я всегда старался структурно разделить эти два направления и найти себе партнера, который бы стал моим дополнением, помог мне закрыть мои слабые стороны.

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

Следующий принцип разделения – это “вторые глаза”. Мы уже говорили, что ответственный всегда один, но обязательно должен быть кто-то кто будет смотреть на то, что этот ответственный делает. И самый лучший вариант, когда этот кто-то напрямую страдает от ошибок ответственного, т.е. он кровно заинтересован высвечивать ошибки своего партнера.

Хочу акцентировать внимание на слове партнер. Очень важно, чтобы даже разделенные сотрудники ощущали себя частью единого племени.

Демонстрация товарищу его ошибки не должна рассматриваться, как желание подставить, выслужиться, подавить. Это помощь в достижении общей цели: сделать общую работу хорошо. Добиться такого положения вещей очень непросто. Но, как показывает практика, вполне возможно. Как конкретно? Об этом мы поговорим в главе про управление ИТ-шниками.

Есть постановщики задачи, есть разработчики, есть тестировщики, есть внедренцы, есть администраторы, есть те, кто обеспечивает работу инфраструктуры.

Я думаю, что вам не составит труда набросать те рабочие противоречия, которые потенциально могут возникать между этими специалистами. Просто представьте кто-кому может предъявить какие претензии.

Разработчики могут упрекать постановщиков в составлении плохого технического задания. В ответ, постановщики будут говорить о невнимательности программистов и нежелании ими понять то, что написано в их понимании практически идеальным языком.

Это нормальное рабочее противоречие. Оно позволяет развиваться и тем и другим. Главное, чтобы они говорили это друг другу, корректно и аргументированно. И ни в коем случае не бегали жаловаться.

Теперь главное. При формировании структуры, впрочем, как и в любых делах, нужно придерживаться принципа разумной достаточности. Не стоит действовать фанатично. Нужно всегда здраво оценивать ситуацию. Необходимость соблюдения любых принципов и правил очень полезно проверять на предмет экономической целесообразности и соответствие элементарной бытовой логике.

Помним, что любое подразделение – это руководитель, который стоит денег и большая его часть не используется по функциональному назначению. Каждый отдельный сотрудник у вас в подчинении – это объект, который требует полноценного внимания, а оно не безгранично.

Не стоит фанатично искать и создавать “вторые глаза”. Не забывайте, что вы тоже обладаете зрением – главное помнить, что есть темные уголки, в которые нужно иногда заглянуть самому. И это нужно делать чаще, чем там может образоваться мусорная куча.

Нужно ли обязательно выделять тестировщиков? Это дорогая функция. Или можно усилить некоторые элементы, которые позволят обеспечить повышение выходного контроля на выходе от программистов, а непосредственное тестирование передать внедренцам?

Можно ли объединить в одном человеке и постановку задач и тестирование и внедрение?.

Не глядя на конкретную ситуацию, конкретную компанию, конкретный фронт работ, конкретных людей я бы не стал давать универсальных советов.

Любое дополнительное подразделение – это деньги. Больше 8-10 непосредственных подчиненных – это потеря управляемости, меньше 4 подчиненных – это расточительство. Людей объединяют общие задачи. Желательно разделять функционал на основе управленческих стилей.

Более или менее за типовую можно принять следующую структуру Департамента информационных технологий достаточно большой компании:

– Отдел системного анализа и проектной поддержки (руководители проектов, проектировщики бизнес-процессов, постановщики задач, создатели технических заданий)

– Отдел развития информационных систем (программисты)

– Отдел сопровождения прикладных программ и администрирования баз данных (администраторы баз данных, специалисты технической поддержки, тестировщики, консультанты по использованию программных продуктов)

– Отдел системного администрирования (серверная группа, сетевые администраторы, специалисты по телекоммуникациям, эникейщики)

– Служба технической поддержки (если есть большая сеть региональных объектов)

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

А дальше мы пережили ряд трансформаций.

Вначале произошло размежевание в результате которого появились Департамент инноваций и внутреннего развития и Управление автоматизации в составе Департамента внутренних сервисов.

Первое подразделение включало в себя:

– Отдел диагностики и проектирования бизнес-процессов

– Отдел проектной поддержки

– Отдел развития универсальных программных решений

– Отдел развития платформенных решений (1С)

В составе управления автоматизации были:

– Отдел развития систем автоматизации торговых объектов (непосредственная автоматизация магазинов: кассы, весы и прочее оборудование)

– Отдел инфраструктуры

– Отдел сопровождения и администрирования баз данных

– Служба технической поддержки магазинов

На следующем шаге на уровне холдинга произошла централизация ряда функций (всего что касается телекоммуникаций и обслуживания компьютерной техники общего назначения). В торговой сети отреагировали и появился Департамент управления изменениями технологий и процессов, состоящий из:

– Управления поддержки системных изменений

– Управления развития универсальных программных решений

– Управления развития платформенных решений

– Управления автоматизации торговых объектов

Как видим, структура подвергалась достаточно существенным изменениям. Безусловно, это определенный стресс и затраты, но в нашем понимании подобные изменения соответствовали текущим требованиям и окупались за счет более эффективной организации деятельности.

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

Не нужно бояться изменений в структуре, но и не стоит ими злоупотреблять.

Стоит остановиться еще на паре моментов.

При внутренней разработке всегда наблюдается недостаток ресурсов программистов. О причинах и вариантах преодоления такого рода голода мы поговорим в отдельной главе. Сейчас же немного о другом.

Нехватка программистов и очередь на выполнение заявок рано или поздно приводят к росту сепаратистских настроений у руководителей функциональных подразделений в компании. Т.е. каждый руководитель начинает мечтать о своем собственном программисте, с которым он мечтает работать напрямую, а еще лучше о группе программистов.

Мой опыт говорит, что если пойти на поводу у подобных настроений, то ничем хорошим это не закончится.

Сложно объяснить, что, как правило, программист не работает в отрыве. Есть разные специализации. Над продуктом работает коллектив. Есть специалисты по структурам, есть по базам данных, есть по интерфейсам, есть тестировщики, админы и пр. Конечно бывают случаи, когда можно очертить достаточно конкретный круг специалистов, действующих сугубо в интересах одного подразделения (например, если разрабатывается WMS – система управления складом), и тогда, такой коллектив, можно отдать непосредственно в логистику, но это скорее исключение. Как правило, все подразделения завязаны на одну систему или группу систем и управлять развитием в таком варианте можно только централизованно.

Кучкующиеся программисты имеют свойство обогащать друг друга, а вырванные из своей среды они хиреют и деградируют. Если вы, как руководитель функционального подразделения заведете собственного программиста, то не удивляйтесь, что он или испортится, либо как-то незаметно размножится, обрастет соратниками и денег компания будет тратить существенно больше..