Val_KillЭЦП действительно нужна. Это требование руководства.
Понятно. Увы, подозреваю что ситуация: "проще согласиться, чем доказывать обратное". Скажу только, что главное в данной ситуации четко разделять понятия: "внедрять ЭЦП" и "вводить юридически-значимый электоронный документооборот" - последнее дорогая и практически бесполезная в современной России. А вот внедрить в простейшем варианте использование ЭЦП для оперативных документов умеет практически любой внедренец, не говоря уже о вендорах.

Val_KillПо поводу отечественной СЭД. Нет ли опасности, что лет через пять контора-разработчик рухнет и что тогда делать.
Принципиально, конечно, такая опасность существует, однако, на мой взгляд, стоит учитывать еще и следующие моменты:
1. Опасность прекратить существование грозит любой фирме не важно, отечественная она или западная, а если сама компания и выживит, то не обязательно сохранит это направление в своем бизнесе. Приведу несколько, наиболее известных, примеров:
- долгое время в Европе и России был известна такая СЭД как Docs Open (не говорю "популярна", потому что для России она был явно дороговата), в настоящее время такой системы не существует. Да, на смену ей пришел Hummingbird, однако, даже сами представители Hummingbird подчеркивали, что это абсолютно разные системы. Стоит ли говорить, что внедерение Hummingbird поверх Docs Open выливалось в весьма внушительную сумму. А теперь и Hummingbird как компании не существует...
- одно время наряду с продуктами Documentum (еще до покупки его ECM) или IBM были системы от Xerox и Canon, однако теперь о них как о поставщиках EDM никто и не вспоминает, а ведь и фирмы, и продукты остались, просто их потихоньку "сместили".

2. По поводу нескольких лет: вот, например, даты основания нескольких известных российских производителей СЭД (дальше, уж извините, нет времени искать):
- Digital Design (DocsVision) - 1992
- Cognitive Technologies (Евфрат) - 1993
- НПО "Компьютер" (Directum) - 1988
- ЭОС (Дело) - не позднее 1996

Как видите каждая из этих компаний существует уже более 10 лет и пока что погибать явно не собирается. А сейчас, когда во всем мире и в России такой спрос на ECM системы это просто сложно сделать :)

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

В общем, решать доверять/не доверять в конечном счете Вам, но иметь в виду то, что я написал, наверное, стоит.

Val_KillВ Documentum радует наличие встроенной BPM. Что на мой взгляд является перспективным направлением. Хотя цены конечно .... весьма.
Documentum интересен как комплексное решение. т.е. когда у вас идут и хранилища, и медиа-сервисы, и BPM, и RM, и Captiva. Но все вместе это стоит столько...
А если брать Documentum чтобы заткнуть отдельные направления, то, по-моему, почти всегда можно найти решения не хуже, но на много дешевле. Например, сравните за сколько предлагали Вам BPM от Documentum и, например, BizTalk, который в Standart-редакции стоит 23-24 тысячи рублей.

Val_KillTo МихаилР
Относительно DocVision
Вот на сайте DocVision прочитал следующее:

...

Хранение файлов в смой базе по моему мнению разбухает ее до невероятных размеров, чт влечет за собой проблемы с использованием SQL серверов. Что вы думаете об этом?

В целом да, база ростет, Вы правы. Однако тут есть несколько интересных нюансов:
1. Сам по себе рост базы, при правильной ее организации не сильно сказывается, например, на производительности. Гораздо больше начинают страдать операции обслуживания, т.е., например, ростет время на выполнение операций резервного копирования/восстановления (тьфу-тьфу-тьфу, конечно, но ведь всякое случается) и увеличиваются требования к месту для хранения.
Однако, эти проблемы решаемы, тем более, что объемы не сравнимы с объемами некоторых баз, которые обсуждаются на sql.ru (по поводу объемов см. ниже)
2. На сколько растет база. Это очень сложный вопрос. Все очень зависит от контента и нагрузки. А общее количество мест - далеко не показатель. У всех вендоров, на сколько я знаю есть некотрое метрики, которые они вынесли из своей практики внедрения.
С ходу я таких не назову, только могу предложить следующее:
- если мы ориентируемся на офисный документооборот, то основные документы это: подготовленные в каком-либо офисном пакете, сканированные образы (как правило tiff), ну и иногда документы в формате PDF.
- примерные размеры их, на которые, например, ориентируюсь я:
- MS Word 300 кб - 1 мб (Microsoft вообще приводит среднюю оценку в районе 300 kb)
- TIFF - примерно 300kb на страницу. Обычно, документы идут не более 5-10 стр., соответсвенно, получаем 1,5-3 мб
- PDF, если это не контейнер для сканироанных картинок, то на уровне MS Word.
Отсюда, если сможете подсчитать свой документопоток, можете прикинуть во что выльется Вам первоначальное наполнение архива (если оно планируется) и сколько будет добавляться ежегодно.
3. У многих вендоров есть решения для "опустошения базы", иногда это полноценный архив, иногда просто перенос в другую базу или просто на другой тип хранилища.


Что же касается конкрентно решения от DocsVision, то мне оно не нравится (впрочем, подобные решения я видел, например и у Евфрат, и там оно вовсе было основным). Помимо тех ограничений, которые перечислены есть сомнения по повду будет ли работать: система прав DocsVision, можно ли будет выполнять некоторые операции с документами, например, реплицировать, работать с ними удаленно...
Еще, очень часто с такими решениями начинаются сложности в части администрирования. По сути, это обычные файловые архивы и как с обычными файловыми архивами нужно настраивать доступ, например, из разных доменов.

Правда, тут должен сказать, что у российских поставщиков я полноценного файлового хранения не видел, у всех есть что-нибудь свое (свои проблемы). Например, у Directum есть файловое хранение, однако, хоть оно и решает половину проблем решения DocsVision (например, в части версий и прав доступа), однако, оставляет, на сколько я знаю, не решенной проблему репликации и администрирования в неоднородной сети (особенно без AD). Хотя, из того, что я видел это наиболее функциональное решение, у остальных еще больше проблем.

GaryaМожно безо всякой специализированной системы после каждой правки файла MS Word попросить всех, кто это делает, сохранять прежнюю редакцию с пометками в свойствах документа MS Word, что это за документ, почему и когда он изменен и т.д. и т.п.
Увы, подобные, меры начинают очень быстро утомлять пользователей. А средств в принудительном порядке поддерживать некий стиль ведения документов встроенные и обычные офисные средства не позволяют. Поэтому и появляются, и появляются новые системы документооборота.


GaryaИ оказывается, что в файловой системе выстроить одновременно все эти параметры крайне сложно.
Совершенно согласен. Собственно в минимальном варианте СЭД - это хранилище (не важно какое - файловое, SQL или специализированное аппаратное...) и база со структурированной информацией - карточками. Ну и конечно функционал для работы со всем этим, например, поиски.

GaryaВыявить документы, ссылающиеся на конкретный документ, стандартными средствами крайне затруднительно. Операционная система не оповещает, что отправленный на визирование документ в требуемые сроки завизирован не был. Она не может обеспечить прохождение документа по заданной регламентом траектории.
Ну да, а после того, как решились проблемы с хранением и поиском, начинают вставать задачи управления документами. :) Сначала, просто выдача поручений (что решается зачастую обычной почтой), затем вдруг обнаруживается, что это слишком трудоемко, т.к. маршруты среднестатистического документа имеют более одного этапа... А потом приходят к тому, что еще нужно выдерживать, например (как было указано), сроки согласования, или, что при согласовании договора с поставщиком должен запуститься процесс оплаты и т.д.
И как следствие:
GaryaЭти и ряд других причин как раз и приводят к тому, что организация в конечном итоге принимает решение приобрести СЭД - для того, чтобы устранить проблемы файлового хранения.


А вот с этим соглашусь, но не до конца:
GaryaЕсли вам приспичило хранить часть информации за пределами хранилища СЭД на файловом сервере, то делать это можно, но при этом многие преимущества ECM-системы утрачиваются. Никакой трагедии я в этом не вижу, просто такова природа вещей... :)
Просто файловое хранение не всегда предполагает хранение вне СЭД. И есть очень много областей, где, например, SQL-хранилище просто не применимо или его применение слишком дорого.
Но еще раз повторю, не обязательно файловое хранение предполагает такое прямолинейное решение, как предлагаемое DocsVision.