Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти как пользователь
Вы можете войти на сайт, если вы зарегистрированы на одном из этих сервисов:

DOCFLOW - теория и практика электронного документооборота. Все о ECM и СЭД (системы электронного документооборота), ЭП

Eng
09.01.2004
К выбору систем автоматизации документооборота

Оригинал статьи размещен на сайте "Компьютерра"
Андрей Акопянц

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

Но каждый раз эти инициативы проваливались, поскольку было очень трудно выработать содержательную систему критериев, таких, чтобы:

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

При этом в последние два года количество систем управления документооборотом растет экспоненциально, и эта задача становится чем дальше, тем неподъемнее.

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

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

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

- Максимально быстрое внедрение системы — интерес топ-менеджмента и «сознательной» части среднего менеджмента.
- Ничего не менять, то есть поддержать существующие процессы как есть, а лучше — вообще ничего не внедрять, — интерес основной части среднего менеджмента и рядовых сотрудников.
- Минимизация затрат на закупку системы — интерес акционеров (или держателей бюджета).
- Максимизация мотивированных затрат на покупку системы — интерес лиц, получающих откаты от поставщика.
- Разумно долгая разработка/внедрение и последующая поддержка силами IT — интерес амбициозного и недостаточно влиятельного IT-департамента.
- Минимальное участие IT во внедрении и поддержке — интерес влиятельного (или не имеющего особых амбиций) IT-департамента, которому и без того хватает головной боли.

Мы по возможности опишем, какие интересы способен удовлетворить тот или иной класс решений.

Технологические критерии
Lotus или не Lotus

Все системы, представленные на рынки, делятся на два больших класса — работающие в среде Lotus Notes и все остальные.

Если в организации используется Lotus и с него не собираются уходить, естественным выбором являются системы лотусовского семейства — от «Интертраста», «АйТи», ИРМ и пр.

Если же Lotus не используется, приобретать его исключительно для автоматизации документооборота вряд ли целесообразно. Lotus — отдельный параллельный мир, и если уж ставить на этот пакет, под него есть смысл переводить всю корпоративную IT-инфраструктуру.

При этом нельзя сказать, что по своим пользовательским качествам системы на базе Lotus превосходят конкурентов из не-лотусовского мира. Более того, в силу функциональных ограничений Lotus Notes до 5-й версии включительно эти системы страдали некоторыми «родовыми дефектами», снижающими их надежность при большом потоке документов.

Правда, надо заметить, что в современной версии Lotus Notes (R6) наконец реализованы транзакции в их честном СУБД'шном смысле (согласованная модификация группы записей в БД с гарантированным результатом). Тем самым устранен главный, на мой взгляд, технологический дефект Lotus, и открыта принципиальная возможность реализации OLTP-систем на его базе.

Так что сейчас технологические противопоказания с лотусовских систем сняты, и выбор является только делом вкуса. Но я склонен думать, что больших миграций уже не будет: те, кто использует Lotus, продолжат его использовать, а те, кто не подсел на него, уже и не подсядут — слишком высока цена смены корпоративной информационной инфраструктуры. Конечно, за исключением форс-мажоров, возникающих при поглощении компаний, — типа покупки ТНК корпорацией British Petroleum, в результате которой ТНК переходит на Lotus, являющийся корпоративным стандартом BP.

При удовлетворении же всевозможных противоречивых интересов Лотус выглядит очень симпатично, что и обусловило, видимо, его достаточно широкое распространение, а именно:

- если Lotus уже внедрен, несложные подсистемы на его базе запускаются очень быстро и начинают приносить реальную пользу;
- поскольку сам Lotus является конструктором (см. дальше), то системы на его базе легко подстраиваются к поверхностным особенностям бизнес-процессов компании, что позволяет как удовлетворить ревнителей существующей практики, так и обеспечить вечной работой по подкручиванию системы IT-департамент компании;
- как с любыми дорогими западными системами, при покупке значительного количества лицензий на Lotus можно рассчитывать на хорошие «откаты»;
- но полноценные лицензии можно и не покупать — имеются «бюджетные» варианты для обеспечения работы через Web.

Используемая СУБД

Собственно, очевидных лидеров тут два — MS SQL Server и Oracle. Практически все не-лотусовские системы, представленные на рынке, используют MS SQL. Некоторые умеют также работать с Oracle (скажем, «Дело»). Системы, ориентированные исключительно на Oracle, мне неизвестны.

Правда, имеется также класс систем, использующих собственные хранилища документов. Как правило, они выросли из некоторых информационно-поисковых систем с большой историей (скажем, «Евфрат» от Cognitive). Свои форматы хранилищ используют также «большие» западные системы — Documentum, HB5 (ex-DocsOpen).

Использование стандартных СУБД является явным плюсом с точки зрения сопровождаемости и масштабируемости системы и простоты ее интеграции в корпоративную IT-инфрастуктуру. Хотя собственное хранилище также обладает некоторыми плюсами: не требуется дополнительно покупать лицензии на СУБД, а с точки зрения администрирования система выступает как единый «черный ящик».

Функциональные критерии
Готовая «коробочная» система или (полу)заказная разработка

Это отличие определяется не столько декларациями поставщика, сколько множеством объективных факторов — функциональной полнотой системы, качеством дистрибутива, качеством и объемом документации и др. То есть, в конечном счете, может ли система быть установлена и внедрена силами «типичного» заказчика без участия программистов фирмы-поставщика. Единственным критерием тут является практика — количество заказчиков, самостоятельно установивших и эксплуатирующих систему.
Известно, что превращение проекта (заказной системы) в продукт (коробочную версию) обходится примерно втрое дороже, чем сама разработка, — такова стоимость необходимой функциональной доработки, качественного тестирования, пакетирования дистрибутива, написания документации и других мероприятий, необходимых для выпуска продукта.

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

Плюсы и минусы тут очевидны: с одной стороны, возможность учесть нюансы бизнес-процессов заказчика, с другой — непредсказуемость результата, как с любой заказной разработкой, и, как правило, более высокая суммарная стоимость внедрения.

Кроме того, с такими системами, существующими в единичных и слегка различающихся экземплярах, обычно возникает проблема сопровождения и развития. Зачастую разработчики не выпускают новых версий, а если выпускают, то они плохо совместимы с предыдущими, и переход на них является далеко не простым занятием. Из-за этого не только теряется возможность развития системы, но и возникает риск отстать от технического прогресса и получить проблемы с эксплуатацией старой системы на новых компьютерах, с подключением периферии и др.

Конструктор типа «сделай сам» или готовая прикладная система

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

В основе каждого такого конструктора лежит некоторая «метамодель», определяющая, с одной стороны, класс систем, которые собираются на нем легко и быстро, а с другой — границы его применимости.

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

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

Тем не менее водораздел между ними, как правило, достаточно четкий. Если при демонстрации системы вы, к примеру, спрашиваете: как осуществляется контроль отправки исходящих документов нашей экспедицией? — и вам показывают как, — вы имеете дело с прикладной системой. А если вам начинают говорить, что это можно легко запрограммировать, для этого достаточно добавить туда-то такое-то поле и т. д., — вы имеете дело с конструктором.

И это понятно — гибкость и универсальность нередко вступают в противоречие с прикладной функциональностью. Это противоречие может сниматься при очень высоком уровне развития. Скажем, в классе бухгалтерских систем для «1С:Предприятие» оно уже снято. Этот пакет, с одной стороны, является мощным конструктором, а с другой — конкретной прикладной системой, функциональность которой описана в типовой конфигурации и успешно используется в неизменном виде большинством пользователей.

Кстати, Lotus можно рассматривать именно как такой конструктор, а все лотусовские системы — как надстройки (конфигурации).

Заметим, что именно засилье конструкторов и полузаказных систем на рынке не позволяет составить пресловутую табличку сравнительного анализа систем, так как для систем класса конструкторов почти в любую клеточку правомерно ставить плюсик — «можно запрограммировать». А какова при этом будет цена вопроса, особенно если нужно запрограммировать не только одну конкретную функцию, а их тесно взаимодействующую совокупность, — непонятно….

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

С точки зрения рисков — на конструкторе больше риск вообще не получить результата, а у готовой системы — упереться в границы ее функционала при развитии организации или увеличении масштабов внедрения. С финансовой точки зрения — на рынке имеются как «бюджетные» отечественные конструкторы cо стоимостью лицензии от десятков до сотен долларов, так и очень дорогие импортные VIP-конструкторы (тот же Documentum с лицензиями от $1000 на одного пользователя), предоставляющие неограниченные перспективы удовлетворения материальных притязаний заинтересованных лиц.

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

Поделиться:


Тэги: СЭД


КАЛЕНДАРЬ
ПОСЛЕДНИЕ НОВОСТИ
21.06.2019
TESSA 3.3 – новые горизонты СЭД
Компания Syntellect объявила о выпуске официального релиза СЭД TESSA версии 3.3.
В новой версии платформы расширены возможности легкого клиента, обеспечена поддержка разных часовых зон и внесено более сотни других улучшений.

28.03.2019
Финансы уйдут в электронный документооборот
На рассмотрение государственной думы РФ вынесен законопроект о введении электронного документооборота в российских организациях. При создании электронных копии бумажных документов, оригиналы нужно будет хранить всего год.

28.03.2019
В ожидании цифрового прорыва
Как выбраться из «колеи», в которой, согласно институциональной теории, движется, увязнув всеми колесами, Россия? Ответ на этот вопрос эксперты ищут не первый год. Вряд ли есть одно решение, но, возможно, в этом стране помогут технологии: отечественная математическая школа всегда высоко ценилась во всем мире, да и IT-отрасль в России развита сильнее прочих. Во всяком случае, именно на их развитие делают ставку власти: от направления «Цифровые технологии» нацпроекта «Цифровая экономика» они ждут настоящего прорыва. Впрочем, его успех, по мнению экспертов, будет зависеть от синхронизации процесса цифровой трансформации во всех российских регионах.