Сценарии работы с мультимедиа контентом в ECM

Откровенно говоря, Артем, специфику именно multimedia данных вы практически не раскрыли. Вы по большому счету перечислили стандартные функции ECM системы: capture, manage, store, preserve, deliver.

Из более-менее специфичного, что вытекает из ваших сценариев: большие объемы контента, массовая загрузка (но тут надо уточнять, т.к. загрузка группы документов тоже выглядит как массовая загрузка, однако здесь, как я подозреваю, имелось в виду, что у всех файлов примерно одинаковые метаданные, которые задаются разом), конвертация.

И еще, вы привели в большинстве случаев не исходные сценарии, а требуемый функционал. А для каких сценариев он требуется - не ясно (и на сколько верно выбран этот функционал - тоже поэтому не понятно). Такую практику я считаю принципиально неправильной. Вот только 1 пример:

Вы приводите сценарий "Массовая загрузка большого числа мультимедиа файлов". Но что можно извлечь из этого сценария? Только то, что кто-то загружает много файлов. Первый же вопрос (я его уже озвучивал) - а чем это отличается от загрузки группы связанных документов договор + приложения, например?

А вот если бы вы описали сценарий "Продавцы/маркетологи возвращаются с выставки и заносят в систему материалы с фотоаппаратов и видеокамер". Оооо... тут уже есть где развернуться! Что мы можем выжать из такого сценария:

• все фото/видео материалы относятся к одной группе "Выставка XXX в YYY году". Вопрос: будем ли вводить некий собирающий объект "событие" и что это будет: тэг, запись справочника, ...?
• внутри этой группы объекты могут разделяться на подгруппы: "Фотографии стендов" (возможно, нужно как-то привязать чей именно стенд изображен на каждой), "Фотографии (видео) выступлений", "Фотографии с нашего стенда", ... Вопросы: будем ли делить на такие группы, в какой момент и кто это делает (заносящий, или другие люди - участники выставки)? Будут ли эти группы соотносится с другими объектами системы (например фотографии стенда конкурента Z c записью о конкуренте Z - если таковая есть в нашей системе)? Ну и опять - как технически мы вводим такое деление (не забывая, что одно фото может относиться к нескольким объектам/понятиям).
• если видео с выступлений снималось непрерывным потоком, то нужно ли его предварительно "нарезать" (за одно выкинуть паузы между выступлениями)? Где это будем делать: в системе после занесения, во внешнем редакторе до, ... ?
• на фотографиях могут быть люди. Вопрос: будем ли мы как-то сохранять информацию о найденных персонах на фотографии (функционал дико популярный в социальных сетях, но вот так ли необходимый в корпоративной системе...)? Ну и полный спектр технических вопросов - как именно это будем делать.
• ну и т.д.

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

P.S. Ну и раз уж вспомнили про тэги. Приведенное требование про тэги явно очень поверхностное, ради интереса сравните потребности в системе тэгов блога на 30-40 сообщений в год, новостного сайта с 1000 сообщений месяц и корпорации на 20-30 тысяч сотрудников, работающую на 4 континентах (и имеющую соответствующее число локальных сотрудников).

Или даже можете взять готовые реализации - линейную систему тэгов любого популярного блого-движка (например WordPress без дополнительных плагинов) и систему тэгов, например, SharePoint (я не скажу что она идеальна, но есть как минимум понимание, почему её сделали именно такой).

Вот кстати да... Раньше я особенно не вникал в тему, но последние месяцы, волею судеб, я куратор проекта в нашем главном информационном агентстве. В целом разрабатывается редакционная система - от планирования освещения, до доставки информации (естественно и медиаинформации) до потребителей. Наш кусок - это планирование освещения событий, сбор сведений и т.д. (все до формирования информационного выпуска). На удивление специфическая задача и потому несмотря на многообразие платформ пишем просто с нуля. 

• Таксономия хранилища. Например тэгирование по персонам, локациям, событиям, темам и т.д. Причем это гибко должно быть, журналисты люди творческие...
• Даты и время имеют значение. Фотография катастрофы сделана в 9 часов. Но по какому поясу? Надо учитывать что журналист оперирует местным временем, редакция в Москве по Москве. При этом даже секунды, когда сделана запись, имеет значение чтобы быть информация попала в различные версии инфолент в нужные позиции.
• Скорость работы. Причем дело не столько в технической части, сколько в организационной. Конкуренция идет за секунды. И если журналист будет как-то нелепо оценивать фото для отправки в редакцию, информация станет просто устаревшей. Отсюда куча требований к простоте управления. Например, чтобы вводить теги делается одно поле, в нем просто вводим текст и отображается набор вариантов (иконками идентифицируется тип). Как то так: "медведев сочи олимпиада", довольно точно определяем персону, локацию и тему, три клика пальцем на планшете и готово. 
• Всяческие конвертеры и упаковщики. Медиаинформация продается. И, например, чем выше качество фото, тем дороже оно стоит. Так что в зависимости от биллинга надо отдавать клиентам разные форматы информации. При этом надо думать и оценивать какие форматы наиболее востребованные и заранее проводить конвертацию и кэширование, иначе накроется  техническая часть.

Много всего еще, тема очень интересная...

Ну у вас, Виктор, и правда не самая распространенная ситуация. Вы по сути продаете контент, причем специфический. Сомневаюсь, использование платформ, которые ориентируются, по большей части, на автоматизацию работы с внутренними документами, вам могло бы чем-то помочь.

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

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

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

Просмотр видео-записей (вебинары, доклады) с любого устройства в любом месте (медиатека компании):

• в компании есть множество видеороликов, все они хранятся в ECM-системе при этом они имеют различный формат, разрешение и значительный объем, что делает проблематичным полное скачивание файла, например, на мобильное устройство. Следовательно, тут не обойтись без медиа-сервера, который бы осуществлял конвертирование в универсальный формат (+несколько разрешений под разные экраны) и потоковую передачу видео по сети. Хорошая стартовая точка - это посмотреть как работает youtube.
• пользователь наверняка захочет оставить комментарий к определенному моменту ролика, и вот у нас уже есть текст, временная метка и количество like-ов - которые нужно где-то хранить.
• необходимы механизмы навигации и поиска, причем для этого может использоваться 4 вида мета-информации: прикладные метаданные электронного документа (вид документа, принадлежность к проекту/событию, автора, дата создание, теги и т.п.), технические метаданные видео-файла (разрешение, длительность, формат), приобретенные (комментарии) и извлекаемые (текст субтитров, преобразовать звук в текст, изображение в текст). Этот вопрос раскрывается при занесения видео-файла в систему.
• механизм комментирования можно применить не только для "социализации", но и для рецензирования (для видеороликов, которые этого требуют), разграничивая при этом права доступа (скрытые комментарии).
• следует отметить что видеофайлы, как правило, редко хранятся в РСУБД, для этого используются распределенные файловые хранилища (DFS) и тут необходимо подробнее рассмотреть работу с версионностью.

Согласование макетов и эскизов нового интерфейса с внешним дизайнером (аутсорсинг)

• у дизайнера нет прямого доступа к ECM системе заказчика, при этом хочется что бы весь процесс рецензирования происходил внутри системы. Тут два пути, либо мы создаем отдельного пользователя в системе, что априори не очень хорошо, так как появляются проблемы с безопасностью, либо организуем "гостевой" доступ через определенный транспорт. Это может быть обычная почта (создание элементов workflow для рецензирования на основе почтовых сообщений) либо какой-то свой протокол и отдельное приложение или плагин к редактору (например, к photoshop).
• ещё один вопрос - это хранение истории рецензирования, тут так же есть несколько путей: упаковываем все в какой-нибудь pdf и оставляем комментарии там или храним комментарии отдельно в своей базе в структурированном виде. Второй вариант выглядит предпочтительнее, но и сложнее в реализации.
• работа с версиями. В ECM-системе должны создаваться отдельные версии после каждой итерации рецензирования, при этом важно, чтобы дизайнер имел к ним доступ.
• документов для рецензирования может быть множество, например 100 иконок или 20 вариантов одного интерфейса. Важно создать удобный механизм предпросмотра, который бы позволил оценивать несколько изображений на одном экране, сравнивать их между собой. Комментарии должны привязываться не к файлу, а к конкретному месту/области на изображении (координаты).

Если у вас есть ещё какие-то интересные сценарии или соображения, то обязательно пишите.

А вот кстати к вебинарам, можно ли вообще отойти в рамках СЭД он "атомарного" представления контента? Если тот же вебинар ретранслировать через ECM? Ну например тут же комментировать, обсуждать, делать заметки, использовать "белую доску". Ясно что есть Линк и уже с ним, но я в целом. Как минимум ECM свой вклад внести может. Весь этот поток можно же счесть мультимедиа-данными? 

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

А вообще вы, Виктор, подняли попутно сразу 2 важных вопроса

• как хранить и обрабатывать композитный/составной контент в СЭД? Я вот, еще ни разу не видел приличного общего решения, только некоторые специальные частные случаи для конкретного сценария.
• нужно ли реально "затаскивать" в единую систему весь контент, генерируемый на предприятии или лучше оставлять этот контент в той системе, которая лучше с ним работает?

Просто для примера (наверное, это уже злостный оффтоп, да простит меня Артем, но раз уж начал мысль - надо завершить) - вновь набирающие популярность LMS (lerning management system). Каждый курс в такой системе это совокупность кучи разного контента: презентации, материалы для самостоятельного изучения (например, примеры кода или руководства по лабораторным), записи видео, тесты для контроля (скорее всего в каком-то структурированном виде). А еще и куча разных структурированных данных: списки "студентов", результаты, ...

И вот вопрос - если LMS реализует уже полный workflow работы с таким контентом, то надо ли вообще дублировать этот контент в СЭД?

Я считаю, что LMS в этом слуаче будет частью ИС предприятия, как и, например, KMS-системы, о которых были материалы в декабре. Другое дело, насколько нужен будет общий поиск, как будут интегрированы разные системы и т.д.. Это вопрос общей политики управления контентом.