Как выглядит ИТ, которое можно масштабировать
Как понять, готово ли ИТ к рост
После поста о том, почему бизнес может не пережить успех, логичный вопрос другой: а как понять, выдержит ли ИТ рост без потери контроля?
Не по списку систем. Не по презентации. И не по обещанию «разберемся по ходу».
Смотреть надо на конструкцию управления.
Я бы начинал с поддержки.
Первая волна роста приходит именно туда: новые торговые точки, новые пользователи, новые обращения, новые ошибки, новые ожидания бизнеса.
И здесь важно не только количество людей.
Важно другое:
- есть ли единое окно для бизнеса; - закреплены ли зоны ответственности; - не держится ли все на нескольких сильных сотрудниках; - можно ли быстро ввести нового человека в работу; - есть ли понятные сервисные обязательства; - собираются ли чистые данные по обращениям.
Потому что единое окно - это не просто удобство. Это база для управленческой аналитики. Без него руководитель получает не картину проблем, а набор мнений и ручных сигналов.
Дальше надо смотреть шире:
- у сервисов есть ответственные; - у изменений есть архитектурные правила; - у проектов есть прозрачная приоритизация; - у руководителя есть аналитика по рискам, перегрузке и цене задержек.
Один из лучших тестов на зрелость ИТ - не спокойная работа, а большой перевод или быстрое расширение сети.
У меня был кейс: после поглощения сети более 100 магазинов 95% объектов перешли в наш контур за одну ночь. Не за счет героизма, а за счет заранее собранной модели: плана перевода, резерва подрядчиков, координаторов служб, распределенных ролей и контроля.
Поэтому вопрос собственника или CEO к ИТ-директору должен звучать не «что еще нужно купить?», а так:
Сколько новых торговых точек мы откроем в следующем году, как это отражено в твоем бюджете и в годовом плане?
Если в ответе есть поддержка, мощности, роли, изменения, сроки, риски и экономика - ИТ готовится к росту.
Если в ответе только список закупок - компания готовит не масштабирование, а новые точки хаоса.
Масштабируемое ИТ - это когда рост заранее разложен по ответственности, процессам, сервисным обязательствам и бюджету.
#CIO #ITдиректор #УправлениеИТ #МасштабированиеБизнеса #ОперационнаяЭффективность #ПроектныйОфис #Розница
· 02.04
А получается не только наоборот но и "временное сокращение". То есть все включая собственника в сезон видят необходимость расширения ИТ команлы но из-за 2-3 месяцев "простоя" низа что не соглашаются на расширение хотя бы дешевой ТП, не говоря уже о разрабах
ответить
коммент удалён
· 02.04
Именно. И здесь ошибка обычно не в том, что бизнес не хочет держать лишний постоянный штат, а в том, что не разделяет базовую и пиковую нагрузку.
Под постоянную нагрузку нужна устойчивая команда. Под сезонный пик - заранее собранная модель усиления: временная ТП, подрядчик, резерв, упрощенный ввод, понятные сценарии.
Когда этого нет, компания каждый сезон заново спорит не про экономику, а про неудобную очевидность.
ответить
ответ удалён
· 02.04
У нас такая команда, что есть чем занять 2-3 человек ТП. У нас помимо техподдержки еще и тесты кому-то нужно писать.
ответить
ответ удалён
· 02.04
Тогда проблема уже не только в нехватке людей. Размер команды обычно определяется не желанием ИТ, а экономикой бизнеса. И даже если нагрузка очевидна, это не значит, что под нее сразу дадут штат.
Поэтому зрелый путь - не только просить ресурсы, а договариваться с бизнесом о правилах: что в сезон делаем, что не делаем, какие изменения замораживаем, где приоритет у стабильности.
У меня так было в рознице: в горячий сезон заранее вводили запрет на релизы - где-то за 2 месяца до Нового года, где-то за месяц. И это часто давало бизнесу больше пользы, чем попытка в последний момент продавить новые изменения через перегруженную команду.
ответить
ответ удалён
· 03.04
Бывает на производстве чаще так что команда разработчиков рассматриваются не как будущие доходы а как прямые расходы. Мнение такое: железки это главное, а прогеры пррсто офигели
ответить
ответ удалён