К выбору систем автоматизации документооборота
АрхивС того самого 1999 года, когда я всерьез заинтересовался системами документооборота и делопроизводства, я как минимум четыре раза наблюдал попытки провести сравнительный анализ систем, имеющихся на рынке, и составить сводную табличку.
С того самого 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 на одного пользователя), предоставляющие неограниченные перспективы удовлетворения материальных притязаний заинтересованных лиц.
Лицензии на прикладные системы обычно обходятся в несколько сотен долларов на одного пользователя. Правда, поставщики, как правило, предлагают дополнительные услуги по обследованию, внедрению и обучению, которые позволяют увеличить стоимость проекта в разы и, соответственно, тоже создать приличную базу для удовлетворения материальных интересов.
Ориентация на поддержку собственно делопроизводства или массовых бизнес-процессов компании
Я опять проведу аналогию с бухгалтерией. Как известно, бухгалтерский учет в любой коммерческой организации состоит из двух частей: учета, связанного с основной производственной деятельностью, оперирующего большим количеством однотипных проводок, и учета всего остального — основных фондов, заработной платы, прочих накладных расходов, командировочных, малоценки и пр., что в общем количестве проводок и проходящих суммах составляет малую часть, но генерирует основное разнообразие проводок, на автоматизации которых обломало зубы большинство разработчиков доморощенных бухгалтерских систем.
Похожая ситуация порой имеет место и с документооборотом, который нередко тоже делится на две части:
- Документооборот, обслуживающий основную производственную деятельность, оперирующий большим количеством однотипных документов, исполняемых по стандартным процедурам (для сотовых операторов — договора на подключение и набор типовых заявлений, для банков — платежные и другие поручения и т. д.).
- Прочий документооборот, как правило, меньший по объему, но гораздо более разнообразный по типам документов и процедурам их обработки (исполнение распоряжений вышестоящих организаций и руководства, договора «обслуживающих» подразделений и др.).
Эти типы документооборота, как правило, разделены по структурным подразделениям, исполнителям и автоматизированным системам. Массовый документооборот обрабатывается функциональными подразделениями, обслуживается специфическими корпоративными информационными системами и зачастую вообще не проходит через канцелярию. Документооборот второго типа обслуживается управлением делами, специальным персоналом (делопроизводителями) и поддерживается системами автоматизации делопроизводства.
Существуют «вырожденные» типы организаций, где основной документопоток относится ко второму типу, — например, органы государственного управления (хотя там иногда тоже существуют сегменты массового типового документооборота — например, обращения и письма граждан). В таких организациях, а также в средних и больших компаниях с заметным объемом «вспомогательного» документооборота как раз и нужны системы автоматизации делопроизводства.
Есть также организации, у которых имеется массовый типовой поток документов, но они либо недостаточно хорошо обрабатываются используемой КИС, либо никакой специальной системы вообще не имеется. В таких организациях в первую очередь стоит именно вопрос автоматизации массового типового документооборота.
Так вот: все системы можно классифицировать по тому, на автоматизацию какого типа документооборота они рассчитаны и соответственно, кто должен являться основным пользователем системы — делопроизводственный персонал или функциональные сотрудники организации.
В названии и/или описании систем это различие, как правило, отражается словами «автоматизация документооборота» или «автоматизация делопроизводства». Первые обычно ближе к конструкторам (поскольку должны позволять настройку на конкретные бизнес-процессы). Приобретать их имеет смысл, если организация не использует корпоративную информационную систему или она используется, но недостаточно хорошо поддерживает собственно функцию документооборота.
Системы автоматизации делопроизводства хуже настраиваются, зато содержат массу специфического функционала (специфическая система ролей пользователей, специфическая терминология, учет организационной структуры при определении маршрутов, учет движения бумажных оригиналов документов и др.), и вовсе не факт, что весь этот функционал удастся воспроизвести на конкретном конструкторе. Они в первую очередь применимы в органах государственного управления, а также в средних и крупных компаниях с солидным объемом «вспомогательного» документооборота.
Конечно, между двумя описанными типами документооборота существует пересечение, как и между функционалом этих двух типов систем. И идеальной является ситуация, когда используется одна система, поддерживающая оба типа документооборота. К сожалению, этого удается достичь нечасто и, как правило, в ущерб либо одной категории пользователей (делопроизводители), либо другой (функциональные подразделения).
В качестве аналогии опять приведем вопросы финансового учета: зачастую для оперативного и управленческого учета, с одной стороны, и фискального бухгалтерского — с другой, используются разные системы. А попытки объединить оперативный, управленческий и бухгалтерский учет в одной системе обеспечили фиаско не одному проекту внедрения КИС.
Впрочем, описанное противопоставление не является абсолютно жестким. Многие системы автоматизации делопроизводства имеют механизмы расширения и настройки на конкретные типы документов, и практически все конструкторы позволяют поддержать основы автоматизации делопроизводства (регистрацию входящих/исходящих, резолюции и контроль исполнения) для не слишком требовательного управления делами. Поэтому выбор между этими классами систем определяется тем, кто выступает основным инициатором закупки. Если управление делами — целесообразнее покупать систему автоматизации делопроизводства. Если основные подразделения — лучше купить конструктор, ориентированный на построение систем массового обслуживания.
DMS vs Workflow
Любой документ имеет свой жизненный цикл — он создается, проходит некий путь, а затем упокоивается в архиве. На каждом этапе с ним работают разные группы пользователей. И системы можно классифицировать по тому, какой этап жизненного цикла они обслуживают.
Если система преимущественно ориентирована на поддержку формализованных процессов разработки, согласования и исполнения документов — она относится к классу Workflow.
Workflow-системы оперируют такими понятиями, как маршруты, списки работ и др., и обеспечивают функции доставки документов исполнителям разными транспортами, контроля исполнения и др. Классический способ использования Workflow-систем — организация массовых процессов обслуживания однотипных документов/запросов.
DMS (Document Managament Systems) в большей степени ориентированы на поддержку «архивной» фазы, когда работа с документом уже закончилась и теперь его нужно хранить и эффективно искать среди множества других документов. Они, как правило, имеют средства поддержки очень больших массивов данных, развитые механизмы поиска и группировки документов, включая полуинтеллектуальные, всякие опции типа автоматической рубрикации погружаемых в них документов, поддержку работы с внешними хранилищами и др.
Классический способ использования DMS-систем — организация корпоративного архива. И в этом смысле предельным случаем DMS являются так называемые информационно-поисковые системы (ИПС), ориентированные в основном на поиск и извлечение документов, а погружение новых документов — обставляющие некими специальными процедурами.
Опять же различие является не очень жестким, так как большие DMS-системы, типа HB5 & Documentum, имеют свои Workflow-компоненты. Поскольку документы нужно где-то хранить в процессе работы с ними, то все Workflow-системы имеют свои «умолчательные» хранилища для документов, хотя, как правило, умеют работать с разными внешними хранилищами и серверами баз данных.
Прикладные системы неким образом сочетают в себе DMS & Forkflow-функциональность. Но они также могут быть классифицированы по шкале Workflow Ц ИПС, в зависимости от того, какие свойства в них выражены сильнее.
Электронный документооборот
Понятие очень модное, но писать о нем трудно, так как его содержание еще толком не устоялось.
Поскольку всё, что циркулирует и хранится во всех без исключения системах, — по определению электронное, выяснилось, что все, оказывается, разговаривают прозой и поддерживают электронный документооборот. А электронно-цифровую подпись при пересылке документов (причем, естественно, в сертифицированном покойным ФАПСИ варианте) сейчас не поддерживает только ленивый.
Но некоторые признаки, позволяющие говорить, что система поддерживает ЭД, указать можно. Учитывая, что по одному из определений электронным считается документ, у которого оригинал существует исключительно в электронном виде, подписанном ЭЦП, система должна обеспечивать:
- Процессы подготовки документов.
- Использование ЭЦП не только при межкорпоративном обмене, но и при работе с документами внутри организации.
- Возможность полноценной работы с документом не только делопроизводителей, но и функциональных сотрудников.
Кроме того, интересен не столько конечный результат (чисто электронный документооборот), сколько процесс перехода к нему. Поэтому критически важным является наличие в системе поддержки смешанного документооборота (бумажно-электронного) и поддержка процессов перехода от бумажного к электронному документообороту.
А переход этот происходит через работу с электронными образами бумажных документов. Поэтому система должна обеспечивать как полноценную работу с образами документов, так и получение этих образов в массовом количестве и увязывание их с учетными карточками документов (поточное сканирование).
Заключение
Здесь бы надо было привести ту самую сводную табличку относительно рассмотренных в статье критериев. Но не хочется — так как наверняка найдется немало разработчиков, которые сочтут, что я неправильно позиционирую их продукт.
Поэтому пусть заинтересованные лица делают выводы сами, благо информации для этого вполне достаточно в общедоступных источниках и на сайтах компаний.
А здесь просто приведем список известных нам систем. Просим извинить, если кто-то сюда не попал…
