Моделирование бизнес-процесса потребительского кредитования

Кроме стандарта IDEF0, BPwin поддерживает также методологии  моделирования DFD (data flow diagram) и IDEF3 (workflow). Методология DFD служит для описания потоков данных, которые возникают  в результате деятельности компании. Методология IDEF3 служит для графического описания потока процессов (работ), взаимодействия процессов и объектов, которые  изменяются этими процессами.

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

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

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

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

3. Построение модели AS IS

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

На основе модели AS-IS достигается консенсус  между различными этапами процесса по тому, «кто что сделал» и что  каждый этап добавляет в процесс. Функциональная модель AS-IS является отправной  точкой для анализа потребностей предприятия, выявления проблем  и «узких» мест и разработки проекта  совершенствования деловых процессов. Модель AS-IS позволяет выяснить, «что и как мы делаем сейчас» перед  тем, как определить то, «что и как  будет делаться завтра». Анализ функциональной модели AS-IS позволяет понять, где  находится проблемная ситуация, в  чем будут состоять преимущества новых процессов и каким изменениям подвергнется существующая структура организации процесса. Исследование необходимости реструктуризации (выявление и ликвидация недостатков) в существующих процессах достигается за счет применения декомпозиции (анализа), производящаяся даже там, где функциональность на первый взгляд является очевидной. Так, например, признаками неэффективности существующих процессов могут быть:

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

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

IDEF0

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

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

Каждая IDEF0-днаграмма содержит блоки  и дуги. Блоки изображают функции  моделируемой системы. Дуги связывают  блоки вместе и отображают взаимодействия и взаимосвязи между ними.

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

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

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

Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие.

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

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

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

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

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

Рассмотрим  поподробнее схему работы кредитного отдела

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

IDEF3

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

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

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

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

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

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

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

На примере  данной работы составим IDEF3 диаграмму  процесса анализа заявки службами банка.

Итак, в  банк пришел клиент с заявкой на получение кредита. Перед тем, как  заключать договор с клиентом, в кредитном отделе происходит анализ предоставленных клиентом данных: верны  ли личные данные о клиенте, все ли данные были предоставлены и т.д. Перекресток ХOR указывает на то, что на данном этапе возможны два несовместных варианта событий: при несоответствии данных, мгновенно следует отказ в выдаче кредита, если же все данные соответствуют действительности, данные передаются на анализ в отдел кредитной политики. Перекресток «асинхронное ИЛИ» указывает на то, что на данном этапе происходит запуск нескольких событий: проверяется, чем занимается клиент, каковы его доходы, сможет ли он выплачивать кредит в течении срока, указанного в заявке, и приемлем ли этот срок для банка.