Многократные переплаты в ИТ и где они возникают. Ч.2

Осторожно: статья‑детектор. Одним из побочных эффектов от прочтения этой статьи является так называемый butthurt. Все, кто рвутся минусовать и доказывать, что даже многократная оптимизация является «экономией на спичках» — ответственны за описываемые переплаты!

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

ФОТ, аутсорс, услуги подрядчиков, проекты

1. ИБД: обновления ради обновлений, разработка ради разработки — отсутствие продуктового подхода. Надо пропустить все проекты (и вообще порывы реализовать у себя порочный круг CI/CD конвейер) через строгий фаервол фильтр продуктового подхода: вкладывать деньги только в то, что принесет доход больше вложений. Значительно больше. Не можем посчитать, сколько это вот ваше выстреливание версий как из пулемета и переписывание кода через раз принесет прибыли? Не можем посчитать, сколько прибыли даст апгрейд версий Windows Server, разного коммерческого ПО? Не делаем. Имитация бурной деятельности пресекается в корне — ФОТ, расходы на проекты сокращаются в разы! Исчезают нарушения бизнес‑процессов, простои из‑за continuous риска что‑то поломать continuous переделками.

2. Частые инциденты, недостаточная инфобезопасность. Всего лишь настройками ОС, которыми упорно пренебрегают, можно было предотвратить если даже не 100, то 99% случаев заражения вредоносным ПО, в том числе шифровальщиками со всеми теми убытками, к которым такое заражение привело. Я уже не говорю о том, что некоторые сотрудники вообще работают с админскими правами. Людям удобно — вирусам тоже. Возможность запустить и поставить любое crapware и частые изменения — админы постоянно суетятся и тушат пожары, а в оставшееся рабочее время занимаются ИБД в виде апгрейдов и переделок, создавая те самые изменения. Порочный круг замыкается. Понятно, что в такой турбулентной среде людей нужно больше. Политикой же запечатанного компьютера, с которым ничего годами не происходит кроме быстрой работы офисных приложений, ФОТ на админов волшебным образом в разы сокращается.

3. ЧСВ ИТ‑директора, оплачиваемое за счет компании. Стремление нанять настолько больше людей, насколько позволит вышестоящее руководство. Больше отдел — лучше для резюме и чувства собственного величия.

4. ИТ подразделение — как театр: люди нужны для исполнения ролей какой‑нибудь методологии. И как Голливуд: чем дороже актер, тем лучше. Формализм — грабит: чисто ради идеи изобразить (опять же как актер) «зрелость компании» — отдаются реальные деньги на высокооплачиваемый overhead из абстрактных, дублирующих и имитирующих бурную деятельность должностей. Например «менеджер по управлению изменениями». Нет лишних изменений — не нужны лишние менеджеры!

   

5. Недоиспользование возможностей удаленного управления. Для решения проблемы пользователя админ приходит лично, ждет пока стул на рабочем месте освободится, по дороге туда/обратно останавливается на разговоры… Хотя, инфраструктура должна обладать таким свойством как управляемость. И тогда уместен чеклист: можно ли решить проблему через удаленную команду / оснастку? да/нет — подключением к графической сессии? (тут уже нужно согласовывать с юзером — а это время) да/нет — и только в случае последнего «нет» идти ногами к рабочему месту! Всё это же про управляемость и грамотное применение консоли и оснасток msc касается и удаленных филиалов, где можно вообще не содержать своих админов, имея только договор со сдельной оплатой на случай устранения физических отказов в инфраструктуре.

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

7. «Под ключ» — в 2–3 раза переплата.
   Как правило у компании есть свой ИТ‑отдел, там есть компетентные люди и не зря же получающие зарплату, способные подготовить инфраструктуру, просто поставить внедряемое ПО — порой это вообще уровень эникея. Так зачем же, реализуя проект, платить за такие услуги подрядчику? Кроме того, делая что‑то под ключ, подрядчик накидывает всего побольше надо‑не надо, продает то, что в компании уже есть. Выгодно же делегировать подрядчику строго ту часть работы, для которой не хватает своих компетенций и ресурсов. И вообще, активно с ним взаимодействовать, а не заплатить и ждать, пока всё сделают за нас.

Существующие «Lean IT» — это сова, натянутая на глобус

Хочется задаться вопросом, а что же существует уже на тему бережливого управления ИТ? Если поискать в интернете про Lean IT — находим только про разработку, что сводится к тому, как накодить больше при прочих равных. Подвох возникает в самом первом шаге перехода от бережливого производства к ИТ: в то время как в настоящем производства произвести больше значит заработать больше, для того же самого завода получить от разработчика больше версий за единицу времени совсем не значит получить прибыль от этого! ИТ, несмотря на все амбиции — поддерживающее материальный бизнес подразделение. Оптимизируя разработку, которая часто делается ради самой разработки, мы «бережливым» управлением из имитации просто бурной деятельности получаем имитацию сверхбурной деятельности — без простоев. Я уже не говорю о том, что тупой переход от производства физических товаров на производство ПО оставляет в ИТ траты на инфраструктуру и лишний поддерживающий персонал — вообще в стороне. Лишний расход памяти в вашем сервере из-за которого вы покупаете сервер на топовом железе, переплачивая в 3-4 раза, вообще не является предметом и методом такого «бережливого ИТ»! Продуктовый подход — основа бережливости в работе с проектами — тоже не является. Ведь задача производить софта больше за единицу времени без простоев программистов. А если пропускать проекты через строгий фильтр продуктового подхода, то разработчики будут простаивать и это «не есть lean»! Вот, в Agile/scrum рекомендуется штат в 7 программистов (привет из п4 пред. абзаца). А что, каждая компания — прямо вендор ПО? Вот они, скрытые растраты, создаваемые, казалось бы «бережливым» направлением в ИТ-менеджменте. Ради еще большего ускорения разработки ради разработки софт переписывают на прожорливых в плане машинных ресурсов технологиях и фреймворках. Частые изменения приносят частые инциденты. Это совсем не бережливо.

Вывод: существует совершенно не освоенный рынок истинно бережливого ИТ-аудита

В котором сейчас каждая компания вроде аудиторской или ИТ-интегратора может стать первой, стать маркетмейкером.

У ИТ есть отличие от других подразделений компаний: расходы на них плохо проверяемы на адекватность. Хуже того, на всех уровнях — от сисадмина до собственника бизнеса — вообще нет культуры, нет понятия оптимизации, как строить и развивать ИТ бережливо, нет вообще мысли о хитрости, хакерском мышлении. Как компании успешно применяют хитрости (латеральное, оно же хакерское мышление) в налоговой оптимизации! Как порой в ущерб репутации рвутся удешевлять состав продуктов! Но при этом в расходах на ИТ — все настолько, наоборот, бесхитростные, конформисты и благотворители, что создается впечатление, что мир сошел с ума! Раздвоение мышления. Культуры, понятия хитрости в ИТ нет даже на бытовом уровне, когда вы все платите в разы больше необходимого за личный компьютер или тарифы связи. Поэтому не только «будущее за ИИ», но и за схлопыванием пузыря лишних затрат, с той же целеустремленностью, с какой бизнесы оптимизируют налоги.