Приветствую всех, кто решил прочитать пост, однако сразу хочу предостеречь крутых ИТ-шных гиков о том, что глубоких технических изысканий здесь не будет (это на случай, если кто – то захочет “закидать помидорами”/накидать дизлайков, например, в связи с тем, что тема не раскрыта по причине отсутствия кода по той или иной автоматизации или роботизации).
Мой пост будет больше интересен руководителям отделов ИТ сопровождения, или проектным менеджерам, перед которыми будет стоять задача по сокращению затрат на ФОТ.
Также оповещаю о том, что мой пост НЕ является рекламой, чтобы плохого никто не думал.
Пару слов обо мне - являюсь обычным ИТ менеджером среднего звена, специализация – выстраивание работы ИТ структур: в основном, структур ИТ сопровождения (системные администраторы (серверная часть, телеком, операционные), администраторы баз данных (разные конфигурационные единицы), тестировщики, разработчики по инцидентам. В свое время управлял отделом разработки, архитекторами.
.
Своим “коньком” считаю способность видеть неэффективности в процессах (бизнесовых, ИТ), “подсвечивать” и устранять их, а также “заражать” команды на то, чтобы эти процессы по устранению неэффективностей стали нормой и не зависели от конкретной персоналии (меня).
Вижу разные стадии, в которых могут находиться структуры ИТ сопровождения:
1. ”все горит и пожарит”: в этот момент бизнес буквально молится на то, чтобы кто – то смог решить проблемы, что мешают ему жить (прямая потеря денег из – за неэффективных процессов ИТ).
2. ”хочется что – то еще”: как только пожары потушены, появляются многочисленные “хотелки” о том, как улучшить сервис.
3. ”ДОРОГО!!!”: пожары практически забыты как сущность, и начинаются “игры разума” в сторону попыток сокращения штата ИТ сопровождения.
Об этом “ДОРОГО!!!” и хотел бы поделиться мыслями с вами, мои дорогие читатели. При этом, важно всегда балансировать между понятиями об эффективном ИТ менеджере:
А) ИТ стратегия следует из стратегии компании (но понятно, что не всегда это возможно, зачастую у компании нет стратегии…)
Б) назначенные ЛПР-ы в бизнесе, влияющие на судьбоносные ИТ решения, могут быть временщиками, принимающими бездумные решения, последствия которых придется кому – то пожинать
В) сокращение опытных людей, владеющих обширной экспертизой и опытом работы в этой конкретной организации, может нанести непоправимый ущерб организации
Г) сократить затраты при помощи увольнения сотрудников – легко; сократить затраты таким образом, чтобы не порушились процессы, не снизилась эффективность – задача
Д) сокращать можно экстенсивно (работа никуда не денется, просто ее нужно будет делать оставшимися сотрудникам) – и здесь есть предел; сокращать можно интенсивно (при помощи современных технологий (автоматизация, роботизация и др.) или пересмотра процесса в сторону его упрощения – и здесь также есть предел
И важно понимать, что этот предел ЕСТЬ.
В этой связи становится особо важным иметь критическое мышление, обдумывать всю обратную связь, которая касается “ДОРОГО!!!”, быть способным вступать в диалог, разбивать фактами необоснованные желания оппонента сократить штат, если есть понимание, что уже некуда. Акцентирую внимание на том, что мероприятия по оптимизации могут уже быть выполнены (как экстенсивные, так и интенсивные), а “хотелки” по сокращению персонала могут не уйти. Хочу отметить, что не рассматриваю случай смены организации в данном посте – нет, моя цель иная: представить свое видение о том, как поступать в таких случаях. Помимо этого, получить в комментариях обратную связь от более опытных в плане умения сокращать затраты ИТ сопровождения коллег, а также их точку зрения концептуально по поводу данного поста, подискутировать.
Итак, переходим к практической части. Есть задача сократить штат ИТ сопровождения, например, администраторов баз данных 1С.
Предлагаемые мероприятия:
1. исключение дублирующих процессов, единая точка ввода информации
2. выявления потенциала и последующая автоматизация процессов ИТ сопровождения (например, автоматическая выдача прав пользователям на основании матрицы должностей в разрезе выполняемых функций)
3. роботизация (например, сверок при сдаче отчетности из Бухгалтерии предприятия)
4. авто тесты (чтобы делать тестирование изменений, а также чтобы не порушились основные процессы при внедрении – производилось не человеком, а технологией)
5. выявление бизнес – функционала, который исторически выполняет ИТ, ставим вопрос о передаче в бизнес
6. предоставление бизнесу списка реализованных в базах данных функций, что усложнили процесс, увеличив нагрузку на ИТ и бизнесовых сотрудников – с целью анализа этих изменений на предмет целесообразности и стоимости владения их (это может привести к упрощению процессов и снижению трудозатрат)
7. предоставление бизнесу статистики обращений в ИТ по нетехническим вопросам, где нет технической ошибки (потенциально заставит бизнес сформировать институт ключевых пользователей, обучать бизнесовых сотрудников)
8. устранение узких мест, вроде неэффективной архитектуры обменов информацией между базами данных (например, внедрение Кафки)
9. запрос на пересмотр времени предоставления услуги (к примеру, было 24*7, а достаточно 16*7), показав стоимость ИТ сопровождения в каждом временном промежутке (9 – 18, 18 – 1, 1 – 9)
10. запрос на модернизацию старого ПО (если имеется старая конфигурация/платформа, на базе которой нельзя автоматизировать процессы ИТ сопровождения)
11. проведение жестких переговоров, исходя из которых стоимость ИТ сопровождения сокращается исключительно после отработки мероприятий, указанных выше, а также просчет целесообразности отработки этих мероприятий (стоимость внедрения должна окупаться в адекватные сроки). Если “эффективный менеджер” от бизнеса не принимает аргументы, предложите ему найти на рынке более дешевые услуги в сравнении с вашими, или же сами сравнитесь с рынком (вы можете ответить, что у вас уникальное нетиповое ПО, и сравниться с рынком невозможно, и таки отвечу: это еще один аргумент для того, чтобы обеспечить отказоустойчивую структуру ИТ сопровождения, потому как если растерять штат – на рынке специалистов не будет; а сравниться с сопровождением типовых сервисов легко, и чем больше организация/штат ИТ, тем более дешевый сервис в сравнению с рынком нужно уметь оказывать, иначе зачем нужен внутренний ИТ, если асутсорс на внешнем рынке стоит дешевле…). Еще раз: сначала выполнение мероприятий, что позволит сократить трудозатраты ИТ сопровождения (а это в том числе бюджеты на проекты по автоматизации/роботизации, время на реализацию проектов и подтверждение эффекта, и прочее), и только потом – сокращение персонала. “Эффективный менеджер” не принимает и аргументы, и сравнение с рынком – настаивайте на том, чтобы поставил свою подпись под рисками (их можно оцифровать: например, увеличение на Х количества инцидентов, аварий, конкретное снижение уровня сервиса (например, скорость реакции на запросы будет не час, как ранее, а три)). Конечно же, чем сильнее роль ИТ в организации, тем проще аргументировать позицию.
Важно помнить, что, получив запрос на сокращение штата, не нужно паниковать, действуем последовательно: прорабатываем возможности, выходим на диалог вместе с проработкой, подсветив риски, согласовываем мероприятия.
Вот и все, иных “секретных ингредиентов не существует”. Буду рад получить обратную связь на сей счет.
