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

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

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

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

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

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

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

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

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

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

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

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

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

Мультисервисная площадочная команда

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

В ИТ-сервисе наблюдается похожая ситуация.
Мы также обслуживаем людей и объекты.
Есть площадки — филиалы и офисы, за которые отвечает команда.
Есть специалисты по направлениям: сеть, администрирование, ремонт, принтеры, связь.
Есть показатели производительности, которые отражают нормы времени, но не показывают влияние на бизнес-результат.

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

Команда мотивируется сбалансировано — на ИТ-показатели (время реакции, MTTR, качество обслуживания) и на результаты актива, который она поддерживает.
Так достигается связь между эффективностью сервиса и результатом бизнеса.

Если инженеру добавляют обязанности по новому сервису,
допуск к этим работам осуществляется по результатам обучения и проверки квалификации.
Это обеспечивает качество и безопасность выполнения задач.

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

У Лалу есть и другой пример — европейский производитель автозапчастей, который внедрил похожие принципы.
Эта модель помогла ему сохранить конкурентоспособность с китайскими заводами, снизить издержки и повысить качество.

А может, и нам стоит оценить эффект от перехода к такой модели в ИТ-сервисе?

Корпоративная идентичность — это когда успехи компании ты считаешь своими.
Кажется, будто вы одно целое. Но стоит сменить логотип на бейджике — и вдруг теряется почва под ногами.

В «Управлении гневом» Джек Николсон смотрит прямо в глаза и спрашивает:
— Кто ты, Дейв?
И в этот момент понимаешь — не так-то просто ответить, если всё, чем ты себя определял, связано с работой.

Личная идентичность — это не должность и не бренд в подписи.
Это понимание, в чём твоя реальная сила и польза.
Что именно ты умеешь делать лучше других: решать конфликты, собирать команду, наводить порядок, придумывать новое.

Когда ты это знаешь — корпорация становится твоей сценой, а не клеткой.

А ты собираешь свою личную идентичность или растворён в корпорации?

В 1917 году датский инженер Агнер Эрланг разработал формулу для расчёта нагрузки на телефонные станции.
Она позволила определить, сколько операторов нужно, чтобы система оставалась устойчивой при любом потоке звонков.

Сегодня этот принцип применим и к IT-сервисам.
Когда поток обращений приближается к максимальной пропускной способности команды, качество обслуживания падает не постепенно, а резко.
При сокращении численности даже на 10–20 % вероятность нарушения SLA растёт нелинейно.

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

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

Догадка — случайность.
Интуиция — закономерность, основанная на опыте.

В управлении это особенно важно: решение часто нужно до анализа.
Интуиция даёт направление, аналитика подтверждает.

Как у Джона Нэша в «Играх разума»:
сначала он видит закономерность,
а потом строит доказательство.

Красная или синяя?

В ИТ-каптиве синяя таблетка — это стабильность, SLA и контроль.
Красная — риск, гипотезы, внешние клиенты и рост.

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

Амбидекстрия — это не компромисс.
Это умение держать обе таблетки в руках:
одной — обеспечивать порядок, другой — строить будущее.

А вы верите, что в ИТ-каптиве можно удержать два независимых контура — и не потерять баланс?

AI-SLA — это соглашение об уровне сервиса для систем, использующих искусственный интеллект.
Оно определяет не только доступность сервиса, но и качество работы модели: точность, актуальность данных, стабильность алгоритма и скорость реакции на деградацию.

AI-SLA вводит метрики предсказуемости и способности системы обрабатывать события без участия человека, сохраняя при этом управляемость и прозрачность решений.

Примеры метрик AI-SLA:
— Accuracy drift — постепенное снижение точности модели со временем.
— Data drift — изменение характеристик входных данных, влияющее на качество предсказаний.
— Retraining interval — периодичность переобучения модели.
— Explainability score — насколько решения модели могут быть объяснены пользователю.
— Human-in-the-loop rate — доля решений, требующих проверки человеком.
— Response integrity — доля корректных ответов без галлюцинаций.

AI-SLA становится обязательным элементом при внедрении корпоративных ИИ-сервисов. Он помогает управлять рисками, связанными с качеством данных и неконтролируемыми изменениями моделей.

Можно ли доверять сервису, который принимает решения, но не может объяснить, почему именно так?

Agile и мультисервисная команда

Agile — как Уотни из «Марсианина».
Он действует в неопределённости, пробует, адаптируется, выживает без инструкций.
Его среда — изменения.
Его сила — гибкость.

А на Земле — команда NASA.
Они не импровизируют. Их работа — точность, устойчивость, расчёт.
Каждый отвечает за свой участок, но вместе они держат систему.

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

Мотивация — сбалансированная:
и на ИТ-показатели (MTTR, SLA, качество обслуживания),
и на результаты актива, который команда поддерживает.

Agile создаёт новое.
Мультисервисная команда обеспечивает устойчивость.
Без первых нет движения вперёд.
Без вторых — шанса дойти.

ИИ — это помощник для тех, кто мыслит,
и замена для тех, кто перестаёт думать.

Посмотрите «Она» — фильм, где главный герой влюбляется в голос, который понимает его лучше всех.
Сначала этот голос помогает — слушает, вдохновляет, подсказывает.
А потом становится ясно: главный герой больше не думает сам, он просто продолжает диалог, где всё уже решено за него.

Так сегодня живут многие программисты.
ИИ пишет код, тестирует, исправляет,
а человек лишь нажимает Run.
Процесс идёт — но мышление исчезает.

Пока мы используем ИИ как инструмент — мы остаёмся авторами.
Когда начинаем ему подыгрывать — превращаемся в зрителей.

Что вы думаете о таком будущем —
где думать становится опцией, а не обязанностью?

Новый купол

Мы хотели удобства —
и получили алгоритмы.

Такси приезжает само,
еда прилетает к окну,
товары находят нас раньше, чем мы их ищем.

Роботы пылесосят, нейросети пишут,
а мы — просто подтверждаем.

Каждый сервис решает проблему,
но вместе они решают нас.

Если мы всё превратим в технологию —
мы построим идеальный мир без ошибок.
И попадём в Шоу Трумана,
где всё работает,
но никто больше не живет.

Что делает с нами само стремление всё превращать в технологию?

Эпоха ×200

Почему ×200?
Потому что раньше разница между хорошим и средним была ×2.
Теперь — ×200.
ИИ не заменяет людей,
он просто увеличивает дистанцию между теми,
кто двигается,
и теми, кто ждёт инструкций.

Главная ошибка — думать, что ИИ это инструмент.
Инструмент можно выключить.
А ИИ — это среда, в которой мы уже живём.
Как воздух.
Он повсюду — в бизнесе, новостях, решениях, даже в бездействии.

Мы продолжаем думать по-старому:
что хаос закончится,
что опыт защитит,
что знания дадут преимущество,
что контроль возможен.
Но эпоха ×200 не вернётся к равновесию —
она и есть равновесие.

Что остаётся?
Держать фокус,
собирать свою экосистему,
делать реальные вещи,
не выгорать.
И главное — иметь волю.

Паровой двигатель усилил волю к движению.
Интернет — к объединению.
ИИ — к созданию.
Если воли нет — технологии просто ускорят пустоту.

Мы уже внутри новой среды.
Она не спрашивает, готов ли ты.
Просто движется дальше.

Ты готов ×200?

Эпоха x200 в ИТ-сервисах

AIOps (Artificial Intelligence for IT Operations) — термин, введённый Gartner в 2016 году.
Он описывает системы, где искусственный интеллект анализирует логи, метрики и события,
чтобы предсказывать, предотвращать и устранять сбои в ИТ-инфраструктуре.

Сегодня AIOps применяется:
— в управлении инцидентами и изменениями,
— в мониторинге и самовосстановлении,
— в оптимизации расходов и устойчивости,
— в управлении безопасностью и сетями,
— в CI/CD и обеспечении производительности приложений.

В интернете легко найти примеры реализаций AIOps

«Плохая тактика при хорошей стратегии — это долгий путь к победе.
Хорошая тактика при плохой стратегии — это суета перед поражением».
— Сунь-цзы

Стратегия — не про документы и слайды.
Она требует веры, ресурсов и времени.
Если акционеры не разделяют её и не поддерживают — она превращается в список хотелок.

— Без веры акционеров стратегия не взлетит.
— Без ресурсов она не реализуется.
— Без времени она не даст эффекта.

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

Сегодня выигрывают те, кто соединяет стратегию и технологии.
Кто не просто оптимизирует процессы, а строит инфраструктуру, способную расти в эпоху X200 — когда всё ускоряется в сотни раз.

А ваша стратегия учитывает X200?
В ней есть место для AIOps?

Сегодня поговорим о том, как использовать искусственный интеллект в сервисе.

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

Тот же принцип можно применить в ИТ-сервисах.
В векторы преобразуются обращения пользователей, логи систем, события мониторинга и документация.
Каждый объект превращается в эмбеддинг, который отражает смысл, а не просто текст.
Похожие по контексту данные имеют близкие векторы и группируются в кластеры.

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

Для реализации подойдут открытые инструменты:

bge-m3 — мультиязычная модель с высокой точностью

Jina embeddings v3 — эффективна для разных языков

InstructorXL — учитывает контекст задачи при формировании эмбеддинга

Qdrant или Milvus — векторные базы данных для хранения и поиска эмбеддингов

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

Вторым инструментом ИИ в ИТ сервисе может быть технология RAG. Контекстный поиск и RAG позволяют использовать ИИ в критичных процессах без риска ошибок.

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

RAG, или Retrieval Augmented Generation, решает эту задачу.
ИИ сначала ищет информацию по смысловой близости — в документах, регламентах, базах знаний — а затем формирует ответ на основе найденных данных.

Используются LangChain, LlamaIndex, GPT-4, локальные LLM.
Такой подход обеспечивает ноль галлюцинаций и делает ответы достоверными.

Эффект — повышение точности, снижение числа ошибок и рост доверия к ИИ-ассистентам.

Вот так выглядит визуализация векторов обращений сгруппированных в несколько кластеров

Смыслы и прибыль. Что измеряет компания, когда считает деньги?

Прибыль — простая и красивая метрика. Она позволяет сравнивать, управлять, строить рейтинги и KPI. Но есть одна проблема: она измеряет не смысл, а следствие.

Для классического бизнеса прибыль — отражение эффективности. Но для каптивной компании (внутреннего оператора, обслуживающего корпорацию) рост выручки и прибыли часто означает обратное — рост затрат корпорации. То, что в отчетности выглядит как успех, для группы может быть экономическим паразитом.

Если прибыль — не цель, что тогда измерять?
Для каптива смысл — в эффекте, который он создаёт для бизнеса владельца, а не в размере внутреннего чека.

Сокращение цикла вывода продукта на рынок.

Повышение надёжности сервисов.

Снижение совокупной стоимости владения инфраструктурой.

Ускорение внедрения инноваций.


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

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