ИТ-Стайер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не бывает дешевого хорошего аутсорсинга. Но бывает выгодный хороший аутсорсинг. Где и когда он оправдан?

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

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

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

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

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

Глава 8

Что мы строим и как выбрать ИТ-решение?

Для начала несколько слов о Миссии. О Миссии, как о предназначении. Мы поищем ответ на вопрос, что ИТ-шники несут людям.

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

Сейчас, начиная разговор на эту тему я рассказываю всем известную притчу.

Мужик толкает тачку с кирпичами. Ему задают вопрос:

– А что ты делаешь?

И в ответ можно получить разные варианты:

– Кирпич везу…

– Тачку таскаю…

– На стройке работаю…

Но есть ответ, который несет в себе более высокую составляющую:

– Храм строю…

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

Хорошие ИТ-шники – люди с сильной интеллектуальной составляющей. Им важно “что они строят”. Нельзя заставлять их катать тачку или таскать кирпич – сбегут на строительство храма.

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

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

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

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

Для Департамента управления изменениями и для Департамента информационных технологий мы сформулировали следующее:

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

Адаптируем ее к изменяющимся условиям, выстраивая оптимальное взаимодействие в рамках эффективных бизнес-процессов.

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

“Мы экономим время людей и освобождаем их от рутины, предоставляя возможность сконцентрироваться на интеллектуальной и продуктивной деятельности.

Благодаря нам, наша Компания выглядит современно и технологично.

Мы облегчаем понимание и помогаем найти лучшие решения.

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

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

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

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

SAP, 1C, Axapta? Что круче и лучше? Или вообще лучше свое доморощенное, напоминающее какой-то языческий культ?

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

Можно сравнивать различные характеристики, можно изучать отзывы и долго ездить по референс-визитам – но это все равно вам не даст никакой гарантии, что вы точно останетесь довольны своим выбором.

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

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

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

Отсутствие реальных знаний всегда порождает мифы. А мифы – это из категории веры. То есть мы опять возвращается к чему то религиозному.

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

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

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

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

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

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

Для примера. Мой опыт говорит, что те же торговые сети очень легко категоризировать исходя из количества магазинов. До 10 торговых точек – это одна история, от 10 до 30-40 – другая, до 100 – третья, до 400 – четвертая, а после 400, если у вас выстроено все правильно, то уже большого значения не имеет. Если присмотреться, то это все напоминает армейские структуры: отделение, взвод, рота, батальон, ну и дальше уже выходим за уровень тактического звена и там начинают работать другие правила.

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

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

Различные решения изначально ориентированы на различный уровень компаний.

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

Когда, с приходом ЕГАИС в РФ (государство обязало регистрировать движение алкоголя), пришло время автоматизироваться мелкой рознице оказалось, что традиционные игроки практически не смогли ничего предложить. И сейчас в этом сегменте играют совсем другие персонажи. Кстати, в основе одного из наиболее популярных сейчас продуктов, лежит разработка небольшой украинской ИТ-компании, в которой я был основным учредителем и идеологом.