Задача
До платформы файлы приходили в типографию по разным каналам и хранились у клиентов и менеджеров разрозненно, а готовность макета к печати проверял специалист SCG вручную. Любая ошибка — неверный цветовой профиль, недостаточное разрешение, отсутствующий вылет, незагруженный связанный ресурс — обнаруживалась только после передачи файла в производство и запускала новый круг переписки.
Коммерческая часть жила отдельно от самих материалов. Клиенту приходилось объяснять менеджеру, какой именно файл нужно печатать, отдельно передавать параметры заказа и отдельно разбираться со счётом. Когда у клиента несколько брендов, у макета несколько версий, а в согласовании участвуют несколько человек, главный риск становится вполне конкретным: в печать уходит неактуальный файл, и это выясняется после изготовления тиража.
Решение
Изолированные клиентские пространства. Платформа мультитенантная: клиент видит только собственную библиотеку, пользователей, заказы, договорные условия и финансовые документы. Внутри организации доступ делится по брендам, подразделениям, папкам и действиям. Для каждого клиента в админке задавались способ расчёта, предоплата или постоплата, порядок выставления счетов, набор доступных услуг и права сотрудников — и применялись автоматически, а не восстанавливались менеджером из переписки при каждом заказе.
Библиотека с настоящими версиями. DAMS поддерживал рабочие форматы печатного производства — изображения, PDF, PSD и другие дизайн-документы — и давал привычную файловую модель: папки по брендам и кампаниям, загрузка крупных файлов и пакетный импорт, превью, поиск по названию и метаданным, теги и атрибуты, скачивание набора, корзина выбранных активов, история операций. Ключевое здесь — версии: связь между исходником и утверждённым вариантом сохранялась, а для производственной передачи фиксировалась конкретная версия. Последующая правка исходника не подменяла уже согласованный тираж.
Редактирование внутри библиотеки. В DAMS встроен Adobe-ориентированный контур редактирования: PSD или другой дизайн-документ открывался прямо из библиотеки, а результат сохранялся обратно новой версией. Экран объединял холст, страницы, слои, изображения, свойства выбранного элемента и комментарии участников — макет не приходилось пересылать между сервисами, чтобы поправить текст или цвет. Делиться файлами и папками можно было с коллегами и внешними участниками: контролируемая ссылка, срок доступа, запрет лишнего скачивания, отзыв выданного доступа. Действия с материалом и решения согласующих попадали в журнал.
Автоматический preflight. Это главная функция продукта: проверку технической готовности файла, которую раньше делали руками специалисты SCG, перенесли в клиентский поток. После загрузки или сохранения новой версии система анализировала файл по профилю выбранной печатной услуги — размеры страницы и соответствие формату изделия, разрешение растровых изображений, цветовой режим и профиль, вылеты, безопасную область и обрезной формат, встроенные и отсутствующие шрифты, связанные изображения и недостающие ресурсы, прозрачности и особенности экспорта, количество страниц и целостность файла, допустимый тип и версию формата.
Результат намеренно не сводился к одному техническому сообщению. Клиент видел, какие условия выполнены, какие замечания носят предупредительный характер и что именно блокирует отправку в печать, а для каждой проблемы получал понятное действие: заменить изображение, догрузить ресурс, изменить настройки или переэкспортировать макет. После исправления новая версия проверялась заново, и только версия, прошедшая обязательные правила либо явно принятая уполномоченным специалистом SCG, переходила в состояние ready for print. Профили настраивались по типам продукции, а каждое исключение фиксировалось в аудите.
Заказ прямо из карточки актива. Проверенный файл превращался в заказ на месте: клиент задавал формат или размеры, количество, материал и отделку. В коммерческий объект попадали print-ready версия файла, конфигурация продукта, тираж, клиент и автор заказа, применённые договорные и ценовые правила, результаты preflight и согласования, связанные комментарии и документы. Обрабатывала заказы Magento — корзина, коммерческие правила, статусы, — но клиент оставался в специализированном интерфейсе DAMS. Интеграционный слой не создавал второй заказ при повторной отправке запроса и возвращал в кабинет актуальное состояние обработки.
Два жизненных цикла вместо одного. Макет и заказ имели связанные, но разные состояния: файл мог быть рабочим, ожидать проверки, иметь замечания, проходить согласование или быть готовым к печати, а заказ появлялся только после выбора подходящей версии и дальше шёл своим циклом — черновик, подтверждение, передача в производство, исполнение, завершение. Уведомления сообщали о новых комментариях, необходимости исправить файл, запросе согласования, смене статуса и появлении финансового документа.
Документы и бухгалтерия. Финансовый сценарий зависел от договора: предоплата у одних, постоплата и периодический счёт у других. Система учитывала это при создании заказа, привязывала строки счёта к конкретным работам, объединяла выполненное за месяц в итоговый инвойс, передавала данные в бухгалтерию и сверяла статусы. Уже применённые условия сохранялись вместе с заказом, поэтому изменение договора не пересчитывало задним числом подтверждённые работы.
Результат
Вместо разрозненных файлов, ручного preflight и заказа через менеджера SCG получила единый клиентский сервис. Клиент хранит и готовит материалы, видит технические проблемы до передачи в производство, выбирает проверенную версию, заказывает печать и получает документы в одном пространстве.
Специалисты типографии переключились с рутинной первичной проверки на исключения и производственный контроль, а история решения — кто согласовал, какая версия ушла в печать, по каким правилам посчитан заказ — сохраняется вместе с активом. Операционный дашборд показывал готовность файлов, активные работы, документы и заявки, ожидающие действия клиента или SCG, а администраторы отдельно видели сбои интеграций.
