<<
>>

Процедуры системного подхода и его преимущества по сравнению с моноаспектным и комплексным подходами

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

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

Моделирование бизнес-процессов в компании

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

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

Для типичной компании, имеющей несколько филиалов, можно предложить следую щ/ю предварительную разработку модели бизнес- процессов управления финансовыми потоками (рис. 5.1).

Схема организации бизнес-процесса управления денежными потоками

Рис. 5.1. Схема организации бизнес-процесса управления денежными потоками

Схема отражает следующее действия участников бизнес-процесса.

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

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

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

После этого все введенные заявки получают статус «новая», что делает возможным просматривать их, но не дает возможности производить платеж. Каждая заявка содержит плановую дату исполнения - проведения платежа.

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

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

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

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

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

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

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

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

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

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

Пример регламентного документа приведен в табл. 5.1.

Регламенты платежей удобно также изображать в вцце диаграммы Ганта, на которой отдельные этапы платежного графика представлены в форме отрезков пропорциональной длины (рис. 5.2).

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

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

Т аблица 5.1. Г рафик прохождения платежей

ign

Операции

Исполнители

Рабочие дм

Приме* іаи не

I г 3 4 5

га pain мрован н ни срок выполнения опера ним

]

2

Формирование

заявки

в электронной системе. Акцепт заявки руководителем ЦФО

Акцепт заявки

Инициатор

платежа,

финансовый

менеджер

Финансовый

менеджер

Финансовый

директор

(для заявок,

требующих

акцепта

финансовым

директором)

Генеральный

директор

(для заявок.

требующих

акцепта

генеральным

директором)

До 16 ч До 18 ч До 10 ч До 11 ч Акцептованная

руководителем

ЦФО заявка

автоматически

поступает

финансовому

менеджеру

3

4

5

  1. 7
Регистрация состояния заявок в электронной платежной системе

Выдача по заявкам наличных денежн ых средств

Осуществление безналичных оплат по заявкам с приоритетом

*L

Осуществление безналичных оплат по заявкам с приоритетом

«2»

Осуществление безналичных оплат по заявкам с приоритетом

«3»

Финансовый

менеджер

Кассир

Операционист

Операционист

Операционист

До 12 ч С II ч В

течение

дня

До 14 ч

В

течение

дня

До 14 ч До 14 ч Заявка, по которой денежные средства небыли подучены в течение трех дней, аннули руется

В случае

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

Дата оплаты определяет финансовый директор

Акцепт менеджером До 18 ч ;|

.Акцепт финансовым директором

Регистрация в платежной системе Вшачз наличных денежны* средств Безналичная оплата по приоритету «1» Безналичная оплата по приоритету «2» Безналичная оплата по приоритету «3»

Акцепт генеральным директором

До Юн

J I Г1л 11а

Диаграмма Ганта прохождения платежей в системе управления финансовыми потоками

С11ч До 14 \';\'; В течение дня

В течение дня

До 14 ч

Понедельник

Вторник ; Среда ; Четверг і Пятиищ і

Рабочие (бзнкоккиеідни

Рис.

5.2. Диаграмма Ганта прохождения платежей в системе управления финансовыми потоками

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

Требования к программному обеспечению

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

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

Внедрение систем управления финансовыми потоками

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

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

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

Проектирование информационной системы управления финансовыми потоками

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

Концептуальная модель

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

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

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

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

На рис. 5.3 представлена одна из форм концептуальной модели.

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

Накопление

I

Ресурсы

Материальные

Предприятие

Результаты

Операционная пол система

Материальные

!\\

I с

_ j і,

Денежные

Денежные

Инвл-тицнснная

полсистема

Кредитно-

финансовые

Финансовая

полсистема

Кредитно-

финансовые

Потребление

Рис. 5.3. Концептуальная модель информационной системы

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

Информационная модель

Информационная модель - это модель объекта, процесса или явления, в которой представлены информационные аспекты моделируемого объекта, процесса или явления.

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

Нефинансовые Собственный
активы капитал
Заемный
Финансовые капитал
активы

Рис. 5.4. Информационная модель

Информационную модель часто представляют в матричной форме. Пример такой модели представлен на рис. 5.4. Подобная форма модели позволяет проводить анализ финансового состояния исследуемого объекта методом наложения [Абрютина, 2002].

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

В этом случае возможны следующие варианты состояния активов и пассивов:

  • собственный капитал больше нефинансовых активов;
  • собственный капитал равен нефинансовым активам;
  • собственный капитал меньше нефинансовых активов.

Из сопоставления трех вариантов моделирования финансовой ситуации можно сделать следующее выводы:

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

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

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

Модель финансовых потоков

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

Модель финансовых потоков это, по сути, таблица, содержащая перечень всех потоков, их величины и дату проведения платежей (табл. 5.2).

Таблица 5.2. Модель финансовых потоков

І Іаимснование статьи Текущий

месяц

Плановый

месяц

Месяц, следующий за плановым
Поступления от продаж

Затраты на операционную деятельность

Кэш-фло от операционной деятельности

Приобретение основных средств

Кэш-фло от инвестиционной деятельности

Поступление заемных средств

Возврат кредитов Платежи по процентам

Кэш-фиго от финансовой деятел ьностти

СУММАРНЫЙ ДЕНЕЖНЫЙ ПОТОК

Наименование статьи 1 2 3 4 ИТОГО
Поступления от продаж

Затраты на материалы

Постоянные затраты

Зарплата

Налога

Приобретение основных средств

Строительство

Прочие капитальные вложения

Платежи по процентам Поступления от кредитов

Возврат кредитов

Дебетовое сальдо на начало периода

Дебетовое сальдо на конец периода

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

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

Структурно-функциональная модель

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

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

Общий вцц структурно-функциональной модели представлен на рис. 5.5.

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

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

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

Структурно-функциональная модель

Рис. 5.5. Структурно-функциональная модель

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

  • SADT (технология структурного анализа и проектирования) и выполненные на его основе пакеты;
  • AUTOIDEFO (комаццно-ориентированная графическая среда);
  • Design/IDEF и Bpwin (проектирование и моделирование сложных систем, связанных с автоматизацией производства, задачами экономико-организационного управления и т.п.);
  • CASE-аналитик (автоматизация, проектирование и внедрение систем обработки информации и управления).

Для реализации имитационных компьютерных моделей используются такие инструментальные средства, как GPSS, СПАМ, С И МУЛА-67 и др.

Интегрированная модель

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

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

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

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

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

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

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

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

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

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

Интегрированная модель

Рис. 5.6. Интегрированная модель

Реализация и внедрение информационных систем

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

Блок-схема алгоритма реализации и внедрения системы автоматизированной управления финансовыми потоками представлена на рис. 5.7.

Описание алгоритма

Блок 1. Моделирование информационной системы.

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

Блок 2. Разработка технического задания.

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

ґ              „              Л

4 Внесение
изменений
по результатам

I              Начало              )

] Модел

инфор

систем

ірование

иационной

ы

Г

2

Разработка

технического

задания

3 Пострс

технол

проект

ение

огической сети ирования

5 Создание 6 Апробация
рабочего - -* рабочего
прототипа прототипа

Неудовлетворительная

8 Доработка 9 Реализация 10 Внедрение
по результатам gt; информационной               gt; рабочего
внедрения системы варианта

Неудовлетворительная

Блок-схема алгоритма реализации и внедрения информационной системы управления финансовыми потоками

Удовлетворительная

Рис. 5.7. Блок-схема алгоритма реализации и внедрения информационной системы управления финансовыми потоками Блок 3. Построение технологической сети проектирования.

На основе технического задания строится пошаговая схема программно-методологической реализации информационной системы в вцце технологической сети проектирования (ТСП). Для этого предварительно определяют один из возможных методов проектирования информационной системы [Никишев, 2005, с. 10 - 12; Жданчиков, 1991, с. 3 - 7]:

  • индивидуальный;
  • системный;
  • подсистемный;
  • типовой.

Пример технологической сети проектирования для подсистемного автоматизированного метода проектирования приведен на рис.

Технологическая сеть проектирования

5.8.

Рис. 5.8. Технологическая сеть проектирования

Согласно методике, предложенной М.А. Королевым, А.И. Мишениным, Э.Н. Хотяшовым, процесс построения информационной системы описывается с помощью ТСП. Сеть состоит из преобразователей (П), документов ( D ), информационной модели (Р 1), программных комплексов разного назначения (G), универсумов (U), содержащих сведения о программах [Королев, Мишенин, Хотяшов, 1984].

В нашем примере преобразователем П1 по информации о финансовой системе (D 1 j и подключаемых для нее функций (D 2), определяются требования к составу и содержанию пакетов прикладных программ ( D 3) и строится информационная модель системы (Р1).

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

На основе полученной информации о составе ППП ( D 4), инструкционных материалов ( D 5) и параметров функциональных модулей, получаемых на основе информационной модели Р, преобразователь ПЗ формирует модель информационной системы в вцце комплекса пакетов прикладных программ.

Преобразователем П4, основой которого является программный комплекс средств автоматизированного проектирования, производится перевод входной информации о функциях будущей системы ( D 6) с подключением ППП (U2 ) в форму программного комплекса информационной системы ( G 3), представляющего иерархическую систему функциональных модулей, документируемую

преобразователем Г15 в вцце пакета организационных документов ( D 7).

Оперативность построения информационной системы достигается в данном случае за счет автоматизации операций выбора ППП (Г12) и взаимоувязки их в систему (Г14).

После завершения работ по проектированию ТСП производится безусловный переход к блоку 5.

Блок 4. Внесение изменений по результатам.

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

Блок 5. Создание рабочего прототипа.

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

Блок 6. Апробация рабочего прототипа.

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

Блок 7. Оценка результатов.

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

Блок 8. Доработка по результатам внедрения.

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

Блок 9. Реализации информационной системы.

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

Блок 10. Внедрение рабочего варианта.

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

Блок 11. Оценка результатов.

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

<< | >>
Источник: Петр Алексеевич Жданчиков. Казначейство. Автоматизированные бизнес-технологии управления финансовыми потоками 2010. 2010

Еще по теме Процедуры системного подхода и его преимущества по сравнению с моноаспектным и комплексным подходами:

- Авторское право - Аграрное право - Адвокатура - Административное право - Административный процесс - Антимонопольно-конкурентное право - Арбитражный (хозяйственный) процесс - Аудит - Банковская система - Банковское право - Бизнес - Бухгалтерский учет - Вещное право - Государственное право и управление - Гражданское право и процесс - Денежное обращение, финансы и кредит - Деньги - Дипломатическое и консульское право - Договорное право - Жилищное право - Земельное право - Избирательное право - Инвестиционное право - Информационное право - Исполнительное производство - История - История государства и права - История политических и правовых учений - Конкурсное право - Конституционное право - Корпоративное право - Криминалистика - Криминология - Маркетинг - Медицинское право - Международное право - Менеджмент - Муниципальное право - Налоговое право - Наследственное право - Нотариат - Обязательственное право - Оперативно-розыскная деятельность - Права человека - Право зарубежных стран - Право социального обеспечения - Правоведение - Правоохранительная деятельность - Предпринимательское право - Семейное право - Страховое право - Судопроизводство - Таможенное право - Теория государства и права - Трудовое право - Уголовно-исполнительное право - Уголовное право - Уголовный процесс - Философия - Финансовое право - Хозяйственное право - Хозяйственный процесс - Экологическое право - Экономика - Ювенальное право - Юридическая деятельность - Юридическая техника - Юридические лица -