Журнал о системах электронного документооборота (СЭД)
Управление контентом

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

  8 комментариев Добавить в закладки

Близится новый год, а это значит, что в скором времени появится множество видеороликов и фотографий с корпоративных мероприятий – это изображения, аудио и видео файлы, которые наверняка захочется занести в свою ECM-систему под тегом «Наш корпоратив. Новый год 30-12-2015».

Управление мультимедиа контентом – это одна из задач ECM-систем. Но что подразумевается под управлением? Каковы реальные сценарии работы с мультимедиа данными?

Собрав немного статистики и опросив людей, мы составили перечь возможных сценариев:

  1. Организация альбомов с корпоративных мероприятий:
    • Массовая загрузка большого числа мультимедиа файлов.
    • Организация удобного доступа и просмотра – создание неких play-листов.
  2. Создание медиатеки компании:
    • Возможность занесения мультимедиа файлов любым сотрудником, в том числе файлов большого размера: записи презентаций, учебное видео, рекламные скринкасты и т.п.
    • Удобный поиск и навигация по материалам на основе тегов.
    • Возможность просмотра материалов стандартными средствами, в независимости от того, в каком формате они были занесены в систему. Автоматическая конвертация между форматами.
    • Обсуждение материалов - комментирование и рецензирование.
  3. Поддержка версионности и механизмов согласования, в том числе с внешним заказчиком, для официальных медиа-документов компании. К таким документам относятся: логотипы, бренд-буки, официальные видео, фото руководства, фото продукции и т.п.
  4. Хранение мультимедиа данных в большом объеме. Например, автоматическая загрузка в систему видеозаписей с камер наблюдения и навигация по ним.
  5. Автоматизация работ с маркетинговыми материалами в крупной компании, к ним относятся: ресайты, интерфейсы (иконки, экраны), web-слайды, визитки, анимированные баннеры, подарочная продукция, видеоролики и т.п.
    • Версионность, удобное согласование и рецензирование, с возможностью просмотра изменений между версиями.
    • Возможность работы с удаленными или не имеющими доступа к ECM-системе сотрудниками. Работа с фрилансерсами.

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

Ещё материалы автора
Похожие записи
Комментарии (8)
Михаил Романов 04 января 2015 г. 13:45  

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

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

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

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

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

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

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

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

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

Виктор Золотов 05 января 2015 г. 20:05  
специфику именно multimedia данных

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

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

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

 

Михаил Романов 08 января 2015 г. 09:22  
На удивление специфическая задача и потому несмотря на многообразие платформ пишем просто с нуля.

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

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

Виктор Золотов 08 января 2015 г. 13:04  
multimedia контенте, который используется внутри компании

Да, но это я к тому, что вообще на мультимедиа шире можно смотреть. У Артема кроме пункта 1.2 ничего специфического про мультимедиа то и нет. Все прочее можно отнести к любому другому типу контента.

Можно структурировать вопрос. Что относим к мультимедиа и какие типы использования есть? По типам использования: чисто потребление типовой медиаинформации и что-то профессиональное, связанное с созданием и обработкой.

В типовом случае к типам контента отнесем графику, звук и видео. И чаще всего функциональность нужна информационно-развлекательная. Тогда что нужно от системы:

  1. Быстрая, красивая и привычная доставка. С просмотром/прослушиванием прямо в браузере, например (если у нас веб-приложение). Однозначно с доступом с любых устройств. С подгонкой качества под тип канала связи. С возможностью давать ссылки на конкретный момент видео и аудио.
  2. Удобная загрузка. Не сложнее чем в facebook.
  3. Социализация. Отметки людей на фото, лайки, комментарии/рецензии и т.д. 
  4. Всякие фичи: создание коллажей (али "история за год"), минимальная обработка контента - типа инстаграмма и т.д.

В профессиональной сфере все уже интереснее. Там к мультимедиа контенту можно отнести, например: данные редакционных систем (выпуск печатных изданий, он-лайн изданий, теле-радио компаний), данные систем проектирования и дизайна (от PageMaker до верстки сайта) и т.д.

В общем, тема мультимеда не раскрыта, я считаю ).

Артём Обухов 12 января 2015 г. 16:15  

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

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

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

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

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

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

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

Виктор Золотов 12 января 2015 г. 18:07  

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

Михаил Романов 15 января 2015 г. 11:43  
Весь этот поток можно же счесть мультимедиа-данными?

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

 

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

 

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

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

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

 

Елена Питомцева 15 января 2015 г. 12:30  

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

Сейчас обсуждают
Больше комментариев