Это вводное замечание нужно сделать для того, что высказать следующих, довольно очевидный, но часто забываемый тезис:
Технические характеристики (например, производительность и масштабируемость) СЭД-системы и СЭД-продукта – это совсем не одно и то же.
Поскольку
СЭД-система = СЭД-решение + Квалификация внедренцы (проектирование, доработка, настройка) + Квалификация заказчика (и в плане постановки задачи и в плане доработки-развития).
Каждый из этих компонентов вносит свой вклад. Хотя нужно сказать, что показателем качества продукта во многом является как раз минимизация "человеческого фактора",
Это была присказка, а вот и сказка. [spoiler]Началась она на прошлой неделе с этого сообщения на нашем Форуме
Продолжение последовало вчера:
Я хотел написать по этому поводу пост еще вчера, но решил, что нужно сначала установить контакт с автором такого серьезного высказывания, в том числе и в плане подтверждения подлинности авторства (кстати, это к вопросу о подлинности документов). Написал через механизм блога письмо, пока ответа не получил.
В посте я хотел сказать то, что написал в "присказке" и искренне посоветовать не решать вопрос о приобретении нового оборудования, а тем более о смене СЭД-решения, до того, как будет выяснена причина проблем. А проблема может быть (с очень большой долей вероятности) именно в человеческом факторе, в неверной архитектуре проекта. И в этой ситуации смена ПО, возможно, просто ничего не решит. При том, что грамотный подход позволит работать и с существующей системой.
Кстати, на конференции RECS 2013 был доклад серьезного заказчика, которые рассказывал о недавно выполненном проекте миграции с Documentum на Lotus. Сама такая постановка задачи сразу несколько удивила слушателей (в том числе основателя Alfresco), а когда докладчик объяснил этот шаг тем, что причиной была недостаточная производительность Documentum, то вызвал в зале просто смех…
Так вот. Ответа от заглянувшей Екатерины я не получил, но утром там появился весьма конструктивный комментарий-предложение от представителя ЭОС (оперативность искренне порадовала):
Потом появилось еще критическое замечание, потому еще ответ…
Лично мне этот разговор видится очень важным, буду следить за продолжением и сразу предлагаю участникам дела сообщить о его результатах.
Добавлю только, что тема производительности и масштабирования (ПиМ) видится очень важной и очень непростой.
Проблема же видится в том (писал еще года два назад), что тема ПиМ уже давно вообще практически не присутствует на нашем СЭД-рынке. Как будто ее нет.
И тут я хочу обратить внимание на продолжение дискуссии на Форуме:
И хочу сказать, что вина в том, что у нас появляются посты в стиле ОБС (одна баба сказала), лежат в первую очередь на самих поставщиках. Которые эту тему много лет обходят вниманием.
Что делают – то и получили.
Например, на прошедшей на прошлой неделе конференции ЭОС я не увидел (в очередной раз) даже намека на присутствие темы ПиМ.
Так что я бы искренне советовал бы Александру Осипову (заместитель начальника управления маркетинга ЭОС и продакт-менеджер направления EOS for SharePoint), компании ЭОС и всем другим СЭД-вендорам, не мешкая заняться этим важным направлением работы…
Фото:
2. Нет особых сомнений, что исходное ПО платформы Microsoft испытывалось в соответствии с современными индустриальными нормами. Но такие испытания, разумеется, не гарантируют исправной работы любых разработанных на платформе приложений в любых конфигурациях.
3. Никакой ECM/СЭД специфики в этом сюжете нет. Кроме разве той, что культура проектирования и приемки готовой ИТ-продукции в бюрократической среде, сложившейся вокруг вспомогательных и не слишком ответственных (типа ОРД) бизнес-процессов предприятий, существенно отстает от таковой в основных производственных контурах тех же предприятий.
4. Сообщения о деградации производительности в соцсетях не имеют для заказчика практического смысла. Прямое обращение в службу техподдержки дает намного большие шансы улучшить ситуацию, чем гадательные советы "с улицы".