ServiceNow и «enterprise plumbing»: почему платформы побеждают

Что значит «enterprise plumbing» и почему это важно

«Enterprise plumbing» — метафора про «сантехнику» компании: незаметные, но жизненно важные соединения между людьми, командами, системами и данными. Как трубы в здании не продают квартиру напрямую, так и внутренние workflow редко попадают в презентации для клиентов. Но если они протекают или забиты, бизнес ощущает это сразу: заявки теряются, согласования зависают, сроки срываются, а качество сервиса становится случайным.

Невидимая инфраструктура, которая держит рост

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

Когда процессы масштабируются, выигрывают те, у кого:

• понятные маршруты задач и ответственности;
• единые правила согласований и изменений;
• общий контекст по заявке (что нужно, почему, какой риск, какой SLA);
• измеримость: где узкое место, сколько стоит задержка, что повторяется.

Что вы получите из этой статьи

Дальше разберём, где в компании прячется эта «сантехника», почему IT часто становится бутылочным горлышком и почему платформенный подход (на примере ServiceNow) помогает соединить процессы, данные и контроль. В конце будет набор критериев выбора подхода, список рисков внедрения и практические шаги, как запустить автоматизацию workflow и измерить эффект.

Где в компании прячется «сантехника» процессов

«Сантехника» процессов — это невидимые потоки работы, которые соединяют людей, команды и системы. Пока они работают, их не замечают. Но стоит где-то появиться протечке — и бизнес начинает «буксовать» на мелочах.

Невидимые потоки, которые есть почти везде

Обычно они живут не в одном отделе, а проходят сквозь всю компанию:

• Заявки и обращения: от «сломался ноутбук» до «нужна новая услуга для клиента».
• Согласования: договор, бюджет, доступ к данным, изменения в системе.
• Доступы и учётные записи: онбординг/оффбординг, роли, права, подтверждения.
• Закупки: запрос потребности → коммерческие предложения → заказ → приёмка.
• Изменения (change): планирование работ, окна внедрения, уведомления, откат.

Важно: это не «про IT» или «про бухгалтерию». Это про то, как решение проходит путь от запроса до результата.

Что ломается, если «труб» нет

Когда процесс держится на переписке и личной памяти, появляются типовые поломки:

• Ручные передачи между командами: «я отправил письмо, дальше не знаю».
• Потеря контекста: детали остаются в чате, в личных заметках, в устных договорённостях.
• Дублирование: две команды делают одно и то же, потому что нет общей картины.

Снаружи это выглядит как «просто долго», но внутри растут риски: ошибки, нарушения сроков, несогласованные изменения.

Сигналы, что сантехника скрыта и течёт

Есть два узнаваемых маркера.

Первый: «всё держится на людях» — на конкретных сотрудниках, которые «знают, кому писать».

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

От ручных операций к платформе: путь автоматизации

Автоматизация в компаниях почти всегда начинается одинаково: сначала «всё держится на людях». Запросы приходят в почту и мессенджеры, статусы хранятся в таблицах, согласования — в цепочках «ответь всем». Это работает, пока объём небольшой и команда знает контекст наизусть.

Типовая эволюция: ручной труд → порталы → очереди тикетов

Следующий шаг — «давайте сделаем портал»: форма заявки, шаблоны, базовые правила маршрутизации. Это снижает хаос и стандартизирует вход.

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

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

Проблема в том, что реальные процессы идут поперёк подразделений: доступы зависят от HR-данных, закупка — от бюджета, изменения — от рисков и расписания, поддержка — от конфигураций. Если автоматизировать по кусочкам (отдельно портал, отдельно согласование, отдельно учёт активов), стыки остаются ручными: люди копируют данные, уточняют контекст, «пробивают» исключения через личные контакты.

Как исключения превращают процесс в «зоопарк правил»

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

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

Почему IT неизбежно становится бутылочным горлышком

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

Очередь на интеграции, права, изменения и отчёты

Большая часть запросов — не «разработка продукта», а обслуживающая работа:

• выдать/отозвать права в нескольких системах и подтвердить это по правилам;
• согласовать изменения (Change) и не сломать связанный сервис;
• подключить новую систему, обмен данными, единые справочники;
• собрать отчётность из разрозненных источников и объяснить цифры.

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

Контроль и безопасность: не всё можно «отдать в бизнес»

Логичное желание — «пусть бизнес сам настраивает». Но права доступа, персональные данные, финансовые операции и изменения в продуктиве требуют рамок: кто запросил, кто согласовал, кто выполнил, где аудит. Без этого скорость оборачивается рисками и инцидентами, за которые всё равно отвечает IT.

Эффект масштаба: каждая новая система добавляет связность

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

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

Цена узкого места: время, риски и качество сервиса

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

Сколько «стоит» обход процесса

Самый заметный счёт — за время. Если запрос на доступ, изменение в системе или согласование закупки зависает на 3–7 дней, бизнес платит не только зарплатой сотрудников, которые ждут.

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

Простой расчёт помогает увидеть масштаб: 30 сотрудников × 2 часа «ожидания/простоя» в неделю = 60 часов. Умножьте на стоимость часа и на 4 недели — и станет понятно, почему «всего пара дней согласования» превращается в заметную сумму.

Рост скрытых затрат

Узкое место почти всегда порождает ручные обходы: пересылки в почте, таблицы, чаты, «позвони Пете». Это приводит к:

• повторной работе (одни и те же данные вводятся в разные места);
• ручным сверкам (кто согласовал, что изменилось, где актуальная версия);
• инцидентам из‑за изменений (что-то внедрили без контроля зависимостей, забыли уведомить, не проверили влияние).

Здесь деньги уходят тихо: команда закрывает последствия — разборы, откаты, исправления, ответы на вопросы, восстановление доступа, объяснения руководству.

Нематериальные последствия

Не менее дорогая часть — качество сервиса.

Когда люди привыкают, что «официально долго», падает доверие к IT как к партнёру. Начинаются теневые практики: обходные инструменты, неформальные доступы, хранение данных «где удобнее». Это повышает риски безопасности и осложняет поддержку.

В итоге узкое место бьёт по трём метрикам одновременно: скорость (SLA/lead time), надёжность (инциденты/ошибки) и удовлетворённость (оценка сервиса). И именно поэтому устранение бутылочного горлышка — не про «удобство», а про экономику и управляемость.

Почему побеждают платформы, а не точечные решения

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

Набор инструментов vs платформа

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

Платформа — это единая среда, где процессы собираются на общих компонентах:

• Единые данные и контекст: один каталог услуг, единые карточки пользователей, активов, заявок, изменений.
• Общие роли и правила: доступы, маршрутизация, SLA, политики согласований задаются централизованно.
• Интеграции как стандарт: подключения к почте, HR, ERP, мониторингу и другим системам делаются по повторяемым шаблонам, а не «вручную под проект».

Почему выигрывает платформа

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

Кроме того, платформа вводит стандарты: одинаковые статусы, единые требования к данным, понятные метрики. Это снижает разночтения между командами и упрощает поддержку.

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

Критичные свойства платформы

Чтобы «enterprise plumbing» работала на масштабе, важны:

• Масштабирование: рост числа пользователей, процессов и интеграций без деградации.
• Расширяемость: возможность добавлять новые сценарии без переписывания старых.
• Аудит и трассируемость: кто, что и почему изменил — для разборов и соответствия требованиям.
• Управление доступами: роли, разграничение данных, безопасное самообслуживание и автоматизация.

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

ServiceNow как «операционная система» для рабочих процессов

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

Что обычно переносят на ServiceNow

Переезд редко начинается с «всего и сразу». Чаще всего на платформу переводят те зоны, где особенно заметны очереди и ручная координация:

• ITSM: инциденты, проблемы, база знаний — чтобы прекращать «пожары» быстрее и повторять удачные решения.
• Запросы услуг: каталог сервисов, согласования, выдача доступов — чтобы у сотрудников был понятный вход в помощь, а у IT и HR — прогнозируемая нагрузка.
• Управление изменениями: единые правила оценки риска, планирования окна, коммуникаций и пост‑контроля.
• Активы и конфигурации: кто чем владеет, что где установлено, как это связано — для поддержки, аудита и принятия решений.

Единый «центр» работ: очереди, SLA и ответственность

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

• прозрачные очереди и загрузка команд;
• измеримые SLA и понятные причины нарушений;
• приоритизация по влиянию на бизнес, а не по громкости запроса;
• закреплённая ответственность: владельцы, роли, правила эскалации.

Когда процесс живёт в одном месте, легче находить узкие места и устранять их не героизмом, а настройкой правил и автоматизацией.

Меньше зависимости от отдельных людей и команд

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

В итоге ServiceNow становится не очередным инструментом «для IT», а опорным слоем, который помогает бизнесу запускать изменения быстрее, не теряя управляемость.

Сквозные workflow: оркестрация вместо пересылки задач

Сквозной workflow — это не «цепочка тикетов», а единый процесс от первого запроса до результата и последующей обратной связи. Он включает все шаги, которые реально происходят между отделами: уточнения, согласования, ожидания, проверки, возвраты на доработку. Если процесс нельзя объяснить простым вопросом «что является готовым результатом и кто его принимает?», то он почти наверняка распадается на пересылку задач.

Как определить «сквозной процесс»

Начните с формулировки границ:

• Вход: кто и в каком виде подаёт запрос (сотрудник, менеджер, клиент, интеграция).
• Выход: что считается завершением (доступ выдан, поставка получена, изменение внедрено, инцидент закрыт и подтверждён).
• Обратная связь: подтверждение результата, оценка качества, причина отклонения, повторное обращение.

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

Принципы: меньше передач, больше прозрачности

Оркестрация заменяет ручные передачи (письма, чаты, «перекину задачу коллегам») управляемыми переходами между стадиями.

Ключевые принципы:

• Минимизация ручных передач: задача не «путешествует» по людям без контроля; следующий шаг определяется правилами и контекстом.
• Единый идентификатор: один номер процесса для всех участников и систем — чтобы не плодить «у нас это другой тикет».
• Прозрачные статусы: понятные состояния (например, «ожидаем данных», «на согласовании», «в работе», «ожидаем внешнюю систему») с измеримым временем в каждом.

Где особенно нужна оркестрация

Оркестрация становится критичной там, где много межотдельных зависимостей и «ожиданий»:

• Межфункциональные цепочки: онбординг сотрудника (HR → безопасность → IT → закупки), увольнение, запрос на доступы, обработка претензий.
• Зависимости: нельзя выполнить шаг B, пока не завершён шаг A (например, доступ нельзя выдать до проверки обучения или согласования владельца данных).
• Ожидание внешних систем и подрядчиков: поставщик не ответил, интеграция вернула ошибку, статус в ERP ещё не обновился.

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

Данные и контекст: что объединяет платформенный эффект

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

Единая модель данных вместо разрозненных таблиц

В «точечных» решениях каждая команда ведёт свои справочники и статусы: у службы поддержки — тикеты, у инфраструктуры — список серверов, у безопасности — исключения, у закупок — активы. На стыках появляется ручная сверка.

Единая модель данных позволяет связать:

• заявки и запросы пользователей;
• конфигурационные единицы (CI), активы и их владельцев;
• отношения между компонентами (что от чего зависит);
• причины инцидентов и повторяющиеся паттерны.

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

Почему важен контекст: инцидент не существует сам по себе

Контекст — это связность событий. Инцидент, связанный с недавним изменением, требует другой реакции, чем сбой «сам по себе». Когда инциденты автоматически связываются с изменениями, релизами и активами, проще:

• быстрее находить первопричину (а не лечить симптомы);
• сокращать время диагностики за счёт истории и зависимостей;
• снижать риск повторений, фиксируя, какие изменения приводят к сбоям.

Отчётность без «ручной сборки»

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

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

Управление рисками и контролем без торможения бизнеса

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

Где начинается риск

Самые дорогие инциденты обычно вырастают из мелочей:

• Неконтролируемые изменения: «поправили в проде», забыли зарегистрировать — и никто не понимает, что именно сломалось и когда.
• Доступы и привилегии: временный доступ «на час» не отзывают, права копятся, ответственность размывается.
• Интеграции и скрипты: маленькая интеграция без владельца превращается в критическую зависимость.
• Обходы процессов: «сделайте срочно, потом оформим» становится постоянной практикой.

Что нужно предусмотреть заранее

Чтобы контроль был быстрым и предсказуемым, важно формализовать базовую «гигиену»:

• Роли и зоны ответственности (владелец сервиса, владелец данных, исполнитель, согласующий).
• Политики и стандарты: какие изменения требуют согласования, какие — нет; что считается инцидентом; как классифицируются риски.
• Аудит и трассируемость: кто запросил, кто одобрил, кто выполнил, что изменилось.
• Разделение обязанностей (SoD): один человек не должен одновременно запрашивать, утверждать и исполнять критичные операции.

Как совместить скорость и контроль

Платформенный подход (например, в ServiceNow) помогает «встроить» контроль в поток работы, а не навешивать его сверху.

Ключевые механики:

• Шаблоны и типовые изменения: для повторяемых задач — заранее описанный путь без ручных согласований.
• Согласования по правилам: маршрутизация по критичности, влиянию, типу системы и уровню доступа.
• Каталоги услуг: сотрудник выбирает понятный запрос, а внутри уже работает правильная политика, проверки и логирование.

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

Типовые ошибки внедрения и как их избежать

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

Ошибка №1: «Слишком много кастомизации»

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

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

Ошибка №2: смешение конфигурирования и разработки

Типичный симптом — отсутствие стандартов: разные команды создают свои статусы, поля и маршруты. Это разрушает аналитику и сквозную оркестрацию.

Как выбирать:

• Конфигурирование — по умолчанию (формы, роли, SLA, правила маршрутизации).
• Разработка — только при явной бизнес-необходимости, с оценкой влияния на обновления.
• Стандарты — единые статусы, приоритеты, классификаторы услуг и изменений.

Ошибка №3: автоматизация хаоса

Если нет понятного каталога услуг и минимального «скелета» процесса, автоматизация ускорит не сервис, а путаницу.

Практика: начните с MVP: каталогизируйте 10–20 ключевых услуг, унифицируйте статусы (например, «Новая → В работе → Ожидает → Решена → Закрыта»), зафиксируйте минимальные шаги и метрики. Затем расширяйте по мере накопления данных и обратной связи.

Практический план: как запустить «сантехнику» и измерить эффект

Запуск «enterprise plumbing» лучше начинать не с большой программы трансформации, а с короткого цикла: найти конкретные очереди, убрать лишние ручные шаги и закрепить улучшение в виде повторяемого workflow на платформе (например, в ServiceNow). Ниже — план, который укладывается в 90 дней.

С чего начать: карта процессов и «где болит»

Соберите мини-карту 10–15 ключевых потоков работ: запросы на доступ, закупки, изменения, инциденты, онбординг/оффбординг, согласования. Важно не рисовать «идеальный процесс», а зафиксировать фактический путь задачи.

Фокусируйтесь на четырёх вещах:

• Очереди и ожидания: где задача простаивает (входящий ящик, согласование, IT-бэклог, ручная проверка).
• Владельцы: у каждого шага должен быть один ответственный, а не «коллективная ответственность».
• Цели по SLA: что считается «в срок» (например, 80% запросов за 2 рабочих дня), и что является нарушением.
• Болевые точки: дублирование данных, пересылка писем, отсутствие статуса, неясные правила приоритета.

План на 90 дней: пилот → измерения → масштабирование

Недели 1–2: выберите один поток для пилота с заметной болью и частотой (например, доступы). Зафиксируйте baseline: текущее время цикла, число касаний, процент возвратов.

Недели 3–6: настройте минимальный сквозной workflow: форма запроса, маршрутизация, согласования, шаблоны задач. Запустите простой каталог/портал, чтобы «вход» стал единым, а не через почту.

Недели 7–10: добавьте минимум интеграций (одна-две), которые дают максимальный эффект: AD/HR-система/почта/CMDB — только то, что убирает ручной ввод и ошибки.

Недели 11–13: обучите исполнителей и владельцев процесса, скорректируйте правила приоритета, подготовьте следующий поток по тому же шаблону.

Как оценивать успех: метрики, понятные бизнесу

Смотрите не на «сколько настроили», а на изменение поведения системы:

• Снижение времени цикла (lead time) и доли задач, «застрявших» в ожидании.
• Меньше ручных шагов: количество касаний/переадресаций, доля автозаполнения.
• Качество сервиса: меньше возвратов из‑за ошибок, стабильность соблюдения SLA.
• Удовлетворённость: короткий CSAT после закрытия плюс прозрачность статуса (задача понятна без звонков).

Если через 90 дней вы можете показать: «время выполнения упало на X%, ручных касаний стало на Y меньше, SLA соблюдается стабильнее», — значит «сантехника» начала работать, и её можно тиражировать на следующие процессы.

Где здесь место TakProsto.AI (и почему это дополняет платформенный подход)

ServiceNow хорош как «сквозной контур» для управления услугами, изменениями и контролем. Но в реальной жизни всегда остаётся слой задач, где нужно быстро сделать вспомогательное приложение, внутренний портал или интеграционный сервис — и именно там IT-бэклог часто раздувается сильнее всего.

TakProsto.AI можно использовать как практичное дополнение к платформенному подходу: это vibe-coding платформа для российского рынка, где web/серверные/мобильные приложения собираются из диалога в чате, а не через длинные циклы классического программирования. Это полезно, когда нужно быстро закрыть «стыки» между системами, собрать прототип для пилота, сделать внутреннюю форму/кабинет или небольшой сервис для исполнителей — с возможностью экспорта исходников, деплоя и отката через snapshots/rollback.

Отдельно важный для корпоративного контура момент: TakProsto.AI работает на серверах в России, использует локализованные и opensource LLM-модели и не отправляет данные за пределы страны — что снижает барьеры для использования в задачах, связанных с внутренними процессами и данными.

Если мыслить в терминах этой статьи, то ServiceNow «держит трубы и правила», а TakProsto.AI помогает быстрее строить и менять «ответвления» вокруг них — без постоянного роста очереди на разработку и без потери управляемости.