Аннотация (стр. 5 из 8)

- Системное администрирование

- Интерфейсы для внешнего программного обеспечения

Эти компоненты добавляют много возможностей для автоматизированной системы и являются составной частью OEBS, начиная с версии 11i. В частности, для управления технологическими процессами используется инструмент Oracle Workflow. В других ERP-системах также присутствуют подобные средства. Например, в MS Axapta используется модуль «Workflow for Axapta».

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

- контроль регистрируемых документов

- процесс загрузки документов и данных;

- формирование протокола обработки информации;

- многоуровневое утверждение документов;

- контроль перехода статуса документа и др.

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

- Быть унифицированным в рамках АСФК. Под унификацией в этом случае понимается использование однотипного прикладного ПО для выполнения однотипных задач, независимо от уровня органа Федерального казначейства, на котором они выполняются

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

- Обеспечивать необходимые показатели производительности

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

- Расходы на разработку и внедрение подобных средств должны быть минимальны при выполнении прочих требований

4.2 Формулировка требований к разрабатываемым программным компонентам

4.2.1 Построение нормативной процессной модели верхнего уровня ФК

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

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

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

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

o Модель должна состоять из наглядных частей, чтобы пользователь мог охватить взглядом весь процесс целиком. Наглядность можно обеспечить посредством декомпозиции

Для построения процессной модели автором была выбрана ПОСТ-нотация, разработанная российскими учеными И.П. Беляевым и В.М. Капустяном. Данная нотация при всей своей простоте является полной и логически проработанной для реализации процессного подхода описания. ПОСТ-нотация («Процессы + Объекты + Связи = Технология»[12]) благодаря своей простоте не требует специфического программного обеспечения для контроля целостности, как, например, нотации IDEF0 и ARIS.

Схема 3 Блок ПОСТ-нотации

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

1) Отбор релевантных для процесса документов, т.е. документов, из которых можно подчерпнуть информацию об объектах и преобразованиях над ними. Результат: некое множество нормативных документов для анализа.

2) Создание чернового варианта процессных схем – в рамках данного этапа каждый документ анализируется на предмет выделения объектов и преобразований между ними. Результат: черновая процессная схема, которая полностью соответствует документу.

3) Использование объектов и преобразований черновых моделей для построения качественной (в плане вышеперечисленных требований) модели. Вынесение объектов и преобразований на нужный уровень декомпозиции.

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

В результате была получена нормативная процессная модель деятельности ФК верхнего уровня. Модель была декомпозирована до третьего уровня. В дальнейшей детализации не было необходимости, т.к. на детальном уровне процессы были уже описаны функциональными консультантами в рамках проекта. Структура диаграмм модели приведена в Приложение № 2:. Пример диаграммы в рамках процессной модели ФК приведен в Приложение № 3:.

4.2.2 Анализ процессной модели ФК

Для описания процессной модели в ПОСТ-нотации использовалось MS Visio 2003. Помимо шаблонов для описания модели И.П. Беляевым был предоставлен Plug-in к MS Visio, позволяющий создавать отчеты по объектам и преобразованиям ПОСТ-модели.

Итоговый отчет по объектам и преобразованиям модели, полученной в 4.2.1, содержал:

1. 132 информационных объекта

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

3. 79 процедур-преобразований

Этих данных оказалось вполне достаточно для проведения анализа. При анализе построенных таким образом отчетов были получены следующие результаты:

1. Объекты системы, которые представляют, собой документы ФК РФ были сгруппированы по 19 группам. Среди них наиболее значимыми в процессе деятельности являются:

a. Бюджетные документы

b. Расходные расписания

c. Заявки на платеж

d. Бюджетные обязательства

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

3. Выделены основные классы процедур-преобразований:

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

i. Возврат документов, непрошедших проверку, в исходную подсистему

ii. Передача документов в рамках органов ФК

iii. Передача документов во/из внешней системы

b. Осуществление контроля данных документа

i. Автоматический контроль данных

ii. Пользовательский контроль данных – проверка осуществляется путем просмотра уполномоченным пользователем

c. Изменение данных документа

i. Изменение статуса документа в производственном процессе ФК

ii. Изменение прочих атрибутов документа

4. Анализ отчета о преобразованиях над объектами позволил сделать следующий вывод – большинство (более 80% от числа) процедур-преобразований в отчете относятся к одному из вышеперечисленных базовых классов

4.2.3 Анализ возможных средств реализации

Решение по общесистемным функциям должно быть напрямую интегрировано в среду Oracle E-Business Suite. В связи с этим, возможно только два способа реализации:

1. Использование стандартных средств OEBS

2. Кастомизация OEBS с использованием «родной» среды разработки, т.е. PL\SQL и Oracle Forms.

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

Для управления бизнес-процессами, а также утверждения (пользовательского контроля), существует стандартное средство Oracle Workflow. Приложение Oracle Workflow можно использовать для решения следующих задач [15]:

o Создание и изменение технологических процессов в автоматизированной системе

o Обмен информацией с другими приложениями OEBS

o Взаимодействие с пользователем посредством системы уведомлений

o Использование инструментов наблюдения за технологическими процессами

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

4.3 Описание компонент разработки

4.3.1 Общее решение по хранению и ведению документов в АСФК

Схема 4 Общая схема хранения документов в АСФК

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

1) Данные документов – данные участвующие в основной деятельности ФК в виде документов.

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

В свою очередь, данные, относящиеся к документам делятся на:

1) Первичные данные – данные в том виде, в котором они поступают в систему. Первичные данные относятся к первичным документам.