По аналогии с информационной компонентой компонента «Приложения» ориентирована на отображение того, какие прикладные системы нужны предприятию для выполнения бизнес-процессов. Также можно перефразировать вопросы в отношении связи прикладных систем и бизнес-процессов: «С учетом нашего общего видения, целей и стратегий, кто и что будет делать?» – компонента приложений должна отвечать на вопрос: «Для эффективного выполнения процессов необходимо использование следующего перечня информационных систем».
Детальность описания прикладных систем должна обеспечиваться на уровне, достаточном для понимания состава автоматизируемых функций, хранимых (обрабатываемых) операционных данных (документов), что в конечном итоге дает объективное представление об уровне ее значимости для организации в целом.
Описание компоненты «Приложения» должно быть не только достаточным для понимания, в какой части бизнес-процессов обеспечивается поддержка, но и с точки зрения оценки затрат и выгод по использованию систем.
Базовые принципы, методы и определения моделирования бизнес- процессов
Одной из составных (зачастую «невидимых» для пользователей) частей модели бизнес-архитектуры является используемая методологическая база. Зачастую данная составляющая оказывается интересной только для разработчиков. Вместе с тем знание базовых принципов и определений, касающихся вопросов моделирования, имеет важное значение для заказчиков и пользователей системы «модель бизнес-архитектуры». Это знание определяет общее представление о возможностях и ограничениях системы, позволяет не только выступать в пассивной роли пользователей, но и формулировать постановки задач по дальнейшему развитию системы.
Крайне сложно ожидать объективной оценки и полноты использования возможностей модели бизнес- архитектуры от пользователей, не имеющих хотя бы общих представлений о системном анализе, процессном подходе, базовых принципах моделирования и т. д. По этой причине авторы посчитали важным дать общее представление о предметной области – моделировании бизнес-процессов.
Определение моделирования
Объектом моделирования может выступать любая сущность, описанные в книге подходы универсальны и могут быть применимы как к архитектуре корпоративной информационной системы или компании в целом, так и при проектировании отдельных информационных систем.
Типология моделей
В общем, модели можно классифицировать по различным критериям, например:
¦ формальные (использующие общепринятые правила, нотации и средства) и неформальные;
¦ количественные – позволяющие производить численные оценки и проверки, и качественные – предназначенные для понимания поведения и структуры системы;
¦ описательные – предназначенные только для восприятия человеком, или исполняемые – позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходном объекте.
Примерами
¦ текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст;
¦ визуальные модели, представляемые в виде диаграмм с определенной нотацией. Вообще говоря, даже эскизное изображение структуры или хода процесса, не обязательно соответствующее какому-либо стандарту, также может рассматриваться как модель – лишь бы оно могло быть использовано в нужном контексте для анализа или обсуждения проблемы.
Примерами
Общие принципы моделирования
Перед тем как дать описание основных используемых на сегодняшний день методов моделирования, укажем общие принципы и особенности, которые должны быть учтены при построении модели.
1. Принцип осуществимости. Создаваемая модель прежде всего должна обеспечивать достижение поставленных целей. Таким образом, прежде чем приступить к сбору информации об объекте, нужно четко определить границы области моделирования, цели и количественные показатели их достижения; «моделирование ради моделирования» обычно создает негативное отношение к проекту в компании, снижает лояльность руководства.
2. Принцип информационной достаточности. При полном отсутствии информации об исследуемом объекте построение его модели невозможно. При наличии полной информации моделирование не имеет смысла. Существует некий критический уровень априорных сведений об объекте, при достижении которого имеет смысл переходить от этапа сбора информации к этапу собственно построения модели.
В данном случае закладываются условия для выполнения такого значимого требования, как адекватность модели, а именно достижение разумного баланса между детальностью и потребительскими качествами модели.
3. Принцип множественности модели. Создаваемая модель должна отражать те свойства реального объекта, которые влияют на выбранные показатели эффективности. При использовании любой конкретной модели познаются только некоторые области действительности. Для более полного исследования реального объекта необходим ряд моделей, позволяющих с разных сторон и с разной детализацией отражать рассматриваемый процесс.
4. Принцип агрегирования. В большинстве случаев сложную систему можно представить в виде совокупности агрегатов (подсистем), для адекватного описания которых оказываются пригодными некоторые стандартные схемы. Имея хорошо структурированные, относительно независимые блоки нижнего уровня, появляется возможность довольно гибко перестраивать модель в зависимости от меняющихся по ходу проекта требований, предлагать на выбор лицу, принимающему решение, различные варианты построения модели, лишь перегруппируя подсистемы и изменяя взаимосвязи между ними.
5. Принцип отделения. Исследуемая область, как правило, имеет в своем составе несколько изолированных компонент, внутренняя структура которых достаточно прозрачна или не представляет непосредственного интереса для целей проекта, в таком случае ее место в модели занимает условный пустой блок, для которого определяются только значимые входные и выходные информационные потоки.
Этот прием используется при определении границ области моделирования и при расстановке