Здравствуй, уважаемый читатель, и спасибо за то, что решил ознакомиться (надеюсь, полностью:)) с моим постом.

Являюсь обычным ИТ менеджером среднего звена, специализация – выстраивание работы ИТ структур: в основном, структур ИТ сопровождения (Системные администраторы (серверная часть, телеком, операционные), Администраторы баз данных (разные конфигурационные единицы), тестировщики, разработчики по инцидентам. В свое время управлял отделом разработки, архитекторами...

Своим “коньком” считаю способность видеть неэффективности в процессах (бизнесовых, ИТ), “подсвечивать” и устранять их, а также “заражать” команды на то, чтобы эти процессы по устранению неэффективностей стали нормой и не зависели от конкретной персоналии (меня).

Вижу разные стадии, в которых могут находиться структуры ИТ сопровождения:

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. проведение жестких переговоров, исходя из которых стоимость ИТ сопровождения сокращается исключительно после отработки мероприятий, указанных выше, а также просчет целесообразности отработки этих мероприятий(стоимость внедрения должна окупаться в адекватные сроки)

Вот и все, иных “секретных ингредиентов не существует”. Буду рад получить обратную связь на сей счет.