6. Выводы. Рекомендации по применению систем в зависимости от типовых задач

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

Задача/Инструментальная среда	ARIS Toolset 5.0	BPWin 4.0
Разовый проект по описанию бизнес-процессов, например: 1) описание одного бизнес-процесса с точки зрения контроля и управления; 2) описание функциональных возможностей новой системы управления на верхнем уровне.	3   3	5   5
Длительный (непрерывный) проект по описанию деятельности компании с различных точек зрения (организационная структура, структура документов, большой объем базы данных процессов  и т.д.)	5	3
Разработка системы автоматизации: 1) описание функциональных возможностей системы; 2) создание логической модели данных; 3) создание физической модели данных.	3 3 -	5 BPWin + ERWin + Paradigm Plus

Таблица 6.

Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (см. рисунок 8).

Рисунок 8.

Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPWin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.

7. Литература

1. Инфопортал www.finexpert.ru

2. Интернет-сайт www.idef.com

3. С.В. Маклаков. BPWin и ERWin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2000.256 с

4. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. Москва, 1993 г.

5. «Методы ARIS». Файл pdf, более 1000 стр. Поставляется вместе с демо-версией системы ARISToolset.

6. Август-Вильгельм Шеер, Бизнес-процессы: основные понятия, теории, методы, Москва.: Просветитель, 1999

См. также http://devbiz.narod.ru/development/eod/biz_modeling.htm

http://www.manual.tl.ru/ooad.asf.ru/student/lectures/risp/lec010.asp

Лекция 4. Анализ и проектирование.

ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ

Для создания программного приложения необходимо описать проблему и требования к системе. Стадия анализа (analysis)состоит в исследовании проблемы, а не в поисках ее решения. Например, при разработке новой экономической информационной системы необходимо описать экономические процессы, связанные с ее использованием. При разработке приложения необходимо также обеспечить высокий уровень и подробное документирование логики решения, удовлетворяющего требованиям к системе и налагаемым ограничениям. В процессе проектирования (design)основное внимание уделяется логическому решению, обеспечивающему выполнение основных требований. Например, как будет функционировать новая экономическая информационная система? Естественно, проект может быть реализован в виде аппаратных средств и программного обеспечения. В реальной жизни программные проекты чаще всего достаточно сложны, и их декомпозиция (по принципу "разделяй и властвуй") - это основная и, наверное, единственная стратегия борьбы со сложностью. Она состоит в разбиении проблемы на мелкие управляемые элементы. До появления объектно-ориентированного подхода во времена господства парадигмы структурного программирования наиболее популярной методологией декомпозиции являлисьструктурный анализ и проектирование (structured analysis and design). Этот подход заключается в декомпозиции задачи на функции или процессы, приводящий к созданию иерархии процессов и подпроцессов. Существовали и существуют и другие методы декомпозиции. В следующем разделе мы рассмотрим наиболее известные и часто применяемые методики анализа, позволяющие минимизировать риски и решать ключевые проблемы, возникающие на различных этапах жизненного цикла.

СТАДИЯ АНАЛИЗА

Стандарты семейства IDEF

Это семейство методологий создавалось в то время, когда существовала "иллюзия всеобщего математического моделирования", в соответствии, с чем предполагалась следующая последовательность действий: определение функциональной (концептуальной) модели бизнеса - определение данных, необходимых для реализации модели - математическое моделирование - оценка результатов - реорганизация модели - и новая итерация, пока модель не будет "поставлена в рамки". В соответствии с этой концепцией и предполагалось создать серию стандартов: · IDEF0 - стандарт функционального моделирования (принят) · IDEF1 (X) - стандарт информационного моделирования (принят), хорошо известен еще и под названием "ER- диаграммы". · IDEF2 - стандарт математического моделирования (не принят). Не принятие стандарта математического моделирования было вполне естественным, так как при реализации математической модели приходилось либо жертвовать ее точностью, либо ... самой возможностью что-то моделировать, ввиду чего никогда нельзя было с полной уверенностью говорить о "соответствии математической модели функциональной", разработанной в стандарте IDEF 0. Тем не менее, существуют программные продукты, которые позволяют проводить математическое моделирование по функциональному описанию в стандарте IDEF0. · IDEF3 - наиболее важный из серии современных стандартов, определяет методологию моделирования процессов, проще говоря, построения технологических карт. Отсутствие методологии моделирования процессов (технологий) было существенным недостатком семейства методологий IDEF, что затрудняло использование их, например, в проектировании корпоративных информационных систем. В последние годы семейство методологий IDEF получило дальнейшее распространение, став полноценной системой разработки систем управления, от концепции проекта до создания кода программного продукта, выполняющего определенные на концептуальном уровне задачи. Наиболее интересные компоненты современного развития семейства IDEF перечислены ниже: · DFD "Data flow diagram", "диаграммы потоков данных" - широко распространенная методология моделирования процессо-ориентированного типа. · "Моделирование в терминах системы" - одной из существенных проблем при использовании "универсальных" методологий моделирования является дальнейшее использование результатов в практической работе, например при внедрении или создании корпоративной информационной системы. Часто оказывается (особенно до создания методологии IDEF 3), что применить результаты длительной работы достаточно сложно. Поэтому неудивительно, что все крупнейшие поставщики интегрированных программных систем озаботились созданием специализированных систем моделирования, адекватных применяемой системе. Наиболее интересная методология "моделирования в терминах системы" создана усилиями специалистов BAAN.

:: Назад::Вперед::Содержание::На главную::

http://www.kv.by/index1998014201.htm