Когда систему уже пора менять
Есть тема, с которой рано или поздно сталкивается почти любая компания.
Системы стареют, бизнес меняется, рынок давит, и в какой-то момент всплывает неприятный вопрос: когда уже пора принять волевое решение и менять контур, даже если это дорого, больно и неудобно?
Ответ на этот вопрос можно найти у автомобилистов. Если стоимость обслуживания машины за год начинает ощутимо приближаться к её рыночной стоимости, ты уже не ездишь на машине - ты обслуживаешь проблему.
Если стоимость владения старой системой - сопровождение, доработки, постоянные “поправить тут”, “заклеить там”, люди, подрядчики, инфраструктура - уже близко к цене нормального перехода на новое, то это уже не теоретический разговор. Это уже практическое решение, просто его пока откладывают.
И тут есть одна ловушка: бизнес обычно считает только прямые расходы. Лицензии, поддержка, подрядчики — всё это видно. А самое дорогое часто остаётся за кадром. Ограничения в развитии, невозможность быстро менять процессы, ручной труд, костыли, интеграции “на честном слове”, зависимость от старой архитектуры, невозможность нормально масштабироваться. Это тоже стоимость. Просто она сидит не в строке бюджета, а в упущенной скорости и потерянных возможностях.
Ещё одна типовая ошибка - воспринимать новую систему как “замену старой”. На самом деле в нормальном кейсе бизнес покупает не просто новый софт. Он покупает следующий уровень управляемости. Скорость изменений, более здоровые интеграции, прозрачность, возможность развиваться без постоянного страха “только не трогайте, а то упадёт”.
❗️Почему такие решения принимаются тяжело — тоже понятно. Люди очень быстро привыкают к тому, в чём работают. Даже если это неудобно. Даже если это тормозит. 😁Я однажды видел, как сотрудникам компания покупала 💵 оболочку под интерфейса Excel 2003, для Excel 2007 чтобы всё выглядело “как раньше”. Не потому что так лучше. Потому что привычнее.🧐
Люди редко сопротивляются плохим системам. Они чаще сопротивляются изменениям.😔 И вот здесь как раз роль руководителя. Такие решения почти никогда не рождаются снизу. ✅Это взрослое управленческое решение: да, будет неудобно, да, будет сопротивление, да, придётся менять процессы и учиться заново. Но оставаться в старом контуре становится дороже и опаснее.
Я для себя обычно формулирую так: если система перестала помогать бизнесу расти, если поддержка стала болезненной, если любое изменение — как отдельный подвиг, если интеграции держатся на “героизме”, а команда больше обслуживает прошлое, чем строит будущее — значит, пора. Не “когда-нибудь потом”.
Хотя бы начинать готовить переход, потому что он всё равно не делается за один вечер.
Знакома ситуация?
· 15.05
В целом согласен со сказанным. Но мораль, как по мне, всё же другая: нужно не дожидаться того момента, когда уже пора менять, а планомерно и регулярно в штатном режиме модернизироваться и обновляться. Не плодить костыли постоянно, а грамотно и гармонично подстраивать систему (архитектуру) в регулярном режиме.
Озвученное вами на 100% перекликается с разработкой ПО: те же самые проблемы. Но вместо того, чтобы регулярно выделять время и ресурсы на устранение тех долга, проблемы годами накапливаются, зачастую как снежный ком, т.е. в геометрической прогрессии (один костыль неизбежно породит ещё несколько).
Ну и изначально стоит делать вещи по уму, закладывая пространство для манёвра на будущее. В этом очень пригождаются инженерные навыки (в том числе как в архитектуре того же ПО), поскольку это общие принципы, работающие везде.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён