Как совместить эффективность с экономичностью
Темы: IT
Как совместить эффективность с экономичностью
В старые «добрые» времена любой ИТ-специалист назывался программистом и выполнял целый ряд функций, начиная с настройки вычислительной сети и заканчивая починкой компьютерного кресла (хоть и кресло, но «компьютерное» же). Тогда потребность в айтишниках несложно было определить, исходя из общего количества рабочих станций в компании.
Но времена менялись, задачи усложнялись. Как определить потребность в ИТ-специалистах для ТЕХНОНИКОЛЬ с ее географически распределенной структурой, десятками разбросанных по стране и миру заводов и единым центром по разработке общих информационных систем?
Понятно, что оставлять удаленные подразделения и заводы без ИТ-поддержки на месте нельзя. Любая проблема со сложной вычислительной техникой может вызвать остановку работы подразделения. Конечно, техника упрощается, вычисления уходят в облака, появляются виртуальные рабочие места и возможности удаленной поддержки.
Другое дело, что не всегда в этом есть экономический смысл. Использовать сложные технологии с централизацией точки отказа — не всегда эффективно. Зачастую проще и дешевле иметь двух ИТ-специалистов на заводе, которые могут обслуживать сеть, серверы, локальные компьютеры, принтеры. А еще будут следить за расходными материалами и за качеством предоставляемых сервисов.
В который уже раз: «лидерство в издержках». Мы не фанаты новых передовых технологий, иногда старые проверенные методы работы являются лучшим выбором. Это не говоря уже о вопросах занятости населения и организации дополнительных рабочих мест (в ряде регионов заводы Корпорации являются крупнейшими работодателями). Впрочем, не будем отклоняться от темы.
Серьезный вопрос — обеспечение взаимозаменяемости персонала. Люди болеют, уходят в отпуск. В ТЕХНОНИКОЛЬ это решено на административном уровне. ИТ-персонал четко знает, кто, кого и когда подменяет — сначала на уровне завода или комбината (в нашей терминологии комбинат — это несколько заводов, относящихся к разным СБЕ, но расположенных территориально в одной географической локации), потом на уровне региона, а затем уже на уровне СБЕ или корпоративного центра. Это очень важно для построения стабильной системы поддержки.
А сколько специалистов нужно для развития информационных систем? Понятно, что чем больше задач по доработке информационной системы мы будем реализовывать, тем больше будет поступать новых заявок. Мы не можем допустить «снежного кома» и бурного роста затрат на разработку, поэтому здесь приходится вводить ограничение сверху.
Получив это ограничение, ИТ-менеджеры могут сосчитать (статистика накоплена), сколько клиент-менеджеров, тестировщиков и «сборщиков» необходимо для обслуживания определенного количества разработчиков.
Размер службы приема заявок тоже определить несложно. Для обеспечения круглосуточного сервиса необходима организация как минимум трех смен. Количество заявок и средняя скорость обработки одной заявки давно фиксируется в существующих информационных системах, и потребность в специалистах легко посчитать. То же касается и сотрудников, которые лично разбираются с заявками и предоставляют прямые ответы пользователям.
Не исключается использование аутсорсинга и аутстаффинга для определенных типов производственных площадок, удаленных подразделений с малым общим количеством персонала. Там это может быть хорошим, приемлемым решением. Для новых производственных площадок или площадок, работающих в рамках одного комбината, активно используется инсорсинг — заключаются договоры на ИТ-сопровождение между различными бизнес-единицами.
Что касается тех, кто должен заниматься инновациями и новыми проектами, — эти специалисты должны быть выведены из общих процессов по поддержке информационных систем. Их количество и качество определяется исходя из бюджета инноваций. Мы уже упоминали, что цель — довести в перспективе размер бюджета ИТ-инноваций до размера бюджета на операционную деятельность ИТ.
Подход к подбору кадров здесь такой же — экономичность плюс эффективность. В штате должны быть грамотные архитекторы. Новая идея рождается и прорабатывается внутри Корпорации. А дальше выставляется на торги среди большого количества разработчиков, не обязательно очень квалифицированных. Привлекаются аутстаффинговые или аутсорсинговые ресурсы.
Основная задача (это, собственно, похоже на модель инкубатора) — создать минимально жизнеспособный продукт, обладающий некоторым набором достаточных для удовлетворения первых потребителей функций, и на этом работающем прототипе «обкатать» все новые технологии, теории и процессы.
Только после получения положительного результата можно двигаться дальше и доводить продукт «до ума». Используя подобные схемы, можно значительно сокращать требуемый для инноваций персонал, сохранять компетенции внутри Корпорации, а также обеспечивать высокий уровень вознаграждения и нематериальной мотивации ключевых ИТ-сотрудников, работающих с новыми продуктами и над новыми проектами.
