НовостиСобытияКонференцииФорумыIT@Work
Документооборот/ECM:

Блог

Проблемы с производительностью СЭД-систем и о тематике ПиМ

Андрей Колесов
23.10.2013 13:58:57

Я понимаю, что "СЭД-системы" – это похоже на тавтологию, но на самом деле это не так. Дело в том, что нужно различать "СЭД" как функционирующие в рамках конкретной организации ИТ-системы, и "СЭД" как программные продукты для реалиазации ИТ-СЭД-систем. И нужно понимать, что "СЭД-системы" (те или иные) есть – изначально, по определению – совершенно в любой организации, в которой есть хотя бы один ПК. И совсем не обязательно, СЭД-системы создаются на базе специальных СЭД-решений…

Это вводное замечание нужно сделать для того, что высказать следующих, довольно очевидный, но часто забываемый тезис:

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

Поскольку
СЭД-система = СЭД-решение + Квалификация внедренцы (проектирование, доработка, настройка) + Квалификация заказчика (и в плане постановки задачи и в плане доработки-развития).

Каждый из этих компонентов вносит свой вклад. Хотя нужно сказать, что показателем качества продукта во многом является как раз минимизация "человеческого фактора",
Это была присказка, а вот и сказка. Началась она на прошлой неделе с этого сообщения на нашем Форуме



Продолжение последовало вчера:



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

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

Кстати, на конференции RECS 2013 был доклад серьезного заказчика, которые рассказывал о недавно выполненном проекте миграции с Documentum на Lotus. Сама такая постановка задачи сразу несколько удивила слушателей (в том числе основателя Alfresco), а когда докладчик объяснил этот шаг тем, что причиной была недостаточная производительность Documentum, то вызвал в зале просто смех…

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



Потом появилось еще критическое замечание, потому еще ответ…

Лично мне этот разговор видится очень важным, буду следить за продолжением и сразу предлагаю участникам дела сообщить о его результатах.

Добавлю только, что тема производительности и масштабирования (ПиМ) видится очень важной и очень непростой.
Проблема же видится в том (писал еще года два назад), что тема ПиМ уже давно вообще практически не присутствует на нашем СЭД-рынке. Как будто ее нет.

И тут я хочу обратить внимание на продолжение дискуссии на Форуме:



И хочу сказать, что вина в том, что у нас появляются посты в стиле ОБС (одна баба сказала), лежат в первую очередь на самих поставщиках. Которые эту тему много лет обходят вниманием.
Что делают – то и получили.

Например, на прошедшей на прошлой неделе конференции ЭОС я не увидел (в очередной раз) даже намека на присутствие темы ПиМ.

Так что я бы искренне советовал бы Александру Осипову (заместитель начальника управления маркетинга ЭОС и продакт-менеджер направления EOS for SharePoint), компании ЭОС и всем другим СЭД-вендорам, не мешкая заняться этим важным направлением работы…

Комментариев: 1

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

23.10.2013 21:58:17

1. Проблема возможной деградации производительности системы при росте объема данных или числа одновременно работающих в системе пользователей известна с глубокой древности. Грамотные технические требования содержат пункты, касающиеся времени отклика при той или иной нагрузке. Чтобы выяснить, как система будет вести себя под реальной нагрузкой, уважающие себя разработчики, делая проект, пользуются специальными, имитирующими нагрузку, скриптами. Такие инструменты могут быть как изготовлены собственными руками, так и приобретены на рынке. Соответствующий класс ПО носит название Application Lifecycle Performance Management. Существуют и специальные, арендуемые на время, полигоны для испытания готовых производственных конфигураций. Проектируемые системы рассчитываются на определенную среднюю и определенную максимальную нагрузку. Как, например, электросети. И при сдаче/приемке проходят соответствующие испытания на соответствие исходным техническим требованиям (см. выше). В России исторически экономили на профессиональном инструментарии, но все же сейчас такая экономия для серьезных игроков рынка нетипична. Тем не менее, заказчики должны обезопасить себя от такого рода неприятных поворотов судьбы, требуя предъявления им системы работающей с (симулированными) данными реального объема и в условиях (симулированного) потока запросов, близкого к реальному. Так сдаются/принимаются, например, банковские on-line (и не-on-line) приложения. Заказчик вправе также поинтересоваться, каким инструментарием тестирования производственного (production) режима работы системы пользовался исполнитель проекта. Очевидно, что изготовленная с применением всех необходимых норм ИТ-продукция, не может быть дешевой.

2. Нет особых сомнений, что исходное ПО платформы Microsoft испытывалось в соответствии с современными индустриальными нормами. Но такие испытания, разумеется, не гарантируют исправной работы любых разработанных на платформе приложений в любых конфигурациях.

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

4. Сообщения о деградации производительности в соцсетях не имеют для заказчика практического смысла. Прямое обращение в службу техподдержки дает намного большие шансы улучшить ситуацию, чем гадательные советы "с улицы".