Что входит в определение контекста модели бизнес процесса - Контакты компаний и предприятий на Adresa.top

Бизнес-архитектура

Контекст и основные элементы бизнес-архитектуры

Большинство организаций имеют достаточно широкие определения того, что является бизнес-архитектурой и бизнес-моделями. Бизнес-архитектура является областью, которая определяется высшими руководителями, отвечающими за основные функции (бизнес) организации [4.3]. Как правило, она включает в себя утверждения по поводу миссии и целей организации, критические факторы успеха, бизнес-стратегии, описания функций, а также структуры и процессы, необходимые для реализации функций.

По оценке Gartner, вплоть до конца 2005 года около 70% всех предприятий будут вести определенные проекты, связанные с анализом и совершенствованием бизнес-процессов, несмотря на некоторый негативный осадок, который в корпоративном мире имела практика реинжиниринга бизнес-процессов середины 1990-х годов. «На самом деле, большинство предприятий в действительности не понимают всей глубины и масштабов выполняемых ими бизнес-процессов, если они не занимались бизнес-моделированием в последнее время», – считает Джим Синур (Jim Sinur), аналитик Gartner.

Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры приложений, которые обеспечивают эти процессы. Хотелось бы в связи с этим привести следующую цитату из книги Unleashing the Killer App «Вы тогда достигаете цели, когда становится невозможно определить, где заканчиваются бизнес-аспекты, и где начинаются технологии».

Таким образом, можно сказать, что Бизнес-архитектура включает в себя, как правило, следующие аспекты:

Бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации.
Архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства – это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т.п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры – например, объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т.д. Эта часть является как бы «точкой соприкосновения» между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений.
Показатели эффективности. Этот аспект состоит в определении ключевых показателей эффективности (КПЭ) работы организации, их текущих уровней и желаемых, будущих уровней и включает в себя также разработку на верхнем уровне модели КПЭ для мониторинга.

«Если архитектура ИТ предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно также бизнес-архитектура описывает, как элементы бизнеса соединены вместе» .

Построение бизнес-архитектуры начинается с общего обзора ситуации, который предполагает поиск ответов на следующие вопросы:

Каков внешний контекст деятельности организации?
В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?
Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации?
Какие необходимы информационные взаимосвязи и процессы обработки информации?

Рис.
5.7.
Контекст Бизнес-архитектуры

Усилия по построению бизнес-архитектуры, которая представляется в виде бизнес-моделей, быстро окупают себя и имеют большое количество дополнительных преимуществ [4.11]. Под бизнес-моделями понимается динамический поток событий, связанных с бизнесом, в который вовлечены различные функции бизнеса, организационные единицы и активы предприятия. Возможная отдача от реализации таких моделей достаточно подробно изучалась и описывалась на протяжении последнего столетия. Основная проблема состоит в том, чтобы убедить руководство в этих преимуществах и добиться от него поддержки проведения проекта разработки бизнес-моделей. А преимущества от построения таких моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса может дать до 10% экономии. А при моделировании альтернативных вариантов бизнес-процессов организации
могут сэкономить до 20% [4.11]. Но не менее важная роль бизнес-моделей состоит в том общем языке, которые они дают представителям бизнеса и ИТ в обсуждении соответствующих возможностей.

Важную роль в процессе формирования целевой архитектуры предприятия играют модели бизнес-процессов. На самом деле, обеспечение соответствия между ключевыми бизнес-процессами и архитектурой информационных технологий является самой важной составляющей всех усилий по созданию архитектуры. Эти модели также могут быть реализованы различными способами, т.е. являются описательными или исполняемыми, качественными или количественными и т.п. Они могут применяться как на исключительно «бизнес-уровне» для оптимизации соответствующих процессов, так и для облегчения взаимопонимания между бизнес-пользователями и специалистами в области ИТ. Обычно в организации имеется 10-20 основных процессов. Предложенные ниже методики помогают реализовать самый трудный начальный этап описания и документирования этих процессов. Подчеркнем, что бессмысленно разрабатывать детальные модели подпроцессов для всех основных процессов. Важно сосредоточиться на тех из них, которые будут подвергнуты изменениям. Это соответствует
принципам «минималистской архитектуры», описанным в
«Процесс разработки архитектур: оценка зрелости, детализация и распределение усилий. Инструментальные средства и мониторинг технологий»
.

Gartner рекомендует начать с построения высокоуровневых моделей бизнес-процессов предприятия. Начальным этапом для этого является определение классов бизнес-процессов. Под классом бизнес-процессов понимается группа процессов, которые состоят из большого числа одинаковых бизнес-активностей. Например, Австралийское бюро статистики выделило для себя такие классы бизнес-процессов как сбор информации о хозяйствующих субъектах, сбор информации о домохозяйствах, сбор вторичных статистических материалов, распространение информации, анализ данных, административные процессы.

Далее рекомендуется выполнить следующие шаги.

Шаг 1. Идентификация критически важных для предприятия процессов (обычно не более восьми).

Хорошими кандидатами для включения в рамки архитектуры предприятия являются те ключевые процессы, которые максимально влияют на способности организации реализовывать свою миссию, достигать цели, выполнять основные функции, а также следующие процессы [4.13]:

процессы, которые открывают новые возможности, например, новые каналы предоставления услуг;
процессы, которые в настоящее время выполняются плохо и являются источниками неудовлетворенности клиентов;
процессы, в которых имеются возможности для экономии.

Желательно, чтобы рекомендуемое число таких процессов, не превышало «волшебного числа» 8 в соответствии с известным принципом: «семь плюс-минус два» объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.

Шаг 2. Отследить связи между этими процессами и бизнес-стратегиями, движущими силами и критически важными факторами успеха. Это можно сделать с помощью матрицы взаимных связей. Для каждого элемента этой матрицы определяется качественная оценка по принципу «важно» – «неважно» или по некоторой условной шкале. Например, можно использовать так называемую шкалу 9-3-1, в соответствии с которой 9 обозначает сильную взаимосвязь, 3 – промежуточную, 1 – слабую.

Шаг 3. Построить модели высокого уровня для ключевых бизнес-процессов (см. следующий раздел). Это включает последовательность основных шагов (желательно, не более восьми на процесс).

Шаг 4. Для каждого шага процессов, идентифицированных на этапе 3, определить ответственных за выполнение шага. Это может быть функциональное подразделение внутри организации, партнер, клиент, внешний регулирующий орган.

Шаг 5. Идентифицировать и документировать основные категории информационных объектов (опять же рекомендуется не более восьми).

Такое небольшое количество высокоуровневых моделей и понимание их связей с ключевыми факторами и факторами успеха позволяет понять в целом деятельность организации и использование ИТ-ресурсов. Более детальные модели, создание которых мы опишем в следующем разделе, полезно привязывать к этим высокоуровневым моделям.

Источник

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «КУЗБАССКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра вычислительной техники и информационных технологий

МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ В СТАНДАРТЕ

IDEF0

Методические указания к лабораторной работе по дисциплине «Проектирование информационных систем» для студентов специальности 351400 «Прикладная информатика в экономике»

Составители О.А. Бияков Н.Ю.Коломарова

Утверждены на заседании кафедры Протокол № 8 от 30.04.03

Рекомендованы к печати учебнометодической комиссией специальности 351400 Протокол № 4 от 30.04.03

Электронная копия находится в библиотеке главного корпуса ГУ КузГТУ

Кемерово 2003

ВВЕДЕНИЕ

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования – вопросы, на которые построенная модель должна дать ответ. IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.

Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы и ее взаимодействия с внешней средой, называется контекстной диаграммой. После описания в целом проводится разбиение системы на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы: эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются и, только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Таким образом достигается соответствие модели реальным бизнеспроцессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Работы (Activity), которые означают некие поименованные процессы, функции или задачи, изображаются в виде прямоугольников. Именем

работы должен быть глагол или отглагольное существительное (например, «Изготовление детали», «Прием заказа» и т.д.). Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, «Заготовка», «Изделие», «Заказ»).

1. Принципы построения модели бизнес-процесса

При построении модели бизнес-процесса в стандарте IDEF0 необходимо руководствоваться следующими принципами.

Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций.

Принцип ограничения сложности. При работе с IDEF0диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0-модели, хорошо структурированы, понятны и легко поддаются анализу.

Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок – главная бизнес-функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная бизнес-функция не может быть сформулирована как, например, “продавать продукцию”. Главная бизнес-функция системы – это “миссия” системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии. При определении главной бизнес-функции необходимо всегда иметь в виду цель моделирования и точку зрения на модель. Одно и то же предприятие может быть описано по-разному в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговый инспектор видят организацию совершенно по-разному. Контекстная диаграмма играет еще одну роль в функциональной модели. Она “фик-

сирует” границы моделируемой бизнес-системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию.

2. Декомпозиция модели в стандарте IDEF0

Функциональный блок декомпозируется, если необходимо детально описать его работу. Построение IDEF0-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг

– они также представляют полный набор внешних интерфейсов системы в целом.

Блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию.

Модель IDEF0, таким образом, представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.

Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец ос-

тается неприсоединенным. Неприсоединенные дуги соответствуют ВХОДАМ, УПРАВЛЕНИЯМ и ВЫХОДАМ родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.

Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть затем детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. В номерах допускается использовать префиксы произвольной длины, но обычно используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер А0.

Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок А0 декомпозируется в блоки А1, А2, А3 и т.д. Блок А2, например, декомпозируется в А21, А22, А23 и т.д. А21 – в А211, А212,

А213 и т.д.

3.Последовательность построения модели бизнес-процесса

3.1.Описание общих свойств модели

Для создания новой модели необходимо либо выбрать в меню

пункт File/New, либо щелкнуть по иконке . После этого на экране появится окно (рис. 1), где необходимо указать имя создаваемой модели и ее тип (IDEF0). Название модели должно быть кратким и емким, отражать сущность моделируемого бизнес-процесса. Например, «Сбор налогов», «Управление персоналом».

В следующем окне (рис. 2) необходимо указать фамилии и инициалы авторов модели.

Далее необходимо выбрать пункт меню Model/ Model Properties и перейти на закладку General (рис. 3). В пункте Project укажите название проекта. Например, если было дано имя модели «Деятельность компании», то название проекта может быть таким: «Модель деятельности

Рис. 1. Окно идентификации модели бизнес-процесса

Рис. 2. Окно описания свойств модели (авторы)

компании». Кроме имени авторов модели должен быть указан тип модели. Если идет построение на основе ранее созданной вербальной модели, то указывается тип AS-IS (как есть). Если модель этого типа была построена ранее и на ее основе строится улучшенная модель, то укажите тип TO-BE (как должно быть).

Далее необходимо перейти на вкладку Purpose (рис. 4) и указать цель моделирования и точку зрения. Выбранное определение цели моделирования должно отвечать на вопросы: почему моделируется данный процесс; что выявит данная модель; какие результаты может принести применение данной модели. Например, формулировка цели может быть следующей: идентифицировать роли и ответственность работников компании для написания должностных инструкций. Другая формулировка – определить текущие проблемы, сделать анализ потенциальных улучшений. Еще одна формулировка – выявить задачи каждого работника компании и понять в целом взаимосвязь между отдельными задачами для оптимизации штатного расписания компании.

Рис. 3. Окно описания свойств модели (General)

Основой для выбора точки зрения должна служить поставленная цель моделирования. Наименованием точки зрения может быть должность, название подразделения, например, руководитель отдела или менеджер по продажам. Четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры.

На следующей вкладке Definition (рис. 5) необходимо дать описание сущности моделируемого бизнес-процесса на основе ранее полученной вербальной модели. Из описания должно быть понятно: почему происходит процесс, где, когда, с какой периодичностью и т.д. В пункте Scope необходимо указать, в каком контексте рассматривается биз- нес-процесс. Например, бизнес-процесс «Оптимизация штатного расписания организации» может рассматриваться в следующих контекстах: сокращение лишних должностей; появление новых должностей в

связи с расширением деятельности организации; перераспределение фонда заработной платы и т.д.

Рис. 4. Окно описания свойств модели (цель моделирования и точка зрения)

Последнее свойство модели, которое обязательно необходимо описать, находится на вкладке Source (рис. 6). В этом пункте должны быть кратко отражены сведения об организации, чей бизнес-процесс моделируется, источники информации (эксперты).

Кроме этого, можно на вкладке Status указать вид модели: working

– рабочая, draft – черновик, recommended – готовая для ознакомления экспертов, publication – полностью законченная модель. На вкладке Display указываются компоненты, которые должны быть отражены на диаграммах. На вкладке Numbering определяется принцип нумерации блоков при их декомпозиции (изменять не рекомендуется). На вкладке

Page Setup указывается формат листа бумаги, на котором можно получить модель при печати (масштаб изображения модели).

Рис. 5. Окно описания свойств модели (описание и контекст)

Рис. 6. Окно описания свойств модели (источники)

3.2. Описание свойств функционального блока (работы)

После определения основных свойств модели на экране появляется контекстная диаграмма с единственной работой, изображающей систему в целом. Двойной щелчок на контекстной диаграмме блока позволит дать его описание (рис. 7). На вкладке Name необходимо дать название блока (работы). Название должно быть в форме отглагольного существительного. Например, «Прием заказа», «Изготовить деталь».

Далее, перейдите на закладку Definition и опишите суть работы в данном функциональном блоке (рис. 8). Следует заметить, что по умол-

Рис. 7. Окно описания функционального блока (название функционального блока)

Рис. 8. Окно описания функционального блока (описание сути функционального блока)

чанию все надписи в модели имеют кегль 10, что затрудняет чтение модели, особенно в распечатанном варианте, поэтому рекомендуется в каждом из пунктов описания использовать закладку Font для изменения кегля на 14.

Источник

Справка по системе
Платформа ELMA BPM

Поиск

Контекст процесса

Контекстом процесса называется структурированная и распределенная по типам совокупность всех данных, имеющихся на входе в процесс, а также добавляющихся или изменяющихся при выполнении этапов процесса. Контекст бизнес-процесса — это информация о его участниках, контрагентах, данные и формы документов, комментарии исполнителей и прочая информация, которая создается, изменяется, обрабатывается, передается, выводится и сохраняется в рамках работы этого процесса.

Единицы информации, характеризующие ход процесса называются переменными, так как в общем случае их содержание (значение) может изменяться в ходе процесса. Для любой переменной можно задать настройки доступа пользователей системы на чтение и редактирование содержащихся в этой переменной данных.

В системе ELMA контекст процесса состоит из переменных. Контекстная переменная — это минимальная единица информации определенного типа. Переменная может быть простой — состоящей из одной компоненты, или составной — в виде набора полей или блока данных.

Список всех контекстных переменных процесса находится на вкладке Контекст карточки процесса (рис. 1). На вкладке Форма (контекст) операции Задача можно указать те контекстные переменные, которые должны быть показаны на форме задачи в веб-приложении, а также параметры их отображения. В дизайнере ELMA для каждой задачи можно настроить свой набор видимых переменных. Значения переменных могут быть изменены пользователями на формах задач в веб-приложении и с помощью сценариев. Кроме того, в системе ELMA реализованы специализированные операции для управления значениями контекстных переменных, связанных с документооборотом, статусами экземпляров процесса, метриками и показателями процесса и его экземпляров, управлением проектами и взаимоотношениями с клиентами.

По умолчанию у процесса существует две переменных: «Экземпляр процесса» и «Уникальный идентификатор». Эти переменные нельзя изменить, скопировать или удалить. В списке контекстных переменных они выделяются зеленым цветом.

Рис. 1. Контекстные переменные процесса

Таблица вкладки Контекст содержит следующую информацию:

Отображаемое имя — название переменной, отображаемое в форме задачи в веб-части, в документации по процессу, а также в настройках операций, в которых используется эта переменная;
Поиск — флажок, установка которого позволяет использовать эту переменную в качестве параметра фильтра и в форме расширенного поиска в веб-приложении. Следует отметить, что для переменных, создаваемых по умолчанию (например, «Экземпляр процесса» и «Уникальный идентификатор»), эта возможность отсутствует. При наведении курсора мыши на данные поля будет отображено всплывающее уведомление «Недоступно изменение значения».
Выходное — флажок, установка которого позволяет передавать значение этой переменной в родительский процесс при запуске настраиваемого процесса в качестве внешнего подпроцесса.

Верхняя панель инструментов

Верхняя панель инструментов процесса состоит из общих блоков, находящиеся на любой из вкладок процесса, и блоков, присущих определенной вкладке.

Блоки и элементы панели инструментов, присущие вкладке Контекст:

	Добавить — добавить контекстную переменную. Добавить блок — добавить свойство типа Блок.
	Редактировать выделенную мышью контекстную переменную.
	Удалить выделенную мышью контекстную переменную. Cистема ELMA не позволяет удалять из системы объекты, поэтому при выполнении этой операции переменная станет недоступна для использования в контексте процесса, но останется возможность её восстановить. При попытке в дальнейшем создать переменную с таким же именем, система предложит восстановить удаленную ранее переменную.
	Переместить выделенную мышью контекстную переменную в списке выше или ниже. Положение элемента в списке контекстных переменных на вкладке Контекст влияет только на удобство просмотра или поиска переменных в списке.

Контекстное меню

Контекстное меню вызывается кликом альтернативной, как правило правой, кнопки мыши в списке переменных вкладки «Контекст». Если клик производится в свободной области таблицы при выделенной в списке контекстной переменной, открывается контекстное меню для выделенной переменной.

Добавить свойство — добавить контекстную переменную.

Добавить блок — добавить переменную-блок.

Редактировать — редактировать выделенную мышью контекстную переменную. При этом открывается карточка контекстной переменной.

Удалить — удалить выделенную мышью контекстную переменную. Cистема ELMA не позволяет удалять из системы объекты, поэтому при выполнении этой операции переменная станет недоступна для использования в контексте процесса, но останется возможность её восстановить. При попытке в дальнейшем создать переменную с таким же именем, система предложит восстановить удаленную ранее переменную.

Выше, Ниже — переместить выделенную мышью контекстную переменную в списке выше или ниже. Положение элемента в списке контекстных переменных на вкладке Контекст влияет только на удобство просмотра или поиска переменных в списке.

Копировать — копировать выделенную мышью контекстную переменную в буфер обмена.

Вставить — вставить скопированную ранее контекстную переменную, создав таким образом её дубликат.

Поиск по контексту процесса

См. также:

Источник

: December 15 2009, 09:11

Контекст, точка зрения, цели и результаты бизнес-процесса…

В бизнесе, пожалуй, нет ничего, что стоило бы делать без определенной цели. Это практически аксиома. Если что-то кем-то делается бесцельно, то либо это плохой бизнес, либо Вы просто не понимаете конечную цель действия. Возможно, что ее при этом специально скрывают от Вас…

То же самое касается моделирования бизнес-процессов. Хотя это и звучит, как занудство, однако вначале следует определить такие вещи, как контекст бизнес-процесса (или точка зрения на бизнес-процесс), а также цели и результаты бизнес-процесса.

Понятие контекста происходит из практики моделирования по стандарту IDEF0, где первая диаграмма — это всегда контекстная диаграмма. Она задает контекст рассмотрения процесса, или другими словами, точку зрения на бизнес-процесс. Контекстная диаграмма всегда состоит из одной функции, как это показано на следующей иллюстрации:

Определение контекстной диаграммы определяет в общем и целом цели моделирования. В некоторых статьях утверждается, что неправильно сформулированная цель служит причиной около 50% неудач при моделировании бизнес-процессов. Возможно, что и так…

Вместе с тем, грамотно сформулировать цель — это тоже искусство. Тут едва ли можно ограничиться одной фразой типа: Цель данного бизнес-процесса — это…. В книге Самуйлова, например, советуается различать цели и результаты бизнес-процесса:

Следует различать понятия бизнес-цели и результата процесса. Каждый бизнес-процесс должен иметь как минимум один результат и быть направлен на достижение хотя бы одной, а лучше — нескольких бизнес-целей. Например, результат процесса «Исполнение заказа на подключение абонента» можно определить как «Получение подтверждения подключения от клиента», тогда как бизнес-цели, которые преследуются при выполнении данного процесса, могут включать «Обеспечение минимального времени исполнения заказа» и «Обеспечение минимального процента рекламаций». Для определения целей следует обратиться к бизнес-стратегии компании».

Пишу об этом, потому как это первые грабли, на которые я умудрился наступить при попытке смоделировать бизнес-процесс бюджетирования. Даже и не заметил, как я вышел за рамки бюджетирования и пошел описывать совсем другой процесс. А все потому, что сразу не определил цель и контекст =)

Источник