Основные направления автоматизации бизнес-процессов управления финансовыми потоками

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

Собственно термин «контроллинг» (от англ. to control – контролировать, управлять) появился в Германии, откуда он и пришел в Россию. В Великобритании и США он практически не используется. Там укоренился термин «управленческий учет» {managerial acconting). В экономическом менеджменте России пока используются оба термина. Однако термин «контроллинг» более информационно емкий, так как включает не только чисто учетные функции, но и весь спектр управления процессом (АСУТП и АСУП) достижения конечных целей и результатов фирмы.

Контроллинг обеспечивает:

• координацию управленческой деятельности по достижению целей предприятия;

• информационную и консультационную поддержку принятия управленческих решений;

• условия для функционирования общей информационной системы управления предприятием;

• рациональность управленческого процесса.

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

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

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

• улучшения качества выпускаемой продукции;

• увеличения объема производства;

• занятия устойчивых позиций на рынке и победы в конкурентной борьбе.

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

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

• надежная защита от несанкционированного доступа к данным и регистрации действий персонала;

• удобный пользовательский интерфейс рабочих мест;

• возможность масштабирования и развития системы;

• интеграция с модулями системы передачи данных;

• возможность конвертации данных из использовавшихся в прошлом приложений в новую систему;

• высокая надежность работы.

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

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

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

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

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

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

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

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

• подготовка рекомендаций по изменению структуры организации и бизнес-процессов (реинжиниринг бизнес-процессов);

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

• разработка стратегии внедрения изменений на предприятии и ее реализация.

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

Из известных методик, применяемых для анализа бизнес-процессов, может использоваться Oracle Method корпорации Oracle, а для достижения высоких стандартов качества при управлении консалтинговыми проектами – методика Project Management Method (PJM) той же корпорации. Их совместное применение (корпорация Oracle более 20 лет выполняет проекты в области реинжиниринга бизнес-процессов) позволяет реализовать проекты с высоким качеством. Инструментальная поддержка осуществляется с использованием CASE-пакета Oracle-Designer/2003, имеющего полнофункциональный набор средств для разных стадий проекта – начиная с моделирования системы на уровне бизнес-процессов и функций и заканчивая поддержкой генерации исполняемого кода прикладной системы.

При выполнении работ по консалтингу используют проектно-ориентированный подход, полностью соответствующий PJM.

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

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

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

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

• определение внешних и внутренних целей системы;

• выделение системы из среды, изучение отношений системы с внешней средой;

• рассмотрение возможных членений системы (интегрального эффекта);

• прогнозирование поведения системы;

• описание информационных потоков в системе;

• выбор для системы методов управления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• определение участников процесса, которые выступают в роли инициаторов и контролеров проводимых в системе платежей;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• поддержку процедур согласования бюджетных планов и заявок на оплату путем визуализации и пересылки финансовому менеджеру акцептованных заявок;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• нефинансовые активы связывают собственный капитал;

• заемный капитал поглощает финансовые активы;

• предприятие имеет собственные финансовые активы, если собственный капитал превышает финансовые активы;

• если собственный капитал меньше нефинансовых активов, заемный капитал поглощает как финансовые, так и часть нефинансовых активов;

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

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

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

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

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

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

Указанная модель является дополнением к информационной модели, изображенной на рис. 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. Разработка технического задания.

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

Блок 3. Построение технологической сети проектирования.

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

• индивидуальный;

• системный;

• подсистемный;

• типовой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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