Название: Информационные технологии в банке - Тютюнник А.В

Жанр: Информатика

Рейтинг:

Просмотров: 1392

Инструментарий бизнес-моделирования

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

Каковы же основные современные термины, стандарты и методологии описания и реинжиниринга бизнес-процессов организации?

Опыт практического реинжиниринга породил ряд методологий и стандартов по разработке и моделированию бизнес-процессов. В основном они сводятся к регламентации построения и описания схемы бизнес-процесса на базе современных CASE-средств (Computer-Aided System of Engineering). Компьтерноориентированные системы инжиниринга предназначены для моделирования и анализа технологии работы, а также проектирования, разработки и сопровождения программного обеспечения. Мы рассматриваем использование CASE-средств лишь для анализа и проектирования всех бизнес-процессов и операций, хотя их способность существенно облегчать процесс создания программных продуктов (осуществлять его в полуавтоматическом режиме), в том числе и для автоматизации новой, измененной технологии работы, объясняет их популярность и широкоераспространение.

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

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

Для статического моделирования бизнес-процессов обычно используется методология SADT (точнее, ее подмножество IDEFO), поддерживаемая пакетами BPWin, Design/IDEF и др. Однако статическая SADT-модель, как отмечалось, может не обеспечивать полного решения задач перепроектирования, так как необходимо иметь возможность исследования динамических характеристик бизнес-процессов.

Одним из возможных решений является использование системы динамического моделирования Design/CPN, основанной на методологии цветных (раскрашенных) сетей Петри. Фактически Design/IDEF и Design/CPN являются компонентами интегрированной методологии перепроектирования: статические SADT-диаграммы автоматически могут превращаться в прообраз динамической модели, которая дорабатывается вручную и затем исполняется в различных режимах с целью получения соответствующих оценок.

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

Следует отметить, что не существует принципиальных ограничений при использовании в качестве средства построения статических моделей бизнес-процессов еще одной традиционной методологии - диаграмм потоков данных, или DFD (data flow diagrams). Более того, в настоящий момент доступен ряд продуктов динамического моделирования (INCOME Mobile, CRN-AMI и др.), базирующихся на сетях Петри различного вида и интегрируемых с DFD-моделью, которые позволяют успешно решать задачи перепроектирования. Многие средства статического моделирования также поддерживают эту методологию, в том числе BP-Win (Platinum).

В общей процедуре реинжиниринга могут одновременно использоваться различные подходы и методологии с целью достижения большего удобства и эффективности проектирования. Например, бизнес-аналитики могут использовать методологию SADT, а разработчики программного обеспечения - методологии и подходы, основанные на стандарте DFD, или одно из современных средств UML (Unified Modelling Language - универсальный язык моделирования), который базируется на методологии объектоориентированного анализа.

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

Группа стандартов IDEF разработана в 1980-1990-х годах несколькими группами американских ученых под общим руководством Лаборатории Армстронга авиабазы Райт-Паттерсон ВВС США. Целью этих стандартов первоначально была унификация методов построения распределенных гетерогенных информационных систем. По мере разработки последующих стандартов становилось ясно, что группа IDEF потенциально имеет гораздо больший спектр применений.

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

При этом в силу весьма высокой степени абстрактности исходных категорий в стандартах IDEF имеется возможность легко переходить к описанию любых областей практической деятельности человека. Для этого формируется понятийный аппарат (определение, спецификация) более конкретного порядка и устанавливаются связи элементов аппарата с лежащими в основе абстрактными категориями. При необходимости еще более конкретизировать (детализовать) рассматриваемую область аналогичным образом создается понятийный аппарат следующего порядка конкретизации и т.д. Из чисто практических соображений стандарты IDEF предусматривают до шести уровней такой детализации. Практика показывает, что такого количества иерархических ступеней (или "уровней вложенности") детализации достаточно для рассмотрения, анализа и моделирования практически любой области человеческой деятельности. Неудивительно, что разработанная первоначально в рамках крупного аэрокосмического проекта ВВС США группа стандартов IDEF и положенная в основу первого из этих стандартов (IDEFO) методика SADT (Structured Analysis and Design Technique) впоследствии с успехом применялись и применяются в самых различных отраслях промышленности и бизнеса. Как отмечает один из основоположников методологии IDEF, автор методики SADT, Дуглас Т. Росс, ее применяли тысячи людей при работе над сотнями проектов во многих областях.

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

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

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

* графический символ;

* текст;

* глоссарий.

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

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

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

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

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

1. Постановка задачи для выполняемых работ:

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

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

2. Определяется точка зрения для построения диаграмм. В основной схеме используется точка зрения бизнес-технолога, задачей которого являются распределение обязанностей между работниками, разработка должностных инструкций. Для разработки пользовательского интерфейса лучше использовать точку зрения дизайнера интерфейса и детализировать в основной схеме блоки типа "Зарегистрировать операцию в АБС". На диаграмме рекомендуется в качестве активностей описать ввод конкретных полей пользователем. В качестве стрелок использовать правила, накладываемые одним полем на ввод другого.

Для разработки отчета можно детализировать активности типа "Формирование отчетности". В качестве активностей рекомендуется использовать бизнес-правила получения данных, в качестве стрелок - потоки данных.

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

4. При построении новой схемы необходимо:

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

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

4.3. соединить активности туннельными стрелками от детализированной диаграммы к порождающей диаграмме;

4.4. провести объединение стрелок без потери информативности схемы;

4.5. провести соединение стрелок, входящих в бизнес-процесс, с граничными стрелками;

4.6. распечатать построенные диаграммы и обсудить их с предполагаемыми исполнителями.

5. Для оптимизации уже разработанной схемы необходимо:

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

5.2. ознакомиться с предметной областью и возможными решениями данной проблемы;

5.3. попытаться поставить задачу без использования специальных терминов;

5.4. используя наработанный опыт и приемы оптимизации, провести перестройку данной схемы;

5.5. проверить соответствие новой схемы оговоренным условиям;

5.6. обсудить решение с предполагаемыми исполнителями.

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

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