Архитектура бизнес-процессов – совокупность определенных в компании взаимосвязанных бизнес-процессов различного уровня, представленных в виде моделей в нотациях IDEF0 и BPMN (eEPC), созданных с использованием программного продукта Business Studio (ARIS, iGrafx, Elma и т.п.).
Приведу еще определение архитектуры системы из Википедии:
Архитектура системы – принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.
Если во втором определении заменить слово «элемент» на «бизнес-процесс», то получится хорошее определение архитектуры бизнес-процессов компании. Далее в книге вы сможете ознакомиться как раз с принципами методологии построения такой системы с использованием нотации IDEF0 и программного продукта Business Studio.
Можно дать и другие определения архитектуры. Вам важно выбрать какое-то одно и постоянно использовать его при выполнении проекта.
Построение архитектуры возможно только с учетом функциональных особенностей и ограничений соответствующего программного продукта. Возможности построения архитектуры в Power Point, на бумаге или в виде липких желтых листочков на стене офиса не рассматриваются в качестве серьезного варианта, хотя могут использоваться на первых порах в рамках групповой работы.
Архитектура состоит из процессов. Приведу рабочее определение:
Бизнес-процесс – устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя.
На рис. 2 бизнес-процесс схематично представлен, как объект управления. Предложенная схема является универсальной и может применяться для процесса любого уровня сложности там, где это целесообразно.
Чтобы определить бизнес-процесс, необходимо установить его границы. Для этого нужно определить входы и выходы, а также условия начала и завершения процесса (события).
Для процессов большого масштаба (например, «Продажа» в крупной компании), определять стартовые и завершающие события можно весьма укрупненно, для содержательного анализа. Для процессов на нижнем уровне (т.н. операционных процессов), определение четких стартовых и завершающих событий является обязательным, в том числе для решения задачи автоматизации.