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

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

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

- критерии были легко проверяемы

- существенны с точки зрения потенциального заказчика

- чтобы система критериев была сколько-нибудь полна,

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

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

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

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

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

``Максимально быстрое внедрение системы '' - интерес топ-менеджмента и ``сознательной'' части среднего менеджмента

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

``Минимизация затрат на закупку системы'' - интерес акционеров (или держателей бюджета)

``Максимизация мотивированных затрат на покупку системы'' - интерес лиц, получающих откаты от поставщика

``Разумно долгая разработка/внедрение и последующая поддержка силами IT'' - интерес амбициозного и недостаточно влиятельного IT-департамента

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

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

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

Лотус или не Лотус

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

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

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

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

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

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

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

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

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

- Как с любыми дорогими западными системами, при покупке значительного количества лицензий на Лотус можно рассчитывать на хорошие ``откаты''

- Но полноценные лицензии можно и не покупать - имеются ``бюджетные'' варианты для обеспечения работы через Web.

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

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

Системы, ориентированные исключительно на Oracle, мне неизвестны.

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

Свои форматы хранилищ используют также ``большие'' западные системы - Documentum, HB5 (ex-DocsOpen).

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

Хотя собственное хранилище также обладает некоторыми плюсами - не требуется дополнительно покупать лицензии на СУБД, а с точки зрения администрирования система выступает как единый "черный ящик".

Функциональные критерии

Готовая "коробочная" система или (полу)заказная разработка.

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

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

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

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

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

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

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

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

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

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

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

Но при этом нет никакой гарантии, что в процессе реализации вы не наткнетесь на трудно преодолимые ограничения конструктора

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

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

Вопрос - в соотношении объема базового и прикладного функционала в предлагаемой системе.

Тем не менее водораздел между ними как правило, достаточно четкий.

Если при демонстрации вам системы вы, к примеру, спрашиваете - ``а как осуществляется контроль отправки исходящих документов нашей экспедицией? '', и вам показывают как - скорее всего, вы имеете дело с прикладной системой.

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

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

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

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

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

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

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

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

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

Ориентация на поддержку именно делопроизводства или массовых бизнес-процессов компании.

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

Аналогичная ситуация часто имеет место и с документооборотом, который зачастую также делится на две части:

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

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

При этом эти типы документооборота, как правило, разделены по структурным подразделениям, исполнителям и автоматизированным системам.

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

Документооборот второго типа обслуживается управлением делами, специальным выделенным персоналом (делопроизводителями) и поддерживается системами автоматизации делопроизводства.

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

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

Так вот - все системы, представленные на рынке, можно классифицировать по признаку - на автоматизацию какого типа документооборота они рассчитаны, и соответственно,

кто должен являться основными пользователями системы - делопроизводственный персонал или непосредственно функциональные сотрудники организации.

В названии и/или описании систем системы это различие, как правило, отражается словами ``автоматизация документооборота'' или ``автоматизация делопроизводства''.

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

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

Они в первую очередь применимы в органах государственного управления, а так же в средних и больших компаниях с заметным объемом ``вспомогательного'' документооборота.

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

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

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

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

DMS vs WorkFlow

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

Если система преимущественно ориентирована на поддержку формализованных процессов разработки, согласования и исполнения документов - она относится к классу WORKFLOW.

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

Классический способ использования Workflow-систем - организация массовых процессов обслуживания однотипных документов/запросов.

DMS (Document Managament Systems) в большей степени ориентированы на поддержку "архивной" фазы, когда работа с документом уже закончилась, и теперь его нужно хранить и эффективно искать среди множества других документов.

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

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

Опять же различие не является не очень жестким, так как большие DMS-системы, типа HB5 & Documentum имеют свои workflow-компоненты. Поскольку документы нужно где-то хранить в процессе работы с ними, то все workflow-системы имеют свои ``умолчательные'' хранилища для документов, хотя как правило, умеют работать с разными внешними хранилищами и серверами баз данных.

Прикладные системы неким образом сочетают в себе DMS & Forkflow-функциональность. Но они также зачастую могут быть классифицированы по этой шкале WorkFlow <--> ИПС, в зависимости от того, какие свойства в них выражены сильнее.

Электронный документооборот

Понятие это сейчас очень модное, но писать о нем трудно, так как его содержание еще толком не устоялось.

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

Но некоторые существенные признаки, необходимые для того, чтобы говорить, что система поддерживает ЭД, указать можно. Учитывая, что по одному из определений, электронным считается документ, у которого оригинал существует исключительно в электронном виде, подписанном ЭЦП, система должна обеспечивать

1. Процессы подготовки документов

2. Использование ЭЦП не только при межкорпоративном обмене, но и при работе с документами внутри организации

3. Возможность полноценной работы с документом не только делопроизводителей, но и функциональных сотрудников

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

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

Заключение

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

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

А здесь просто приведем список известных нам систем. Просим извинить, если кто сюда не попал....

Система	Производитель	Ссылка
1С:Архив	1С	http://www.1c.ru/rus/products/1c/arcdoc/default.asp
ALESTA Library	ALESTA Software Services	http://www.alesta.ru/050Dev/030ALib/Default.asp
AquaDoc	Аквариус Консалтинг	http://www.aqc.ru/way/199551.html
CompanyMedia, OfficeMedia	ИнтерТраст	http://www.inttrust.ru/site3/products.nsf/d/products
DIRECTUM	НПО "Компьютер"	http://www.npo-comp.ru/
DIS:системы (ex-Золушка)	Института развития Москвы	http://www.mdi.ru/dis/new/disclass.html
DocBase_I -Комплекс	ПО Комплектсервис	http://www.icomplex.ru/proddocbase.asp
DocsVision	Digital Design	http://www.docsvision.com
Documentum	Documentum	http://www.documentum.ru/products/index.html
DocuShare	XEROX	http://www.xerox.ru/themes/basic/product-group-document.asp?folder=981&matId=827
DWARF	Центр информационных технологий - СИТ	http://cit.org.by
Hummingbird DM5 (ex-DocsOpen)	Hummingbird	http://www.hummingbird.ru/products/rm/overview.html?cks=y
IIG Intravert	IIG (Info Industries Group)	http://www.iig.ru/Products/intravert
IncoFlow	IT InCo	http://www.it-inco.ru/
LanDocs	ЛАНИТ	http://www.landocs.ru/
NauDoc	NAUMEN	http://www.noumen.ru/go/products/naudoc
OPTiMA-WorkFlow	Оптима	http://www.optima-workflow.com/RUS/AboutSystem/
PartY	Лоция Софт	http://www.lotsia.com/
SAPERION	SAPERION	http://www.saperion.ru/index.html
SiTex[tm] Документооборот	Анд Проджект	http://www.mysitex.com/sitex_dokumentooborot.html
Web-Dialog	Web-Segment	http://web-dialog.ru/
БОСС-Референт	АйТи	http://www.it.ru/boss/referent.html
Гран-Док	Гранит-Центр	http://www.granit.ru/products_info.asp?id=10
ДЕЛО	Электронные офисные системы (ЭОС)	http://eos.ru/eos/eos_delo
ДокМенеджер	СофтИнтегро	http://www.softintegro.ru/sftw_dev/doc_manager/
ЕВФРАТ-Документооборот	Cognitive Technologies Ltd	http://www.evfrat.ru/about/
Кодекс: Документооборот	Консорциум Кодекс	http://www.kodeks.net/
ЭСКАДО	Интерпрокомлан	http://www.interprocom.ru/
ЭффектОфис	Гарант Интернэшнл	http://www.garant.spb.ru/offex/eo_start.shtm