Блог Кирилла Позднякова

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 в России уже выходит за стадию экспериментов: появляются зрелые решения, интеграции с логистикой и элементами ИИ-оптимизации.

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

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

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

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


---

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

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

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

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

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

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

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

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

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

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

Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, чтобы свободно подключать разные инструменты визуализации и аналитики, не завися от одного решения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имперскость ИТ-каптива и управляемый конфликт

1. Проблема
Когда у заказчика нет выбора, конфликт направлен наружу.
ИТ-каптив превращается в «империю процессов»:
бизнес жалуется, ИТ оправдывается, энергия уходит на защиту границ.

2. Решение
Создать внутри каптива несколько моделей взаимодействия:

Ресурсная — заказчик управляет людьми и задачами сам.

Сервисная — фокус на SLA и чётких обязательствах.

Партнёрская — совместная работа на бизнес-эффект.

3. Что происходит
Конфликт не исчезает, но перемещается внутрь.
Теперь спорят не бизнес и ИТ, а разные команды внутри каптива —
о подходах, эффективности, удовлетворённости заказчиков.

Вы скажете — дублирование.
Я отвечу — воздух для идей и управленческих решений.
Без параллельных подходов не возникает сравнения,
а без сравнения не рождается развитие.

4. Результат

Между бизнесом и ИТ — доверие и прозрачность.

Внутри каптива — здоровая конкуренция.

Империя превращается в экосистему, где конфликт работает на развитие, а не на оборону.

Вывод:
Перенос конфликта внутрь — не угроза, а механизм взросления.
Только там, где есть выбор, конкуренция и немного дублирования, появляется воздух — и движение вперёд.

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

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

Если карьерный рост зависит от результатов на человека, от производительности без расширения штата, от снижения числа обращений при той же нагрузке, то руководитель начинает искать не новые ставки, а новые решения.

Пример.
Было: руководитель гордится тем, что у него 30 инженеров.
Стало: руководитель гордится тем, что 15 инженеров справляются с тем же объёмом за счёт автоматизации и профилактики.
И это уже повод для повышения, а не для урезания.

Так формируется здоровая отрицательная обратная связь: рост штата перестаёт быть единственным способом показать значимость.
А настоящая карьера строится на умении делать больше — меньшими силами и с большим умом.

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