 |
Комплексный взгляд на workflow
24.11.03
Мне, разработчику бизнес-приложений, часто приходится беседовать с людьми, которые находятся на стадии выбора того или иного программного инструментария. В частности, те, кто выбирает систему электронного документооборота, нередко предъявляют к ней только требования, специфические именно для этой части корпоративной информационной системы. Разговор идет в основном об удобстве и качестве ввода отсканированных бумажных документов, возможности их перевода в различные текстовые форматы, обсуждаются средства хранения полученных текстов, анализируется решение проблем workflow и пр.
Такой подход выглядит странным, ведь мы живем в эпоху сквозной автоматизации, а посему все проблемы надо рассматривать с точки зрения комплексности корпоративной информационной системы. Основой организации комплексной системы является модель учета «от первичного документа»; следовательно, подсистема документооборота становится стержнем корпоративной информационной системы.
При такой модели исходными данными, которые вводятся в систему, являются именно первичные документы. Немного утрируя, можно сказать, что вся остальная учетная информация (она одновременно служит основой оперативного и долгосрочного планирования) получается посредством обработки данных, имеющихся в первичных документах. В процессе обработки первичная информация может быть дополнена некоторыми атрибутами, взятыми из справочников или введенными оператором; скажем, в ходе бухгалтерской разноски вводятся счета бухучета. Очень важно, что основной массив данных не вводится повторно. Это, с одной стороны, минимизирует объем учетных работ в целом по предприятию, а с другой — позволяет уменьшить количество ошибок, неизбежно возникающих в процессе ручного ввода.
Подобная организация корпоративной информационной системы кардинально меняет критерии выбора средств документооборота. На первый план выступают вопросы их интеграции с другими подсистемами, быстрого оформления первичных документов. В то же время проблемы, связанные со сканированием «бумажек» и распознаванием образов, становятся менее актуальными, поскольку основная информация готовится на компьютере. Возможность сканирования пока все еще очень полезна для ввода документов, поступивших «со стороны». Однако думается, что это ненадолго, ведь электронный обмен данными между организациями развивается семимильными шагами. Свидетельств тому немало: это и получившие широкое распространение системы «клиент-банк», и электронные форматы сдачи отчетности в налоговые органы, и, главное, унифицированные стандарты, которые уже находят отклик в сердцах разработчиков программного обеспечения делового назначения; среди подобных стандартов на первом месте с большим отрывом идет XML.
Часто говорят: «Конечно, интеграция необходима, но мы решим эту проблему за счет создания межпрограммных шлюзов». Несомненно, такое решение имеет право на существование, однако практика показывает, что качество «шлюзования» невысоко. Во-первых, нередко снижается оперативность поступления данных из одной подсистемы в другую. Во-вторых, зачастую такой вариант ведет к двойному вводу нормативно-справочной информации. А это не только двойной объем работы, но и — что гораздо важнее — постоянно возникающие рассогласования между справочниками различных подсистем.
Вот простой пример. Одним из основных элементов автоматизации документооборота является справочник партнеров, где хранятся все их реквизиты, необходимые для быстрого оформления документов. Но в таком справочнике нуждается и подсистема управления финансами, в которой коды партнеров выступают в качестве аналитических шифров к некоторым счетам бухгалтерского учета. Кроме того, на кодах базируется и управление взаиморасчетами. Если документооборот и бухгалтерия связаны посредством шлюза, то постоянно возникают ситуации, когда под одним и тем же кодом бухгалтер и готовящий документы менеджер заносят — каждый в свой справочник — разных контрагентов. В результате при импорте в финансовую подсистему происходит путаница: например, платежи, отправленные одному партнеру, ведут к снижению кредиторской задолженности совсем другому.
Оценивая взаимодействие системы документооборота с другими подсистемами, следует помнить, что помимо прямой связи необходима и обратная. При подготовке документов удобно бывает получать информацию из самых разных частей корпоративной информационной системы. Например, при подготовке документов на частичную оплату поставок хорошо бы знать задолженность по тому или иному счету или по контрагенту в целом. Эта сумма хранится, как правило, в базе данных подсистемы контроля взаиморасчетов или же рассчитывается этой подсистемой «на лету». Возможность автоматического занесения задолженности в поле «сумма» платежки украсит жизнь пользователя. Точно так же подсистема расчета зарплаты должна обеспечивать автоматическую выдачу рассчитанных сумм налогов при подготовке платежных поручений в налоговые органы, сумм «на руки» при оформлении кассовых ордеров, алиментов при формировании почтовых переводов и т. п. При выборе системы документооборота надо составить полный перечень всех необходимых предприятию обратных связей и тщательно оценить, насколько удобно они реализованы в программе. (Кстати, — если я ошибаюсь, то пусть читатели меня поправят, — если прямую связь через «шлюзование» реализовать не так сложно, то обратную — невозможно.)
Обмен данными в корпоративной информационной системе
Остановимся подробнее на процессе занесения информации, полученной из первичного документа, в учетные подсистемы. Он может инициироваться по запросу пользователя (иначе говоря, вручную) или самим программным обеспечением, то есть автоматически. К сожалению, поддержка ручного варианта ввода по-прежнему остается актуальной. Его необходимость диктуется существующей практикой работы, при которой отнюдь не все однородные документы отражаются в учетной информации, или, используя общепринятые эвфемизмы, существует разница между управленческим и финансовым учетом.
Почему к сожалению? Да потому, что чем больше бизнес-процессов удается перевести в автоматический режим, тем ощутимее эффект от использования программного обеспечения! Трудозатраты на подготовку документов однозначно коррелируют со средней скоростью их подготовки. Кроме того, человеку свойственно ошибаться. Всегда существует вероятность того, что, пока сотрудники обработают документ (или создадут полную пачку документов, которые с ним связаны), кто-нибудь что-нибудь да забудет, после чего какое-то время придется потратить на выяснение того, что же было упущено. В полностью автоматическом режиме трудозатраты на поиск ошибок минимизируются.
Снижение дает и существенный дополнительный эффект. Например, если на основе снижения трудозатрат добиться кадровых сокращений, то это приведет к прямому повышению эффективности бизнеса.
Бывает и так, что кадровые сокращения не дают прямого денежного эффекта, так как тот же фонд зарплаты просто распределяется на меньшее количество сотрудников. Но и тут есть свои преимущества. Во-первых, такая ситуация повышает конкурентоспособность предприятия, которое в результате побеждает в соревновании за более квалифицированные кадры. Во-вторых, предоставляется возможность возложить на сотрудника дополнительные функции, которые раньше просто не выполнялись, поскольку для этого не было ресурсов. К примеру, введение CRM-системы разгрузило маркетологов одного из наших клиентов от рутины, и они смогли тем же штатом, что и раньше, организовать регулярный анализ деловой прессы и Internet для поиска сообщений о получении различными предприятиями крупных заказов и выявления таким образом потенциальных клиентов.
Несколько иной вариант экономии был осуществлен у других наших клиентов — на Ломоносовском фарфоровом заводе. В результате замены старой программы расчета зарплаты на систему управления персоналом они сократили рабочее время расчетчиков. Увольнять никого не стали, но по мере ухода сотрудников на пенсию или на другие предприятия на их место никого не нанимали, а функции этих сотрудников передавали другим сотрудникам расчетного отдела.
А вот обратный пример. Хорошо известно, что сейчас оптовая торговля медикаментами — выгодный бизнес, поэтому и конкуренция здесь очень высока. Одна из ведущих питерских фирм, специализирующихся в этой области, несколько лет назад приняла решение о замене собственного программного обеспечения (кстати, прекрасно работавшего в качестве учетной системы) на более функционально насыщенный комплекс. Было принято решение внедрить один из самых современных западных пакетов управления предприятием в надежде задействовать богатые аналитические возможности и развитую поддержку принятия решений. Внедрили. Сразу же выяснилось, что транспортные документы в системе выписываются крайне медленно. У столов менеджеров по продажам стали образовываться очереди из экспедиторов заказчиков, у которых простаивал транспорт. Им это не нравилось, и они начали уходить к конкурентам. Прямо из очереди! В результате анализировать и вести стало просто нечего.
Надеюсь, этих примеров достаточно, чтобы показать, почему снижение трудоемкости подготовки документов я считаю важным критерием.
Интеграция бизнес-систем
Можно выделить три модели автоматической совместной работы подсистем в режиме, близком к реальному времени. Первую назовем «подокументной». Эта модель предполагает, что каждой бизнес-процедуре, меняющей состояние учетных подсистем, соответствует свой тип документа. Состояние меняется только в момент занесения в базу данных нового документа или корректировки любых атрибутов уже имеющегося. Эта модель удобна в тех случаях, когда согласно принятой в организации технологии управления нет разницы между временем выпуска документа и временем корректировки учетных записей. Например, если накладная выпускается только в связи с реальной выдачей материалов со склада.
Вторая модель называется «событийной» (или «статусной»). В ней изменение состояния системы происходит в случае изменения статуса документа, всего лишь одного поля описывающей его записи. Это очень удобно, когда существуют значительные временные разрывы между выпуском документа и его утверждением. Правда, и в «подокументной» технологии можно моделировать подобные бизнес-процессы, например, за счет наличия документов-черновиков, заявок, заказов и пр., а также аппарата создания документов по образцу, о котором мы поговорим чуть ниже. Однако этот вариант часто ведет к избыточному разрастанию базы данных.
Наконец, третья модель является смешанной, позволяющей настраивать каждую конкретную разновидность документов на работу в соответствии с одной из двух указанных выше моделей. В преимуществе такого подхода в последнее время приходится убеждаться все чаще; на сегодняшний день я считаю его оптимальным.
Документооборот решает не все
Удобство и качество взаимодействия системы документооборота с остальными частями комплекса являются, на мой взгляд, ключевым, но отнюдь не единственным критерием ее оценки. Следующий по значению параметр — удобство интерфейса для переноса данных из одного документа в другой. Очень часто бывает нужно подготовить новый документ на основании того, что уже хранится в базе (например, акт о выполнении работ по какому-либо этапу хозяйственного договора или же платежное поручение на основании счета поставщика). Очевидно, что подавляющее большинство данных в имеющемся и новом документах будет совпадать.
Чтобы минимизировать труд пользователей и избежать ошибок, возникающих в процессе повторного ввода информации, многие разработчики включают в свои программы понятие «прототипа». Иначе говоря, они предоставляют пользователям инструмент для создания документов по образу и подобию тех, что когда-то уже были введены в систему. Этот инструмент может содержать в себе и перенос в создаваемый документ части данных из документа-прототипа, а также включение данных, содержащихся в различных учетных подсистемах (например, занесение величины полной кредиторской задолженности по тому или иному счету или партнеру в целом в качестве суммы платежа). Это та самая обратная связь с другими подсистемами, о которой говорилось выше.
Еще одним удобным способом создания документа по образцу является возможность дать команду «скопировать текущую запись в новую».
Третий критерий тесно связан с предыдущим. Когда мы пользуемся аппаратом прототипов, это не должно проходить бесследно. Информацию о том, что являлось основанием создания документа, следует хранить в базе данных.
Еще лучше, если в системе имеется понятие пачки, или пакета документов, когда организована возможность одновременной подготовки сразу всех документов, которые требуются для проведения той или иной бизнес-процедуры. Например, если оператор отгружает товар за наличный расчет, то система может сразу же выдать ему и изменяющую складские остатки накладную, и приходный кассовый ордер, и счет-фактуру, и, если надо, акт к договору на поставку. Помимо очевидного удобства, понятие пачки хорошо тем, что не приходится держать в уме уйму информации.
Удобной бывает и возможность синхронной корректировки, когда при изменении одного документа из пачки автоматически меняются и все остальные, а также возможность совместного удаления.
Четвертая черта, реализация которой делает жизнь пользователя «легче и веселее», — пакетная обработка документов. Если есть возможность отметить нужные записи и дать команду «создать по образцу каждого из них новый документ другого типа» или «выполнить бухгалтерскую разноску всех выбранных», то это также минимизирует временные затраты.
Пятый критерий относится к области классических систем документооборота. Хотя я и критиковал пользователей выше, которые интересуются при отборе программного обеспечения только такой спецификой, следует признать, что реализация функций workflow очень нужна. Схемы прохождения документов по инстанциям с нормативными сроками, а еще лучше — и со сроками создания новых документов по образцу существующих — помогают улучшить организацию работы предприятия, повысить исполнительскую дисциплину.
Шестым критерием я бы назвал удобную систему автоматической нумерации документов. Пользователь должен иметь возможность настроить ее: приписать к изменяющейся части произвольный префикс и суффикс (часто в качестве суффикса выступает номер года); задать период нумерации (месяц, квартал, год или «вечность»), по окончании которого она автоматически начинается с единицы; организовать контроль на повтор номеров различной степени жесткости; установить совместную сквозную нумерацию нескольких типов и т. д.
Наконец, хочется сказать о требованиях к гибкости. Очень хорошо, если система позволяет быстро и просто менять формы экранного представления как перечней (реестров), так и отдельных документов. Естественно, что такой инструмент должен давать возможность передвигать поля ввода и визуализации с помощью мыши. Хорошо, если в экранную форму можно вводить элементы типа «страницы» (систему закладок), «таблица», «переключатель», «кнопка», «выпадающий список», «рисунок из файла». Большим удобством является возможность группировки нескольких элементов, после чего они будут перемещаться совместно в процессе настройки формы. Нужно уметь не только рисовать внешний вид, но и связывать элементы документа с полями таблиц базы данных. Существенны также средства описания вычисляемых элементов, значение которых автоматически меняется при изменении значений в других полях ввода.
Ну а необходимость наличия хорошего генератора отчетов и печатных форм документов (желательно, интегрированных с Microsoft Office) просто очевидна.
Приведенный перечень критериев оценки программного обеспечения для автоматизации документооборота отнюдь не является полным и окончательным. Наверняка сюда можно добавить еще какие-то значимые параметры. Более того, каждый конкретный проект имеет свои характерные черты, влияющие как на состав списка, так и на порядок критериев в нем. Тем не менее описанные моменты должны являться, на мой взгляд, существенными факторами выбора.
Игорь Якобсон, главный эксперт компании «Компас»
Такой подход выглядит странным, ведь мы живем в эпоху сквозной автоматизации, а посему все проблемы надо рассматривать с точки зрения комплексности корпоративной информационной системы. Основой организации комплексной системы является модель учета «от первичного документа»; следовательно, подсистема документооборота становится стержнем корпоративной информационной системы.
При такой модели исходными данными, которые вводятся в систему, являются именно первичные документы. Немного утрируя, можно сказать, что вся остальная учетная информация (она одновременно служит основой оперативного и долгосрочного планирования) получается посредством обработки данных, имеющихся в первичных документах. В процессе обработки первичная информация может быть дополнена некоторыми атрибутами, взятыми из справочников или введенными оператором; скажем, в ходе бухгалтерской разноски вводятся счета бухучета. Очень важно, что основной массив данных не вводится повторно. Это, с одной стороны, минимизирует объем учетных работ в целом по предприятию, а с другой — позволяет уменьшить количество ошибок, неизбежно возникающих в процессе ручного ввода.
Подобная организация корпоративной информационной системы кардинально меняет критерии выбора средств документооборота. На первый план выступают вопросы их интеграции с другими подсистемами, быстрого оформления первичных документов. В то же время проблемы, связанные со сканированием «бумажек» и распознаванием образов, становятся менее актуальными, поскольку основная информация готовится на компьютере. Возможность сканирования пока все еще очень полезна для ввода документов, поступивших «со стороны». Однако думается, что это ненадолго, ведь электронный обмен данными между организациями развивается семимильными шагами. Свидетельств тому немало: это и получившие широкое распространение системы «клиент-банк», и электронные форматы сдачи отчетности в налоговые органы, и, главное, унифицированные стандарты, которые уже находят отклик в сердцах разработчиков программного обеспечения делового назначения; среди подобных стандартов на первом месте с большим отрывом идет XML.
Часто говорят: «Конечно, интеграция необходима, но мы решим эту проблему за счет создания межпрограммных шлюзов». Несомненно, такое решение имеет право на существование, однако практика показывает, что качество «шлюзования» невысоко. Во-первых, нередко снижается оперативность поступления данных из одной подсистемы в другую. Во-вторых, зачастую такой вариант ведет к двойному вводу нормативно-справочной информации. А это не только двойной объем работы, но и — что гораздо важнее — постоянно возникающие рассогласования между справочниками различных подсистем.
Вот простой пример. Одним из основных элементов автоматизации документооборота является справочник партнеров, где хранятся все их реквизиты, необходимые для быстрого оформления документов. Но в таком справочнике нуждается и подсистема управления финансами, в которой коды партнеров выступают в качестве аналитических шифров к некоторым счетам бухгалтерского учета. Кроме того, на кодах базируется и управление взаиморасчетами. Если документооборот и бухгалтерия связаны посредством шлюза, то постоянно возникают ситуации, когда под одним и тем же кодом бухгалтер и готовящий документы менеджер заносят — каждый в свой справочник — разных контрагентов. В результате при импорте в финансовую подсистему происходит путаница: например, платежи, отправленные одному партнеру, ведут к снижению кредиторской задолженности совсем другому.
Оценивая взаимодействие системы документооборота с другими подсистемами, следует помнить, что помимо прямой связи необходима и обратная. При подготовке документов удобно бывает получать информацию из самых разных частей корпоративной информационной системы. Например, при подготовке документов на частичную оплату поставок хорошо бы знать задолженность по тому или иному счету или по контрагенту в целом. Эта сумма хранится, как правило, в базе данных подсистемы контроля взаиморасчетов или же рассчитывается этой подсистемой «на лету». Возможность автоматического занесения задолженности в поле «сумма» платежки украсит жизнь пользователя. Точно так же подсистема расчета зарплаты должна обеспечивать автоматическую выдачу рассчитанных сумм налогов при подготовке платежных поручений в налоговые органы, сумм «на руки» при оформлении кассовых ордеров, алиментов при формировании почтовых переводов и т. п. При выборе системы документооборота надо составить полный перечень всех необходимых предприятию обратных связей и тщательно оценить, насколько удобно они реализованы в программе. (Кстати, — если я ошибаюсь, то пусть читатели меня поправят, — если прямую связь через «шлюзование» реализовать не так сложно, то обратную — невозможно.)
Обмен данными в корпоративной информационной системе
Остановимся подробнее на процессе занесения информации, полученной из первичного документа, в учетные подсистемы. Он может инициироваться по запросу пользователя (иначе говоря, вручную) или самим программным обеспечением, то есть автоматически. К сожалению, поддержка ручного варианта ввода по-прежнему остается актуальной. Его необходимость диктуется существующей практикой работы, при которой отнюдь не все однородные документы отражаются в учетной информации, или, используя общепринятые эвфемизмы, существует разница между управленческим и финансовым учетом.
Почему к сожалению? Да потому, что чем больше бизнес-процессов удается перевести в автоматический режим, тем ощутимее эффект от использования программного обеспечения! Трудозатраты на подготовку документов однозначно коррелируют со средней скоростью их подготовки. Кроме того, человеку свойственно ошибаться. Всегда существует вероятность того, что, пока сотрудники обработают документ (или создадут полную пачку документов, которые с ним связаны), кто-нибудь что-нибудь да забудет, после чего какое-то время придется потратить на выяснение того, что же было упущено. В полностью автоматическом режиме трудозатраты на поиск ошибок минимизируются.
Снижение дает и существенный дополнительный эффект. Например, если на основе снижения трудозатрат добиться кадровых сокращений, то это приведет к прямому повышению эффективности бизнеса.
Бывает и так, что кадровые сокращения не дают прямого денежного эффекта, так как тот же фонд зарплаты просто распределяется на меньшее количество сотрудников. Но и тут есть свои преимущества. Во-первых, такая ситуация повышает конкурентоспособность предприятия, которое в результате побеждает в соревновании за более квалифицированные кадры. Во-вторых, предоставляется возможность возложить на сотрудника дополнительные функции, которые раньше просто не выполнялись, поскольку для этого не было ресурсов. К примеру, введение CRM-системы разгрузило маркетологов одного из наших клиентов от рутины, и они смогли тем же штатом, что и раньше, организовать регулярный анализ деловой прессы и Internet для поиска сообщений о получении различными предприятиями крупных заказов и выявления таким образом потенциальных клиентов.
Несколько иной вариант экономии был осуществлен у других наших клиентов — на Ломоносовском фарфоровом заводе. В результате замены старой программы расчета зарплаты на систему управления персоналом они сократили рабочее время расчетчиков. Увольнять никого не стали, но по мере ухода сотрудников на пенсию или на другие предприятия на их место никого не нанимали, а функции этих сотрудников передавали другим сотрудникам расчетного отдела.
А вот обратный пример. Хорошо известно, что сейчас оптовая торговля медикаментами — выгодный бизнес, поэтому и конкуренция здесь очень высока. Одна из ведущих питерских фирм, специализирующихся в этой области, несколько лет назад приняла решение о замене собственного программного обеспечения (кстати, прекрасно работавшего в качестве учетной системы) на более функционально насыщенный комплекс. Было принято решение внедрить один из самых современных западных пакетов управления предприятием в надежде задействовать богатые аналитические возможности и развитую поддержку принятия решений. Внедрили. Сразу же выяснилось, что транспортные документы в системе выписываются крайне медленно. У столов менеджеров по продажам стали образовываться очереди из экспедиторов заказчиков, у которых простаивал транспорт. Им это не нравилось, и они начали уходить к конкурентам. Прямо из очереди! В результате анализировать и вести стало просто нечего.
Надеюсь, этих примеров достаточно, чтобы показать, почему снижение трудоемкости подготовки документов я считаю важным критерием.
Интеграция бизнес-систем
Можно выделить три модели автоматической совместной работы подсистем в режиме, близком к реальному времени. Первую назовем «подокументной». Эта модель предполагает, что каждой бизнес-процедуре, меняющей состояние учетных подсистем, соответствует свой тип документа. Состояние меняется только в момент занесения в базу данных нового документа или корректировки любых атрибутов уже имеющегося. Эта модель удобна в тех случаях, когда согласно принятой в организации технологии управления нет разницы между временем выпуска документа и временем корректировки учетных записей. Например, если накладная выпускается только в связи с реальной выдачей материалов со склада.
Вторая модель называется «событийной» (или «статусной»). В ней изменение состояния системы происходит в случае изменения статуса документа, всего лишь одного поля описывающей его записи. Это очень удобно, когда существуют значительные временные разрывы между выпуском документа и его утверждением. Правда, и в «подокументной» технологии можно моделировать подобные бизнес-процессы, например, за счет наличия документов-черновиков, заявок, заказов и пр., а также аппарата создания документов по образцу, о котором мы поговорим чуть ниже. Однако этот вариант часто ведет к избыточному разрастанию базы данных.
Наконец, третья модель является смешанной, позволяющей настраивать каждую конкретную разновидность документов на работу в соответствии с одной из двух указанных выше моделей. В преимуществе такого подхода в последнее время приходится убеждаться все чаще; на сегодняшний день я считаю его оптимальным.
Документооборот решает не все
Удобство и качество взаимодействия системы документооборота с остальными частями комплекса являются, на мой взгляд, ключевым, но отнюдь не единственным критерием ее оценки. Следующий по значению параметр — удобство интерфейса для переноса данных из одного документа в другой. Очень часто бывает нужно подготовить новый документ на основании того, что уже хранится в базе (например, акт о выполнении работ по какому-либо этапу хозяйственного договора или же платежное поручение на основании счета поставщика). Очевидно, что подавляющее большинство данных в имеющемся и новом документах будет совпадать.
Чтобы минимизировать труд пользователей и избежать ошибок, возникающих в процессе повторного ввода информации, многие разработчики включают в свои программы понятие «прототипа». Иначе говоря, они предоставляют пользователям инструмент для создания документов по образу и подобию тех, что когда-то уже были введены в систему. Этот инструмент может содержать в себе и перенос в создаваемый документ части данных из документа-прототипа, а также включение данных, содержащихся в различных учетных подсистемах (например, занесение величины полной кредиторской задолженности по тому или иному счету или партнеру в целом в качестве суммы платежа). Это та самая обратная связь с другими подсистемами, о которой говорилось выше.
Еще одним удобным способом создания документа по образцу является возможность дать команду «скопировать текущую запись в новую».
Третий критерий тесно связан с предыдущим. Когда мы пользуемся аппаратом прототипов, это не должно проходить бесследно. Информацию о том, что являлось основанием создания документа, следует хранить в базе данных.
Еще лучше, если в системе имеется понятие пачки, или пакета документов, когда организована возможность одновременной подготовки сразу всех документов, которые требуются для проведения той или иной бизнес-процедуры. Например, если оператор отгружает товар за наличный расчет, то система может сразу же выдать ему и изменяющую складские остатки накладную, и приходный кассовый ордер, и счет-фактуру, и, если надо, акт к договору на поставку. Помимо очевидного удобства, понятие пачки хорошо тем, что не приходится держать в уме уйму информации.
Удобной бывает и возможность синхронной корректировки, когда при изменении одного документа из пачки автоматически меняются и все остальные, а также возможность совместного удаления.
Четвертая черта, реализация которой делает жизнь пользователя «легче и веселее», — пакетная обработка документов. Если есть возможность отметить нужные записи и дать команду «создать по образцу каждого из них новый документ другого типа» или «выполнить бухгалтерскую разноску всех выбранных», то это также минимизирует временные затраты.
Пятый критерий относится к области классических систем документооборота. Хотя я и критиковал пользователей выше, которые интересуются при отборе программного обеспечения только такой спецификой, следует признать, что реализация функций workflow очень нужна. Схемы прохождения документов по инстанциям с нормативными сроками, а еще лучше — и со сроками создания новых документов по образцу существующих — помогают улучшить организацию работы предприятия, повысить исполнительскую дисциплину.
Шестым критерием я бы назвал удобную систему автоматической нумерации документов. Пользователь должен иметь возможность настроить ее: приписать к изменяющейся части произвольный префикс и суффикс (часто в качестве суффикса выступает номер года); задать период нумерации (месяц, квартал, год или «вечность»), по окончании которого она автоматически начинается с единицы; организовать контроль на повтор номеров различной степени жесткости; установить совместную сквозную нумерацию нескольких типов и т. д.
Наконец, хочется сказать о требованиях к гибкости. Очень хорошо, если система позволяет быстро и просто менять формы экранного представления как перечней (реестров), так и отдельных документов. Естественно, что такой инструмент должен давать возможность передвигать поля ввода и визуализации с помощью мыши. Хорошо, если в экранную форму можно вводить элементы типа «страницы» (систему закладок), «таблица», «переключатель», «кнопка», «выпадающий список», «рисунок из файла». Большим удобством является возможность группировки нескольких элементов, после чего они будут перемещаться совместно в процессе настройки формы. Нужно уметь не только рисовать внешний вид, но и связывать элементы документа с полями таблиц базы данных. Существенны также средства описания вычисляемых элементов, значение которых автоматически меняется при изменении значений в других полях ввода.
Ну а необходимость наличия хорошего генератора отчетов и печатных форм документов (желательно, интегрированных с Microsoft Office) просто очевидна.
Приведенный перечень критериев оценки программного обеспечения для автоматизации документооборота отнюдь не является полным и окончательным. Наверняка сюда можно добавить еще какие-то значимые параметры. Более того, каждый конкретный проект имеет свои характерные черты, влияющие как на состав списка, так и на порядок критериев в нем. Тем не менее описанные моменты должны являться, на мой взгляд, существенными факторами выбора.
Игорь Якобсон, главный эксперт компании «Компас»
