Практика и проблематика моделирования бизнес-процессов
Шрифт:
Нижний уровень Строительные блоки (Bricks) соответствует технологической архитектуре и включает в себя операционные системы, серверы, базы данных, сами данные и прочее.
IDEF-технологии
Первые методы семейства стандартов IDEF (Integrated DEFinition) были разработаны в США в середине 70-х годов по программе Integrated Computer-Aided Manufacturing. В настоящее время данный комплекс стандартов включает в себя методы функционального, информационного, поведенческого моделирования и проектирования, приведенные ниже.
IDEFO (Function Modeling Method) – стандарт функционального
IDEF1 (Information and Data Modeling Method) – стандарт описания информационных потоков внутри системы, позволяющий отображать и анализировать их структуру и взаимосвязи.
IDEF1X (IDEF1 Extended) – стандарт проектирования реляционных структур, основанный на концепции «сущность – связь» (ER – Entity-Relationship), предложенной в 1976 году сотрудником корпорации 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 основных процессов в первую очередь необходимо сосредоточиться на тех процессах, которые будут подвергнуты изменениям.
- Telegram
- Viber
- Skype
- ВКонтакте