Аис1
.pdfнесогласованность должна быть преодолена, чтобы получить модель, представляющую объект моделирования или какую-то его часть адекватно.
Методология IDEF0 предусматривает необходимость сохранения записей о всех решениях и альтернативных подходах по мере того, как они возникают на протяжении проекта.
Копии диаграмм, разработанные автором, критически (конструктивно) анализируются компетентными экспертами, которые заносят свои замечания и предложения непосредственно на копиях диаграмм. Авторы отвечают на каждое замечание письменно на тех же копиях.
Предложения принимаются или отвергаются письменно с указанием причин. После внесения изменений и исправлений старые варианты диаграмм остаются в архиве проекта.
Впроцессе чтения диаграмм ничто не должно предполагаться в модели по умолчанию, а также не должны делаться выводы, выходящие за пределы действия и утверждения модели. Это побуждает автора к тщательному комментированию и иллюстрированию каждого добавляемого к модели фрагмента, чтобы при чтении и интерпретации модели ее толкование было однозначным и соответствующим поставленной цели и установленной точке зрения без личного присутствия автора и его дополнительных пояснений.
Вколлектив, занимающийся моделированием ИС, обязательно должны входить следующие
участники:
руководитель проекта;
авторы (разработчики) модели;
технический совет;
эксперты в предметной области;
библиотекарь.
Можно добавить к вышеприведенному списку специфического участника проекта - «Источники информации». Источниками информации могут служить люди и документы. Природа этой информации во многом зависит от стадии разработки модели.
При проведении работ с привлечением сторонних организаций может создаваться Координационный совет, обеспечивающий взаимодействие всех участников проекта, работающих как в составе проектирующей организации, так и вне ее. Выполняемая функция («роль», кото-рую выполняет участник проекта) не зависит от должности. Один и тот же человек может выполнять несколько функций. Однако «роль» каждого участника проекта индивидуальна, должна быть определена и зависит от рассматриваемой части проекта.
Принципы коллективной работы в IDEF0 - методологии гарантируют, что окончательная версия IDEF0 - модели будет верной, так как модель корректируется по результатам рецензирования частей модели, оформленных в виде папок. Более подробная детализация достигается построением необходимого количества диаграмм. По новым частям модели делаются новые замечания, вносятся новые изменения. Окончательная модель соответствует представлениям автора и экспертов о системе, смоделированной с данной точки зрения и для данной цели.
Руководитель проекта и разработчики модели (авторы) должны быть главными исполнителями. Хотя конечной целью разработчика является получение одобрения модели техническим советом, утверждает результаты руководитель проекта. Таким образом, обеспечивается согласованность интересов авторов, рецензентов, совета и руководителя проекта.
Руководитель проекта
Это участник проектной группы, осуществляющий административное управление проектом. Ру-ководитель проекта должен выполнять при моделировании следующие
основные функции:
выбирать разработчиков модели (авторов). Главным аспектом данной функции является достижение руководителем проекта и разработчиком модели согласия относительно ос-новополагающих правил, в соответствии с которыми выполняется моделирование. Сюда входят использование методологии, степень контроля за разработчиком модели со стороны руководителя проекта, область действия и ориентация разрабатываемой модели;
определять обязательные источники информации, на которые разработчик модели
141
будет опираться при построении модели. Этими источниками могут быть либо люди, осведомленные о различных аспектах рассматриваемой сферы деятельности, либо документы, освещающие предметную область моделирования. Эти источники определяются на начальной стадии моделирования, но список их в процессе моделирования должен пересматриваться и уточняться, поскольку по мере построения модели потребности в информации меняются
выбирать экспертов, чьи знания будут использованы разработчиком для получения оценки (одобрения) диаграмм и частей модели. Список экспертов составляется на начальной стадии проекта и уточняется по мере необходимости;
формировать технический совет. Этот совет под председательством руководителя проекта периодически собирается для обсуждения существенных вопросов, рецензирования и определения статуса модели и ее частей;
присваивать статус рассматриваемой советом части модели.
Автор модели
Это участник проектной группы создающий IDEF0 -модели на основе материала, собранного из источников информации. К функциональным обязанностям автора, как системного аналитика относятся:
сбор исходных данных от обязательных источников информации, определенных руково-дителем проекта. Автор должен понимать, что каждый эксперт-источник информации смотрит на информацию со своей точки зрения, поэтому он должен стараться увидеть глазами источника информации ее смысл и структуру. Синтезируя эти точки зрения в процессе сравнения и противопоставления, разработчик создает образ изучаемого объекта моде-лирования. При недостаточности собранных сведений автор вправе использовать любые другие источники информации с обязательным указанием ссылок на них;
обучение (при необходимости) основам IDEFO-моделирования руководителя проекта, экспертов (рецензентов и читателей) и других членов технического совета для обеспечения правильного понимания ими моделей, создаваемых авторами. Помощь в изучении и использовании технологии моделирования заключается в общем ориентировании членов технического совета, источников информации и экспертов, ознакомлении их с навыками чтения модели, а также с навыками моделирования.;
организация процесса разработки модели;
оформление модели в виде IDEFO-диаграмм;
установление необходимого контакта со всеми участниками проекта на основании предос-тавленного руководителем проекта списка источников информации и списка экспертов;
оформление модели в виде набора IDEF0-диаграмм и оформление папки с диаграммами для рецензирования и передачи их в библиотеку проекта;
организация построения модели. Для поддержки принятых автором решений и регистрации вклада каждого участника записи исходной информации, собранной в процессе моделиро-вания, сохраняются в течение определенного времени после завершения проекта. Это по-зволяет следить за тем, чтобы исследуемая область была охвачена со всех сторон. Зная, кто и в каких областях поставлял информацию,
икак это происходило, автор может оценить степень соответствия стадии моделирования исходным целям;
после очередного этапа декомпозиции аналитик создает диаграмму на основе общих знаний, анализа документации и опроса экспертов. Общие знания не позволяют создать диаграмму достаточно корректно, поэтому она нуждается в уточнении и дополнении.
автор устно и письменно опрашивает экспертов. Читатели сообщают о замеченных недостатках автору с помощью вносимых прямо в папку замечаний, которые называются комментариями.
автор читает эти комментарии и отвечает на них письменно. На основании замечаний
142
создает новый набор взаимосвязанных диаграмм, а затем, путем отсылки папки, автор обращается с просьбой к экспертам произвести повторное рецензирование своей работы;
Последовательность выполнения декомпозиции имеет большое значение, поскольку в IDEF анализ объектов системы оказывает важнейшее влияние на анализ функций. На основании правил, изложенных в стандарте IDEF0, может быть предложен следующий порядок разработки модели автором:
1.Изучение объекта моделирования и определение области действия модели.
2.Разработка плана проекта - определение состав и последовательность работ, которые не-обходимо выполнить для достижения поставленных целей.
3.Анализ и синтез системных объектов, записывая, как именно подверглись разбиению объекты, входящие в ограниченный объект. Список данных начинается со всех граничных стрелок и их ICOM-кодов, а заканчивается их составляющими.
4.Просматривает список данных и, возможно, объединяет эти составляющие, чтобы выделить те объекты, которые будут выступать в качестве управляющих.
5.В соответствии со списком данных подобный анализ и синтез функций системы. В процессе свободного объединения и введения новых управляющих стрелок создается список функций для дальнейшей детализации. Функции вносятся в список до тех пор, пока поток идей не иссякнет.
6.Функциональные части объединяются в сбалансированные наборы из 3-6 блоков. Такое тре-бование стандарта вынуждает автора использовать абстракцию и декомпозицию для по-степенного представления деталей системы.
7.Создаются основные стрелки, представляющие ограничения, потом внешние и, наконец, внутренние стрелки.
8.После определения функциональных частей список данных и список функций используются для чернового варианта диаграммы.
9.Снова выполняются анализ и синтез, в результате чего формируются наборы объектов, ко-торые представляются стрелками, соединяющими блоки.
После создания диаграммы, прежде чем рассылать ее для подробного рецензирования, аналитик должен самостоятельно выявить возможные ее недостатки. Опытные аналитики при декомпозиции блока разделяют этап создания и этап самостоятельного критического рассмотрения диаграммы. Создание диаграмм и критическая оценка являются различными этапами, но являются неотъемлемой частью процесса декомпозиции в IDEF0.
Авторская проверка
АВТОРСКАЯ ПРОВЕРКА - процесс критической оценки собственной работы, позволяющий определить качество диаграммы, которая декомпозирует блок и его стрелки. Авторская проверка позволяет аналитику объяснить объект самому себе. При критической оценке аналитик должен максимально абстрагироваться от своей работы, что позволяет ему взглянуть свежим взглядом на диаграмму с тем, чтобы информация, которую она несет, стала доступной не только ее автору, но и другим людям.
Процесс критической оценки должен происходить по следующему алгоритму:
1.Выявление недостатков новой диаграммы.
2.Создание альтернативных декомпозиций, чтобы проверить, является ли исходный набросок лучшим для передачи желаемой информации.
3.Корректировка новой диаграммы, которая включает, в том числе, проверку ее взаимосвязи с родительской и другими диаграммами.
4.Корректировка всех связанных с ней диаграмм.
Выявление недостатков диаграммы обычно происходит по схеме вопрос-ответ, поэтому нельзя четко сформулировать правила ее пошаговой оценки. Опытный аналитик, однако, в процессе оценки диаграммы задает определенный набор вопросов относительно блоков, связи с родительской диаграммой и внутренних стрелок. Ответ на каждый из них дает направление последующим вопросам. Таким образом, поток вопросов и ответов управляет анализом каждой части диаграммы.
Для критической оценки блоков диаграммы и определения функциональных аспектов диаграммы, можно задавать следующие вопросы:
143
представляют ли блоки содержательную декомпозицию функции?
не выглядит ли диаграмма запутанной?
все ли блоки соответствуют точке зрения модели?
несут ли блоки достаточный объем новой информации?
все ли блоки имеют одинаковый уровень детализации?
соразмерна ли сложность всех блоков?
отражает ли каждый блок какой-либо аспект блока родительской диаграммы?
Для уточнения связей диаграммы с ее родителем, т.е. проверки как диаграмма вписывается
вмодель, можно задать вопросы:
все ли внешние стрелки имеют ICOM-коды?
все ли ICOM-коды соединяют стрелки с одним и тем же значением?
дополняют ли названия внешних стрелок информацию, сообщаемую диаграммой?
не противоречит ли смысл анализируемой диаграммы смыслу родительской диаграммы?
Поиск ошибок в диаграмме обычно заканчивают вопросами о внутренних стрелках. Можно задать вопросы типа:
не слишком ли много внутренних стрелок?
нет ли блоков без стрелок управления?
нет ли блоков без выходных стрелок?
правильно ли отражают стрелки, представляющие ограничения, доминирование блоков?
верно ли решение диаграммы?
все ли важные обратные связи отражены?
все ли ошибочные ситуации учтены?
На основании новой информации о диаграмме, полученной в результате авторского рассмотрения, следует создать альтернативные декомпозиции - создать более точную диаграмму.
Даже если не удастся построить совершенно новую диаграмму, то можно исправить хотя бы часть исходного эскиза, с помощью четырех подходов, описанных ниже. Однако, применяя эти приемы, следует обращать внимание на то, что критерий качества для блоков достаточно противоречив. Например, добиваясь одинаковой сложности блоков, можно усложнить соеди-нения между ними, или наоборот, упрощая связи между двумя блоками можно скрыть какой-либо важный на данном уровне детализации факт. Основной целью всегда должна быть - получение наилучшего описания декомпозируемого объекта, поэтому построение хороших блоков возможно только при достижении равновесия между требованиями к сложности соедине-ния блоков и к достаточности уровня детализации. Необходимо быть осторожным и стараться сохранить равновесие между стремлением к детализации и сохранением наглядности диаграммы.
Способом оценки диаграммы является рассмотрение сценариев ее работы. Таким образом, проверяется точность и понятность представленной в диаграмме информации.
Аналитик представляет какую-либо возможную ситуацию и исследует, как работает диаграмма в заданных условиях. По мере развития сценария обычно выполняются определенные пометки на диаграмме, что дает возможность всегда повторить сценарий, а такая информация может помочь при декомпозиции блоков этой диаграммы.
Способом проверки правильности диаграммы является разложение одного - двух ее блоков. Детализация некоторой части новой диаграммы поможет определить сбалансированность декомпозиции и выявить неувязки в распределении функций между новыми блоками. (При этом сохраняйте свои наброски, чтобы облегчить будущие декомпозиции этой диаграммы.)
Иногда диаграмму, состоящую из четырех блоков, можно декомпозировать по-другому, заменив ее диаграммой из пяти - шести блоков, которая будет ненамного сложнее, но более информативная.
После определения вопросов к диаграмме, тестирования и выполнения альтернативных эскизов диаграммы, аналитик приступает к ее корректировке. При выполнении этого этапа необходимо следить за правильным доминированием, выбором названий блоков, информативностью стрелок, правильным графическим расположением, которое повышает читабельность диаграммы.
Создаваемая откорректированная диаграмма создается для того, чтобы донести
144
информацию в точном и понятном виде до читательской аудитории, поэтому наличие пояснительных надписей к такой диаграмме является обязательным условием.
После построение откорректированной диаграммы наиболее важные понятия, которые нельзя изобразить в виде блоков и стрелок, описываются с помощью замечаний или дополнительного материала. С другой стороны, описание типичных незаконченных заданий существенно облегчит объяснение того, как они должны быть завершены.
Создание диаграммы, ответы на связанные с ней вопросы и переделка ее обеспечивают более глубокое понимание родительской диаграммы и диаграмм - потомков вновь построенной диаграммы. Во время исправления диаграммы понимание ее функций аналитиком постоянно фиксируется, осуществляя, таким образом, перенесение информации снизу-вверх, что естест-венным образом вписывается в технику декомпозиции. Автор переносит информацию на другие диаграммы в трех ситуациях:
при изменении меток внешних стрелок. Перенесение измененных меток внешних стрелок немедленно обеспечивает предоставление родительской диаграммой всех данных, необ-ходимых диаграмме-потомку;
при появлении новых внешних стрелок. Эти новые стрелки должны, так или иначе, возник-нуть на родительской диаграмме. Есть два пути сделать перенесение: нарисовать новые стрелки на родительской диаграмме или объединить стрелки новой диаграммы в одну и изменить соответствующим образом метку стрелки на родительской диаграмме. Делая это, соблюдайте правила соединения и разветвления стрелок;
при перераспределении функций. Перемещение блоков представляет самую сложную си-туацию и происходит, когда функция (обычно на низком уровне модели)
должна появиться, но не появляется на диаграмме, которую рисуется, а появляется на другой диаграмме модели, или наоборот.
Перенесение функции, представленной блоком и всеми его стрелками, с одной диаграммы на другую обычно приводит к большим изменениям в метках стрелок, появлению множества новых и исчезновению некоторых старых стрелок. Иногда перемещение одного блока ведет к перемещению других блоков на различные диаграммы, вызывая целую волну изменений.
Как правило, перемещение блока влечет за собой обилие тех-нически сложной работы и может привести к ошибкам, если изменения не отслеживаются достаточно тщательно.
Технический совет
Это элемент организации процесса создания моделей, предлагающий арбитражные решения по моделированию и рекомендации по установлению статуса диаграмм, части и/или модели в целом (статусы: «Рабочий проект», «Эскиз», «Рекомендовано» и «Публикация»). Технический совет выполняет роль комитета технического контроля и поэтому его главной обязанностью является контроль качества моделей, создаваемых авторами IDEF-проекта и, что создаваемая в процессе анализа, модель будет точна и используема в дальнейшем.
Членам Комитета технического контроля для обсуждения и утверждения направляются модели, которые, с точки зрения технических требований, достигли желаемого уровня детализации и точности.
Основные функции комитета:
на каждом этапе оценки применимости модели определять текущее направление развития проекта;
вырабатывает предложения по корректировке модели и ее развития;
направлять аналитику свои замечания и предложения по необходимой доработки в виде рецензий;
после признания модели применимой для решения поставленной цели, давать разрешение на ее публикацию.
Втехническом совете должно быть несколько специалистов с высоким уровнем компетентности способных отстоять свои решения перед высшим руководством объекта моделирования. Технический совет формируется руководителем проекта (председателем совета) из экспертов и профессионалов, знакомых с предметной областью моделирования. Поскольку основной причиной, побуждающей создавать модель, является необходимость
145
повышения эффективности объекта моделирования, важно, чтобы в совете были представлены все службы, имеющие отношение к рассматриваемой в проекте предметной области. Полезно включать в совет экспертов из смежных областей объекта моделирования, не входящих в исследуемую область, но связанных с ней. Эти эксперты могут быть членами совета и помогают адекватно оценить влияние окружающей среды на объект моделирования. Эксперту обычно показывают только ограниченные фрагменты модели на промежуточных стадиях, в то время как совет должен принять решение по всей модели. Иногда в совет могут входить лица, играющие роль источников. В силу очевидной противоречивости интересов нецелесообразно, чтобы в совет входили разработчики модели.
Технический совет проводит политику проекта через рекомендации и замечания авторам, предложения по установлению статуса руководителю проекта и подготовку компромиссных решений для разрешения конфликтов, которые могут возникнуть в процессе проекта.
Эксперт
Это участник проектной группы выбираемый руководителем проекта, обладающий специальными знаниями некоторых аспектов моделируемой области. Его опыт в предметной области, к которой относится моделируемый объект, позволяет делать полезные критические замечания в процессе создания модели. Эксперты, как участники проектной группы, подразделяются на две группы:
эксперт-рецензент – это специалист знающий предметную область моделирования, спе-циализирующийся на некоторой конкретной функции предприятия и ответственный за обеспечение критических комментариев относительно разрабатываемой модели. Эксперт - рецензент должен знать IDEF0 - методологию и уметь делать письменные структурированные замечания в рассылаемых папках. Он является постоянным и активным участником цикла автор/читатель;
эксперт-читатель - член коллектива разработчиков, профессионально знающий пред-метную область моделирования, понимающий IDEF0 - методологию и умеющий читать IDEF0 - диаграммы. Эксперт - читатель знакомится с документацией (IDEF0 - папкой), не делая письменных комментариев. От экспертов-
читателей авторы получают замечания с помощью опроса.
Эксперт с помощью папок предоставляющих информацию в наглядном виде, обеспечивающих его набором информации, описывающей законченный фрагмент моделируемого объекта (цикл автор/читатель), должен в ходе нескольких циклов изучения критически оценивать создаваемую по частям модель. В процессе рецензирования эксперт может заполнить пробелы или даже завершить изложение материала, представленного в папке. Хотя папка во многом основывается на интерпретации разработчиком ранее полученной информации, комментарии экспертов служат ценным материалом для уточнения модели. В информационных папках перед экспертом должны ставиться конкретные, четко сформулированные вопросы, связанные с моделированием.
Аналитик и эксперты многократно совещаются (устно и письменно) относительно достоверности создаваемой модели. Читатель рецензирует папку и записывает свои комментарии. Замечания вносятся в диаграмму по определенным правилам. Если читатель решил внести замечание, он должен указать номер замечания, затем внести текст замечания и в каркасе диаграммы в разделе Notes зачеркнуть цифру, соответствующую номеру замечания. В случае устного собеседования особенно важно вносить замечания эксперта и комментарии автора в диаграмму для документирования всех идей, возникших в результате моделирования.
Главной задачей эксперта является оценка соответствия модели соответствующей предметной области. Экспертная оценка является основным средством в достижении консенсуса среди изучающих модель экспертов. Требуемые улучшения вносятся до тех пор, пока они позволят максимально точно представить реальную систему. Сделанные письменные замечания документируются и помещаются в папку в виде нумерованных комментариев.
Если эксперты согласны с тем, что модель или ее часть адекватно представляет рассматриваемый объект, то модель считается одобренной. ОДОБРЕННАЯ МОДЕЛЬ - это
146
модель, согласованная с экспертами. Если есть эксперты не согласившиеся с какими либо аспектами модели, то их мнение должно обязательно фиксироваться, и модель считается неправильной, пока не доказано обратное. Для достижения консенсуса авторы учитывают комментарии и за-мечания экспертов при пересмотре той части модели, к которой эти замечания относятся.
Библиотекарь
Это член проектной группы, ответственный за хранение документации, изготовление копий, координацию обмена письменной и/или электронной информацией (рассылка папок, получение рецензий, регистрация и публикация диаграмм и модели).
В процессе разработки системы особая роль определена для библиотекаря - роль координатора взаимосвязи между разработчиком и читателями. Основной обязанностью библиотекаря является контроль над всеми связями между разработчиками модели.
Библиотекарь отвечает за распространение рабочих материалов:
прохождение папок и архивирование диаграмм модели, причем одна архивная копия всегда направляется автору;
дальнейшее распространения папок - пересылка папки экспертам по предметной области (читателю);
контроль за своевременным и согласованным движением папок - рассылает напоминания о своевременном возвращении авторам папок с замечаниями и о сроках ответов авторов на предложения читателей;
печать законченных моделей после того, как они одобрены и приняты к использованию.
Библиотекарь должен обеспечивать проведение рецензирования в срок. Затем папки регистрируются и направляются автору. Аналитик отвечает на каждое замечание и обобщает критику, содержащуюся в замечаниях. Если он согласен с замечаниями, то вносит изменения в модель и опять ее направляет библиотекарю для архивирования и передачи эксперту. Дополнительная экспертиза, если это необходимо, проводится у того же или у другого эксперта.
Источники информации
Исходная информация для IDEFO-модели поступает к разработчику из разных источников: от людей и от документов. Люди, являющиеся источниками информации, обладают конкретными знаниями о частных свойствах объекта моделирования, управлении или ходе бизнес-процесса и их участие в моделировании может быть ограничено несколькими минутами опроса. Однако именно эти источники обеспечивают основу для моделирования. Информация, предоставляемая ими, используется для создания модели, а восприятие этой информации обеспечивает разработчику понимание, необходимое для построения точной модели.
Руководитель проекта подбирает адекватные источники информации, исходя из направления проекта и потребностей разработчика. По мере развития процесса моделирования потребности в информации изменяются, и список источников информации руководитель проекта пересматривает. Собираемая разработчиком информация должна как можно точнее фиксироваться.
Каждый источник воспринимает предметную область по-своему, и на разработчике лежит ответственность за правильный отбор информации. Особенно это относится к источникамдокументам. ИСТОЧНИК - документ отражает состояние объекта моделирования в некоторый момент времени. Поэтому документы являются важным источником информации для модели, но для их эффективного использования необходима значительная работа, связанная с интерпретацией, пониманием и подтверждением.
Лица, выступающие в роли источников информации, могут оказывать разработчику модели дополнительную помощь, объясняя, как сообщенная ими информация поступает, интерпретируется или используется. Разработчик должен воспользоваться этой помощью
147
для понимания того, как восприятие информации одного источника связано с восприятием другого.
CASE-инструмент BPWIN 4.0
Это практическое руководство по созданию информационных систем с помощью CASEинструмента анализа проектирования BPWIN 4.0. Данное пособие может быть полезным для студентов и аспирантов, изучающих основы системного анализа и проектирования ИС, т.к. в нем описывается конкретная технология разработки ИС.
Введение в CASE-инструмент BPWIN
4.0
В настоящее время эффективная автоматизации любого вида деятельности предприятия может производиться только на основе применения информационных систем (ИС). Под автоматизацией можно понимать разработку ИС, или ее выбор на рынке с последующей адаптацией под специфику предприятия, а также процесс внедрения, обслуживания и ведения с целью модернизации. Разработка ИС включает в себя несколько этапов, одним из первых и важнейших из которых является проведение изучение и анализ автоматизируемого процесса, а также его моделирование для определения путей возможного улучшения и оптимизации работы, которые будут реализованы в создаваемой ИС. При проведении такого анализ, в соответствии с требова-ниями системного подхода необходимо произвести точное описание процессов, деятельность которых требуется автоматизировать. Не сделав корректного описания автоматизируемых процессов, бессмысленно переходить к следующим стадиям анализа деятельности предпри-ятия и тем более к его автоматизации.
CASE-средство верхнего уровня BPwin
CASE-средство верхнего уровня BPwin – это инструмент визуального моделирования ИС, позволяющий:
наглядно описывать, анализировать и совершенствовать сложные бизнес-процессы, любую деятельность или структуру в виде модели, что позволяет значительно повысить эффек-тивность работы предприятия;
проверить модель на соответствие стандартам ISO9000. Для отечественных предприятий сертификация по ИСО 9000 – это пропуск на международный рынок, а также действенное средство для эффективного улучшения работы всего предприятия;
спроектировать структуру информационных потоков, а соответственно, и модернизировать организационную структуру предприятия;
четко выявить факторы, оказывающие влияние на бизнес: какие операции являются наибо-лее критичными, как повысить их эффективность, какие ресурсы требуются для этого;
снизить издержки и повысить производительность;
выявить и исключить лишние или неэффективные операции;
повысить гибкость и эффективность.
Все это позволит получить целостное представление о том, как работает предприятие, начиная от структурного подразделения и заканчивая предприятием в целом. Если компания занимается системной интеграцией или поставкой готовых решений в области ИТ, модель бизнес-процессов - это наилучшее средство обосновать, как повлияют инвестиции в ИТ на эффективность деятельности предприятия.
BPwin входит в семейство продуктов AllFusion компании Computer Associates под именем AllFusion Process Modeler и предназначен для поддержки всех стадий жизненного цикла
148
разработки ИС. В линейку продуктов AllFusion Modeling Suite кроме BPwin для поддержки всех стадий разработки программного обеспечения, входят CASE-средств ERwin, BPwin, ModelMart, Paradigm Plus, ERwin Examiner и средства управления проектами. Совместное применение этих продуктов обеспечивает прочный фундамент для построения, развертывания и управления приложениями. При этом не накладываются ограничения на выбор базовых технологий, методов и платформ разработки. AllFusion Modeling Suite предлагает моделирование и управление процессами, проектами, изменениями, конфигурациями.
BPwin - инструмент моделирования, который используется не только для анализа и документирования, но и реорганизации сложных процессов. BPwin соответствует требованиям к инструментам для разработки ИС, так как позволяет четко документировать различные действия, которые необходимо предпринять, а также способы их осуществления и требуемые для этого ресурсы. BPwin является интуитивно понятным визуальным инструментом, позволяющим сформировать целостную картину деятельности предприятия: от моделей организации работы в маленьких отделах до сложных иерархических структур. В руках же системных аналитиков и разработчиков BPwin - мощное средство моделирования процессов при создании корпоративных информационных систем (КИС).
BPwin достаточно легок в освоении и может применяться практически во всех сферах деятельности, ориентирован на различные категории специалистов: от системных и деловых аналитиков до руководителей, от консультантов до специалистов по маркетингу и менеджеров по качеству. В первую очередь BPwin предназначен для облегчения труда и увеличения производительности системного аналитика на первом этапе разработки системы, т.к. является средством для сбора всей необходимой информации о работе предприятия и графического изо-бражения этой информации в визуальной модели (рисунке).
BPwin является также средством системного анализа деловой и производственной активности, позволяющим отслеживать соответствие структуры бизнеса, документооборота, финансовых потоков требованиям современной экономики.
Нотации BPwin
BPwin автоматизирует задачи, связанные с построением моделей, обеспечивая семантическую строгость, необходимую для гарантирования правильности результатов, а также целостность и непротиворечивость модели, которые гарантируются применением методологий IDEF0, IDEF1X (Data Flow Diagram) и IDEF3 (Work Flow Diagram). Каждая из этих трех нотаций, поддерживаемых в BPwin, позволяет рассмотреть различные стороны деятельности предприятия и комплексно описать предметную область с трех различных, но
взаимосвязанных точек зрения:
функциональности системы. В рамках методологии IDEF0 (Integration Definition for
Func-tion Modeling) процесс представляется в виде набора работ (функций), которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой. С помощью функционального моделирования можно провести систематический анализ процессов, сосредоточившись на регулярно решаемых задачах/функциях, свидетельствующих об их правильном выполнении показателях, необходимых для этого ресурсах, результатах и исходных материалах/сырья. Пра-вильно построенная функциональная модель адекватна на всех уровнях абстрагирования;
потоков информации (документооборота) в системе. Т.к. DFD не принадлежит к семейству IDEF, то более верно будет именовать ее нотацией Диаграммы DFD (Data Flow Dia-gramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между функциями. Моделирование потоков данных часто используется при разработке программного обеспечения, сосредоточенного вокруг потоков данных, пе-редающихся между различными операциями, включая их хранение, для достижения макси-мальной доступности и минимального времени ответа. Такое моделирование позволяет
149
рассмотреть конкретный процесс, проанализировать операции, из которых он состоит, а также точки принятия решений, влияющих на его ход;
последовательности выполняемых работ. Более точную картину можно получить,
дополнив модель диаграммами IDEF3. Моделирование потоков работ позволяет рассмотреть конкретный процесс, проанализировать операции, из которых он состоит, а также точки принятия решений, влияющих на его ход. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития процесса.
В зависимости от корпоративного стандарта по проведению системного анализа процессов на начальном этапе проектирования системы, могут использоваться различные типы или комбинации этих методологий моделирования. Если в процессе моделирования нужно осветить специфические стороны технологических процессов конкретного предприятия, то BPwin позволяет переключиться на любой вид модели созданный с помощью IDEF3 или DFD или создать смешанную модель. Совместная работа в трех нотациях позволяет пользователю/аналитику более подробно описать деятельность исследуемого объекта, поскольку одного метода, как правило, бывает недостаточно.
На основе использования указанных выше методологий и нотаций визуального моделирования с помощью BPwin можно построить модель системы в виде иерархически упорядоченных диаграмм, которая может работать не только сегодня, но и в случае необходимости быстро и эффективно скорректировать систему в соответствии с новыми условиями. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. Модель, созданная средствами BPwin, позволяет четко документировать различные аспекты деятельности - действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и др. Модели BPwin дают основу для осмысления бизнес-процессов и оценки влияния тех или иных событий, а также описывают взаимодействие процессов и потоков информации в организации. Неэффективная, высокозатратная или избыточная деятельность может быть легко выявлена и, следовательно, усовершенствована, изменена или устранена в соответствии с общими целями организации.
Основные характеристики BPwin
поддерживает три стандартные нотации: IDEF0, DFD, IDEF3, что обеспечивает комплексное описание предметной области;
обладает редакторами для описания операций/функций и связей;
имеет модуль функционально-стоимостного анализа ABC (ФСА) расчета затрат на выпол-нение исследуемого процесса. BPwin полностью поддерживает методы расчета себестои-мости по всему объему хозяйственной деятельности;
обеспечивает создание структуры диаграмм, облегчающих последовательное уточнение элементов модели;
позволяет разрабатывать диаграммы:
-контекстные - для описания границ системы, области действия, назначения объектов;
-декомпозиции - для описания особенностей взаимодействия различных процессов;
-диаграммы FEO (For Exposition Only) для создания вариации модели или проблемной области, позволяющих произвести анализ вариантов, не внося изменений в основную модель;
-диаграммы Swim Lane - для координации сложных процессов и функциональных ограничений, позволяя вам видеть процессы, роли и обязанности во всем их многообразии;
-организационные. Организационные структуры оказывают огромное влияние на определение и выполнение процессов. BPwin поддерживает явное определение ролей, а это определяет и категоризирует задачи или работы, составляющие процессы. Основываясь на ролях, определенных пользователем, BPwin формирует организационные диаграммы;
150