Skip to content
RiverCore
Пожарная служба Западного Мидленда отказалась от собственной разработки в пользу SaaS
SaaS build vs buyfire service softwarepublic sector platformswest midlands fire service prevention softwarereplacing in-house software with SaaS

Пожарная служба Западного Мидленда отказалась от собственной разработки в пользу SaaS

2 май 20268 мин. чтенияJames O'Brien

Каждая инженерная организация рано или поздно получает в наследство здание, которое не проектировала: скрипящую внутреннюю систему, начинавшуюся как изящный обходной путь и превратившуюся в несущую инфраструктуру, которую никто не решается трогать. Пожарная служба Западного Мидленда (WMFS) только что решила снести свою и переехать в меблированную квартиру. Всем, кто управляет платформой в госсекторе — или любой платформой с десятилетним самописным CRM в подвале — стоит прочитать этот материал внимательно.

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

В чём проблема

WMFS — не маленькая организация. Как сообщает International Fire & Safety Journal, служба проводит более 20 000 визитов «Safe and Well» в год и обучает безопасности более 30 000 детей. Это серьёзный объём планирования, фиксации рисков, последующего сопровождения и отчётности по результатам — причём всё это происходит в жилых комнатах и школьных залах, а не за офисным столом.

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

Эмили Фернандес, заместитель директора по профилактике WMFS, охарактеризовала переход как оптимизацию процессов и предоставление командам более совершенных инструментов. Читая между строк, можно увидеть изменившиеся ограничения. Подход mobile-first — теперь базовое требование для любой полевой команды. Офлайн-сбор данных — это ожидание, а не пожелание. Интеграция с Microsoft 365, SharePoint и инструментами управления идентификацией вроде Entra ID — всё больше становится стандартным фундаментом IT британского госсектора, и самописное .NET-приложение 2014 года вряд ли могло угнаться за этим без значительных усилий.

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

Варианты выбора

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

Дверь первая: пересборка in-house на современном стеке. Взять накопленные доменные знания, перенести на Azure или AWS, добавить React Native на фронте — и дело сделано. Соблазнительно, особенно когда есть команда, которая уже понимает рабочий процесс. Ловушка — та, которую каждый CTO в итоге познаёт: первые 80% занимают год, последние 20% — пять лет, и к тому моменту, как вы выпускаете функцию загрузки фото, смартфоны успели обновить ОС дважды. Для пожарной службы, чья основная миссия — не писать программы, это почти всегда плохая ставка.

Дверь вторая: коммерческое готовое решение, вертикально-специализированное. Именно это выбрала WMFS. Платформа Prevent + Protect от LearnPro Group создана специально для пожарных и спасательных служб, работает на Microsoft Azure и интегрируется с сервисами Microsoft 365, включая SharePoint Online и Entra ID. Она использует no-code-конфигурацию, так что служба сама может настраивать типы задач, анкеты и систему оценки без заведения тикета в Jira. Рассел Вуд, руководитель LearnPro по рынку UK FRS, назвал WMFS «одной из крупнейших и наиболее инновационных служб в стране» — такие цитаты обычно пролистывают, но они важны: вертикальный SaaS живёт и умирает своими референсными клиентами.

Дверь третья: горизонтальная платформа плюс масштабная кастомизация. Взять Salesforce или Dynamics 365, надстроить профилактические рабочие процессы поверх, интегрировать со всем остальным. Этот вариант всегда выглядит великолепно в презентации для закупок и обычно обходится дороже первой двери. Горизонтальные CRM мощны, но разрыв между «поддерживает пользовательские объекты» и «знает, что такое визит Safe and Well» оплачивается по консалтинговым дневным ставкам. Для рабочего процесса настолько специфичного, как профилактика пожарной безопасности в сообществах, вы по сути финансируете вендора, чтобы тот строил для вас вертикальный SaaS — и делал это плохо.

Матрица компромиссов здесь не требует тонкого анализа. Первая дверь даёт контроль и вечный счёт за поддержку. Третья даёт знакомую платформу и зависимость от консалтинга. Вторая даёт скорость и проблему vendor lock-in. WMFS явно решила, что lock-in — меньшее из зол, и я бы сказал, что они правы — при условии, что в контракте прописаны зубастые положения о переносимости данных.

Что инженерным командам делать на практике

Если вы руководите платформой в iGaming, fintech или ad-tech, урок применим в общем виде. Вопрос не в том, строить или покупать абстрактно. Вопрос в том, является ли автоматизируемый рабочий процесс вашим конкурентным преимуществом или операционной «сантехникой».

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

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

Второе: когда вы выходите на рынок, придавайте большой вес архитектурным основам. Cloud-native и mobile-first — в данном контексте не маркетинговые слова. Это разница между системой, которая переживёт следующие пять лет смены устройств и ОС, и той, которой потребуется переписывание через три. Офлайн-возможности платформы Prevent + Protect, планирование маршрутов и поддержка загрузки фото и файлов — именно те скучные, но необходимые функции, которые внутренняя команда откладывала бы годами.

Третье: настаивайте на no-code-конфигурации. Главная причина, по которой внутренние системы создаются, — коммерческие альтернативы требовали разработчика для изменения выпадающего списка. Современный вертикальный SaaS в значительной мере закрыл этот разрыв. Если вендор не может показать вам в демо, как не-разработчик меняет рабочий процесс в реальном времени, — уходите.

Подводные камни и граничные случаи

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

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

История интеграции с Microsoft 365 выглядит аккуратно на слайде. SharePoint Online и Entra ID — хорошо проторённая дорожка, но детали — наследование разрешений, гостевой доступ, политики условного доступа — могут превратить двухнедельную интеграцию в двухквартальную. Подключайте команду по идентификации до подписания контракта, а не после.

SMS-петли обратной связи со ссылками на персонализированные анкеты — умно, но это кошмар для обучения антифишингу, который ещё только ждёт своего часа. Тот же механизм, что позволяет WMFS измерять эффективность вмешательств, выглядит идентично smishing-схемам, от которых каждая служба безопасности учит граждан защищаться. Выбор домена, брендирование ссылок и формулировка сообщений важны здесь больше, чем инженерные решения.

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

Ключевые выводы

  • Замена WMFS внутреннего ПО для профилактики на Prevent + Protect от LearnPro — наглядный пример того, как государственная организация решает, что операционная «сантехника» должна быть в вертикальном SaaS, а не в самописной кодовой базе.
  • Cloud-native и mobile-first архитектура с офлайн-возможностями и интеграцией с Microsoft 365 через SharePoint Online и Entra ID — теперь реалистичный базовый стандарт для любой платформы полевых сотрудников.
  • No-code-конфигурация типов задач, анкет и системы оценки — именно та функция, которая исторически толкала организации к самостоятельной разработке. Современный вертикальный SaaS в значительной мере закрыл этот разрыв, и она должна быть обязательным требованием в любом RFP.
  • Миграция данных, интеграция идентификации и SMS-паттерны обратной связи — три места, где внедрения чаще всего дают сбой. Планируйте их явно, а не открывайте для себя по ходу.
  • Решение «строить или покупать» — это на самом деле вопрос о том, является ли рабочий процесс вашим преимуществом или вашей сантехникой. WMFS ответила на него правильно. Большинству инженерных команд в регулируемых отраслях стоит задать себе тот же вопрос в этом квартале.

Вернёмся к зданию, с которого начали. WMFS не просто съехала из скрипящего дома — она подписала договор аренды меблированной квартиры, где вынесен мусор и уже работает Wi-Fi. Это обмен автономии на скорость, и для службы, чья реальная миссия — обеспечивать безопасность людей, а не поддерживать планировщики, это правильный обмен. Остальным из нас, сидящим на собственных стареющих внутренних инструментах, стоит хотя бы пройти мимо нового здания и сделать заметки.

Часто задаваемые вопросы

В: Почему пожарная служба заменяет собственное ПО на коммерческий SaaS-продукт?

Внутренние системы, созданные много лет назад, накапливают технический долг и с трудом соответствуют современным требованиям: mobile-first дизайн, офлайн-возможности, интеграция с системами управления идентификацией. Для рабочих процессов, не являющихся конкурентным преимуществом, вертикальный SaaS вроде Prevent + Protect от LearnPro, как правило, обеспечивает более высокую скорость появления функций и меньшие долгосрочные затраты на поддержку по сравнению с самописной кодовой базой.

В: Что cloud-native и mobile-first реально означают для полевых рабочих процессов?

Cloud-native означает, что платформа изначально создана для работы на инфраструктуре вроде Microsoft Azure с эластичным масштабированием и управляемыми сервисами, а не перенесена с on-prem-приложения. Mobile-first означает, что основной интерфейс рассчитан на телефон или планшет в полевых условиях: офлайн-сбор данных, планирование маршрутов, работа с функциями устройства — камерой и загрузкой файлов — без постоянного подключения к сети.

В: Каковы главные риски при переходе с самописной внутренней системы на вендорский SaaS?

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

JO
James O'Brien
RiverCore Analyst · Dublin, Ireland
ПОДЕЛИТЬСЯ
// RELATED ARTICLES
ГлавнаяРешенияПроектыО насКонтакт
Новости06
Дублин, Ирландия · ЕСGMT+1
LinkedIn
🇷🇺RU