Файл: Проектирование реализации операций бизнес-процесса «Управление денежными потоками» (Характеристика существующих бизнес – процессов).pdf

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

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

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

С1 – план развития ИТ Банка;

С2 – стандарты, регламенты в области ИТ;

С3 – нормативные документы ЦБ РФ;

С4 – инструкции;

I1 – информация о потребности определенной техники;

I2 – информация о поломке техники;

О1 – заявка на приобретение новой техники и программных средств;

О2 - ремонт техники;

М1 – системный администратор;

М2 – помощник системного администратора.

Управление информационными ресурсами и технологиями

Планирование обеспечения потребностей банка

Установка техники и программного обеспечения

Поддержание бесперебойной работы техники и ПО

Контроль работы и обслуживание

М1

О1

О2

С3

С1

М1

С1

С2

О1

М1

О1

О2

О1

С2

С4

С2

С4

Рисунок 2 - IDEF - диаграмма для отдела информационных технологий

С2

С3

М2

С3

М2

С4

М2

М1

М3

2.2. Характеристика нормативно-справочной, входной и оперативной информации

Элементы системы управления денежными потоками, к ним следует отнести финансовые методы и инструменты, нормативно-правовое, информационное и программное обеспечения:

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

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

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

2.3. Характеристика результатной информации

Процесс «Управление денежными потоками» прежде всего необходим для составления бюджета, хотя и опирается на бухгалтерские данные, включает в себя ряд плохо структурированных решений. Существует три подхода к его составлению: сверху вниз, снизу вверх и смешанный.

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

Рисунок 3 - Контекстная диаграмма системы «Управление денежными потоками

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

После создания контекстной диаграммы, я постаралась рассмотреть

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

В результате декомпозиции была получена диаграмма первого уровня.

Рисунок 4 - Диаграмма детализации первого уровня системы «Управление денежными потоками»

2.4. Общие положения (дерево функций и сценарий диалога)

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

Рисунок 5 – Дерево функций процесса «Управление денежными потоками»

Use case diagram (диаграммы прецедентов) - позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.

Исходя из поиска ответов на следующие вопросы:

Кто взаимодействует с системой или использует систему?

Кто передает или принимает информацию в/из системы?

Кто является внешним по отношению к системе?

Я выявила следующих субъектов.

Рисунок 6 - Субъекты системы

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

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

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

Рисунок 7 - Прецеденты системы

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

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

Достоинства модели вариантов использования заключаются в том, что она:

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

Рисунок 8.

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

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

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

Рисунок 9 - Диаграмма прецедентов для субъекта Клиент банка

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

Следует прокомментировать некоторые особенно «привлекательные» отношения между вариантами использования.

Так, смысл отношения «include» состоит в том, что Создание платежного документа включает в себя Создание платежного поручения и Создание платежного требования. Также, прецедент Подписать документ ЭЦП выполняется только в рамках Создания платежного документа, Создания нового письма или Отзыва документа.

Смысл же связи <<extend>> в том, что прецедент, например, Создание платежного документа «расширяется» вариантом использования Сохранение документа, которой в свою очередь расширяется прецедентом Проверка реквизитов документа. Я объясняю это тем, что сохранить документ можно только проверенный системой на наличие ошибок. Распечатка перечня документов за определенный период «расширяет» прецедент Получение выписки. Таким образом, связь <<extend>> говорит о выполнении того или иного прецедента в зависимости от определенных условий.

Рисунок 10 – Сценарий диалога

2.6. Структурная схема пакета (дерево вызова программных модулей)

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