Результаты голосования говорят сами за себя.
Две трети выбрали партнёрскую модель — «мы часть бизнеса».
Лишь 2% готовы быть просто ресурсом.
Это не про форму взаимодействия, а про внутренний запрос на субъектность — право влиять, а не только исполнять.

Когда-то в одной крупной корпорации проводили исследование социального климата под руководством Александра Аузана.
И выяснили: самые низкие показатели удовлетворённости — у ИТ-специалистов.
При том что у основного бизнеса ситуация была заметно лучше.

Причина, по мнению исследователей, в высокой объектности ИТ.
Сотрудники чувствуют себя исполнителями, которые всё время «виноваты» и редко понимают, когда становятся «хорошими» в глазах своей компании.
Не хватает не похвалы — её достаточно, — а осознания результата и влияния на общий успех.

Партнёрская модель — это не просто формат взаимодействия.
Это попытка вернуть ИТ ощущение смысла:
не обслуживать бизнес, а работать вместе с ним, видеть результат, участвовать в создании ценности.

Генри Форд однажды шел по цеху: конвейер работает, а рабочие сидят.
Инженеры возмутились — мол, бездельники.
А Форд сказал: «Я им плачу не за то, что они работают. Я им плачу, чтобы конвейер не вставал.»

Он понимал: ценность не в движении, а в стабильности.

В ИТ мы ценим скорость реакции — кто быстрее чинит, кто закрывает больше заявок.
Но настоящий профессионал — тот, у кого заявок нет вообще.

MTTR — это шаг к зрелости,
а следующий шаг — считать неслучившиеся инциденты:
Неслучившиеся = Прогнозируемые − Фактические.
Где прогнозируемые — это среднее число инцидентов × коэффициент риска изменений.

Если ожидалось 120, а случилось 30 —
значит, 90 не случилось.
И, возможно, именно за эти девяносто стоит оценивать команду.

Что думаете об этой цели — оценивать за тишину, а не за героизм?

Конечно, «открытая книга» — вещь полезная. Клиент видит, из чего складывается стоимость услуги: сервер, лицензия, человек, ещё один человек, кофе. Всё вроде честно. Но дальше возникает старый как мир вопрос — а можно было лучше?

Мы нашли три инструмента, чтобы искать этот «лучше».

Первый — коммерческая утилизация активов. Мы начали считать не только, сколько стоит, но и сколько живёт. Актив без пользы — как пылесос без розетки: вроде есть, а толку ноль. Конечно, бывают переподписки и простои. Но если простой бьёт по показателям — команда шевелится, ищет, куда этот ресурс пристроить. Так появляется здоровая тревожность.

Второй инструмент — сравнение тарифов с рынком. Если наши услуги дороже — спрашиваем, почему. Если дешевле — тоже спрашиваем, почему. Разница — это не повод для драмы, а повод для разговора. А разговор — лучшая форма терапии для системы, которая слишком уверена в своей исключительности.

И третий — цели по эффективности. Например, не перекладывать инфляцию в тариф, а перекрывать её ростом производительности. Скромно? Может быть. Но вы посчитайте сложный процент — через пять лет это уже не скромность, а разница между теми, кто живёт на субсидиях, и теми, кто стоит на своих ногах.

Имперскость любит расти ради роста. Экономика — ради смысла. И это, пожалуй, единственный вид роста, который не стыдно измерять.

Из опыта скажу — тарифы ИТ-каптива часто оказываются ниже рынка. Это не потому, что он «не считает деньги». Наоборот — считает, просто по-другому.

Во-первых, норма прибыли.
У каптива она нормирована, единицы процента. Цель не в том, чтобы заработать на корпорации, а чтобы не тратить лишнего. Рынок живёт иначе — двузначные проценты заложены в саму бизнес-модель. Там прибыль — воздух. У нас — побочный продукт.

Во-вторых, утилизация инфраструктуры.
Каптив лучше знает свой спрос. Мы видим план работ, понимаем, что будет запущено через квартал, и не закупаем «впрок». Меньше складов, меньше простаивающего железа. Сбыт предсказуем — это редкая роскошь, которую рынок компенсирует ценой.

И в-третьих, расходы на эксперименты.
Рынок постоянно проверяет гипотезы: «А пойдёт ли эта новая услуга?», «А нужно ли клиентам это облако?» — и платит за ошибки. Мы инвестируем только в то, что нужно корпорации. Каталог предложений не раздуваем, работаем ближе к сути.

Так что, когда кто-то удивляется, почему у каптива дешевле, ответ простой: не потому что «хуже», а потому что без избыточности. Это, пожалуй, и есть редкий случай, когда экономия не убивает качество, а вытесняет шум.

Я много писал про борьбу с имперскостью.
Про то, как каптиву важно не разрастись до размеров собственного мифа — не строить башни, не копить полномочия, не превращать рост в самоцель.
Это паранойя выживания — считать, ограничивать, контролировать.

А у венчура — другая паранойя. Он боится упустить “тот самый” проект, который вырастет в единорога. Поэтому покупает всё подряд: стартапы, лицензии, консалтинги, амбиции. Делает десять ставок, зная, что девять сгорят. Платит не за результат, а за надежду.

Две крайности: одна боится лишнего, другая — недополученного.
Одна держит мечту в узде, другая готова сжечь себя в её погоне.

Можно ли совместить их в одной культуре?
Чтобы контроль не убивал мечту,
а мечта не превращалась в имперскость.

Результаты голосования показали: большинство — за мечту.
Но мечта без меры быстро превращается в новую империю.
А если слишком считать — ничего не вырастет.

Значит, теперь вопрос не в выборе стороны,
а в том, как жить между ними.
Как искать новое, не теряя почву под ногами.
Как разрешать противоречия — не лозунгами, а практиками.

Мониторинг — это взгляд в прошлое.
Он отвечает на вопрос: что произошло?
Система собрала метрики, зафиксировала события, выдала алерт.
Мы реагируем, исправляем, двигаемся дальше.

Цифровой след и цифровые двойники — следующий шаг.
Цифровой след показывает, как система живёт и меняется во времени, связывая события и причины.
Цифровой двойник добавляет возможность моделировать будущее — проверять сценарии, искать уязвимости, прогнозировать сбои и оптимизировать работу заранее.

Мониторинг говорит: «заметь, что случилось».
Цифровой след — «пойми, почему».
Цифровой двойник — «посмотри, что будет дальше».

И в этом контексте вопрос звучит иначе:
стоит ли инвестировать в импортозамещение старых систем мониторинга —
или логичнее сразу строить новую архитектуру, где цифровой след и двойники станут её естественным ядром?

Ключевая метрика цифрового следа в обслуживании инфраструктуры и пользователей — для 90% инцидентов есть данные, которые позволяют установить причину.

Я верю в три гипотезы:

1. Классификация обращений по контексту позволит быстро группировать похожие случаи и видеть повторяющиеся проблемы.

2. Чат-бот поддержки с поиском по базе знаний и переформулированием ответов сократит время реакции.

3. Быстрый поиск релевантной информации ускорит разбор причин инцидентов и повысит точность решений.

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

В какие гипотезы верите вы?

Важная метрика, которая есть не у всех — MTTR (Mean Time To Repair) — среднее время восстановления сервиса. Простая метрика, которая показывает, насколько быстро команда возвращает систему в рабочее состояние.

Пять причин, почему MTTR стоит использовать как целевую метрику:

1. Фокус на реальном результате.
MTTR измеряет не процесс, а факт — сколько времени система была недоступна.

2. Проверка эффективности процессов.
Сокращение MTTR происходит только при реальных изменениях: автоматизации, стандартизации, улучшении диагностики.

3. Связь ИТ и бизнеса.
Время восстановления напрямую влияет на потери и выручку, поэтому метрика понятна обеим сторонам.

4. Выявление узких мест.
MTTR показывает, где тормозит реакция: в мониторинге, коммуникациях или исполнении.

5. Основа для профилактики.
Анализ причин длительных восстановлений помогает устранять источники инцидентов заранее

📍Как построить экосистему телеметрии вместо монолита

Ключевые понятия:

Telemetry — данные о работе систем: метрики, логи, трассы.

Метрики — числовые показатели (нагрузка, задержка, ошибки).

Логи — текстовые события, фиксирующие действия и ошибки.

Трасса (trace) — цепочка операций, показывающая путь запроса через сервисы.

OpenTelemetry (OTel) — открытый стандарт и инструменты для сбора телеметрии.

OTLP (OpenTelemetry Protocol) — протокол передачи метрик, логов и трасс в любые системы.

Collector — шлюз, принимающий телеметрию по OTLP, фильтрующий и пересылающий её.

Lakehouse — архитектура, сочетающая гибкость озера данных и структуру хранилища.

Семплинг (sampling) — сбор только части телеметрии (например, 10% трасс или все ошибки) для снижения объёма.

---

🎯 Цель:
Снизить MTTR и TCO, перейти к мультивендорной модели, где инструменты можно менять без переделки всей системы.

---

⚙️ Принципы:

Инструментировать один раз — использовать во множестве систем.

Collector — единая шина телеметрии.

Lakehouse — дешёвое и масштабируемое хранилище.

Общие атрибуты: service, env, owner, sla.

---

🗓 План на 90 дней:

1–2 недели: запустить Collector, включить OTLP, настроить семплинг.

3–6 недель: подключить 5–10 ключевых сервисов, собрать данные в lakehouse.

7–12 недель: масштабировать, внедрить аналитику MTTR и отчёты.

---

🚀 Быстрые эффекты:

Единый поток телеметрии, меньше агентов.

Поиск по логам, метрикам и трассам из одной точки.

Видимость SLO и MTTR по всем сервисам.

---

⚠️ Риски и ответы:

Рост хранения данных → применяем ретеншн — задаём срок хранения (например, 30 или 90 дней).
Старые данные архивируем или удаляем, чтобы не платить за избыточный объём.

Перегруз метрик → используем rollup — укрупняем данные (секундные значения сворачиваем в минутные или часовые).
Это снижает объём без потери тенденций.

Сопротивление команд → готовим шаблоны включения OTel и минимальные требования к телеметрии.
Цель — «включил и работает».

Мультивендор → храним первичные данные в Lakehouse, чтобы свободно подключать разные инструменты визуализации и аналитики, не завися от одного решения.

Я обещал, что в этом блоге будут идеи. Блог начался с поста о том, как важно превратить идею в веру, хотя бы для самого себя. А для этого мне важно понимать, как это могло бы работать.

Быстрая замена как новый стандарт сервиса

Apple и Samsung давно меряют качество не количеством обращений, а временем, когда пользователь остаётся без устройства.
Это главный KPI сервисного опыта.

Сегодня похожая логика приходит и в корпоративный сегмент.
Например, Velocity Smart реализует модель умных постаматов для замены устройств: сотрудник создаёт заявку, получает код, забирает новое оборудование — всё без участия инженера.

Некоторые ячейки таких шкафов оснащены питанием и сетью, что позволяет удалённо настраивать, обновлять и тестировать устройства прямо внутри постамата.

Добавляем сюда удалённый сервис — и получается комбинация, которая:

- сокращает время восстановления рабочих мест,

- снижает выезды и затраты,

- заметно повышает удовлетворённость пользователей.

https://www.velocity-smart.com/

Не нашел нормального перевода этого термина, поэтому оставил так. Дословный перевод — Основатель, соответствующий рынку.

Почему Founder-Market Fit решает больше, чем идея

В венчуре есть негласное правило: если у команды сильный Founder-Market Fit, можно простить сырой продукт.
Если его нет — проект, скорее всего, не взлетит, как бы красиво ни выглядел питч.

Founder-Market Fit (FMF) — это степень совпадения личного опыта и компетенций основателя с проблемным полем рынка, на котором он строит продукт.
Проще говоря — когда фаундер глубоко понимает рынок, его игроков и боли клиентов, потому что сам из этого мира.

FMF — это не про интуицию, а про три вещи:

1. Опыт: фаундер жил в этой среде и видел её ограничения изнутри.

2. Доступ: он знает, с кем говорить и кому верить.

3. Мотивация: его движет личная потребность что-то изменить, а не случайная идея.

Примеры:

Бывшие логисты делают сервисы для цепочек поставок — и за месяц находят пилотов.

Врачи создают медтех — и сразу говорят о безопасности, а не о «прорывных алгоритмах».

Инженеры из прома запускают B2B SaaS — и не путают PoC с внедрением.

FMF ускоряет всё:

гипотезы валидируются быстрее,

продажи начинаются раньше,

решения принимаются осознаннее,

пилоты становятся не экспериментом, а шагом к бизнесу.

FMF — это гарантия, что команда не ищет смысл, а реализует свой собственный опыт.
Поэтому грамотные акселераторы и корпорации выбирают не идею, а человека, который знает, почему именно этот рынок должен стать лучше.

🧭 Кризис и три северные звезды каптива

Итак, пришёл кризис.
Бюджеты режут. В том числе — на ИТ-сервисы.

Можно сделать по-старому:
📉 разослать разнарядку “минус 20% всем”.
Просто. Быстро. Безумно.

А можно — управленчески.
Через три северные звезды каптива 👇


---

СЗ-1. Консолидация платформ
Убираем дубли. Объединяем мощности.
Чем меньше зоопарк технологий — тем ниже TCO и проще поддержка.

СЗ-2. Взвешиваем SLA по приоритетам
Не все сервисы равны.
Для критичных держим уровень, для вспомогательных — снижаем.
Надёжность должна быть по ценности, а не по среднему.

СЗ-3. Снижаем тарифы за счёт эффективности
Не «срезать маржу», а уменьшить себестоимость:
автоматизация, дистанционная поддержка, self-service, FinOps.

FSM (Field Service Management) — это система управления выездными сервисами: помогает планировать маршруты, контролировать выполнение заявок и повышать эффективность работы полевых специалистов.

🚗 FSM и ИИ: как умное планирование экономит километры
Современные FSM-платформы вроде Microsoft Dynamics 365 Field Service и ServiceNow FSM уже не просто фиксируют выезды — они сами перестраивают маршруты и графики в реальном времени.

📍 Как это работает
Copilot в Dynamics 365 за секунды перераспределяет заявки при отменах или пробках.
Модуль RSO минимизирует пробеги, учитывает навыки и зоны.
ServiceNow FSM предлагает аналогичные функции — AI-powered dynamic scheduling и route optimization прямо в интерфейсе диспетчера.

⚙️ Где FSM-оптимизация даёт эффект
Сотни заявок и широкая география.
Разные навыки и склады.
Частые отмены, простои и трафик.
📉 Гигиена данных решает
ИИ не спасёт, если адреса и длительности заявок устарели — получится «идеальный» маршрут в никуда.

🇷🇺 А что в России? Реальные пилоты FSM уже идут
Вайнах Телеком — телеком-оператор Чеченской Республики.

👉 Автоматизация выездного обслуживания с помощью SNRD FSM, повышение утилизации инженеров и сокращение времени подключений.
🔗 Кейс Вайнах

ICL Services — российский ИТ-провайдер.
👉 Разрабатывает решения с модулем FSM для заказчиков с выездными бригадами.
🔗 Российская сфера ИТ переходит к комплексным решениям

HubEx — отечественная FSM-платформа, обслуживающая более 20 000 объектов в России и СНГ.
👉 Реализует отраслевые FSM-решения для сервиса, логистики и инфраструктуры.
🔗 HubEx — управление выездным сервисом

📊 Вывод
FSM в России уже выходит за стадию экспериментов: появляются зрелые решения, интеграции с логистикой и элементами ИИ-оптимизации.

Продуктовый подход в операторе

Когда говорят «продуктовый подход», часто вспоминают стартап: гипотезы, команда, инвесторы.
В операторской модели, где услуги отлажены и работают по SLA, продуктовый подход нужен для осознанного управления услугами и их экономикой.

1. Почему у продукта должен быть P&L
P&L показывает, из чего складывается результат — какие есть доходы, расходы и маржа.
Без этого продукт остаётся просто статьёй затрат.
Когда владелец продукта видит финансовый результат, он может принимать решения, исходя из реальной эффективности, а не из ощущения загруженности.

2. Роль владельца продукта и ответственность за P&L
Владелец продукта отвечает за экономику услуги — маржинальность, себестоимость, устойчивость.
В каптивной модели продажи ведут внутренние коммерческие подразделения, но ответственность за выручку остаётся у владельца продукта.
Для этого он должен знать своих клиентов, понимать прогнозы потребностей, собирать данные от коммерческих служб, проводить корпоративный маркетинг и анализировать спрос.

3. Кто считает тарифы
Расчёт тарифов — зона ответственности владельца продукта совместно с финансовой службой и экономикой оператора.
Владелец продукта формирует модель себестоимости (ресурсы, лицензии, труд, инфраструктура), прогнозирует объёмы потребления, а финансовая служба проверяет корректность расчётов и формирует общую тарифную матрицу.
Тариф должен отражать реальную стоимость услуги и стимулировать эффективное использование ресурсов.

4. Как отвечать за выручку, если клиентов много, а ты один
Необходимо выстраивать систему работы с клиентами: сегментировать их по профилю потребления, выделять тарифные категории, учитывать SLA и циклы обновления инфраструктуры.
Понимая экономику и структуру спроса, владелец продукта может планировать выручку и управлять развитием услуги.

Вывод:
Продуктовый подход в операторе — это управление услугами как самостоятельными экономическими единицами.
Когда у продукта есть клиент, P&L и тариф, появляется прозрачность и возможность принимать решения на основе данных.

Архитектор и владелец продукта: роли и границы ответственности

1. Роли
Владелец продукта отвечает за результат — выручку, удовлетворённость пользователей, эффективность сервиса.
Архитектор отвечает за целостность и устойчивость решений, за соблюдение стандартов и управляемость системы.

2. Кто отвечает в итоге
Окончательная ответственность — на владельце продукта. Он принимает решения, влияющие на экономику, и несёт последствия этих решений.
Архитектор предоставляет информацию о технических рисках, стоимости изменений и долгосрочных эффектах.

3. Если на хорошую архитектуру нет денег
Архитектор обязан предложить решение, соответствующее возможностям бизнеса: без избыточности, но с соблюдением минимальных требований к надёжности и поддерживаемости.
Экономия не должна создавать скрытый технический долг, который потом будет дороже.

4. Как урегулировать противоречия
Основой взаимодействия должна быть прозрачность.
Архитектор формулирует последствия технических решений в экономических терминах.
Владелец продукта принимает решение, исходя из приоритетов бизнеса.

Так достигается баланс между скоростью изменений и устойчивостью инфраструктуры.