сотрудником корпорации IBM Питером Ченом. Применяется для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы и обеспечивающий универсальное представление структуры данных в рамках организации, независимое от конечной реализации базы данных и аппаратной платформы.
¦ IDEF2 (Simulation Modeling Method) – стандарт динамического моделирования развития систем. В связи с весьма серьезными сложностями задачи построения модели динамической системы и ее последующего анализа от использования этого стандарта практически отказались, и его развитие приостановилось еще на начальном этапе. IDEF2 использует модели и методы имитационного моделирования систем массового обслуживания, сети Петри, модель конечного автомата, описывающую поведение системы как последовательность смен состояний.
¦ IDEF3 (Process Flow and Object Stale Description Capture Method) – стандарт документирования процессов, происходящих в системе. Применяется при исследовании, например, технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3.
¦ IDEF4 (Object-oriented Design Method) – стандарт проектирования объектно- ориентированных систем. IDEF4 позволяет наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым давая возможность анализировать и оптимизировать сложные объектно- ориентированные системы.
¦ IDEF5 (Ontology Description Capture Method) – стандарт наглядного и эффективного описания онтологии системы: словаря терминов и определений, используемых при описании характеристик объектов и процессов, имеющих отношение к рассматриваемой системе, и классификации логических взаимосвязей между ними.
¦ IDEF6 (Designed Rational Capture Method) – назначение стандарта состоит в структурировании «знаний о способе» моделирования, их представления и использования при разработке информационных систем. Под «знаниями о способе» понимаются причины, обстоятельства, другие мотивы, которые обусловливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель выглядит таким образом?». Стандарт IDEF6 акцентирует внимание именно на процессе создания модели.
¦ IDEF8 (Human-System Interaction Design) – стандарт описания интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем) и на деталях интерфейса (какие элементы управления предлагает интерфейс для выполнения операции).
¦ IDEF9 (Business Constraint Discovery) – стандарт описания бизнес-ограничений, используется при определении и анализе ограничений, в которых действует организация.
¦ IDEF14 (Network Design) – стандарт проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.
Глава 3
Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке
Общий подход к проектированию
Очевидно, что заказчика интересуют в первую очередь потребительские качества модели – что может и что дает модель, и в гораздо меньшей степени – как это реализовано. На наш взгляд, это может быть оправдано далеко не во всех ситуациях. Заказчик должен понимать и задавать общие контуры проектных решений, поскольку именно в них кроятся возможности и проблемы использования и развития модели.
Существует ряд ключевых методологических моментов при проектировании модели бизнес-архитектуры, которые могут быть интуитивно понятны (либо объяснены) заказчику, имеющему самые общие представления о моделировании, и контроль которых на начальных стадиях проекта позволит избежать в дальнейшем ошибок и разочарований в получаемых результатах.
Несомненно, подходы к проектированию бизнес-архитектуры определяются целевыми задачами, которые ставятся соответствующим заказчиком, и имеют свою специфику. Таких целей может существовать много не только в рамках охватываемого поля заказчиков (как организации), но и внутри самого заказчика. Вместе с тем можно выделить ряд общих моментов, которые так или иначе должны быть реализованы.
Одним из таких обязательных условий для успешности проекта является поддержка возможности наблюдения и анализа объекта изучения с различных точек зрения. Помимо того что «потребительские» качества модели очень сильно зависят от того, насколько полно отражены интересующие свойства бизнес- процесса для конкретной группы пользователей, в общеметодологическом плане выстраивание целостной картины невозможно в рамках одностороннего рассмотрения.
Вторым значимым моментом является синтез (интеграция) моделей локальных компонент в единую модель бизнес-архитектуры с возможностью различных вариантов ее представления, исходя из постановок задач. Многогранность «синтетических» моделей определяет качество и универсальность использования разработанной архитектуры бизнес-процессов.
Основное внимание при разработке бизнес-архитектуры должно уделяться картине в целом, поэтому рекомендуется начать с построения высокоуровневых моделей бизнес-процессов предприятия. Выскоуровневые модели, включенные в бизнес-архитектуру, должны давать необходимый минимум сведений о ключевых функциях, процессах, бизнес-событиях и потоках информации, достаточный для процесса принятия решений, поиска новых возможностей для инноваций. Из 10–20 основных процессов в первую очередь необходимо сосредоточиться на тех процессах, которые будут подвергнуты изменениям.
Основные шаги, которые требуется выполнить для построения высокоуровневых моделей, следующие.
1. Идентификация критически важных для предприятия процессов (обычно не более восьми). Чаще всего это те ключевые процессы, которые:
¦ максимально влияют на способности организации реализовывать свою миссию, достигать цели, выполнять основные функции;
¦ открывают новые возможности;
¦ в настоящее время выполняются плохо и являются источниками неудовлетворенности клиентов, имеют возможности для оптимизации затрат.
2. Прослеживание связи между этими процессами и бизнес-стратегией, движущими силами и критически важными факторами успеха.
3. Построение модели высокого уровня для ключевых бизнес-процессов.
4. Определение для каждого шага процесса ответственных за выполнение шага. Это могут быть как внешние организации, так и подразделения компании.
5. Идентифицирование и документирование основных категорий информационных объектов.
Построение таких моделей и понимание их связей с ключевыми факторами позволяет понять в целом деятельность организации. Последующее углубление в тщательно отобранные ключевые процессы и информационные потоки возможно с использованием основных инструментов, таких как:
¦ декомпозиция функций/процессов;
¦ анализ бизнес-событий.
Декомпозиция бизнес-процессов позволяет преодолеть сложность описываемой предметной области, представить объекты модели верхнего уровня в виде другой модели, раскрывающей то или иное внутреннее содержание данного объекта. Основные вопросы, на которые необходимо ответить при осуществлении
