Управленческий документооборот. От бумажного к электронному

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

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

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

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

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

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

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

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

Иными словами, в приведенном условном примере максимальную оценку получили программные продукты А (90 баллов по функциональным требованиям и 85 по системно-техническим) и В (83 балла по функциональным требованиям и 87 по системно-техническим).

Таблица 7

Пример заполнения таблицы экспертной оценки программных продуктов

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