ИТ-Стайер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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