Практика автоматизации бизнес-процессов

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

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

Приведем некоторые доводы «за» разработку собственной системы:

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

ТРЕБОВАНИЯ К СИСТЕМЕ

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

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

В результате система должна позволить:

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

АРХИТЕКТУРА СИСТЕМЫ

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

Головной модуль

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

Для представления логической модели описываемой предметной области введем ключевой элемент — Бизнес-Объект. Реализация Бизнес-Объекта представляет собой совокупность данных, загружаемых (по мере обращения к ним) из хранилища. При запуске программы перечень доступных Бизнес-Объектов отбирается в соответствии с правами аутентифицированного пользователя. К этому элементу применимы стандартные методы: Отобрать, Добавить, Изменить, Удалить, Ограничить, Найти и т. д.

Для проецирования набора данных и методов Бизнес-Объекта на конкретную реализацию (в зависимости от используемой СУБД или различных методов доступа к данным) введем элемент Адаптер. В перечень его стандартных методов входят: Создать подключение, Отобрать, Добавить, Изменить, Удалить данные. Этот элемент должен генерировать SQL-запросы на основании описания Бизнес-Объектов, связей между ними и типа СУБД.

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

Подключаемые библиотеки

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

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

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

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

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

Значительное удобство при работе с системой может обеспечить встроенный Исполнитель SQL-запросов. Он должен загружать SQL-запросы и выполнять отбор данных или исполнять действия. Исполнитель поможет выполнять сгенерированные системой запросы на создание и изменение объектов СУБД, а также просматривать результаты отбора данных, используя параметры текущие состояния загруженных Бизнес-Объектов.

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

БИЗНЕС-ЛОГИКА СИСТЕМЫ

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

Определение в системе сущностей

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

Для удобства работы cущности можно объединить по категориям, имеющим иерархическую структуру.

Свойства cущности — отбор определений, характеризующих еётекущее состояние. Описание сущности и ее свойств можно в дальнейшем использовать в качестве подсказки в визуальных формах, в отчетах и схемах, описывающих предметную область, при проектировании элементов БД и т. д.

Связи cущностей. Если свойство сущности является ссылкой на какую-либо другую сущность, то между ними необходимо установить соответствие. При этом логично возложить на систему функцию автоматического создания записи, характеризующую связь «один ко многим», по умолчанию установить признак создания вторичного ключа и внешнего соединения. Если сущность ссылается сама на себя, то система определит ее как древовидную, а свойство по ссылке — как свойство «родитель».

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

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

Определение виртуальных сущностей

Для оптимального использования хранилища в системе можно ввести понятие виртуальной сущности. Физически все виртуальные сущности используют один массив данных, состоящий из двух свойств («Ключ» и «Значение»). Их применяют в случае, когда необходимо использовать набор данных, состоящий из постоянного числа элементов (например, Выбор — «Да», «Нет»).

Проекты

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

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

При необходимости перечень работ по проекту может быть изменен и дополнен.

Бизнес-объекты

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

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

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

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

В сценариях проектов можно использовать методы, реализующие поведение бизнес-объектов:

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

Сценарии

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

• текущее состояние бизнес-объектов;
• константы, заданные на этапе проектирования;
• выходные параметры других сценариев;
• ссылки на бизнес-объекты.

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

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

Универсальные формы

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

В карточке данные могут быть представлены в виде:

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

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

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

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

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

В сценариях проектов используются следующие методы архитектурного элемента Форма:

• создать;
• скрыть;
• ограничить экземпляры по заданному свойству (ограничивает записи на клиенте не обращаясь к хранилищу — в отличие от ограничения бизнес-объекта);
• снять ограничения по заданному свойству;
• вернуть текущее значение свойства (во время изменения или добавления записи значения ее свойств могут не совпадать с состоянием родительского бизнес-объекта).

Отчеты

Для каждого отчета система создает сценарий его вызова. В сценарии можно использовать следующие действия:

• загрузить отчет;
• выполнить отчет;
• корректировать отчет (загрузить дизайнер отчета);
• загрузить данные в отчет;
• загрузить в отчет параметр;
• выгрузить отчет.

Загрузка данных в отчет производится в два этапа.

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

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

Пользователи системы

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

Главное меню

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

ФУНКЦИОНИРОВАНИЕ СИСТЕМЫ

Старт системы

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

Регистрация объектов системы

Диспетчер проверяет: существует ли регистрируемый объект в текущем сеансе, и если да, то возвращает ссылку на него. Если объект еще не существует, Диспетчер обращается к библиотеке, в которой описан класс объекта и создает его экземпляр. Ссылка на загруженный в текущем сеансе объект записывается в реестр Диспетчера.

Процедура настройки

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

Выполнение сценария автозагрузки

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

Загрузка главного меню

Главное меню представляет собой небольшое окно с перечнем пунктов — сценариев работы.

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

Загрузка и работа модели бизнес-объектов

Диспетчер управляет моделью бизнес-объектов посредством Менеджера бизнес-объектов, экземпляр которого создается и регистрируется при первом обращении к нему. В его реестре хранится перечень всех бизнес-объектов, описанных при проектировании системы и доступных ролям аутентифицированного пользователя. При обращении к любому объекту проверяется — создан ли он в текущем сеансе. Если нет, Менеджер создает его и регистрирует в своем реестре.

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

Загрузка и работа универсальной формы

Диспетчер управляет визуальными формами посредством Менеджера форм, экземпляр которого создается и регистрируется при первом обращении к нему.

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

При загрузке формы Менеджер бизнес-объектов проверяет — создан ли объект, отображаемый формой, и если нет — создает его. Созданная форма активизируется на экране (при необходимости ее можно скрыть).

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

Загрузка и работа отчетов

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

При создании отчета система автоматически генерирует сценарии его вызова и загрузки в дизайнер.

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

ИТОГИ

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

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

Об авторе:

Радзишевский Алексей Олегович — начальник отдела программного обеспечения ООО "Консоль ЛТД".