Бизнес vs IT. Часть 3Продолжаю серию про деление на бизнес и ИТ, которую обещал не превращать в долгострой. При этом долгострой всё-таки получился, видимо, это такая фирменная фишка :-)
Поэтому коротко напомню, о чём были предыдущие части.
В
первой части рассуждал о том, откуда вообще взялось разделение на бизнес и ИТ и почему сегодня оно скорее вредит компании, чем помогает.
Во
второй вспомнил популярную в 2000-х модель Demand / Governance / Supply и объяснил, почему бизнесу удобно считать ИТ внутренним подрядчиком: можно заказывать
разработки, тратить корпоративный бюджет, а за эффект от инвестиций особо не отвечать.
Но было бы несправедливо обвинять в этом только бизнес: по моим наблюдениям, самим айтишникам такое разделение нравится ничуть не меньше, а иногда они даже активно отстаивают право не заниматься ничем, кроме технологий.
Знакомые фразы?
"Пусть бизнес сначала определится, чего хочет, а потом приходит с требованиями"
"Мы систему внедрили, теперь ваше дело её правильно использовать. Если не используют -- это не наша проблема"
"Наша задача -- качественно разрабатывать софт, а за прибыль пусть отвечают продажи"
Причём зачастую это позиция не рядового разработчика, а вполне состоявшегося ИТ-руководителя, который одновременно жалуется, что его воспринимают как обслуживающий персонал. Такие вот взаимоисключающие параграфы.
И, если задуматься, у такого поведения есть вполне рациональные объяснения.
1️⃣ В технологиях мы эксперты, и тут нам более-менее всё понятно: архитектура, надёжность, производительность, выбор стека. А чтобы обсуждать маржинальность, оборачиваемость запасов или экономику нового канала продаж, нужно снова становиться новичком. Да ещё и рисковать репутацией эксперта
2️⃣ За технический результат отвечать комфортнее. Работает система или нет -- проверить относительно просто (ну, относительно :-)). А выросла ли прибыль после внедрения? Тут куча факторов, которые мы не контролируем и не хотим за них отвечать
3️⃣ Технологии сами по себе интересны
. Отсюда желание переписать legacy (или просто любой чужой код), внедрить новую платформу, переделать архитектуру. Иногда это действительно необходимо, а иногда ИТ начинает напоминать научную лабораторию, удовлетворяющую своё любопытство за счёт корпоративных грантов. При всей моей любви к учёным и инженерам :-)
Это как раз то интересное противоречие, которое я назвал взаимоисключающими параграфами:
ИТ часто не хочет отвечать за экономический результат, однако вполне охотно предлагает и продвигает решения, которые на него влияют.
Какую архитектуру выбрать, сколько инвестировать в платформу, когда переписывать старую систему, какой техдолг закрывать в первую очередь (будь добр 20% налога на техдолг -- вынь да положь!) -- всё это решения в том числе о деньгах компании.
Причём остальные руководители часто даже не способны критически оценить эти предложения, потому что необходимая экспертиза находится как раз внутри ИТ.
Получается довольно удобная ситуация: когда обсуждаем, на что потратить деньги -- мы эксперты.
А когда обсуждаем, что компания получила за эти деньги, -- мы всего лишь исполнители.Это, на мой взгляд, как раз и есть та самая граница между ИТ-подрядчиком и ИТ как частью бизнеса.
Готов ли ИТ-руководитель не только обосновывать собственные инициативы, но и отказываться от них? Например, прийти к CEO и сказать:
"Мы можем это сделать, но компании сейчас выгоднее потратить деньги на что-то другое. Возможно, вообще не на ИТ"
Конечно, это не означает, что разработчик должен отвечать за EBITDA, а архитектор -- за продажи. Но если руководитель ИТ хочет участвовать в управлении компанией, ему придётся иногда рекомендовать решения, невыгодные собственному подразделению.
В следующей части попробую разобраться, кто вообще этот "бизнес", который должен ставить задачи ИТ. И почему на практике такого единого заказчика часто просто не существует.
