/13267796/i_800.jpg)
Компании редко начинают цифровизацию с глобальной стратегии. Чаще всего отправной точкой становится конкретная «боль»: договоры согласовываются слишком долго — значит, нужна система электронного документооборота (СЭД); поддержка пользователей хаотична — требуется платформа для сервис-деска; выполнение многочисленных рутинных операций не дает персоналу сфокусироваться на сложных, интересных задачах, движущих компанию вперед, — пора внедрять искусственный интеллект.
На этом этапе задача выглядит понятно: выбираем продукт, внедряем, получаем результат. Такое представление о коробочном решении живет ровно до того момента, как оно попадает в реальную корпоративную среду — и вместе с этим на первый взгляд простая задача трансформируется в комплексный проект.
Что скрывается за интерфейсом корпоративного приложения
Практически любое бизнес-приложение на рынке позиционируется как самодостаточное. Но в корпоративной среде довольно быстро выясняется, что за интерфейсом и функциональными модулями бизнес-приложения скрывается по крайней мере семь обязательных слоев архитектуры, без которых оно либо не заработает, либо быстро превратится в источник проблем.
Первый слой, о котором часто забывают, — инфраструктура. Приложению нужны серверы, виртуализация, сети, системы хранения данных (СХД). Старые мощности могут не выдержать возросшую нагрузку — в этом случае система потеряет производительность и доступность при пиковых запросах.
Второй слой — интеграции. Новая СЭД должна обмениваться документами с ERP, CRM — получать справочники из учетных систем, сервис-деск — подтягивать структуру подразделений из HR-контура. Без спроектированной заранее архитектуры обмена приходится использовать «костыли»: ручные выгрузки в Excel, промежуточные базы, скрипты, которые написали «под задачу» и забыли задокументировать. И когда накапливается критическая масса таких «временных решений», система перестает быть предсказуемой.
Третий слой — информационная безопасность. Любое приложение, работающее с персональными данными, коммерческой тайной или финансовыми операциями, обязано соответствовать внутренним политикам и требованиям регуляторов. Нужно проработать модель доступа, настроить журналирование, подключить системы сбора событий (SIEM) и предотвращения утечек (DLP), а нередко — еще и многофакторную аутентификацию. Если вопросы безопасности начинают решать уже после выбора бизнес-приложения, проект рискует упереться в аттестацию по ФСТЭК, доработку инфраструктуры и пересмотр архитектуры. В результате внедрение затянется на месяцы.
Четвертый слой — организационные процессы и люди. В enterprise-проектах заказчик обычно формирует центр компетенций — команду аналитиков, разработчиков и архитекторов, которая будет развивать решение внутри компании. Подготовка таких специалистов может занимать месяцы и включать профессиональную сертификацию. Отдельной задачей остается обучение пользователей. Без него новое решение рискует остаться невостребованным — люди будут по привычке дублировать данные в почте, согласовывать документы в мессенджерах и вести «свою» аналитику в таблицах.
Пятый слой — управление данными. Даже идеальная система не даст результата, если она оперирует некачественными данными. Типичный пример: продавцы по-разному заполняют карточки контрагентов, и в отчетах для финансового директора один и тот же клиент появляется под разными названиями. ИИ, обученный на таких данных, будет выдавать правдоподобные, но совершенно недостоверные ответы.
Шестой слой — технологическая стратегия. Для проектов с ИИ это критично вдвойне: интеллектуальный бот или агент требует фундамента из правильно структурированных данных, продуманной архитектуры их хранения и вычислительных мощностей (например, серверов с GPU). Но прежде чем закупать «железо» и разворачивать модели, нужно ответить на стратегический вопрос: зачем это бизнесу и как решение будет развиваться в ближайшие 3–5 лет? Именно стратегия определяет все остальное — от выбора платформы до бюджета на развитие.
Однако даже самая продуманная стратегия бесполезна без регулярной поддержки. Седьмой слой — эксплуатация и развитие. Системе нужны обновления, резервное копирование, тестовая среда, мониторинг и четкий порядок реагирования на инциденты. Если этого нет, любой сбой рискует обернуться остановкой бизнес-процессов.
Как многослойная архитектура проявляется в реальных проектах
Разберем два показательных кейса, которые иллюстрируют комплексную природу современных проектов.
Первый пример — внедрение системы для конфиденциального делопроизводства. С виду рядовая задача: поставить СЭД, настроить маршруты согласования. Но специфика в том, что документы содержат коммерческую тайну. Это автоматически означает работу в закрытом контуре.
Контур нужно выстроить, «обвязать» средствами защиты информации и, что не менее важно, внедрить строгие регламенты доступа: кто, когда и с какими правами может входить в систему. Без этого проект невозможен в принципе.
Однако технической изоляции недостаточно. Во-первых, требуется содержательная классификация: каждому документу должен быть присвоен гриф конфиденциальности — коммерческая тайна (КТ), служебная тайна (ДСП) или секрет производства (ноу-хау). Сами данные при хранении и передаче необходимо шифровать. Во-вторых, сотрудник обязан подтвердить, что осознает уровень ответственности. Для этого перед открытием документа система должна выводить дисклеймер с требованием подтвердить отсутствие рядом третьих лиц — и только после этого предоставлять доступ к содержимому.
Второй, более сложный пример — создание корпоративного электронного архива. На поверхности задача выглядит как оцифровка бумажных документов. Но на практике это целый каскад взаимосвязанных этапов.
Стартует проект с ретроконверсии: промышленные сканеры переводят бумагу в цифру, затем с помощью распознавания из документов извлекаются ключевые атрибуты (даты, номера, контрагенты), и карточки электронных документов заполняются автоматически. Далее документы нужно разместить в системе хранения. Но архив не существует сам по себе — его требуется интегрировать с ERP, где живут данные о закупках, отгрузках и финансах. Чтобы связка работала, справочники синхронизируют и приводят к единому формату. В профессиональной среде этот этап называют нормализацией нормативно-справочной информации.
Когда массив документов достигает критических объемов, возникают новые требования к инфраструктуре: нужны серьезные СХД и вычислительные мощности. А если бизнес хочет получить умный поиск по архиву или автоматическую обработку входящих, в дело вступает искусственный интеллект. Под большую языковую модель, как правило, требуются специализированные серверы с GPU, причем с правильным «сайзингом» — чтобы не переплачивать за избыточную мощность и не попасть в ситуацию, когда ее не хватает.
Почему комплексный проект выходит за рамки сроков
Ошибки на одном из уровней архитектуры редко видны сразу. На старте все выглядит хорошо: есть бюджет, команда, одобрение руководства. Проблемы накапливаются постепенно, проявляясь на стыках слоев.
Например, выясняется, что мощности не рассчитаны на одновременную работу тысячи пользователей. Интеграция с ERP оказывается сложнее, чем думали, потому что в ней за десятилетие накопились десятки неактуальных справочников. Служба безопасности выставляет требования, о которых бизнес не предупреждали. Пользователи саботируют новую систему, потому что их не научили с ней работать.
Проект начинает распадаться: появляются дополнительные задачи, растут бюджеты, сроки сдвигаются на полгода, а то и на год. Руководство теряет веру в цифровизацию, хотя продукт сам по себе был выбран верно.
Архитектурный подход как стандарт
Опыт крупных внедрений подсказывает другой, более надежный подход: не подбирать архитектуру под продукт, а проектировать решение целиком, понимая его многослойную структуру. Это требует больше усилий на старте, но кратно сокращает риски на последующих этапах.
Сначала анализируются бизнес-процессы, определяются узкие места и точки роста. Потом проектируется архитектура: где будут жить данные, как распределится нагрузка, какие потребуются мощности и как обеспечить отказоустойчивость. Затем прорабатываются интеграции со смежными системами. И только после этого выбирается конкретный продукт, который должен реализовать заложенную логику. В этой модели приложение не центр вселенной, а один из элементов – важный, но не единственный.
С чего на самом деле начинается внедрение
В этом контексте особенно актуальна старая поговорка в современном прочтении: семь раз «отмерь» архитектуру, один раз «отрежь» — внедри приложение.
Перед стартом любого серьезного ИТ-проекта, особенно связанного с ИИ или чувствительными данными, стоит провести стратегическую сессию с участием всех вовлеченных сторон — от продаж и финансов до ИБ и ИТ-эксплуатации и пройти по чек-листу:
- Оценены ли требуемые мощности и достаточно ли текущих ресурсов?
- Проработаны ли сценарии обмена данными со смежными системами?
- Учтены ли требования к защите данных в соответствии с их категорией?
- Определен ли порядок обучения сотрудников и обновления регламентов?
- Проанализировано ли состояние данных, подготовленных к загрузке?
- Заложена ли возможность масштабирования системы на горизонте 2-3 лет?
- Закреплена ли ответственность за поддержку и обновление системы после запуска?
Потратив время на проработку архитектуры, можно сэкономить в десятки раз больше на этапе внедрения и эксплуатации. Тогда бизнес получит не просто установленное приложение, а устойчивую цифровую конструкцию, которая будет работать, развиваться и приносить реальную пользу.
Автор – Кирилл Александров, руководитель направления продаж комплексных бизнес-решений «Софтлайн Решения» (ГК Softline)
