Версионность документов в приложении к визуальному контенту
Версионность документов в приложении к визуальному контенту
Насколько можно понимать современные тенденции, в ECM-системах считается моветоном НЕ поддерживать версионность документов.
Версии отражают состояние документа на различных стадиях его жизненного цикла, позволяют отследить эволюцию документа: как проект нового изделия пришёл из состояния «Во мне миллиард страниц, и на каждой приводится по 4 варианта решения каждой микроскопической задачи, из которых вам, уважаемый рецензент, нужно выбрать наиболее верное» в состояние «Я хороший проект нового изделия. Во мне всё правильно, логично и красиво». Версии дают нам возможность в дальнейшем вернуться к тому, на какой стадии было принято некое спорное решение, каким образом оно аргументировалось, какие размышления привели к его принятию. Версии позволяют показать, например, удачное завершение сделки, если одной из версий договора является его скан-образ с живой подписью и печатью.
Очень поддерживаю выделение версий текстового контента, однако, что делать с контентом визуальным? Как правильно организовать работу с визуальным контентом в условиях поддержки ECM-системой версионности документов?
Допустим, некий Василий Пупычев вот уже 50 лет работает в одной и той же фирме, понятно, что с течением времени его внешний вид изменяется, и по фотографии 20-летнего юнца мы с трудом сможем опознать вот уже 70-летнего Василия. Поэтому Василию, скорее всего, придётся временами обновлять своё фото, которое отображается, например, в разделе сотрудников на корпоративном портале. И вот вопрос: фотография Василия в 70 лет – это уже другой документ или версия документа с фотографией Василия в 50 лет? Думается, что если это фотография для портала, то, скорее всего, версия, ведь она какбе отражает жизненный цикл… в данном случае, Василия. Но с другой стороны, правильно ли перетирать 70-летним Василием Василия 50-летнего, ведь обычно всех интересует последняя версия и 50-летнего вообще никто смотреть не будет, если это будет не последняя версия?
Фотографии одного и того же здания в один и тот же день и примерно в одно и то же время с фасада и с торца – это разные документы или версии одного документа?
Портретная фотография и фотография в полный рост одного и того же человека, сделанные в ходе одной и той же фотосессии – это разные документы или версии одного документа? А если они были сделаны в разных фотосессиях, но участвуют только совместно в неком конкурсе, которая проводит компания, это версии или отдельные документы?
Быть может, для визуального контента повсеместно нужен какой-то иной механизм работы. Ведь для изображений, в отличие, от текстовых документов каждая последующая версия равнозначна любой предыдущей, и «последняя» не всегда значит самая «актуальная» (как, например, в случае со зданием). Поэтому ECM-системе, на мой взгляд, нужно уметь отделять визуальный контент от любого другого и предлагать иной способ взаимодействия с ним. Такой, который позволит, во-первых, избежать безумного разрастания количества документов в системе с появлением новых фотографий, во-вторых, не заставит пользователя рассуждать, какая из фотографий актуальнее, чтобы она в документе последней версией, ну и наконец, в-третьих, просто сделает и поиск изображений, и саму жизнь проще и красивее.
Комментарии 16
На мой взгляд, здесь имеет место подмена понятий. Для текстовых документов речь идет об изменении содержания со временем, а для графических почему-то упоминается "Портретная фотография и фотография в полный рост одного и того же человека" или "Фотографии одного и того же здания ... с фасада и с торца". Для корректности сравнения надо вспомнить что и текстовые документы почти никогда не существуют поодиночке и часто некоторое заявление на льготу неотделимо, например, от анкеты заявителя, а проект нового изделия от маркетингового исследования и расчета экономического эффекта. Конечно, текстовые документы можно "склеить" в один документ, но это усложнит поиск и... отслеживание изменения документа со временем, т.е. формирование новых версий.
Поэтому предлагаю не путать понятия "версии документа", отражающие изменение содержания документа со временем и "комплект документов", т.е. совокупность взаимосвязанных документов в данный момент времени. В этом случае фотографии Василия Пупычев в разные годы его жизни - это версии документа, а вот фотографии здания со всех ракурсов - это комплект. Иными словами основным критерием является время.
Теперь попробуем добавить ко времени еще одно изменение - формат документа. Кто сказал, что текстовый документ - это не графический документ? Текстовый документ может существовать в исходном, редактируемом виде, в PDF для публикации на сайт, в отсканированом, с "живыми" подписями и печатями контрагента и т.п. И это все один документ в один момент времени с одним текстом но в разных форматах. Вроде и не комплект, но и не версии. Кто-то в этом случае вводит понятия версий и подверсий, мажорных и минорных версий, древовидную структуру версий...
А дальше все становится еще интереснее, т.к. предстоит ответить на вопрос, а как удобнее это реализовать? Например, комплект (использую термин, который описал выше) фотографий удобнее просматривать в едином окне, перелистывая их друг за другом или в режиме слайд-шоу, а не открывая каждое изображение двойным кликом мыши на документе. А вот комплект текстовых документов, как правило, враз весь просматривать не требуется, достаточно открыть в каждый конкретный момент лишь один текст из комплекта. А комплект документов разного формата (где заявление на льготу соседствует со сканами паспорта и пенсионного свидетельства, например)?
Следующим шагом в размышлениях будет вопрос о версии комплекта :-) Приведу пример: допустим мы хотим получить кредит на любые цели. Надо подготовить десяток-другой документов. Подготовили, распечатали, подали в банк, получили кредит, расплатились, получили хорошую кредитную историю. Проходит время. Возникла потребность в новом кредите в том же банке на те же цели. Половина документов от старого комплекта подходит без изменений (сканы паспорта, справка о составе семьи и пр.), остальные документы требуют лишь незначительных изменений (прописать другие даты в заявлениях, указать новую сумму, внести сведения о своей положительно кредитной истории от прошлого кредита и т.п.). Вот как тут быть? Создавать копии каждого документа из комплекта и прервать связь документа со своим предком или же удобнее было бы создать версию комплекта в целом, внеся в некоторые документы этой версии комплекта требуемые изменения?
В общем к вопросам поставленным в записи блога я добавил еще несколько, дабы решать задачу комплексно.
Меня переполняют эмоции, постараюсь быть максимально сдержанным, заранее извините, если кого случайно обижу.
Ольга, крайне рекомендую вам еще раз разобраться в жизненных циклах документов, а также определиться с понятиями документ/record(s), проект документа,представление и версионность и на каком этапе жизненного цикла последнее имеет место быть. Почитайте пожалуста стандарты MoReq, ISO 15489 (обе части), многочисленные послы на данную тему в форуме Docflow и PCWEEK (Колесов), блог коллег из Documentuma "Как переводить слово record" http://my-documentum.blogspot.com/2010/11/record.html, "Управление документами и управление записями – найдем 6 отличий" http://my-documentum.blogspot.com/2010/11/6.html Если бы идеи озвученные в данной статье мне выдал мой студент на экзамене по ECM, он получил бы неуд и пошел на допсу, т.к. это основные термины и понятия ECM и они даются на первых занятиях.
Едем дальше по порядку.
Скан-образ с «живой» подписью и печатью не является одной из версий документа. Это запись (record), неизменный документ, подтверждающий факт заключения сделки. Даже если что-то и будет меняться, то только в допниках, или на крайнем случае договор подменится и переподпишется.
Пример с фотографиями Василия вообще эзотерически выносит мозг. Вы хотите сказать, что Василий в 20 лет по его содержимому (контенту) = Василий в 70 лет? Или человек в 20 лет и он же в 50 — это просто версии одного и того же субъекта. Даже если бы Василий все это время пролежал в коме и практически не изменился, у данных субъектов и тем более их фотографий будет одна большая разница — возраст. Кстати, а что значит слово «какбэ»? Это новый термин?
С человеком все сложно, много философии, давайте про здания. Фотографии одного объекта, сделанные с разных ракурсов - абсолютно разные документы, а не версии одного и того же документа. На одной фотографии есть информация, которой нет на другой. Контент разный. Иначе по вашей логике все документы компании, начиная от Устава и учредительного договора, заканчивая сегодняшним счетом — версии одного документа, т.к. относятся к одной компании (зданию).
Ольга, вы перестанете путаться и путать других, когда поймете суть слова record(s). Не надо относиться к визуальному контенту как чему-то обособленному, иначе придется еще много чего выделять.
Мое мнение. Пост крайне слабый, содержит многочисленные исходные ошибки на которых строятся неверные выводы. Был крайне удивлен вашей должности, ИТ-аналитик одной из лидирующих СЭД компаний не имеет права писать такое.
Дамир, теперь с вами.
Вы говорите о «комплекте документов», о котором Ольга и не высказывалась. Вы также соглашаетесь со всеми ошибками Ольги в частности с тем, что документ с печатями — тоже версия документа. Дальше переходите на комплекты и не можете разобраться как работать с одним документом, используемым в разных комплектах и как относиться к комплектам на разные кредиты. Очень странно.
Если ИТ-аналитики ведущих СЭД-компаний не могут разобраться в основах СЭД, что же происходит с конечными клиентами?
К чему эмоции ).
К Станиславу. По договорам. Да, с точки зрения ЖЦ документа и Records Management вполне разумно что подписанный сторонами договор это "запись" и все такое...
Но представьте себе реальную и полномасштабную работу в СЭД. Что бы вот я делал?:
Надо обеспечить неизменность такой записи? ну заберем автоматически у всех права, "спишем" его в архив с установленными правилами хранения и уничтожения. Но технически - это просто версия. И это выглядит логичным. Это просто удобно - нашел документ, увидел что в нем "уже есть запись", надо - посмотрел предыдущие версии (к которым кстати также можно ограничить доступ).
С изображения, да и не только, как определить что есть версия, что есть новый документ... С трудом представляю рабочую инструкцию для сотрудников где было бы можно сформулировать когда как правильно делать. А значить все остается на уровне Методических инструкций. Как вариант: "Правки, вносимые в документ в процессе подготовки, согласования и утверждения, следует оформлять версиями. Актуализацию действующего документа так же рекомендуется оформлять версиями.".
А лучше прописать наиболее часто встречающиеся ситуации, например:
и т.д.
Т.е. все должно быть прежде всего логично ). И даже следовать стандартам надо не забывая про логику.
1. MoReq и иже с ним нормативные документы, относящиеся к стандартам, добровольны и не обязательны к использованию/исполнению. Они формализуют отношения заказчика и исполнителя к предмету взаимодействия и дают точку опоры и уровень приемлемого качества. Кстати, не думал, что «библия» является твердыней знаний.
2. Я не говорю, что автор ситуацию высосал из пальца и вопрос конечно же актуальный. Однако, специалист, заявляемый как эксперт-аналитик должен как минимум владеть предметной областью, терминологией и базовыми понятиями. В данном посте я этого не увидел.
Хорошо, что вы согласились выделить документ с «живыми» подписями и печатями в отдельную категорию нежели драфты(проекты) данного документа.
Дальше ваши выкладки не понял. Напоминает мнение: «есть ПДД, но посмотрите на реальную действительность. Права покупаются, все ездят как хотят, пробки. О каком соблюдении ПДД может идти речь? И вообще у меня мигалка и мне удобно ездить по встречке.» Вы пытаетесь несоответствие определенным требованиям обосновать сложившейся практикой, удобством, реализованной функциональностью используемого продукта и т.д. Для описанных вами ситуаций кроме версий есть понятие статуса документа: проект, действует, отменен, заменен на. Как вы будете работать с этими документами в вашей системе и в качестве чего хранить и выводить — ваше личное дело, но как это преподносить пользователю и вещать на всю страну, извините.
P.S. Виктор, рад вашему появлению на данном блоге. Надеюсь, это не последний коммент и ваша активность по защите ИТ-молодежи, сложившихся традиций и логики будет замечена и оценена по достоинству ;)
Ну так а в чем не соответствие стандарту?
Вот предположу, что для вас более "приемлема" такая архитектура - есть информационная система где создаются проекты документов, согласуются, утверждаются. А потом надо зафиксировать запись и переместить ее в "специализированное хранилище". Почему отдельно? Аргументы есть, да. Во-первых реквизиты могут быть отдельными и нужными только для хранения, безопасность повыше, так как изолировать все проще, проще искать в теории актуальные документы и т.д.
Вот в такой ситуации мы практически идеально выполним обсуждаемую часть требований? Т.е. условно введем жизненный цикл документа, и на его стадии условно называемая "Действующий" (в случае договора, например после подписания сторонами) будем делать по факту его клон который будем называть запись. И у это клона будут свои реквизиты, правила хранения, изъятия и уничтожения?
Мне самому такая система нравится, так как лучше защищает от ошибок как проектирования, так и пользования ИС.
Но на практике это целесообразно только тогда, когда в компании в силу не важно каких причин нет логически единой ECM. Типичный пример - SharePoint. Мы имеем шаблон сайта Document Center и Records Center. Функциональных отличий - ну совсем минимум. Идейно - с документами творим что хотим в рабочих группах, а их как и библиотек сколько угодно, а вот потом уже перемещаем на хранение как запись.
А коллеги из DIRECTUM уже на уровне спинного мозга воспринимают ECM как вертикально интегрированную ИС (со всеми оговорками на распределенные системы и т.д.). И потому с вами "не на одной волне".
А вы Станислав, как раз напротив, имея потребность дифференцироваться - четко видите задачи отдельного хранения документа, и не годуете, как же они не видят. А им просто не надо, для них "записи" - это подмножество документов, поисковая выборка, если хотите.
Так вот к стандарту и ПДД )...
Да, всем надо соблюдать ПДД, особенно если все знают о существовании ПДД и эти самые ПДД - одни. Но как там сформулирован вопрос в экзаменах? "С какой скоростью безопасно двигаться в потоке? - Со скоростью ниже разрешенной, - Со скоростью ранвой разрешенной или Со скоростью потока?".
Ответ принимаемый ГИБДД очевиден - со скоростью потока. Да, даже если вы нарушаете скоростной режим, главное ехать безопасно. И это примут в суде как основание для опротестование штрафа.
Мораль - соблюдать стандарты надо, но до тех пор пока это выгодно. В хорошем смысле этого слова ).
Постараюсь примирить все стороны.
Виктор правильно уловил один важный момент и акцент. Есть предметная (логическая, методическая) архитектура, есть техническая модель реализации.
Первую как раз описывает Станислав, и, действительно, версия документа должна появляться крайне редко. Версия -- это способ зафиксировать изменение "документной единицы" во времени, так и только так. Для проекта документа это будет новая редакция между соседними правками, а также, возможно, финальный вариант документа (например, уже в виде образа). Впрочем, если, например, отсканированный образ является самостоятельным равноправным участником процесса (в задачах архивирования, например), то имеет смысл выделять его в отдельную "документную единицу". (Я тут ввел временный и довольно дурацкий термин "документная единица" - "ДЕ", чтобы уйти от сомнительного документа и от еще более сомнительного record'а, который, увы, даже Станиславом никак не переводится).
Другие варианты документа -- например, новая редакция стандарта, представление документа в другом формате для другой аудитории и т.д. -- еще более имеет смысл оформлять самостоятельными ДЕ.
Однако есть техническая реализация, и каждая СЭД/ECM решает вопрос с версионностью в меру своей испорченности: исторической практики, ограничений архитектуры и ресурсов. Вопрос Ольги -- если копнуть -- как раз, видимо, в когнитивном диссонансе: восприятии разницы между технической и методической стороной вопроса.
И да, Станислав, спасибо за ваши комментарии и высокие требования к специалистам DIRECTUM. Будем стараться соответствовать!
Далее в примечании указано, что версией считается один из проектов документа или окончательный документ. В некоторых случаях, однако, законченный документ существует в нескольких версиях (например, техническое руководство). И только официальный документ не может существовать более, чем в одной версии.
Проблема, я уверен, лежит в понятийной основе. Точнее - в ее отсутствии. В отрасли нет достаточно понятного определения "документ". Если нет понятия документ, то как можно говорить о версиях документа.
Я написл свой комментарий в виде записи в своей блоге: http://www.pcweek.ru/ecm/blog/andrey-kolesov/580.php
Андрей, вы столь упорно пытаетесь найти всему универсальные термины...
Оно конечно правильно, но если не выходит - ну может и не надо пока? Локальные определения подойдут?
Если у меня просто есть задача автоматизировать работу (подготовка, согласование, утверждение...) договора, то всем же ясно что такое документ? А если не ясно так ввести определения "прямого действия"? Ну например:
Это же разговор такой... ну немного затянувшийся. Есть определения, например "коммуникатор", "смартфон", "КПК"... И что к чему относится не разберешь. Но никто и не парится - просто вот Iphone... Всем понятно о чем речь. А что это? Ну как посмотреть ).
В нашем конкретном примере, неужели непонятно что такое документ и что такое версия? Классифицировать что-то это не так просто, тут упорство и годы Карла Линея надо ). А нам то оно надо?
Коллеги, здравствуйте,
Отвлекся на проведение семинара про проектированию и прототипированию программных интерфейсов, кстати тоже крайне актуальная для СЭД тема, особенно касательно проектировования и кастомизации интерфейсов СЭД под конкретную отрасль, заказчика, группу специалистов. Об этом как-нибудь отдельно поговорим.
В первых словах еще раз хотел бы извиниться за "жесткий троллинг" (по форме моих высказываний, но не содержимому) в первую очередь перед Ольгой. Я не призываю быть зашоренным и бегать только в зоне огороженной флажками, но если вы специалист, то должны не просто задавать вопросы (такие-то фотографии - версия или не версия?), но и утверждать с какой точки зрения это версия, с какой - официальный, значимый для бизнеса документ, а с какой просто информационный материал для того же портала. Плюс изъясняться надо четче и яснее и приводить более продуманные примеры, которые будут наводить на нужные мысли, а не размывать и так зыбкие представления о СЭД-действительности. А терминологические войны будут всегда, пока отрасль бурно развивается, развитие закончится, все стандартизируется, обсуждать будет нечего.
Всем: моя задача не просто высказать свое мнение, но и привлечь максимальное количество людей к обсуждению. Учитывая резонанс, а также появление в эфире "новых" старых специалистов, моя задача выполнена. Если при этом несколько пострадали молодые бойцы, ничего страшного, крепче будут.
Станислав, Ваше мнение о том, что должны, а чего не должны делать специалисты, имеет место быть. Однако, я считаю, что не всегда вещи, как Вы написали, наводящие на "нужные мысли" - это именно то, чего хочет добиться автор статьи, поста, блога, высказывания, да чего угодно. Да и опять же вопрос: кому нужные мысли и для чего нужные?
И да, иногда задать вопрос и оставить его без ответа - лучше для чужого мозга, чем дать ответ или его варианты непосредственно в тексте. Вы где-нибудь в ненаучной литературе видели, чтобы автор писал "а вот тут у меня героиня под поезд бросилась, потому что её совесть заела..."? Да, в научных статьях идеи-решения предлагаются, НО мой пост на научную статью не претендовал, не претендует и претендовать не будет. Он претендует на сборник вопросов в конкретной области, касающейся того, что сейчас ВООБЩЕ НЕ ПОНЯТНО, ЧТО ДЕЛАТЬ С КАРТИНКАМИ В ECM. Ваше мнение по поводу того, что это должны быть разные документы (или record-ы, по-вашему) понятно и учтено.
Ну как минимум Станислав заставил Ольгу "подумать над вопросом" ).
Но Ольга слишком остро реагирует на критику. Мне уже жалко Станислава). И так то "был невиновен", еще и извинился (и ведь все ради Ольги!), а его снова поминают в суе...
Критика - то что нас учит. Критика в целом, если конструктивна - в любом виде полезна. Публичная кстати - тем более.
Так что привыкайте, Ольга. Будете писать в публичном блоге, будет получать комментарии в сравнении с котором скромный и порядочный представитель культурной столицы вспомнится вам как трогательный момент столь быстро прошедших дней.
<Комментарий удален модератором>
Спасибо всем за интересную дискуссию. Надеюсь, все смогут найти полезное для себя в этом споре, оставив в стороне эмоции.