mad_nazgulОбе требуют пристального внимания.
Впрочем, этого же требует любая более-менее крупная система. Увы.

Последний выдох ГПЖпока не формализуете сами процессы будете продолжать страдать...
софт - не серебрянная пуля, гарантий что все изменится он не дает, пока не будут налажена работа
Увы, но в точку.
Если сейчас нет четких правил, то как только вы, matalata, придете со стороны IT (вы ведь именно IT-шник?) с навязыванием новых правил, ваши попытки будут саботироваться.

Начните с рисования 1 процесса на бумажке, лучше с самого простого (какой именно это у вас, я судить не возьмусь, коллеги консультанты говорили, что обычно это служебные записки - у них самый простой workflow).

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

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

Я видел сам и знаю со слов коллег, что очень часто все внедрение по сути сводилось к переходу на использование электронного архива + ad-hoc workflow (т.е. аналогично отсылке обычных писем - сам решаю кому послать). Процессы же так и не запустили (почему - отдельный вопрос, подозреваю из-за того, что не смогли насадить их жестко, а договариваться не получилось).

GaryaЕсли, к примеру, более высокий приоритет среди перечисленных имеет "система которую можно будет внедрить и настроить под любую организацию", то лучше посмотреть в сторону Directum.
Так это можно сказать практически про любую СЭД с развитым инструментом разработки: Directum, DocsVision, SharePoint, Alfresco, ... - у Directum здесь нет сколько-нибудь значительных преимуществ, даже наоборот, из-за полностью собственного инструментария разработчика с достаточно ограниченными возможностями расширения, он может оказаться не применим там, где задачи сильно отличаются от стандартных для Directum.

Ну и конкретно в этом запросе Directum не проходит практически по всем остальным критериям (особенно поддержка Oracle и многоплатформенность - текущий Web-клиент все еще уступает Desktop-клиенту по функционалу, а последний работает только на Windows).

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

Мое впечатление я бы выразил так: основной плюс документума в том, что у них практически на любую использующуюся в управлении контентом технологию есть собственное решение, и есть просто куча реализованных проектов в различных бизнес-сферах.

Чтобы было понятнее пара примеров (необходимость каждого из них пока оставим за рамками обсуждения):
- поточный ввод и распознавание инвойсов. У Documentum вы можете взять Captiva, которая и поддерживает кучу аппаратуры и имеет средства разработки и ввода бумажных форм и кучу всего остального. У Alfresco собственного решения нет, значит нужно будет искать и интегрировать что-то стороннее.
- управление правами на информацию (Information Rights Management, IRM). Опять-таки у Documentum есть готовое решение причем с клиентской часть для кучи клиентских продуктов. У Alfresco вы будете либо интегрироваться с AD RM (если клиент под Windows), либо искать стороннее решение...

Таких примеров можно набрать еще, наверное, с 10-ок. Alfresco просто физически не обладает такими ресурсами, которые есть у EMC (и Documentum) а потому вынуждены сосредосточиться на решении нескольких базовых задач: хранилище контента, управление процессами (кстати, тут они просто используют готовое Open Source решение), UI, некоторые функции доставки контента (различные протоколы доступа к контенту + преобразование контента). По большому счету и все. Т.е. это то, что предоставляет базовый Documentum Content Server + Webtop.
Если у вас стоит задача просто создания электронного архива + некие процессы их обработки. То все навороты вроде IRM, Capture, eDiscovery, RM, ... вам никуда не упрутся и Alfresco полностью вас устроит.

А вот дальше надо смотреть на все остальное - поддержку (например, то же качество локализации), наличие и стоимость разработчиков, партнерскую сеть (и подходы к работе с партнерами), ...

Вы убьетесь это сравнивать сколько-нибудь досконально.

elshad82Я как-то прочитал что сам SAP в качестве документооборота использует Alfresco, и поделился на другом форуме этой инфой. Так меня забросали гнилыми помидорами, мол - на проектах SAP в качестве СЭД устанавливают OpenText.
Ну вообще, наверное что-то в этом есть.
OpenText, судя по всему, сделали ставку на глубокую интеграцию с SAP. Это можно увидеть по перечню их продуктов/решений. На сколько это опрадывается, и есть ли у них какие-то соглашения с SAP я понятия не имею. Но в целом, да достаточно часто услышав "SAP и документооборот" вспоминают OpenText.

iscrafmесть примеры не уступающих?
Те, которые не имеют Desktop-клиента вообще, т.е. практически любая западная платформа.

iscrafmТолько не таких, где уровень функционала опущен по уровня web-браузера...
Тут надо понимать, что в отличие от большинства других учетных систем, СЭД/ECM не требуют сколько-нибудь сложного интерфейса.
Да, это тоже учетная система, но управляет она объектами, которые имеют, в большинстве случаев, достаточно простые метаданные. Конечно, встречаются вырожденные случаи, когда на базе ECM реализуют фунционал бухгалтерии или чего похлеще... Но мы ведь не о таких?

Поэтому в большинстве случаев Web-интерфейса ECM хватает просто за глаза. Ну и некоторые идут дальше - организуют достаточно хорошую интеграцию с клиентами. Например, Sharepoint и MS Office - при правильной настройке я могу обращаться к интерфейсу Sharepoint только отдельных задач, а большую часть (открытие

простите, не дописал... нажал "отправить" раньше

(открытие/закрытие документов, изменение их метаданных, управление версиями, поиск, ...) - все это можно делать из интерфейса клиентских приложений или Windwos Explorer.

iscrafmэто не корректное сравнение.
Почему некорректное?
Вы спрсили в каких системах web-клиент не уступает desktop. Я ответил: там где web - единственный клиент.

Я реально не знаю ни одной ECM системы, которая бы имела Web-клиент изначалаьно и начала бы разрабатывать desktop. И наоборот, почти все, имевшие изначально desktop-клиента либо выпустили web (но он почти везде уступает настольному, ибо требует серьезной переделки архитектуры системы и поддерживать и развивать его сложно), либо полностью перешли на web-клиент.

Единственное исключение - клиенты для мобильных устройств.
Но там есть особенности, с которыми приходится мириться и из-за придется или разрабатывать хитрую версию Web-интерфейса или разрабатывать свой специализированный клиент:
- ограничения поддержки некоторых протоколов. Например, настольная Windows поддерживает WebDAV со времен 98-ой, а в Windows Mobile/Windows Phone/iOS/(не уверен)стоковом Android - поддержки его "из коробки" нет.
- необходимость работы вне офиса (т.е., скорее всего по ограниченным каналам или вообще вне доступа к сети). Т.е. нужен режим off-line или что-то типа подобного.
- малые размеры и необходимость специализированной верстки интерфейса.
- отсутствие привычных клиентски приложений с которыми была сделана глубочайшая интеграция.
...

МихаилРчто понимается под "сложностью"?
Примерно так:
- наличие больших списков на множество столбцов,
- наличие форм с большим количеством полей и сложной логикой отображения,
- необходимость использовать какие-либо нестандартные контролы,
- необходимость использовать горячие клавиши, сложный Drag&Drop.

В принципе, сейчас даже большую часть из перечисленного можно с приемлемыми трудозатратами реализовать для Web-клиента. Но как я уже говорил, для большинства ECM систем это не нужно.
Ведь, что собой представляет типичный документооборот?
1. Хранилище документов (тел) с карточками. Карточки, в большинстве своем, простые - 10-20 полей (монстры тоже встречаются, но это вырожденный случай), часть полей - простые скалярные, часть - ссылки на справочники (контрагент, автор, ...). Справочники зачастую ведутся в других системах.
2. Манипуляция с телами: сохранение/извлечение, версии, ...
3. Навигация и поиск (навигация - обычная иерархия, поиск - по атрибутам и тексту).
4. Запуск/исполнение процессов (WorkFolw). Которые представляют собой форму на странте да несколько простейших форм на этапах выполнения.

Все остальное (т.е. именно создание контента), как правило, делается в клиентских приложениях. СЭД обеспечивает только backend - базу, логику, хранилище, движки поиска и Workflow, ...

Есть конечно и отхождения от этого правила: например, некоторые ECM имеют средства для создания контента в виде страниц сайтов (как многие CMS), блогов, Wiki, но вот честно, я пока не вижу в Enterprise для этого какой-то большой заинтересованности. А если что-то подобное появляется, то используются специализированные платформы, а ECM, в лучшем случае, служит только хранилишем или поисковым агрегатором.

iscrafmа зачем тогда браузер? Только для банального просмотра контента, если нет под рукой нормального клиента?
Ну почему...
Навигация по хранилищу остается в Web-клиенте, там же обычно и поиск (там, где нужен не просто текстовый а-ля Google поиск, а полноценный поиск по атрибутам). Если карточка все же имеет некоторую логику (например, банальные зависимые поля), её все равно не возможно будет реализовать на клиенте - средств таких нет.

Плюс всякие, не связанные непосредственно с контентом задачи:
- ведение справочников/списков (если они не синхронизируются извне)
- специализированные манипуляции над контентом. Например, регистрация документа или создание record, ...

iscrafmгде нет таких средств, не совсем понял? Это же банальная возможность любого смарт-клиента
Прошу прощения, не совсем корректно выразился.

Под клиентскими приложениями во всех своих комментариях я имел в виду приложения, которые используются для создания и редактирования контента: Office, Adobe (Reader), графический редактор, CAD, ...

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

А вот когда этого не хватает - нужен специальный клиент web или desktop/smart это уже другой вопрос.

antares0А можно пример "сложного интерфейса" учетной системы?
Я же вроде расписал тут 15009114 .
Примерно так:
- наличие больших списков на множество столбцов,
- наличие форм с большим количеством полей и сложной логикой отображения,
- необходимость использовать какие-либо нестандартные контролы,
- необходимость использовать горячие клавиши, сложный Drag&Drop.