Nickorurk,

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

TimyTim,

то ли ваш друг не в теме, то ли вы слишком много чая выпили.

МихаилР,

попробую в кратце....

TimyTimМысль товарища проста, EMC Documentum сильно просел за последние несколько лет и скатиться ещё больше в ближайшем будущем с такой политикой.Это правда, но причины иные.

TimyTimDocumentum - это огромная мощь при практически полной отсутствии гибкости. Так что давите в требованиях про гибкостиь, сроки и кастомизацию.Мощь при отсутствии гибкости - это какой-то оксюморон. В принципе на документуме можно реализовать любые хотелки заказчика, по крайней мере я еще не встречал случаев, когда нельзя что-то сделать, основная проблема больше заключается в том, что заказчик зачастую сам не понимает что он хочет, к примеру, ФЗ в жизни видел только лотус и поэтому хочет чтобы было все как в лотусе, причем бестпрактис и консалтиг категорически игнорирует (вот тут ссылка в тему: http://aiim.typepad.com/aiim_blog/2010/02/8-ways-to-kill-your-ecm-project.html ). Также подобное мнение об отсуствии гибкости может быть вызвано тем, что у большинства интеграторов за долгий срок накопились какие-то собственные наработки (кто-то даже решением называет) под определенного заказчика, зачастую кривые, и они пытаются эти наработки впарить совершенно нецелевой аудитории, и получается, что перелапатить легаси-код под новые требования гораздо сложнее, чем что-то построить с нуля.

TimyTimбольшинство партнёров EMC сейчас столкнулись с очередной проблемой - EMC в очередной раз поменяли пользовательский интерфейс, т.е. меньше чем за 10 лет они меняют его в четвертый раз, самое интересное, что они не совместимы между собой.Сейчас есть такие вебморды:
webtop и производные - несколько старый интерфейс (хотя на одном нашем проекте со стороны пользоввателя выглядит довольно достойно), API существенно не менялось уже наверное лет 8, поддерживает почти все возможности Content Server, в webtop вбухано столько денег и ресурсов, что просто так взять и прикрыть его не получится, в роадмапе евойная жизнь пока обозначена до 2020 года (в прошлом году сейлы бегали как угорелые и рассказывали что webtop собираются прикрыть - обманывали).

CenterStage - выпустили по-моему в 2008, сделан на Flex, предназначен для медиа-котента. Ввиду того что его кастомизировать особо нельзя его партнеры закопали сразу же после выхода, потому что не ясно кому его можно внедрить вообще

xCP - вроде тоже 2008, здесь продакт-менеджеры начали грезить мечтой, что не плохо было бы сделать продукт, который для кастомизации нужно настраивать, а не кодить, в итоге они к webtop прикрутили XForms и получили какого-то крокодила, некоторое время грозились выкинуть из него все наследие webtop, но в итоге в прошлом году закопали.

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

xCP2 - официально называется последователем xCP, но платформа совершенно другая, выпустили год назад, пока все очень сыро, и если не бросят пилить, то года через 3 может чего достойное и выйдет.

В итоге то что действительно похороили - xCP, но лично мне изначально казалось что он не жилец особо, к нам как-то приходил сейл из EMC и пытался впарить коробку EPFM, проблема в том, что EPFM начали делать через год-два после появления xCP, вот только проблема в том, что сделано оно на webtop, что говорит само за себя о возможностях xCP. Вот это вот:
TimyTimТ.е. все, что партнеры за это время разработали на предыдущих интерфейсах можно смело выкинуть.правильно было бы сказать так: то что наработали партнеры можно выкинуть.

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

TimyTimКто то из партнёров EMC Documentum считают убытки и покупают новую версию системы, а кто то выбирает другую систему.С версиями у них реально сейчас наблюдается бардак. Время жизни последних релизов что-то в районе двух лет, после EOL поддержка уже услуги не оказывает и заставляет обновляться (за лицензии платить не нужно, потому что они куплены), но в самих версиях особо-то ничего не меняется: идет какой-то багфиксинг, навешивается новый шильдик, если посмотреть на то, что поменялось за последние лет 5, но от силы можно насчитать с десяток крупных изменений, причем их реальная полезность довольно спорная. Я за последние полтора года довольно усердно сношал поддержку в плане ошибок (завел в районе 300 дефектов, именно дефектов, а не обращений в поддержку) в итоге они все критичное нам зафиксили на нашем релизе и куда-то обновляться в принципе смысла вообще не имеет.

TimyTimПоэтому многие российские партнёры EMC смотрят в разные стороны, кто в сторону OpenText, кто в сторону Alfresco, кто в сторону решений от Microsoft, включая упомянутый Sharepoint и решения на его основе. Смотреть партнеры могут много куда, но в действительности шарик и альфреска играют уровнем ниже, тут скорее всего акцент на том, что крупных заказчиков не осталось, а мелким Documentum не нужен.

по поводу недостатков в документуме.

Основной недостаток - для людей с бэкграундом в .Net документум будет неподъемным - у документума весь стек построен на жаве, т.е. непосредственно с контент-севером (работа идет не с базой напрямую, а через отдельный сервис, который умеет некое подобие SQL + примитивный набор операций) может работать только жавская библиотека. EMC конечно за последнее время прикрутила поддержку SOAP, CMIS и REST, но они все работают через жавское API. При этом беспрактис по обеспечению консистентности данных - писать реализацию бизнес-объектов на жаве, в противном случае один и тот же бизнес-код придется таскать по всем системам и его везде поддерживать, такое в природе конечно встречается, но как показывает практика работает довольно чрезжопно. Поэтому если ТС в жаве не зуб ногой (при этом нужно еще знать и контент-сервер, и API и иметь какой-то опыт с документумом вообще), то что-то сделать самостоятельно вряди получится. Для самостоятельного внедрения и поддерки не плохо было бы у себя иметь человека два-три в штате, которые во всей документовской кухне разбираются (причем еще фиг найдешь кого-то вменяемого (думаю с OpenText и P8 ситуация такая же)), причем поддерка EMC кастомные решения поддерживать не будет - они хотят кейсы на некастомном коде.

NickorurkСистема максимум на 5000-6000 юзеров, одновременных до 2000.
Планировали закрыть этот всё за 6-8 месяцев максимум.Для документума здесь нет ничего сложного.

sergeynsNickorurk,
1) озадачьте HR просьбой поискать на рынке спецов по Документуму - много ли найдут? На этом форуме, помнится, разработчика для документума искали несколько раз, по пол-года...Ну по opentext и P8 найти сложнее, насчет альфрески не в курсе, но я точно знаю, что пилить ее куда сложнее чем тот же документум (мы для внутренних целей используем альфреску, причем в наличии есть грамотные разработчики, впечатление такое, что коробочный webtop куда функциональнее и удобнее чем альфреска, кроме этого по отзывам разработчиков складывается впечатление, что альфреска представляет из себя некий фарш из жавы и сервеного жаваскрипта, кроме этого база используется как EAV, так что с отчетами и поиском ой какая беда)

sergeyns2) попросите подрядчика сводить, "показать" уже внедренный Документум.. Если смогут показать довольного заказчика, то
- либо решаемая задача примитивна, и не требовала кастомизации этого монстра
- либо спросите сколько стоило "допилить" документум до вменяемого состояния.. Тут больше вопрос в ожиданиях заказчика, насколько я понял ТС хочет документооборот по ГОСТ + возможность допилить всякого рода интеграции, и ТС изначально позиционирует предложенные варианты (opentext и documentum) как СЭД, но ни opentext ни documentum СЭД не являются - это просто платформы, можно там реализовать ГОСТ? В документуме точно можно, но про наличие готовых релазизаций в том же documentum мне ничего не известно, причем я точно знаю почему - потому заказчикам, которые внедряют "монстров", этот ГОСТ нафиг не впился - им нужно решать другие задачи, т.е. целевая аудитория продукта несколько иная нежели у коробочных СЭД.

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

Partisan MЯ хорошо знаю DocumentumНе особо вяжется с этой мурзилкой: Documentum - есть ли там понятие "транзакция БД" ? :)

NickorurkНам показывали свои коробки корус и терралинк, но это делопроизводство и документооборот в чистой воде не более. Остальное - их услуги.

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