Министерство общего и профессионального образования
Российской Федерации
Московский Физико-Технический Институт
(
Государственный Университет)
Факультет общей и прикладной физики
Кафедра системной интеграции и менеджмента
Щелканов Виктор Владимирович
Разработка общесистемных функциональных решений для автоматизированной системы Федерального Казначейства
Магистерская диссертация
Научный руководитель: кандидат филологических наук, доцент Рыков В.В. Рецензент:
доктор технических наук, профессор Беляев И.П.
Москва 2007
Аннотация
В данной магистерской диссертации выносится на защиту техническая разработка, по части исполнения общесистемных функций документооборота в территориально-распределенной автоматизированной системе Федерального Казначейства. Приведенное в работе программное решение в настоящий момент реализовано в рамках проекта по созданию и внедрению автоматизированной информационной системы Федерального Казначейства.
Содержание
Аннотация.................................................................................................. 1
Содержание................................................................................................... 2
Список сокращений.............................................................................. 4
1 Введение................................................................................................ 5
1.1 Актуальность..................................................................................... 5
1.2 Цели и задачи................................................................................... 5
1.3 Научно-техническая новизна...................................................... 6
1.4 Практическая ценность................................................................. 6
1.5 Объекты исследования................................................................. 6
1.6 Используемый метод..................................................................... 7
2 Общие сведения о бизнес специфике ФК РФ.................. 7
2.1 Федеральное Казначейство и его место в бюджетной системе РФ......................................................................................................... 7
2.1.1 Осуществление бюджетного процесса в Российской Федерации................................................................................................................................... 7
2.1.2 Роль Федерального Казначейства в бюджетном процессе РФ. 8
2.2 Особенности центрального рабочего процесса ФК РФ. 10
2.3 Необходимость автоматизации............................................... 13
3 Обзор проекта по созданию и внедрению АСФК......... 15
3.1 Основные сведения о проекте ([2][11])................................. 15
3.2 Цели и задачи проекта................................................................ 15
3.3 Методология ведения проекта......................................... 16
3.3.1 Обзор методологий Oracle по реализации проектов автоматизации................................................................................................................................. 16
3.3.2 Доработка стандартной методологии проекта под специфику бизнес-области..................................................................................................... 18
3.4 Личное участие автора............................................................... 19
4 Описание разработки.................................................................... 20
4.1 Предпосылки разработки общесистемных функций для АСФК................................................................................................................... 20
4.2 Формулировка требований к разрабатываемым программным компонентам........................................................................ 21
4.2.1 Построение нормативной процессной модели верхнего уровня ФК................................................................................................................................. 21
4.2.2 Анализ процессной модели ФК...................................................... 23
4.2.3 Анализ возможных средств реализации...................................... 24
4.3 Описание компонент разработки............................................ 25
4.3.1 Общее решение по хранению и ведению документов в АСФК 25
4.3.2 Операции над документами...................................................... 26
4.3.3 Реализация контроля документов в АСФК................................... 29
4.3.4 Многоуровневое утверждение................................................ 30
4.3.5 Журналирование и формирование протоколов обработки..... 32
4.3.6 Синхронизация между подсистемами.......................................... 34
5 Заключение......................................................................................... 36
6 Список литературы......................................................................... 37
Приложение 1: План реализации в MS Project 2003........... 38
Приложение 2: Структура диаграмм нормативной процессной модели ФК....................................................................................... 39
Приложение 3: Пример диаграммы процесса деятельности Федерального Казначейства в ПОСТ-нотации............................ 40
Список сокращений
| AIM
|
Application Implementation Method (Методика внедрения приложений) |
| AME
|
Approval Management Engine (Средство для управления утверждением) |
| API (АПИ)
|
Application Programming Interface (Программный интерфейс приложения) |
| OEBS
|
Oracle E-Business Suite (Пакет приложений для управления предприятием от корпорации Oracle) |
| SQL
|
Structured Query Language (Язык формирования запросов) |
| XML
|
Extensible Markup Language (Расширяемый Язык Разметки) |
| АСФК
|
Автоматизированная Система Федерального Казначейства |
| БД
|
База данных |
| ДУБП
|
Другие участники бюджетного процесса |
| ОФК
|
Отделение Федерального Казначейства |
| ПО
|
Программное обеспечение |
| РФ
|
Российская Федерация |
| СУБД
|
Система управления базами данных |
| СУФД
|
Система удаленного финансового документооборота |
| ТА
|
Техническая архитектура |
| УФК
|
Управление Федерального Казначейства по субъекту РФ |
| ФА
|
Функциональная архитектура |
| ФК
|
Федеральное Казначейство |
| ЦАФК
|
Центральный аппарат Федерального Казначейства |
1 Введение
1.1 Актуальность
Несмотря на все многообразие бизнес объектов и алгоритмов их обработки в деятельности Федерального Казначейства, все они состоят из небольшого набора составляющих элементов таких, как
- проверки атрибутов объектов,
- передача объектов из одной подсистемы в другую,
- формирование новых объектов на основе уже имеющихся
- утверждение со стороны исполнительного лица и т.д.
В связи с этим, логично иметь некий набор стандартных компонент, чтобы из них можно было бы минимальными усилиями сконструировать процессы автоматизированной системы.
Наборы таких стандартных компонент могут функционально различаться в зависимости от бизнес области. Деятельность Федерального Казначейства имеет существенные отличия от деятельности коммерческого предприятия, пусть даже очень большого и с развитой сетевой структурой. Таким образом, специфика бизнес области ФК РФ, отраженая в требованиях Заказчика, заставляет отказаться от использования стандартных компонент, которые являются неотъемлемой частью современной ERP-системы, и разработать новые.
1.2 Цели и задачи
Целью настоящей работы является реализация программных средств, обеспечивающих настройку и функционирование основных бизнес процессов Федерального Казначейства в рамках распределенной автоматизированной системы в соответствии с требованиями, предъявляемыми Заказчиком.
Для достижения поставленной цели необходимо решить следующие задачи:
1) На базе общих требований Заказчика к автоматизированной системе разработать уточненные требования к общесистемному (общепроцессному) прикладному программному обеспечению
2) На базе уточненных технических требований разработать функциональный и технический дизайн общепроцессных решений в виде технического задания и передать его в разработку
3) Консультировать по функциональным и техническим вопросам участников команды разработки
4) Обучить участников групп функциональной и технической архитектуры проекта по созданию АСФК пользованию разработанным решением
5) Осуществлять доработку решения при дальнейшем уточнении требований, которые возникают в результате проектирования АСФК
Подробная иерархическая структура задач приведена в Приложение № 1: «План реализации».
1.3 Научно-техническая новизна
Научно-техническая новизна данной работы заключается в следующем:
1) Разработанное прикладное программное обеспечение до настоящего момента нигде не применялось и, несмотря на это, есть основания утверждать, что оно является наиболее подходящим среди аналогичных для достижения поставленной цели при имеющихся ресурсных ограничениях
2) Программное решение обеспечивает сквозную обработку данных в масштабах, которое не может обеспечить никакое аналогичное программное обеспечение. Под масштабами понимается:
a. Пространственное распределение компонент системы
b. Количество пользователей (30 тыс. пользователей ФК [
2
]
)
c. Количество обрабатываемой информации в единицу времени
3) Функциональная модель, на базе которой написано техническое задание на разработку, наиболее адекватным образом отражает специфику деятельности ФК РФ по сравнению с имеющимися аналогами
4) При разработке требований создана наглядная графическая модель процессов верхнего уровня ФК РФ. До этого вся деятельность ФК была представлена только в виде текстовых нормативных документов и схем процессов нижних уровней.
1.4 Практическая ценность
Приведенное в данной работе решение позволяет осуществлять настройку процессов АСФК, которые обеспечивают исполнение ключевых бизнес процессов организации. Разработанный программный продукт в дальнейшем планируется инсталлировать на 90
экземпляров АСФК в каждом субъекте РФ и в Центральном Аппарате ФК. Программно-аппаратный комплекс АСФК, частью которого является описанное в данной работе решение, планируется активно использовать на всех организационных уровнях Федерального Казначейства.
1.5 Объекты исследования
Объектами исследования настоящей работы являются:
1) Ключевые бизнес процессы Федерального Казначейства РФ
2) Программно-технические средства, обеспечивающие управление потоками работ и документов
3) Методология реализации программных средств в рамках проекта по созданию и внедрению автоматизированной системы Федерального Казначейства
1.6 Используемый метод
В данной работе используется метод дедукции – от общего к частному. Это находит отражение в структуре работы:
1) В начале рассматривается общая организация бюджетного процесса в РФ и определения в нем роли объекта автоматизации, в нашем случае ФК.
2) Показывается необходимость автоматизации деятельности ФК и приводится обзор проекта автоматизации в целом
3) Подробно рассматривается конкретная задача в рамках проекта, решенная при активном участии автора
2 Общие сведения о бизнес специфике ФК РФ
2.1 Федеральное Казначейство и его место в бюджетной системе РФ
2.1.1
Осуществление бюджетного процесса в Российской Федерации
Объектом исследования и автоматизации в рамках данной работы является Служба Федерального Казначейства при Министерстве Финансов РФ. В настоящем разделе определяется состав деятельности ФК РФ, а также роль этой организации в бюджетной системе государства.
Общие принципы организации и функционирования бюджетной системы Российской Федерации, а также основы бюджетного процесса и межбюджетных отношений устанавливает Бюджетный Кодекс[1].
Согласно Бюджетному Кодексу имеют место следующие определения:
- бюджет
- форма образования и расходования фонда денежных средств, предназначенных для финансового обеспечения задач и функций государства и местного самоуправления;
- бюджетная система Российской Федерации
- основанная на экономических отношениях и государственном устройстве Российской Федерации, регулируемая нормами права совокупность федерального бюджета, бюджетов субъектов Российской Федерации, местных бюджетов и бюджетов государственных внебюджетных фондов;
- бюджетный процесс
- регламентируемая нормами права деятельность органов государственной власти, органов местного самоуправления и участников бюджетного процесса по составлению и рассмотрению проектов бюджетов, проектов бюджетов государственных внебюджетных фондов, утверждению и исполнению бюджетов и бюджетов государственных внебюджетных фондов, а также по контролю за их исполнением.
Бюджетный процесс целиком пронизывает деятельность всего народного хозяйства. Так коммерческие предприятия выплачивают налоги и пошлины в бюджеты различных уровней. Эти средства идут на обеспечение функций государства. Можно говорить, что результатом исполнения функций государства является набор общественных благ. Общественные блага потребляются гражданами, которые, в свою очередь, в результате своего труда формируют поступления в бюджеты.
Ряд государственных организаций оказывает ключевое влияние на бюджетный процесс. Эти организации регулируют бюджетную деятельность и несут ответственность за качество исполнения бюджетного процесса. Согласно Бюджетному Кодексу [1] ключевыми участниками бюджетного процесса являются:
- Органы исполнительной власти – составление проектов бюджетов и исполнение утвержденных бюджетов;
- Органы законодательной власти – рассмотрение и утверждение проектов бюджетов;
- Банк России – разработка денежно-кредитной политики, которая является основой для составления проектов бюджетов; обслуживание банковских счетов бюджетов.
- Финансовые органы (Федеральное Казначейство) – распределение доходов в соответствии с нормативами, кассовое обслуживание бюджетной участников бюджетной системы (производится через лицевые счета), собирает материалы и формирует отчетность об исполнении бюджета.
- Органы финансового контроля – осуществление предварительного, текущего и последующего контроля за исполнением бюджетов. На федеральном уровне органом контроля является Счетная Палата РФ.
- Главные распорядители бюджетных средств – орган государственной власти Российской Федерации, имеющий право распределять средства федерального бюджета по подведомственным распорядителям и получателям бюджетных средств, а также наиболее значимое бюджетное учреждение науки, образования, культуры, здравоохранения и средств массовой информации.
В самом упрощенном виде бюджетный процесс можно представить в виде следующей схемы:
Схема 1 Упрощенная схема бюджетного процесса
2.1.2
Роль Федерального Казначейства в бюджетном процессе РФ
Федеральное Казначейство как объект нашего исследования и автоматизации реализует ряд функций по исполнению бюджетов и на общей схеме бюджетного процесса относится к блоку «Исполнение бюджетов». Исполнение бюджета находится в сфере ответственности правительства, исполнительной ветви власти. Основная его функция заключается в реализации закона о бюджете, принятого парламентом.
Схема 2 Цепочка подчиненности ФК РФ
«В Российской Федерации устанавливается казначейское исполнение бюджетов. На органы исполнительной власти возлагаются организация исполнения и исполнение бюджетов, управление счетами бюджетов и бюджетными средствами.[1]» Казначейское исполнение бюджетов основывается на принципе «Единства кассы». «Принцип единства кассы предусматривает зачисление всех поступающих доходов бюджета, привлечение и погашение источников финансирования дефицита бюджета и осуществление всех расходов с единого счета бюджета, за исключением операций по исполнению федерального бюджета, осуществляемых за пределами Российской Федерации в соответствии с законодательством Российской Федерации» [1]. Казначейская форма исполнения бюджетов позволяет достичь следующих преимуществ:
- Средне срочное планирование, ориентированное на результат, что создает основы для принятия долгосрочных бюджетных обязательств – альтернативой является среднесрочное финансовое планирование, которое не обеспечивает правовой основы для многолетних государственных контрактов [5]
- Четкое разделение частных и государственных финансовых активов [4]
- «Создание более удобных условий для налогоплательщиков по перечислению любых налогов или сборов только на один счет»[4]
- Уменьшение конфликтного поля между участниками бюджетного процесса [4]
- Увеличение прозрачности процесса распределения средств, т.е. становится возможным увидеть, что лежит в основе тех или иных бюджетных ассигнований (для этого вводится понятие «Расходные обязательства» [5])
Казначейская форма исполнения бюджетов подразумевает, что организация исполнения и исполнение бюджетов осуществляется органами исполнительной власти. Органы Федерального Казначейства управляют счетами бюджетов, являются кассирами всех распорядителей и получателей бюджетных средств. От имени и по поручению бюджетных учреждений они осуществляют платежи за счет средств бюджета[6].
Полномочия ФК РФ, которые являются основой для процессов деятельности организации, изложены в Положении о Федеральном Казначействе. Согласно этому документу «Федеральное казначейство (Казначейство России) является федеральным органом исполнительной власти (федеральной службой), осуществляющим в соответствии с законодательством Российской Федерации правоприменительные функции по обеспечению исполнения федерального бюджета, кассовому обслуживанию исполнения бюджетов бюджетной системы Российской Федерации, предварительному и текущему контролю за ведением операций со средствами федерального бюджета главными распорядителями, распорядителями и получателями средств федерального бюджета»[7].
2.2 Особенности центрального рабочего процесса ФК РФ
Процессный подход по описанию деятельности организации уже давно вошел в обычную практику. В соответствии с концепцией IDEF0 иерархия процессов выглядит следующим образом:
1) Стратегические процессы
2) Ключевые процессы
3) Процедуры
4) Задания
К стратегическим процессам зачастую относят единственный процесс, который также называется основным или центральным бизнес-процессом. В случае коммерческой организации основным процессом называют крупномасштабную работу организации, которая начинается с определения потребностей клиентов и заканчивается получением оплаты за произведенную продукцию или оказанную услугу. Примером основного процесса может служить следующая цепочка: исследование потребностей рынка - разработка проекта продукции - производство - хранение - реализация. Каждый центральный процесс в организации состоит из набора ключевых или ведущих процессов.
Ключевые процессы – процессы, оказывающие значительное влияние на деятельность организации. Ключевые процессы должны быть определены и задокументированы. Это требование выражено и в стандартах на системы управления качеством. Исключение ключевого процесса влечет недостижение общего результата, т.е. результата основного процесса.
В книге И.П. Беляева и В.М. Капустяна «Процессы и концепты» рассматриваются предпосылки, лежащие в основе процессного подхода. При этом основным понятием является понятие жизненного цикла системы и характерной фазы жизненного цикла. Характерная фаза – это фаза, на которой система выполняет свое основное предназначение. При этом утверждается, что «В каждом жизненном цикле систем конкретной природы можно обнаружить всегда одну так называемую характерную фазу»[12
]. При рассмотрении характерной фазы системы в книге «Процессы и концепты» используется термин - "центральный рабочий процесс системы" как основной процесс, выполняемый в характерной фазе.
Центральный рабочий процесс – это процесс, который:
а) «может быть описан лишь в терминах объективных событий,
б) может быть описан лишь как "натуральный процесс", имеющий натуральные, например, физические характеристики (набор обнаруживаемых в процессе и измеряемых физических величин вместе с их точными параметрами),
в) не может быть элиминирован в системе без того, чтобы система не утратила смысл, целостность и реализацию,
г) не может быть вытеснен из системы физическим процессом-заменителем без того, чтобы система не стала, по-существу, качественно иной, хотя бы и продолжала "называться" прежним именем»[
12
]
.
Понятие центрального рабочего процесса лучше всего поясняется на примерах.
- Для автомобиля – перевозка грузов и/или пассажиров,
- Для холодильника – поддержание заданной низкой температуры в холодильной камере,
- Для ресторана – качественное кормление клиентов и т.д.
Таким образом, в начале исследования любой сколько-нибудь сложной системы необходимо:
1. Определить жизненный цикл системы
2. Определить характерную фазу системы
3. Описать центральный рабочий процесс
Для Федерального Казначейства центральным рабочим процессом в рамках приведенного определения является кассовое обслуживание единого казначейского счета в Банке России.
Можно выделить следующие особенности центрального рабочего процесса ФК РФ.
1) Высокая степень формализации деятельности – каждая процедура процесса описана в нормативных документа, неописанные действия считаются нелегитимными;
2) Большой объем обрабатываемой информации по отношению к количеству людей, участвующих в обработке
3) Требование абсолютно точного учета – балансы должны быть полностью сведены (специфична также для банковской сферы и бухгалтерии)
2.3 Необходимость автоматизации
[
8
]
В свое время Ф.Энгельс выдвинул гипотезу об экспоненциальном росте знаний, отмечая, что наука движется вперед пропорционально массе знаний, унаследованных ею от предшествующих поколений. Если- масса знаний, то гипотеза Энгельса может быть представлена в виде:
,
где p – константа; t – время. Откуда получаем:
,
Таким образом, общая масса знаний, включающая научную и научно-техническую информацию, растет по экспоненциальному закону.
Продиффиринцировав уравнение по t, получаем:
,
т.е. величина, характеризующая прирост знаний в единицу времени также растет по экспоненциальному закону.
В науковедении обычно используется такой показатель, как время удвоения знаний:
Значения функции x(t) – масса знаний – достаточно абстрактная характеристика, т.к. в настоящее время не существует сколько-нибудь полной «теории меры знания» и инструментов по его измерению. Единственным способом можно считать косвенное измерение знаний через количество информации. Очевидно, этот способ имеет ряд существенных недостатков. Например, статья по физике элементарных частиц может содержать такое же количество информации (например, занимать объем 5 кБ), как и статья из бульварной газеты, но количество знания будет в обоих случаях сильно отличаться.
Приведенная формула должна быть уточнена, т.к. очевидно, что время удвоения, а значит и показатель p, являются функциями времени (См.Таблица 1).
Таблица
1
| 00 г. |
1500 г. |
1800 г. |
1950 г. |
1970 г. |
1981 г. |
2000 г.[1]
|
|
| Т, год |
2000 |
1000 |
50 |
10 |
5 |
2,5 |
1 |
| P, 1/год |
0,001 |
0,002 |
0,014 |
0,07 |
0,14 |
0,28 |
0,73 |
Новые знания овеществляются, в результате чего происходит непрерывное расширение и обновление номенклатуры продукции, товаров, услуг, технологических процессов. Что приводит к усложнению народного хозяйства. Сложность народного хозяйства можно охарактеризовать числом связей между его объектами, а число связей растет примерно пропорционально квадрату единиц номенклатуры[
8
].
С давних пор человечество использует знания, опосредованные в виде знаковой информации. Всякий объект народного хозяйства имеет название, а также перечень свойств. Соответственно увеличение «массы знания» приводит к увеличению количества информации. При этом количество информации увеличивается гораздо быстрее, чем происходит увеличение знаний.
Увеличение количества объектов народного хозяйства усложняет деятельность Федерального Казначейства, в частности, увеличивается количество:
- Плательщиков в бюджет
- Получателей бюджета
- Кодов бюджетной классификации
В качестве примера усложнения деятельности, связанной с увеличением количества объектов, в данной работе был рассмотрен Доклад по итогам за 2006 год «О деятельности Управления Федерального Казначейства Брянской области»[
9
]
.
Таблица 2
| Наименование показателя
|
2005 г.
|
2006 г.
|
| Число муниципальных образований[2]
|
40 |
289 |
| Количество счетов, открытых в учреждениях Банка России |
43 |
472 |
| Количество используемых кодов бюджетной классификации |
~1700 |
~2100 |
В связи с этим, можно сделать два вывода:
1) Увеличение номенклатуры объектов, происходящие в следствие качественного улучшения экономики, приводит к неизбежной автоматизации действующих информационных систем.
2) С учетом динамики усложнения народного хозяйства автоматизированные информационные системы должны создаваться с существенным запасом производительности (в несколько раз).
3 Обзор проекта по созданию и внедрению АСФК
3.1 Основные сведения о проекте (
[2][11])
Проект по созданию единой автоматизированной системы для Федерального Казначейства РФ стартовал 14 декабря 2005г. По результатам тендера, продолжавшегося более двух лет, был заключен контракт между Заказчиком системы, которым является Служба Федерального Казначейства при Министерстве Финансов РФ, и исполнителем, которым выступает консорциум, возглавляемый корпорацией Oracle.
«Согласно контракту корпорация Oracle выбрана в качестве ответственного партнера и головного исполнителя проекта. В состав консорциума, ведущего работы по проекту, вошли российские партнеры Oracle, обладающие необходимыми ресурсами и имеющие успешный опыт участия в крупных российских проектах государственного значения: ООО "ФОРС - Центр разработки", ЗАО "Борлас Ай-Би-Си", НИИ "Восход" и ЗАО "Овионт информ".
Масштабы проекта охватят 367 000 рабочих мест, включая более 30 000 пользователей на всех уровнях Федерального казначейства, Минфина России, а также Счетной палаты, и около 337 000 пользователей других участников бюджетного процесса [2
]».
Автоматизированная информационная система создается на базе следующих программных решений:
- Oracle E-Business Suite как основной платформы АСФК
- Системы удаленного финансового документооборота (СУФД), разработанной на СУБД Oracle
Особенности разрабатываемой системы позволяют выделить данный проект среди прочих проектов автоматизации:
1. Территориально-распределенная (90 инсталляций, т.е. в каждом субъекте РФ)
2. Многофункциональная
3. Имеет высокий класс защищенности
3.2 Цели и задачи проекта
Основной целью создания АСФК является поддержка производственных процессов в органах ФК. В состав производственных процессов Федерального Казначейства, поддерживаемых АСФК, входят:
- регистрация бюджетных данных по доходам, расходам и источникам финансирования дефицита бюджета;
- выполнение кассового планирования бюджета с использованием средств прогнозирования и моделирования;
- регистрация и доведение бюджетных ассигнований, лимитов бюджетных обязательств, предельных объемов финансирования, выдаваемых Главными распорядителями, распорядителями средств бюджета для подведомственных им получателей средств бюджета, а также возможность блокировки расходов;
- контроль и учет бюджетных обязательств получателей бюджетных средств;
- контроль и осуществление платежей;
- обеспечение высокого уровня внутреннего контроля при регистрации операций включая:
a. контроль полномочий пользователя
b. контроль допустимости и непротиворечивости вводимых значений
c. сохранение аудиторского следа по всем операциям в системе и т.п.;
- учет доходов от уплаты налогов, сборов и других платежей;
- обеспечение распределения доходов от уплаты налогов, сборов и других обязательных платежей между бюджетами бюджетной системы РФ;
- составление стандартных периодических отчетов о ходе исполнения бюджета, а также необходимых бухгалтерских отчетов;
- составление отчетов по запросу для получения необходимой информации по ключевым показателям
- обеспечение сверки учетных данных казначейской системы с учетными данными других участников бюджетного процесса;
- информационное взаимодействие с автоматизированными системами других участников бюджетного процесса.
Для достижения поставленной цели проектной команде, как со стороны исполнителя, так и со стороны Заказчика необходимо решить следующие задачи [11
]:
- Разработать детальную функциональную модель исполнения бюджетов органами ФК на основе интегрированной информационной системы в условиях функционирования единого казначейского счета;
- Разработать общую, программно-аппаратную, телекоммуникационную и информационную архитектуру АСФК
- Произвести внедрение в пилотных регионах
- Осуществить тиражирование системы во всех регионах РФ
3.3 Методология ведения проекта
3.3.1 Обзор методологий
Oracle по реализации проектов автоматизации
Согласно определению взятому из БСЭ [13
] «Методология
(от метод и... логия) – учение о структуре, логической организации, методах и средствах деятельности. М. в этом широком смысле образует необходимый компонент всякой деятельности, поскольку последняя становится предметом осознания, обучения и рационализации».
Различают два вида методологии:
1. Нормативная – представляет собой набор предписаний и норм, в которых фиксируются содержание и последовательность определённых видов деятельности;
2. Дескриптивная – описание фактически выполненной деятельности.
«В обоих случаях основной функцией этого знания является внутренняя организация и регулирование процесса познания или практического преобразования какого-то объекта»[13
].
Проекты по созданию и внедрению автоматизированных систем представляют собой достаточно сложную организацию деятельности нескольких десятков, а порою и сотен, людей. Успешная реализация проектов подразумевает:
- Выполнение заявленного объема работ
- Соблюдение сроков выполнения согласно контракту
- Использование заранее оговоренного количества ресурсов
- Сдача результатов удовлетворяющих соответствующим критериям качества
Для успешной реализации помогает использование типовых методик разработки, внедрения и управления проектов в целом. Зачастую такие методики основываются на детальном документировании работ, которое обеспечивает контроль соответствия достигнутых результатов поставленным целям и задачам проекта. В настоящее время существует большое количество подобных методик. Часть из них является даже международными стандартами, например, стандарт PMI.
Корпорация Oracle разработала ряд своих методик, «заточенных» под специфику проектов внедрения и разработки в рамках своих продуктов. Проведение работ в рамках данных методик гарантирует получение ожидаемых результатов в достаточно четко определенные сроки. Наиболее известные среди методик Oracle:
- PJM (Project Management Method) – методология управления проектом. Проект представляется в виде набора параллельных процессов, разбитых по фазам. По сути, является адаптированным для ИТ-проектов стандартом PMI.
- OBM (Oracle Business Models) – методология отображения бизнес процессов. По сути, является модификацией метода data-flow диаграмм.
- CDM (Custom Development Method)
–
представляет собой множество полностью определенных процессов проектирования программных средств, которые могут быть реализованы различным образом
- AIM (Application Implementation Method) – методология внедрения готовых приложений. Как и PJM, представляет собой совокупность процессов и фаз проекта. Данная методология представляет собой детальное описание задач, выполняемых в ходе проекта, и результатов, которые необходимо получить по окончании каждой задачи. Задача в терминах данной методологии представляет собой элементарный (неделимый) объем работ, который обязательно заканчивается каким-либо результатом (в большинстве случаев - документом).
Рис. 1 Процессы и фазы согласно методологии Oracle AIM
В крупных проектах таких, как проект АСФК, для реализации подпроектов может использоваться целая совокупность различных методов.
Рис. 2 Связь различн
3.3.2 Доработка стандартной методологии проекта под специфику бизнес-области
Проект АСФК не является типовым проектом внедрения ERP-системы. Отличительные особенности проекта:
1) Масштаб проекта – ни одна ERP-система не обслуживает в настоящее время
2) Специфичная бизнес область – производственные процессы ФК не являются типовыми процессами коммерческого предприятия, в частности, имеются следующие отличия:
a. Четкая нормативная регламентация деятельности, которая не предусматривает изменения процессов «под систему»
b. Отсутствие материального оборота в основных процессах деятельности
c. Высокая централизация управления
По этой причине, стандартные методологии Oracle, эффективно применяемые на проектах внедрения в коммерческих предприятиях, не в полной мере подходят для реализации проекта АСФК.
В практике внедрения OEBS на предприятиях СНГ неоднократно делались попытки модифицировать стандартные методологии Oracle. Наиболее известная статья на эту тему Саидова-Лебединского [14
], коллектив которого разработал, на их взгляд, более подходящую методологию по внедрению готовых приложений под названием AIM-M (Modified). В рамках этой работы был проведен анализ стандартной AIM. Согласно данному анализу: «Основную суть методики составляет адаптация бизнес-процессов к применению информационных технологий и, одновременно, адаптации этих самых информационных технологий к конкретным бизнес-процессам». Очевидно, что бизнес-области обусловленные специфическим регламентом или, наоборот, совсем не регламентированные не входят в сферу применения методики AIM.
В самом деле:
- «в узкоспециализированной деятельности бизнес-процессы обычно не поддаются изменению, а потому само приложение должно быть написано точно под бизнес (и не нужно методики, чтобы его внедрять),
- в нерегламентированном бизнесе, по определению, бизнес-процессы четко не определены, поэтому подгонять приложение не подо что»[14
].
Другая причина, почему нельзя использовать стандартные методики в чистом виде заключается в том, что проект АСФК является всего лишь одним из проектов в рамках бюджетной и административной реформы. В связи с этим, проект АСФК должен гармонично сочетаться с другими проектами в рамках этих реформ. При этом должна обеспечиваться общая управляемость портфелем проектов в рамках реформы. Все это накладывает дополнительные ограничения на методику ведения проекта.
Таким образом, разработка и внедрение ППО АС ФК будет выполняться в рамках четырех отдельных стадий.
- Стадия 1 – Уточнение требований к системе
- Стадия 2 - Разработка и тестирование ППО.
- Стадия 3 - Пилотное внедрение базовой системы.
- Стадия 4 – Полнофункциональная реализация и тиражирование.
Под ППО подразумевается как OEBS, так и СУФД.
3.4 Личное участие автора
Автор работы привлечен на проект по созданию АСФК на стадию System Design (Проектирование Системы) в качестве консультанта от Генерального Подрядчика в октябре 2006г. Автору было поручено разработать и согласовать обеспечивающую функциональность для процессов документооборота в АСФК. В настоящий момент все разработанные компоненты проходят тестирование для внедрения на пилотных проектах.
4 Описание разработки
4.1 Предпосылки разработки общесистемных функций для АСФК
Основной платформой ППО АСФК является Oracle E-Business Suite – ERP-приложение, разработанное корпорацией Oracle. ERP-система представляет собой интегрированный набор модулей, каждый из которых отвечает за исполнение какой-то бизнес-задачи. OEBS относится к классу систем оперативной обработки транзакций (OLTP). Большинство функций такой системы предназначено для организации постоянного взаимодействия с системой и обработки транзакций. В таких системах многие ручные и автоматические транзакции могут инициировать появление автоматических транзакций в других модулях. Отчеты в такой системе предназначены для получения сведений о выполненных транзакциях, для управления процессами, а также вычисления остаточных балансов.
Помимо OLTP существует класс систем хранилищ данных (Data Warehouse). Отличия двух классов информационных систем представлены в Таблица 3.
Таблица
3 Сравнение OLTP и Data Warehouse[15]
| Свойство |
OLTP |
Data Warehouse |
| Характерное время отклика на событие |
Секунды |
Минуты и часы |
| Характерные типы операций |
Вставка, изменение |
Выборка |
| Структура данных |
Нормализованная |
Денормализованная |
| Назначение |
Операционная деятельность |
Стратегическое планирование, бюджетирование, аналитика |
Всякая современная ERP-система имеет в своем составе общесистемные или общепроцессные компоненты (модули). В работе [15
] приводится примерный перечень таких компонент:
- Управление технологическими процессами
- Корпоративное взаимодействие
- Системное администрирование
- Интерфейсы для внешнего программного обеспечения
Эти компоненты добавляют много возможностей для автоматизированной системы и являются составной частью 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 с использованием «родной» среды разработки, т.е. PLSQL и Oracle Forms.
Для решения задачи по автоматическому контролю атрибутов произвольных таблиц в процессе документооборота не существует стандартного средства OEBS, удовлетворяющего необходимым требованиям. В результате решение задачи было перенесено на уровень разработки.
Для управления бизнес-процессами, а также утверждения (пользовательского контроля), существует стандартное средство Oracle Workflow. Приложение Oracle Workflow можно использовать для решения следующих задач [15
]:
o Создание и изменение технологических процессов в автоматизированной системе
o Обмен информацией с другими приложениями OEBS
o Взаимодействие с пользователем посредством системы уведомлений
o Использование инструментов наблюдения за технологическими процессами
Несмотря на все преимущества Oracle Workflow решение не удовлетворяет необходимым требованиям к производительности на больших объемах данных и в случае синхронных процессах, т.е. процессах, в результате которых ожидается реакция пользователя. По этой причине было возможно только частичное использование стандартного средства.
4.3 Описание компонент разработки
4.3.1 Общее решение по хранению и ведению документов в АСФК
Схема 4 Общая схема хранения документов в АСФК
Все данные системы можно условно разделить на две большие группы:
1) Данные документов – данные участвующие в основной деятельности ФК в виде документов.
2) Справочники – относительно статические данные, которые регистрируются в системе и хранятся особым образом, выполняют обеспечивающие функции в процессе документооборота. В рамках данного проекта к справочникам относят также ряд настроек системы.
В свою очередь, данные, относящиеся к документам делятся на:
1) Первичные данные – данные в том виде, в котором они поступают в систему. Первичные данные относятся к первичным документам.
2) Учетные данные – преобразованные первичные данные в рамках операции «Регистрация»
Для обеспечения целостности системы, а также для связи учетных и первичных данных было принято решение – все актуальные документы АСФК в рамках одного экземпляра системы регистрировать и хранить в центральной таблице «Реестр документов». Запись в таблице «Реестр документов» характеризует один документ системы и называется «Карточка документа».
Карточка документов содержит основную техническую информацию о документе и связана (путем использования ссылок на неё) как с первичными документами, так и с учетными данными по ним. Карточка документов включает основные атрибуты документов такие, как:
- Глобальный межсистемный идентификатор документа – идентификатор уникальный для всех экземпляров системы (имеющихся и возможных). С помощью такого идентификатора решается задача синхронизации документов в рамках всей распределенной системы.
- Ключ и имя таблицы первичных документов
- Ключ и имя таблицы учетных документов
- Бизнес-статус – характеризует стадию жизненного цикла документа
- Статус утверждения – характеризует состояние документа относительно процесса утверждения
- Статус перехода – характеризует состояние документа относительно процесса передачи из одной подсистемы АСФК в другую.
Предполагается, что в таблице «Реестр документов» будет одновременно храниться около 107
записей. При существующих программно-аппаратных средствах не представляет особой проблемы обеспечить приемлемое время отклика при выборке данных. В частности, предлагается использовать такие средства СУБД Oracle 10g, как индексация и партиционирование.
4.3.2 Операции над документами
В разделе 4.2.3 «Анализ возможных средств реализации» было показано, что стандартные средства по обеспечению жизненного цикла документов не покрывают всех требований к АСФК. В связи с этим руководством проекта была поставлена задача – разработать альтернативный механизм, обеспечивающий все базовые функции документооборота в системе. Все автоматизированные бизнес-процессы в рамках АСФК должны работать, используя этот механизм.
Основные преимущества данного механизма по сравнению со стандартными средствами (Oracle Workflow):
- Существенный выигрыш в производительности за счет передачи управления другому участку процесса без обработки списка событий (как в Workflow)
- Возможность настройки логики на трехуровневой архитектуре OEBS. (настройка Oracle Workflow базируется на клиент-серверной архитектуре)
- Отражение бизнес специфики Федерального Казначейства в интерфейсе настроек и простота настройки
Для выполнения всех требований по документообороту достаточно было реализовать несложный алгоритм (см.
Схема 5 Алгоритм операционной модели).
Схема
5 Алгоритм операционной модели
В рамках операционной модели используются следующие понятия:
Операция (над документом)
– бизнес-активность, примененная (автоматически или пользователем вручную) к экземпляру информационного объекта. Примерами операций являются отмена документа, регистрация документа, и т.п. Возможным результатом операции является изменение бизнес-статуса документа, автоматическое создание или изменение других документов в системе. В рамках выполнения операции над экземпляром информационного объекта последовательно выполняются шаги операции, которые могут быть проверками (не изменяющими информационные объекты) либо действиями (над этим или другими экземплярами информационных объектов). Состав выполняемых в рамках операции шагов зависит от группы, типа документа, и его текущего статуса.
Шаг операции
– элементарная составная часть при настройке операции. Результатом исполнения шага является либо “Success”, либо “Error”. В зависимости от результата выполнения шага, может осуществляться условный переход к другим настроенным шагам операции.
Возможны следующие типы шагов:
- Стандартное действие
– шаг операции, в рамках которого выполняется сохраненная в базе данных PLSQL процедура. Результатом выполнения действия может являться проверка, изменение атрибутов информационного объекта (либо создание новых информационных объектов). Данная процедура не открывает автономных транзакций.
- Проверка
– действие, в рамках которого выполняется проверка атрибутов документов системы. Единственным результатом выполнения проверки является подтверждение истинности или ложности логического выражения применимо к проверяемому экземпляру информационного объекта. В случае истинности проверка передает 0, в случае предупредительного контроля 1, в случае блокирующего контроля 2.
- Действие с автономной транзакцией
– действие, выполняемое на шаге исполнения операции над документом, в рамках которого происходит commit автономной транзакции. В результате выполнения commit, в случае отката операции при возникновении необрабатываемой ошибки, автономная транзакция не будет отменена актоматически. Для отмены изменений, произведенных автономной транзакцией, при откате операции выполняется Действие по откату автономной транзакции.
- Действие по откату автономной транзакции
– действие, выполняемое при откате операции в случае возникновения на каком-либо шаге необрабатываемой ошибки. Сохраненная процедура, соответствующая действию по откату автономной транзакции, должна в рамках собственной автономной транзакции производить изменения в БД, реверсирующие результат работы оригинальной автономной транзакции, выполненной на шаге действия с автономной транзакцией.
- Вложенная операция
– операция над документом (см. выше), вызываемая на шаге выполнения другой операции. При этом родительская операция и вложенная операция выполняются, как правило, над разными множествами (и группами, типами) документов. Использование вложенных операций позволяет обрабатывать подмножество документов, каким-либо образом связанных с обрабатываемым документом. Например, при выполнении операции обработки пакета платежей можно вызвать операцию изменения атрибутов входящих в пакет платежей заявок на платеж.
- Конец обработки
– последний шаг выполнения операции, в рамках которого может осуществляться переход статуса документа.
Основным недостатком данной модели является невозможность графического представления процессов документооборота.
4.3.3 Реализация контроля документов в АСФК
Контроль является одной из основных функцией в деятельности Федерального Казначейства. В тоже время, Контроль – функция, которая в наибольшей степени подлежит автоматизации посредством программных средств. Обеспечение различных видов контроля на разных этапах жизненного цикла документа является одной из приоритетных задач при проектировании АСФК.
На проекте по созданию АСФК выделяют два типа контроля:
1) Автоматический – контроль атрибутов документов, на основании предварительно настроенных правил в системе
2) Пользовательский – контроль осуществляется визуально путем просмотра пользователем данных формы. Пользовательский контроль в АСФК реализован посредством многоуровневого утверждения (см 4.3.4).
В настоящий момент система Oracle E-Business Suite не имеет средств, покрывающих все требования к АСФК по части контроля, а также обеспечивающих единый подход к настройке контроля для всех типов документов системы. В связи с этим группой функциональной архитектуры проекта было принято решение о реализации единой компоненты, обеспечивающей автоматический контроль. Посредством автоматического контроля необходимо обеспечить решение ряда следующих задач:
1) Контроль данных, передаваемых в данный экземпляр OEBS из вне посредством XML файла
2) Контроль полей форм при вводе документов вручную пользователем
3) Контроль полей документов, попадающих в систему посредством сканирования бумажных носителей
4) Контроль атрибутов документов в таблицах системы на разных стадиях жизненного цикла документа в АСФК
Все эти задачи были решены с помощью одной настроечной формы и 10 таблиц с правилами настройки.
Схема 6 Алгоритм автоматического контроля
В рамках разрабатываемой функциональности используются следующие термины:
Процедура контроля
– свод необходимых правил проверки выполняемых применительно к информационному объекту в рамках выполнения шага операции, определенного как Проверка. Состав выполняемых правил проверки зависит от группы, типа документа, и его текущего статуса. Единственным результатом выполнения процедуры контроля является подтверждение истинности или ложности логического выражения применимо к проверяемому экземпляру информационного объекта.
Правило проверки
– логическое выражение, определяющего какой атрибут информационного объекта, при выполнении каких условий, каким образом и на какие хранящиеся данных в АСФК должен быть проверен.
Контроль
– осуществление правила проверки.
4.3.4 Многоуровневое утверждение
Посредством многоуровневого утверждения в системе АСФК реализован пользовательский контроль. Кроме этого данная функциональность интегрирована со средствами электронной цифровой подписи.
В отличие от Операций и Автоматического контроля утверждение выполняется в асинхронном по отношению к пользователю режиме и, следовательно, не предъявляет серьезных требований к производительности. В связи с этим возможно использование ряда стандартных средств, в частности Oracle Workflow, в который встроена компонента по утверждению документов (Approval Management Engine).
Тем не менее, специфика проекта накладывает дополнительные ограничения:
1) Необходимость работы с кастомизированными формами
2) Необходимость привязки электронной цифровой подписи к документу
3) Обеспечение правил настройки посредством трехуровневой архитектуры, а не через клиент-сервер.
4) Необходимость интеграции с общим подходом по реализации базовых функций АСФК, который включает в себя Операции, Контроли и др.
5) Отсутствие в системе модуля HR (управление персоналом) для настройки иерархий пользователей в рамках организаций
По этой причине потребовалось обеспечить ряд разработок, касающихся:
1) Вычисления цепочки утверждающих пользователей на основании предварительно настроенных правил
2) Привязку к средствам электронной цифровой подписи
3) Изменение статуса утверждения документа в зависимости от стадии утверждения
4) Интеграция с операционной моделью, которая, в частности, подразумевает автоматический запуск многоуровневого утверждения по окончанию операции
Процесс непосредственного исполнения утверждения реализован посредством стандартных средств и может быть наглядно представлен в виде следующей схемы из Workflow Builder:
Схема 7
4.3.5 Журналирование и формирование протоколов обработки
Не менее важным компонентом является создание подсистемы контроля и учета результатов автоматизированной обработки, обеспечивающей уполномоченных пользователей информацией о состоянии обработки, а также о возникающих в процессе обработки ошибках.
Oracle E-Business Suite имеет встроенные средства для журналирования исполнения в каждой своей компоненте. Основу этих средств составляют пакеты приложения Foundation (базовое). Некоторые из этих компонент (например, механизма стандартных сообщений OEBS) использовалась для создания системы журналирования при кастомизации.
Разработанная подсистема журналирования является встроенной в операционную модель. Процесс журналирования заключается в автоматическом формировании журнала обработки при выполнении автоматической или автоматизированной обработки документов / данных в системе. Журнал обработки состоит из нескольких разделов (субпротоколов), включающих следующую информацию:
- Технические данные о выполнении процедур обработки;
- Ошибки/ предупреждения;
- Результат обработки документа включающий, если это определено для данного типа документа, статус документа в АСФК, информацию, добавленную при обработке (например, регистрационный номер, дату регистрации).
В начале обработки документов / данных в информационном объекте «Журнал обработки документов (Технический протокол)» формируется запись, содержащая основные атрибуты процедуры обработки: тип документа (данных), глобальный системный идентификатор документа, время обработки, данные о пользователе.
В случае, когда обработка предполагает изменение атрибутов объекта, в журнал обработки документа добавляются записи, описывающие выполненные изменения.
Факт, время и общий результат завершения обработки отражается в журнале соответствующей записью.
Удаление (архивирование) данных по журналу обработки документов и сформированным протоколам по документам, относящимся к закрытым периодам, происходит в рамках выполнения процедур архивирования документов и данных. Так же по запросу администратора (уполномоченного пользователя) могут быть отправлены в архив (удалены) журналы обработки по документам и протоколы по документам, которые находятся в конечном статусе (в статусной модели установлен соответствующий атрибут для статуса).
Журналы, полученные в результате обработки, содержат всю информацию, относящуюся к операциям над документам. При этом различным группам пользователей АСФК нужна только информация определенного вида. Например, администратор АСФК заинтересован в техническом аспекте функционирования системы, т.е. ему нужна информация о системных ошибках и уведомлениях. Бизнес пользователь наоборот заинтересован в конечных результатах обработки и для него будут абсолютно неинформативны сообщения в технических терминах. Также немаловажен аспект безопасности, т.е. имеет ли право данный пользователь получать ту или иную информацию по обработке документа.
В связи с этим была создана функциональность, благодаря которой можно было бы гибко и удобно настраивать правила выборки из журналов, а также рассылки полученной выборке в виде отчета заинтересованным получателям.
Алгоритм журналирования и выборки в виде протоколов представлен на Схеме 8. Темным цветом показан участок журналирования, а белым процесса формирования и доведения протоколов.
Схема 8 Алгоритм журналирования и формирования протоколов обработки
Доведение протокола означает, что пользователю OEBS становятся доступными для просмотра соответствующие разделы журналов документа по нужным пользователю документам. С помощью инструмента Oracle XML Publisher пользователь может сформировать отчет в нужном ему формате (PDF, XML, HTML, TXT).
4.3.6 Синхронизация между подсистемами
Проектируемая АСФК является в высокой степени территориально-распределенной системой. Это означает следующее:
1. Система будет состоять из 90 аппаратно разделенных экземпляров системы, каждый из которых включает СУБД и сервер приложений. Планируется, что эти экземпляры будут взаимодействовать с подсистемой ЦАФК и друг другом посредством online.
2. Наличие подсистем, функционирующих в offline режиме (Система удаленного финансового документооборота)
В связи с этим, возникает ряд задач по синхронизации информационных объектов в рамках общей системы. А именно, необходимо обеспечить синхронизацию объектов следующих классов:
- Документы системы
- Справочная информация
- Настройки системы
В данной работе рассматривается только решение задачи по синхронизации документов. Задача по синхронизации возникла в связи с тем, что в различных подсистемах АСФК могут существовать экземпляры одного и того же документа. Данную задачу можно разбить на ряд подзадач:
- Синхронизация изменений атрибутов
- Синхронизация статуса обработки
- Синхронизация журналов обработки – пользователи должны знать все об операциях, проводимых над документом, вне зависимости от подсистемы, в которой та или иная операция была проведена.
- Избежание дублирующей информации – в одной подсистеме может быть не более одного экземпляра документа
- Соблюдение очередности синхронизации – все изменения документов при синхронизации должны осуществляться строго в хронологическом порядке источника изменений
Задачи по синхронизации были решены на базе уже имеющихся программных средств от сторонних разработчиков, обеспечивающих гарантированную доставку сообщений получателю в рамках распределенной автоматизированной системы. Данное решение подразумевает использование единого адресного пространства, т.е. формат адресов получателей стандартизирован в рамках АСФК.
Для передачи данных из одной подсистемы АСФК в другую используется формат XML. Основные причины использования XML заключаются в следующем:
1) Является стандартом и многие стандартные программные средства «заточены» на обработку XML
2) Знаком широкому кругу проектных участников, что позволяет использовать без проведения дополнительного обучения
3) Обеспечивает большую гибкость настройки, что позволяет достичь практически 100% семантического соответствия между документом в формате XML и реальным документом бизнес процесса.
Тем не менее, благодаря своей иногда излишней гибкости XML обладает рядом существенных недостатков по сравнению со стандартами, в которых смысл каждого тэга фиксирован (например, EDI [
16
]
). Самым существенным недостатком является увеличение объемов передачи. Документ в виде XML занимает, по меньшей мере, в три раза больше места, чем такой же документ, представленный в таблице реляционной БД. Также недостатком является необходимость согласования форматов (названий тэгов) всеми участниками проектной команды, что для большого проекта может привести к существенным издержкам.
5 Заключение
Проект по созданию территориально-распределенной, многофункциональной, защищенной, автоматизированной системы Федерального Казначейства является наиболее масштабным проектом автоматизации в государственной сфере. Реализация общесистемных программных компонент позволяет существенно упростить и ускорить разработку автоматизированной системы в рамках данного проекта при выполнении всех требований к гибкости настроек, безопасности и производительности.
В рамках данной работы представлены следующие результаты, полученные при активном участии автора во время работы на проекте по созданию АСФК:
1) Составлена нормативная процессная модель деятельности ФК, благодаря которой удалось получить в достаточной степени полный перечень информационных объектов системы (используемых документов) и примерный перечень операций над ними
2) Проведен анализ стандартной функциональности OEBS на предмет покрытия требований к общесистемным функциям обеспечению деятельности в рамках модели, результатом которого стал список расширений для обеспечения базовой функциональности документооборота ФК РФ.
3) Разработаны частные технические задания на расширения и проведен контроль разработки. В результате полученное решение передано в тестирование. После проведения комплексного тестирования планируется осуществить инсталляцию данного решения в рамках OEBS на пилотных проектах.
6 Список литературы
В работе были использованы материалы из следующих источников:
1.
Бюджетный кодекс Российской Федерации (в редакции 02 февраля 2006 г.) N 145-ФЗ
2.
Пресс-релиз компании Оракл «Федеральное казначейство Российской Федерации и Oracle подписали контракт на разработку и внедрение автоматизированной системы для Федерального казначейства» // Москва, январь 2006
3.
К. Панов «DocFlow и ERP: интегрировать или достраивать?» // IKS-online No 9.2006
4.
М.А. Тарасов «Кассовое обслуживание бюджетов. От конфликта к дискуссии», журнал «Бюджет», 02.2004.
5.
Т.Г. Нестеренко «Роль Федерального Казначейства в реформировании бюджетного процесса»
// РИА «РосБизнесКонсалтинг», 2006
6.
Университетская информационная система «Россия» «Бюджетная система Российской Федерации»
7.
Положение о Федеральном Казначействе (в ред. Постановления Правительства РФ от 11.11.2006 N 669)
8. Г.С. Поспелов «Искусственный интеллект – основа новой информационной технологии» // Москва, «Наука» 1988;
9. Доклад по итогам за 2006 год «О деятельности Управления Федерального Казначейства» // Управление Федерального Казначейства Брянской области.
10. Федеральный Закон «О бюджетной классификации»
11.
Пресс-релиз Федерального Казначейства «Федеральное казначейство информирует о завершении первой стадии проекта по разработке и внедрению автоматизированной системы Федерального казначейства» // 2006
12.
И.П. Беляев, В.М. Капустян «Процессы и концепты» // Москва, 1997
13.
Большая Советская Энциклопедия // Советская Энциклопедия
14.
Саидов-Лебединский О.З. «Пособие по освоению методики внедрения готовых приложений на основе методики Oracle AIM»
//
http://www.naytov-bis.ru
15.
Jim Crum “Using Oracle 11i” // Boss Corporation, 2001
16.
Ольга Кузнецова «
EDI: единый стандарт обмена данными обретает плоть в Росси»
// http://www.c-news.ru, 18.10.2004
Приложение № 1: План реализации
в MS Project 2003
Приложение № 2: Структура диаграмм нормативной процессной модели ФК
Приложение № 3: Пример диаграммы процесса деятельности Федерального Казначейства в ПОСТ-нотации
[1]
http://e-learning.su/materials/catalog/brief/37/ Владимир Тихомиров, ректор МЭСИ, председатель Экспертно-консультативного совета при Государственной Думе РФ
[2]
В связи вступления в силу Федерального закона от 6 октября 2003 года № 131-ФЗ "Об общих принципах организации местного самоуправления в Российской Федерации"