4 июня 2015
Отвечает Илья Константинов, эксперт департамента корпоративных систем Digital Design
Как адаптировать систему к росту компании?
Начальник отдела ДОУ, Томская обл.
Рост компании может сопровождаться географической экспансией, усложнением организационной структуры компании и коммуникаций, а также освоением новых процессов и технологий. Чтобы адаптировать систему к росту компании необходимо предусмотреть множество моментов как организационных, так и технических.
На техническом и программном уровнях важно заранее спланировать границы системы и проекта, причем как актуальные на данный момент, так и те, которые станут таковыми в будущем. Нужно понять, какие подразделения, включая удаленные, будут работать в системе, сколько всего пользователей требуется сейчас и сколько должны будут включиться в работу через год-два. Кроме того, необходимо заложить возможность наращивания мощности серверного оборудования адекватно росту данных и интенсивности нагрузки, включая возможности виртуализации серверов и мобильного защищенного доступа. При этом необходимо учитывать текущие и будущие расходы на приобретение и владение программным обеспечением. Также нельзя забывать о развитии средств администрирования системы, включая постоянный мониторинг ее состояния и доступности, и при этом создавать единое пространство для масштабирования системы (единый домен или доверительные отношения доменов организации, высокоскоростные каналы связи, защищенная среда передачи данных).
Многое потребуется сделать и на прикладном уровне. Так, в ходе проектирования системы нужно стараться выделить паттерны, закономерности, шаблоны. Стоит как следует продумать структуру данных.
К примеру, каким должен быть справочник номенклатуры дел, чтобы сегодня в него было удобно загружать и использовать данные для участвующих подразделений, а через год – для всех вновь подключенных.
Задайтесь вопросом, какие функции, контуры и конфигурации системы в целом будут повторяться для разных подразделений и процессов? Можно ли их шаблонизировать, т. е. сделать процесс их дельнейшего тиражирования и масштабирования более легким или (полу) автоматическим?
Так, в шаблоне маршрута согласования, в котором есть четыре этапа (рецензирование, согласование, консолидация и подписание), часть этапов (например, первые три) актуальна для подразделений А и Б, а для подразделений В и Г – нет; при этом шаблон маршрута можно сделать единым для всех подразделений, таким, чтобы в случае использования его подразделениями В и Г пропускались все этапы кроме подписания.
Другой пример – нумераторы документов. Известно, что регистрационный номер исходящего документа содержит кроме порядкового номера еще индекс подразделения регистратора и индекс номенклатурного дела.
Допустим, что сегодня регистрацией документов занимаются в системе три подразделения, а через полгода их будет пятнадцать. В этом случае правило нумерации можно сделать единым, а сами счетчики порядковых номеров создавать и подключать к правилу по мере появления новых подразделений-регистраторов.
Рассмотрим также ситуацию с набором виртуальных папок для какого-либо пользователя или группы пользователей (например, для всех, кто является «ответственным за контрольный учет документов»). Папки необходимы каждому участнику этой функционально обособленной рабочей группы, в каком бы подразделении она ни появлялась.
Такой ролевой набор папок можно настроить и хранить в виде шаблона в дереве папок, но отображать только тем пользователям, которые ассоциированы с ролью, причем ассоциация может быть как статической (все участники явно указаны), так и динамической (на основе правила, например: «Я являюсь временным заместителем сотрудника, указанного в поле документа «Контролер», и у меня есть право подписи»).
Нельзя оставить без внимания и workflow-процессы, которые будут автоматически обрабатывать определенные сценарии в системе. Нецелесообразно вносить в их логику изменения каждый раз, когда инструмент workflow потребуется предоставить какой-то новой группе пользователей.
Например, автоматизированный процесс платы контрагенту, которая должна производиться после согласования и подписания электронной подписью в системе счета на оплату, может позволять «включать» в него новые ветки (разновидности) платежей без переработки основной логики процесса.
Другой вопрос, который следует задать: какие наборы данных целесообразно сделать справочными, иерархичными или матричными?
В случае автоматизации договорного документооборота часто бывает, что видов документов всего три (договор, приложение и доверенность), а подвидов договорных документов – несколько десятков. В этом случае, вместо того, чтобы плодить десятки подвидов документов, проще создать справочник-матрицу, который будет хранить все возможные наборы специальных значений для каждого подвида документа (условия поставки, оплаты и пролонгации, маршрут и участники согласования, сроки согласования и т. д.) и загружать в документ какой-то конкретный набор (строку матрицы) в тот момент, когда в документе выбран некий отличительный признак этого подвида.
Еще один интересный вопрос – какие модули или подсистемы целесообразно реализовать в виде веб сервисов и в дальнейшем предоставлять к ним доступ по шлюзам, через API?
Например, СЭД аккумулирует данные по документообороту и исполнительской дисциплине, но строить аналитические отчеты планируется в системе класса BI. В этом случае СЭД будет источником данных, а BI будет регулярно делать к ней запросы и получать ответы.
Развитие структуры данных СЭД в ходе проекта можно спланировать таким образом, чтобы интеграцию с BI не приходилось значительно переписывать каждый раз, когда в СЭД будут появляться новые виды документов или процессов. Здесь также будут работать принципы масштабируемости.
Если в СЭД планируется реализовать качественный справочник, например, КЛАДР (ФИАС), можно создать специальный модуль, который будет обновлять данные, устранять дубли и выполнять еще много полезных функций, делая справочник сервисом с актуальной информацией. Такой сервис в дальнейшем может представлять интерес и за рамками СЭД, например, служить источником для какой-либо геоинформационной системы в организации. В этом случае целесообразно заранее продумать архитектуру справочника и API к нему для любых других систем.
На организационном уровне также есть нюансы, которые стоит учитывать при создании системы. Например, необходимо заранее выстраивать центр компетенций, поскольку тиражирование системы на новые подразделения или новые функции должно сопровождаться обучением и адаптацией пользователей. Функция обучения и методической поддержки может выполняться по-разному, и здесь также важно предусмотреть принцип масштабируемости.
Например, освоить методику дистанционного обучения пользователей, разработать систему адаптации новых пользователей через видео- или интерактивные уроки. Еще один вариант – создать институт наставников, в рамках которого выделять и закреплять в обязанностях и штатном расписании подразделений роль наставников, чьи компетенции и навыки позволяли бы закрывать большой процент всех обращений пользователей и выполнять методическую поддержку на местах. Кроме того, не следует забывать о развитии внутреннего портала и wiki, благодаря которым пользователи могли бы самостоятельно получать ответы на интересующие вопросы. Также необходимо инициировать и поддерживать внутренние мероприятия по обмену опытом и получению обратной связи от пользователей.
Другой важный организационный момент – развитие службы технической поддержки системы. Аналогично центру компетенций данную функцию можно централизовать или децентрализовать, главная задача – максимально быстро решать технические вопросы СЭД. Путей решения этой задачи несколько:
- во-первых, на портале или в самой системе может быть создан интерфейс (личный кабинет) для самостоятельной регистрации и контроля рассмотрения обращений пользователей по техническим вопросам (ошибки и сбои системы);
- во-вторых, локальные администраторы на местах могут обладать полномочиями и компетенциями решать все или большую часть технических проблем пользователей.
Словарь
Workflow – это полная или частичная автоматизация бизнес-процесса, при которой документы, информация или задания передаются от одного участника (бизнес-процесса) к другому для выполнения действий согласно набору руководящих правил.
API (англ. application programming interface, интерфейс программирования приложений) – это интерфейс прикладного программирования для интеграции одного программного обеспечения с другим. BI (Business intelligence – бизнес-анализ, бизнес-аналитика) – программное обеспечение, созданное для помощи менеджеру в анализе информации о своей компании и ее окружении. КЛАДР (классификатор адресов РФ) – ведомственный классификатор ФНС России, созданный для распределения территорий между налоговыми инспекциями и автоматизированной рассылки корреспонденции. ФИАС (Федеральная информационная адресная система) – ведомственный классификатор ФНС России. Классификатор содержит адресные элементы и историю их изменения: регионы, районы, города, городские округа, населенные пункты, улицы, дома.
Wiki (англ.) – веб-сайт, структуру и содержимое которого пользователи могут самостоятельно изменять с помощью инструментов, предоставляемых самим сайтом. Форматирование текста и вставка различных объектов в текст производится с использованием вики-разметки. На базе этой технологии построена Википедия и другие проекты Фонда Викимедиа.
Источник:
СОВРЕМЕННЫЕ ТЕХНОЛОГИИ ДЕЛОПРОИЗВОДСТВА И ДОКУМЕНТООБОРОТА, № 6 2015
http://www.sekretariat.ru