Критерий согласия Пирсона, Колмогорова, Романовского

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

Существует ряд критериев согласия. Чаще применяют критерии Пирсона, Романовского и Колмогорова.

Критерий согласия Пирсона  – один из основных: где k – число групп, на которые разбито эмпирическое распределение,   – наблюдаемая частота признака в i-й группе, – теоретическая частота. Для распределения   составлены таблицы, где указано критическое значение критерия согласия  для выбранного уровня значимости   и степеней свободы df.(или  ) Уровень значимости   – вероятность ошибочного отклонения выдвинутой гипотезы, т.е. вероятность того, что будет отвергнута правильная гипотеза. В статистике пользуются тремя уровнями:

• a= 0,10, тогда Р=0,90 (в 10 случаях их 100 может быть отвергнута правильная гипотеза);

• a= 0,05, тогда Р=0,95;

• a= 0,01, тогда Р=0,99.

Число степеней свободы df определяется как число групп в ряду распределения минус число связей: df = k –z.  Под числом связей понимается число показателей эмпирического ряда, использованных при вычислении теоретических частот, т.е. показателей, связывающих эмпирические и теоретические частоты. Например, при выравнивании по кривой нормального распределения имеется три связи: ;           ;            . Поэтому при выравнивании по кривой нормального распределения число степеней свободы определяется как df = k –3.   Для оценки существенности расчетное значение   сравнивается с табличным  . При полном совпадении теоретического и эмпирического распределений  , в противном случае  >0. Если  > , то при заданном уровне значимости и числе степеней свободы гипотезу о несущественности (случайности) расхождений отклоняем.  В случае, если  , заключаем, что эмпирический ряд хорошо согласуется с гипотезой о предполагаемом распределении и с вероятностью Р=(1-a) можно утверждать, что расхождение между теоретическими и эмпирическими частотами случайно. Критерий согласия Пирсона используется, если объем совокупности достаточно велик  , при этом частота каждой группы должна быть не менее 5.

Критерий Романовского с основан на использовании критерия Пирсона,  т.е.  уже найденных значений  , и числа степеней свободы df:

Он удобен при отсутствии таблиц для  . Если с<3, то расхождения распределений случайны, если же с>3, то не случайны и теоретическое распределение не может служить моделью для изучаемого эмпирического распределения.

Критерий Колмогорова l основан на определении максимального расхождения между накопленными частотами и частостями эмпирических и теоретических распределений:    или    , где D и d – соответственно максимальная разность между накопленными частотами   и накопленными частостями   эмпирического и теоретического рядов распределений; N          – число единиц совокупности. Рассчитав значение l, по таблице Р(l) определяют вероятность, с которой можно утверждать, что отклонения эмпирических частот от теоретических случайны. Вероятность Р(l) может изменяться от 0 до 1. При Р(l)=1 происходит полное совпадение частот, Р(l)=0 – полное расхождение. Если l принимает значения до 0,3, то Р(l)=1. Основное условие использования критерия Колмогорова – достаточно большое число наблюдений.

ПРОЦЕССНЫЙ ПОДХОД

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

Главное понятие, которое использует процессный подход – это понятие процесса. Существуют различные определения, но наиболее часто используется определение стандарта ISO 9001. «Процесс - это совокупность взаимосвязанных и взаимодействующих видов деятельности, которые преобразуют входы в выходы». Важной составляющей процесса, которая не отражена в этом определении, является систематичность действий. Действия процесса должны быть повторяющимися, а не случайными.

ЦЕЛЬ ПРОЦЕССНОГО ПОДХОДА

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

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

ПРИНЦИПЫ ПРОЦЕССНОГО ПОДХОДА

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

При внедрении управления по процессам важно придерживаться следующих принципов:

Принцип взаимосвязи процессов. Организация представляет собой сеть процессов. Процессом является любая деятельность, где имеет место выполнение работ. Все процессы организации взаимосвязаны между собой;

Принцип востребованности процесса. Каждый процесс должен иметь цель, а его результаты должны быть востребованы. У результатов процесса должен быть свой потребитель внутренний или внешний.

Принцип документирования процессов. Деятельность по процессу необходимо документировать. Это позволяет стандартизовать процесс и получить базу для изменения и дальнейшего совершенствования процесса;

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

Принцип ответственности за процесс. В выполнении процесса могут быть задействованы различные специалисты и сотрудники, но отвечать за процесс и его результаты должен один человек.

КЛЮЧЕВЫЕ ЭЛЕМЕНТЫ ПРОЦЕССНОГО ПОДХОДА

Процессный подход предполагает наличие ключевых элементов, без которых он не может быть внедрен в организации.

К таким ключевым элементам относятся:

Вход процесса;

Выход процесса;

Ресурсы;

Владелец процесса;

Потребители и поставщики процесса;

Показатели процесса.

2. Случайные процессы и их классификация

Случайным процессом  называется случайная функция аргументаt, гдеtтекущее время. Случайный процесс обозначается прописными буквами греческого алфавита , , . Допустимо и другое обозначение, если оно заранее оговорено .

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

Реализации x(t), y(t), z(t)по отношению к соответствующим процессам , , играют ту же роль, что и возможные значения х, у,zпо отношению к своим случайным величинам , , . Вид конкретной реализацииx(t)может задаваться определенной функциональной зависимостью аргументаtили графиком. Другими словами, это обычная детерминированная функция аргументаt.

В зависимости от того, непрерывные или дискретные значения принимают аргумент tи реализация х, различают пять основных видов случайных процессов. Поясним эти виды с указанием примеров.

Непрерывный случайный процесс характеризуется тем, что tи х являются непрерывными величинами (рис. 1,а). Таким процессом, например, является шум на выходе радиоприемного устройства.

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

Случайная последовательность характеризуется тем, что tявляется дискретной, а х — непрерывной величинами (рис. 1,в). В качестве примера можно указать на временные выборки в конкретные моменты времени из непрерывного процесса.

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

Случайный поток представляет собой последовательность точек, дельта-функций или событий (рис. 1, д, ж) в случайные моменты времени. Этот процесс широко применяется в теории надёжности, когда поток неисправностей радиоэлектронной техники рассматривается как случайный процесс.

Рис. 1

В статистической радиотехнике все процессы также можно клас­сифицировать по виду их функциональной зависимости. Например, различают детерминированные, квазидетерминированные и случайные модулированные колебания.

у детерминированного процесса или колебания вид функциональной зависимости полностью определен. Например, гармоническое колебание с известными амплитудой, частотой и фазой.

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

К случайным модулированным колебаниям относятся модулированные колебания, у которых тот или иной параметр модулируется случайным образом, то есть у которого модулирующая функция является случайным процессом. Таким образом, модулированное колебание, являясь функцией случайного процесса, также представляет собой случайный процесс. Примерами являются AM, ЧМ и ФМ колебания, у которых амплитуда, частота или фаза изменяются в соответствии со случайной модулирующей функцией.

IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев [7 – 9]. Сценарием (Scenario) называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цехе и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологические карты, стандарты и т.д.), и документов, отображающих ход его выполнения (результаты тестов и экспертиз, отчеты о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота.

Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

1. Документировать данные о технологии процесса.

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

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

4. Содействовать принятию оптимальных решений при реорганизации технологических процессов.

5. Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..." Такая возможность существует при использовании, например, системы имитационного моделирования ARENA.

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы, относящиеся к первому типу, называются диаграммами потокового описания процесса (Process Flow Description Diagrams, PFDD), а ко второму – диаграммами сети изменения состояний объектов (Object State Transition Network, OSTN).

Рассмотрим пример [9, 10]. Предположим, требуется описать процесс окраски детали в производственном цехе на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки. На следующем примере, опишем, как графические средства IDEF3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.

Рисунок 3.9. Пример PFDD диаграммы

На рис.3.9 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB)^[1] и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия, полученного в результате декомпозиции, обычно предваряется номером его родителя (рис. 3.10).

Рис. 3.10. Изображение и нумерация действия в диаграмме IDEF3

Существенные взаимоотношения между действиями изображаются с помощью связей. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 3.4 приведены три возможных типа связей. Стандарт предусматривает и другие типы стрелок [8, 11], но они малоприменимы и не поддерживаются CASE‑системами

Таблица 3.4. Типы связей IDEF3

Связь типа "временное предшествование" показывает, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия.

загрузка...

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

Связь типа "нечеткое отношение" используется для выделения отношений между действиями, которые невозможно описать с использованием связей предшествования или объектных связей. Обычно эти связи указывают, что между объектам существуют некоторые отношения, но на момент описания процесса они не определены.

Объект, обозначенный J1, называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и перекрестки для разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в табл. 7.5.

Таблица 3.5. Типы перекрестков

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".

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

Описания процессов могут состоять из нескольких сценариев и содержать как диаграммы PFDD, так и OSTN. Для обозначения отношений и связей между UOB различных уровней PFDD и OSTN диаграмм и разных сценариев в IDEF3 используются специальные ссылки (Referents).

Ссылки могут использоваться:

− для обращения к ранее определенному функциональному модулю UOB без повторения его описания;

− для передачи управления или индикации наличия циклических действий при выполнении процесса;

– организации связи между диаграммами описания процесса PFDD и OSTN диаграммами.

Соответственно, выделяют следующие типы ссылок:

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

UOB – экземпляр другого, ранее определенного UOB, выполняется в определенной точке. Например, UOB "Контроль качества" может быть использован в процессе "Изготовления редуктора" несколько раз, после каждой единичной операции.

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

TS (Transition Schematic) – переход на схему. Это ссылка на соответствующую диаграмму, т. е. процесс, на который ссылаются, должен быть инициализирован.

NOTE (примечание) используется для документирования информации, относящейся к каким-либо графическим объектам на диаграмме. Элемент примечание может использоваться как в диаграммах описания процесса, так и объектных диаграммах OSTN. Этот элемент может быть применен к функциональному элементу UOW, перекрестку, связи, объекту или ссылке.

Отметим, что в BPwin используются немного другие ссылки[12].

Методология IDEF3 определяет два вида ссылок по способу запуска. Ссылка "Вызвать и продолжить" (Call and Continue Referent) указывает, что элемент, указанный в ссылке, должен быть активизирован до завершения выполнения действия модулем, к которому относится ссылка. Ссылка "Вызвать и ждать" (Call and Wait Referent), указывает, что элемент, указанный в ссылке, должен начать и закончить выполнение действия до завершения действия модулем, к которому относится ссылка.

Графические обозначения ссылок приведены на рис. 3.11.

Рис. 3.11. Графическое обозначение ссылок

В основном поле символа ссылки указывается её тип (Referent Type) "UOB", "SCENARIO", "TS" или "GOTO" и через дробь "Label" – уникальное наименование блока, сценария, схемы или функции узла, на который указывает ссылка. В поле "Locator" указывается уникальный идентификатор элемента, указанного в ссылке. Пример использования ссылок показан на рис. 3.12 [8].

Рис. 3.12. Примеры использования ссылок

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB "Окрасить Деталь", представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называтьсядочерней, по отношению к изображенной на рис. 3.9, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации. На рис. 3.13 приведен пример декомпозиции модулей (UOB) и принцип формирования их номеров. Для наглядности все модули представлены на одном рисунке, но в IDEF3 они отображаются в трех диаграммах.

Рис. 3.13. Декомпозиция функциональных блоков

Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Возможность множественной декомпозиции отражается в нумерации работ: номер работы состоит из номера родительской работы, номера декомпозиции и номера работы на текущей диаграмме. На рис. 7.14 представлен пример двух вариантов декомпозиции родительского модуля [8].

Рис. 3.14. Пример двух вариантов декомпозиции модуля

Если диаграммы PFDD описывают технологический процесс "с точки зрения наблюдателя", то другой класс диаграммOSTN – диаграммы сети изменения состояний объектов (не поддерживаются в BPwin) позволяет рассматривать тот же самый процесс "с точки зрения объекта". С ее помощью можно графически представить, как одни виды объектов преобразуются в другие или изменяют свое состояние в ходе выполнения рассматриваемого процесса.

На OSTN состояния объектов изображаются окружностями с именем объекта внутри, а изменения состояний − соединительными линиями. Состояние объекта описывается фактами и ограничениями, которые должны выполняться, чтобы объект находился в данном состоянии. Требования для перехода объекта в заданное состояние определяются условиями входа. Условия выхода говорят о ситуации, в которой объект выходит из заданного состояния. Эти ограничения описываются в списке свойств. Связи переходов состояний задают возможные способы изменения состояний объектов.

Для изображения последовательностей переходов объектов из одного вида в другой и изображения перехода одного и того же объекта из одного состояния в другое в диаграммах OSTN используются связи переходов (Transition Links), которые бывают слабыми (Weak Transition Link) и сильными (Strong Transition Link). Слабые связи переходов изображаются сплошными одинарными стрелками (рис. 3.15) и показывают, что объекту вида В предшествует объект вида А или что состоянию В некоторого объекта предшествует его состояние А.

Рис. 3.15. Пример слабой связи переходов

Сильные связи переходов изображаются двойными однонаправленными стрелками (рис. 3.16) и подчеркивают, что объекту вида В должен предшествовать объект вида А или что состояние В объекта достижимо только из состояния А.

Рис. 3.16. Пример сильной связи переходов

В диаграммах OSTN используются те же виды ссылок, что и в диаграммах PFDD. Исключение составляет лишь ссылка типа GOTO, которая используется только в диаграммах потоковых процессов PFDD. Ссылки могут относиться как к символу объекта, так и к связи перехода. Соответственно, они интерпретируются как действия, которые необходимо осуществлять для поддержания объекта в данном виде или состоянии, или как действия, которые необходимы для преобразования вида или состояния объекта. Так как процессы поддержания объекта в определенном состоянии и его преобразования могут быть сложными, то допускается использование нескольких ссылок к любому элементуOSTN диаграммы.

На диаграммах OSTN могут использоваться перекрестки. Перекресток изображается кружком, внутри которого содержится условное обозначение логической функции, реализуемой перекрестком В качестве логических функций могут использоваться И (&), ИЛИ (O) и ИСКЛЮЧАЮЩЕЕ ИЛИ (X). Как и на диаграммах PFDD, узлы перехода могут означать слияние и разветвление. Но на диаграммах OSTN перекрестки не делятся на асинхронные и синхронные. На рис. 3.17 показан пример использования узла разветвления с логической функцией ИЛИ.

Рис. 3.17. Пример перекрестка с логической функцией ИЛИ

Диаграмма рис. 3.17 означает, что под действиями UOB с именем P объект из состояния А может перейти в одно или сразу несколько состояний из множества возможных: B₁, В₂, …, В_n. Если бы в качестве логической функции использовалась функция ИСКЛЮЧАЮЩЕЕ ИЛИ, то это говорило бы, что возможен переход только в одно из возможных состояний B₁, В₂, …, В_n. Использование же функции И в перекрестке отображало бы переход объекта из состояния А сразу во все состояния B₁, В₂, …, В_n.

На рис.3.18 представлено отображение процесса окраски с точки зрения OSTN диаграммы.

Рис. 3.18. Пример OSTN диаграммы

BPwin имеет возможность преобразования диаграмм IDEF3 в имитационную модель популярной системы моделирования Arena [13 – 14]. Идея преобразования описана в [2, 3], подробное описание дано в фирменной документации [12].

Инструментальные средства описания процесса

С точки зрения системы, каждая операция, входящая в состав процесса, содержит задание, выполнение которого предполагает ввод и/или обработку информации. Типовыми параметрами описания операции являются следующие:

 адресат - пользователь или группа пользователей, получающих задание, при этом указываются права на пересылку задания другому пользователю и права на копирование данных, относящихся к заданию;

 экранная форма, содержащая представление данных и функций, используемых пользователем при выполнении задания;

 предельный срок выполнения задания, определяющий, до какого времени соответствующая операция должна быть выполнена;

 действия системы при инициализации и завершении операции.

Последовательность выполнения операций и условия их перехода от одной к другой составляют алгоритм выполнения процесса. Помимо уже рассмотренных операций в описании алгоритма, как правило, используются:

 логические условия;

 внешние по отношению к процессу события;

 средства создания параллельных ветвей;

 точки встречи, позволяющие согласовать результаты параллельно выполняемых операций;

 автоматические операции - операции, выполняющиеся без участия пользователя и запускающие на сервере внешнюю процедуру обработки циркулирующих в процессе данных;

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

Использование инструментальных средств описания процессов в большинстве современных систем класса Workflow не требует от разработчика каких-либо знаний в области программирования или систем управления базами данных. Например, в системе Staffware средством такого класса является графический построитель процедур для Windows, работа которого основана на технологии пиктограмм и режиме drag-and-drop.

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

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

Значения данных представляются в экранной форме в виде полей. При этом различаются:

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

обязательные поля - поля, которые необходимо заполнить в процессе выполнения задания;

необязательные поля - поля, значения которых могут быть введены пользователем, однако это не является необходимым условием выполнения задания;

вычисляемые поля - поля, значения которых вычисляются в соответствии с заданными правилами;

невидимые поля - вычисляемые, но неотображаемые на экране.

Построение форм представления данных является составной частью описания операций, составляющих процесс Workflow, и включает:

 задание и форматирование текста, образующего форму;

 определение требуемого подмножества данных;

 указание способа их представления в форме;

 описание условий и обстоятельств, определяющих содержание формы.

Кроме того, для каждого поля могут быть заданы:

 справка-пояснение того, как это поле заполнить; справочная информация будет выдаваться на экран по требованию пользователя;

 диапазон или список допустимых значений;

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

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

В большинстве современных систем класса Workflow присутствуют высокоуровневые инструментальные средства создания и редактирования экранных форм. Например, в Staffware таким средством является графический построитель форм для среды Windows.

Управление выполнением процесса

Любой конкретный случай выполнения процесса называется экземпляром или вариантом. Выполнение любого экземпляра состоит в рассылке пользователям заданий в виде экранных форм и управлении процессом их заполнения в соответствии с предусмотренным алгоритмом. При этом система класса Workflow обеспечивает:

 одновременное выполнение множества экземпляров каждого процесса;

 передачу заданий между операциями процесса посредством системы электронной почты;

 обмен произвольными сообщениями между пользователями;

 доступ к функциям системы и внешним программам, предусмотренным для пользователя разработчиком процесса;

 взаимодействие путем обмена данными с внешними программами на сервере и клиенте.

Работа пользователя с любой формой состоит из следующих действий:

 просмотр содержимого;

 заполнение и/или редактирование полей;

 печать формы;

 выпуск формы для последующей обработки.

Часто при заполнении экранных форм поддерживается технология электронной подписи.

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

Набор операций для работы с очередью заданий содержит следующие операции:

 выбор задания;

 переход к заполнению экранной формы выбранного задания;

 выпуск выбранного задания - информирование системы об его выполнении;

 пересылка выбранного задания другому пользователю в случае невозможности его выполнения;

 установка критериев сортировки заданий в очереди;

 ограничение списка отображаемых заданий посредством критерия-фильтра;

 управление периодом обновления очереди.

После выпуска или пересылки задания оно автоматически удаляется из очереди.

В управлении и выполнении процесса Workflow участвуют следующие классы пользователей:

администратор системы - поддержка и сохранение целостности всех данных, не относящихся к процессам, например данных о пользователях;

разработчик процесса - разработка, тестирование и поддержка конкретного процесса;

владелец процесса - редактирование конкретного процесса;

менеджер - контроль исполнения экземпляров процесса посредством регистрационных отчетов и сервисных программ;

пользователь - доступ к системе через очередь заданий, функция запуска экземпляра конкретного процесса и справочная подсистема.

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

Для контроля и управления текущим состоянием выполнения экземпляров процесса в системах Workflow предусмотрены следующие функции:

 регистрационные журналы;

 отчеты о состоянии;

 пересмотр данных;

 административные отчеты.

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

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

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

Классификация типовых про­цедур (задач) проектирования. Проектная процедура на­зывается типовой, если она предназначена для много­кратного применения при проектировании многих типов объектов. Классификация типовых проектных процедур представлена на рис. 1.2.

 Различают проектные; процедуры анализа и син­теза. Синтез заключает­ся в создании описания объекта, а анализ — в оп­ределении свойств и ис­следовании работоспо­собности объекта по его описанию, т. е. при синтезе создаются, а при анализе оцениваются проек­ты объектов.

Процедуры ана­лиза делятся на проце­дуры одно- и многовари­антного анализа. При одновариантном анализе заданы значения внут­ренних и внешних параметров, требуется определить значения выходных параметров объекта. Полезно использовать геометрическую интерпретацию этой задачи, связан­ную с понятием пространства внутренних параметров. Это n-мерное пространство, в котором для каждого из а внутренних параметров x_i выделена координатная ось. При одновариантном анализе задается также некоторая точка в пространстве внутренних параметров и требуется ' в этой точке определить значения выходных параметров. Подобная задача обычно сводится к однократному решению уравнений, составляющих математическую модель, что и обусловливает название этого вида анализа.

Многовариантный анализ заключается в исследовании свойств объекта в некоторой области пространства внутренних параметров. Такой анализ требует много­кратного решения систем уравнений (многократного вы­полнения одновариантного анализа).

Процедуры синтеза делятся на процедуры структурного и параметрического синтеза.

Целью структурного синтеза является определение; структуры объекта — перечня типов элементов, составля­ющих объект, и способа связи элементов между собой в составе объекта.

Параметрический синтез заключается в определении числовых значений параметров элементов при заданных структуре и условиях работоспособности на выходные параметры объекта, т. е. при параметрическом синтезе нужно найти точку или область в пространстве внутренних параметров, в которых выполняются 

те или иные условия (обычно условия работоспособности).

П р и м е ч а н и е. Характеристика отдельных видов задач ана­лиза и синтеза, перечисленных на рис. 1.2, дана в разделе, по­священном математическому обеспечению САПР.

Типичная последовательность проектных процедур [2].

На рис. 1.3 представлена типичная последовательность проектных процедур на одном из этапов нисходящего проектирования.

На предыдущем этапе решались задачи k-го иерархи­ческого уровня, одним из результатов решения этих за­дач при нисходящем проектировании является форму­лировка ТЗ на проектирование систем (k+l)-гo рассмат­риваемого уровня.

Проектирование системы начинается с синтеза исход­ного варианта ее структуры. Для оценки этого варианта создается модель: математическая — при автоматизиро­ванном проектировании, экспериментальная или стенд — при неавтоматизированном проекти-

ровании. После вы­бора исходных значений параметров элементов выполня­ется анализ варианта, по результатам которого стано­вится возможной его оценка. Обычно оценка заключает­ся в проверке выполнения условий работоспособности, сформулированных в ТЗ. Если условия работоспособно­сти выполняются в должной мере, то полученное проект­ное решение принимается, система (&+1)-го уровня опи­сывается в принятой форме и формулируются ТЗ на про­ектирование элементов данного уровня (т. е. систем следующего уровня). Если же полученное проектное ре­шение неудовлетворительно, выбирается один из воз­можных путей улучшения проекта.

Обычно проще всего осуществить изменения число­вых значений параметров элементов, составляющих век­тор X.

Совокупность процедур модификации X, анализа и оценки результатов анализа представляет собой про­цедуру параметрического синтеза. Если модификации X целенаправленны и подчинены стратегии поиска наилуч­шего значения некоторого показателя качества, то про­цедура параметрического синтеза является процедурой оптимизации. Возможно, что путем параметрического синтеза не удастся добиться приемлемой степени выпол­нения условий работоспособности. Тогда используют другой путь, связанный с модификациями структуры.

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

Рис. 1.3 позволяет установить характерную особен­ность взаимосвязи проектных процедур анализа и синте­за. Эта взаимосвязь имеет характер вложенности про­цедуры анализа в процедуру оптимизации (параметри­ческого синтеза) и процедуры оптимизации в процедуру синтеза, объединяющую синтез структурный и парамет­рический. Вложенность процедур показана на рис. 1.4.

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

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

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

Согласно классическому подходу стандарт DFD, который расшифровывается, как Data Flow Diagram, представляет из себя диаграмму потоков данных, которая используется для описания бизнес-процессов верхнего уровня. В свою очередь стандарт WFD расшифровывается как Work Flow Diagram и представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеются и другое название - диаграмма алгоритмов. Давайте рассмотрим два этих стандарта, составляющих классическую методологию описания бизнес-процессов.

Стандарт описания бизнес-процессов DFD - Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня.

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

Входы и выходы, которые были показаны при описании окружения бизнес-процесса являются внешними. Внешние входы на DFD-схеме поступают из вне от поставщика процесса, а внешние выходы уходят наружу к клиенту процесса. При построении DFD-схемы бизнес-процесса их нужно перенести со схемы окружения процесса DFD-диаграмму. Для окончательного описания бизнес-процесса остается описать только внутренние информационные и материальные потоки. Каждый из них является выходом одной из работ и в то же является входом для другой (Рисунок 3.1).

Рисунок 3.1 – Диаграмма потоков данных – DFD

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

Рисунок 3.2 – Пример несовпадения временной последовательности работ и направления движения документа

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

Рисунок 3.3 – Пример бизнес-процесс верхнего уровня

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

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

Правило 1. Названия работы нужно формулировать согласно следующее формуле.

загрузка...

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

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

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

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

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

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

Рисунок 3.4 – Разработка сети бизнес-процессов.

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

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

При построении DFD-схемы бизнес-процесса необходимо использовать правило «7», согласно которому нужно выбрать такой уровень абстрагирования и детализации, при котором схема бизнес-процесса будет состоять в среднем из семи работ. Использование большей детализации и соответственно количества работ приведет к сильному усложнению схемы и снижению возможности проведения качественного анализа бизнес-процесса. Это в свою очередь связано с тем, что человек может эффективно оперировать не более чем семью различными объектами. Использование небольшой детализации и меньшего количества работ на схеме бизнес-процесса приведет к тому, что работы будут достаточно укрупненными для того и это также уменьшит возможность проведения их качественного анализа и оптимизации.

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

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

В случае необходимости работы на схеме процесс а второго уровня могут быть декомпозированы на схемы бизнес-процессов третьего уровня и т.д. Декомпозиция бизнес-процесса должна продолжаться до тех пор, пока не будут достигнуты цели его описания. В данном случае удобно использовать понятия вложенный процесс или подпроцесс. На рисунке 3.9 процессная схема работы 3 является вложенным процессом или подпроцессом процесса верхнего уровня. Аналогичным образом процессные схемы работ 3.1 и 3.4 являются вложенными процессами или подпроцессами процесса второго уровня.

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

Рисунок 3.5 – Декомпозиция бизнес-процесса

При описании бизнес-процессов нижнего уровня используются немного другие процессные схемы, под названием WFD - Work Flow Diagram, что переводится как диаграмма потоков работ. На этой схеме появляются дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки (Рисунок 3.6).

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

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

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

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

Отличительной особенностью WFD - диаграммы является то, что стрелки между операциями бизнес-процесса обозначают не потоки объектов (информационные и материальные), а потоки или временную последовательность выполнения работ.

Итак с помощью двух классических схем DFD и WFD можно описать подробно все бизнес-процессы компании.

Рисунок 3.6 – Диаграмма потоков работ- WFD

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

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

На самом деле, несмотря на свое различие, в основном связанное с названием диаграмм и видов используемых объектов современные методологии описания бизнес-процессов практически идентичны и представляют из себя незначительные видоизменения двух классических схем - DFD и WFD - Work Flow Diagram, которые были рассмотрены.

Давайте рассмотрим другие современные языки описания бизнес-процессов:

· IDEF0;

· DFD в нотациях Гейна-Сарсона и Йордана-Де Марко;

· IDEF3;

· Oracle;

· BAAN;

· ARIS.

Методология IDEF0

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

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

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

Четыре типа объектов, применяемых для описания входов и выходов в стандарте IDEF0, в английском варианте образуют сокращение ICOM и на схеме IDEF0 размещаются в строго отведенных местах относительно работ, которые называются функциональными блоками (Таблица 3.1).

Таблица 3.1 – Название и размещение входов и выходов в стандарте IDEF0 относительно функционального блока

Давайте рассмотрим пример бизнес-процесса «Выточить деталь», который выполняет токарь. Входом процесса является заготовка из которой вытачивается деталь - она физически преобразуется в процессе. Для того, что бы токарь начал точить деталь ему нужно дать задание или план. Также ему понадобится чертеж с размерами детали. Так вот, чертеж, задание или план нужны для реализации бизнес-процесса и процесс без них не начнется, но по ходу выполнения процесса они не преобразуются. Согласно стандарту IDEF0 их относят к управлению. Для того, что бы выточить деталь нужен токарь, нужен станок - их относят к механизмам. Выходами или результатами бизнес-процесса является деталь (Рисунок 3.7).

Рисунок 3.7 – Стандарт описания бизнес-процесса IDEF0

Стандарт IDEF0 получил большое распространение в США и активно используется в России. Ввиду того, что в стандарте IDEF0 появилась дополнительная аналитика пс сравнению с классическим стандартом DFD, схемы бизнес-процессов получаемые при описании в стандарте IDEF0 выглядят более сложными с точки зрения менеджеров компании, в виду ограниченного наличия у них свободного времени. Данная сложность часто приводит к тому, что менеджеры, особенно высшего уровня, которые должны принимать активное участие в проекте по описанию и оптимизации деятельности компании, «отказываются» от работы с IDEF0. В данном случае IDEF0 - является излишне информационно насыщенным и сложным стандартом.

Второй недостаток стандарта IDEF0 связан с тем, что он дает больше поводов и возможностей сторонникам сопротивлений изменениям притормозить проект по описанию и оптимизации бизнес-процессов и дискредитировать его идею. Это также связано с усложненной аналитикой стандарта IDEFO, которая часто дает повод задуматься и задавать следующие вопросы: «А правильно ли, что этот объект отнесен ко входу? Может его отнести к управлению?»

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

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

Методология DFD в нотациях Гейна-Сарсона и Йордана-Де Маоко

Следующий стандарт описания бизнес-процессов, который получил распространение, был разработан на основе развития классической методологии DFD. Данный стандарт представлен двумя немного различающихся вариантами, которые называют нотациями. Первая из них называется нотацией Гейна Сарсона, вторая нотацией Йордона-Де Марко.

Гейн Сарсон, предложил классическую DFD-схему немного усложнить. Он предложил ввести дополнительный объект, с помощью которого показываются места бизнес-процесса, в которых хранится информация, либо материальные ресурсы. Примерами таким мест являются архив, в котором хранятся документы, база данных, в которой хранится информация, либо склад, на котором хранятся материальные ресурсы. Данный объект получил название - хранилище данных. На DFD-схемах в нотациях Гейна-Сарсона и Йордона-Де Марко также используются объекты, с помощью которых показывают внешних субъектов, с которыми бизнес-процесс взаимодействует. Данные объекты называют внешними сущностями. На рисунке 3.8 приведен пример DFD-схемы бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику при увольнении», разработанной в нотации Гейна-Сарсона.

Рисунок 3.8 – DFD-схема бизнес-процесса «Оформление и выдача трудовой книжки сотруднику при увольнении» в нотации Гейна-Сарсонса

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

Вторая нотация Йордона-Де Марко методологии DFD была названа в честь разработавшего ее специалиста Йордона-Де Марко. В первом приближении эта нотация аналогична нотации Гейна Саросна, за исключение форм объектов: для описаний операций бизнес-процесса вместо закругленных прямоугольников стали использоваться круги, немного видоизменились и другие объекты- хранилище данных и внешние сущности (Рисунок 3.9).

Рисунок 3.9 – DFD- схема бизнес-процесса «Оформление и выдача трудовой книжки сотруднику при увольнении» в нотации Йордона-Де Марко

В таблице 3.2 приведены названия, обозначения и смыл элементов, используемых при построении DFD-схемы бизнес-процесса в нотациях Гейна-Сарсано и Йордона-ДеМарко.

Таблица 3.2 – Элементы методологии DFD в нотациях Гейна-Сарсано и Йордана-Де Марко

 однократное решение задачи синте­за — многократного ре­шения задачи оптими­зации. Очевидно, что такой же характер вза­имодействия имеют процедуры анализа — однократный многова­риантный анализ основан на многократном одновариантном анализе. Нетрудно подсчи­тать, что синтез про­ектного решения на очередном этапе проектирования может потребовать выполнения чрезмерно большого количества вариантов анализа. Если ввести коэффициент f_ij, равный количеству выполнений процедуры i, вложен­ной в процедуру j, при однократном выполнении про­цедуры j, а процедурам синтеза, оптимизации, многовариантного и одновариантного анализа присвоить номера соответственно 1,2, 3, 4, то

f₄₁ = f_2l f₃₂ f₄₃;

Пример синтеза объектов.При синтезе объекта просматривается fu вариантов его структуры, каждый вариант структуры опти­мизируется с выполнением fi2 шагов оптимизации, а каждый шаг оптимизации заключается в оценке объекта, требующей /« вариантов анализа; пусть /21=/з2 = /« = 40. Тогда потребуется /41 = 6,4-104 вариантов анализа — решений уравнений матема­тической модели объекта. Подобная задача может оказаться не­посильной для современных ЭВМ, если порядок системы урав­нений достаточно высок.

Приведенный выше пример свидетельствует о боль­шой трудоемкости проектирования и о необходимости поиска путей сокращения этой трудоемкости. Разработка способов сокращения затрат вычислительных ресурсов на выполнение проектных процедур — актуальная проб­лема автоматизированного проектирования.

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

29

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

Примеры маршрутов проектирования технических объектов.

Маршрут проектирования объекта — последователь­ность этапов и (или) проектных процедур, используемая для проектирования этого объекта. Маршрут называют типовым, если он применяется при проектировании мно­гих объектов определенного класса.

Примеры типовых маршрутов проектирования. На рис. 1.5 пред­ставлена схема маршрута проектирования сверхбольших интегральных схем (СБИС) [3]. Если СБИС предназначена для многих применений, то форму­лировка ТЗ относится к внешнему проектированию. Если СБИС специализированная, т. е. используется для построения конкрет­ной радиоэлектронной системы, то ТЗ на СБИС получается в результате нисходящего проектирования этой системы. На эта­пе Э1 (рис. 1.5) выполняются процедуры верхнего иерархиче­ского уровня функционального проектирования СБИС — про­цедуры синтеза логической схемы, ее анализа с учетом предпо­лагаемых задержек распространения сигналов в элементах. На этапе Э2 производится синтез принципиальных электрических схем фрагментов СБИС, считавшихся на этапе Э1 элементами. Синтез проводится на основе просмотра нескольких вариантов структуры и ориентировочной оценки этих вариантов. Парал­лельно с выполнением этих этапов выполняют этап Э7 — про­ектирование компонентов (элементов электронных схем). Здесь 

Рис. 1.5. Схема маршрута проектирования СБИС

Рис. 1.6. Схема маршрута технологической подготовки производства в машиностроении

синтезируется физическая и топологическая структура компо­нентов и выбирается технология изготовления СБИС. На эта­пе ЭЗ исходными данными являются, во-первых, варианты струк­туры принципиальных электрических схем, отобранные на эта­пе Э2, во-вторых, характеристики и значения электрических параметров части компонентов, полученные на этапе Э7. Другая часть параметров компонентов варьируется на этапе ЭЗ с целью их оптимизации. Здесь же проверяется работоспособность схем в условиях воздействия различных дестабилизирующих факто­ров. Этапы Э4 — Э6 относятся к конструкторскому аспекту. На этапе Э4 синтезируется топология микросхемы, т. е. конфигура­ция и взаимное расположение компонентов и связывающих их электрических соединений в полупроводниковом кристалле. Све­дения о ранее спроектированной топологии отдельных компонен­тов поступают от этапа Э7. На этапе Э5 проверяется соответст­вие топологии исходной принципиальной электрической схеме и соблюдение конструкторско-технологических проектных норм. На этапе Э6 проектируются фотошаблоны, которые содержат- в себе информацию о топологии и будут непосредственно исполь­зоваться в процессе изготовления СБИС. Так как конструктор­ские решения влияют на значения ряда электрических парамет­ров, то после выполнения этапов Э4 — Э6 требуется уточнение результатов логического и схемотехнического проектирования, т. е. итерационный возврат к этапам Э1 и ЭЗ. На рис. 1.6 показана схема маршрута технологиче­ской подготовки производства в машинострое­нии[4]. Технологическое планирование для неоригинальных

 деталей отличается от техноло­гического планирования для оригинальных деталей. Для не­оригинальных деталей техноло­гический процесс проектируется путем конкретизации и адапта­ции типового обобщенного тех­нологического процесса, соз­данного ранее для рассматри­ваемого класса деталей. Для оригинальных деталей выпол­няется нисходящее проектирование технологического про­цесса, состоящее из этапов про­ектирования принципиальной схемы, маршрутной и операци­онной технологии, проектирова­ния оснастки, инструмента и синтеза управляющих программ для станков с ЧПУ. На рис. 1.7 представлена схема маршрута функцио­нального проектирования следящих гидро­приводов с ЭВМ в контуре управления [5]. Этап Э1 состоит из проектных процедур выбора элементов (ис­полнительного двигателя, усилителя мощности, редуктора, при­водного двигателя) и анализа работоспособности силовой части в целом; этап Э2 — из процедур определения необходимости включения корректирующих устройств, их синтеза, анализа функционирования привода с учетом нелинейностей силовой ча­сти; этап ЭЗ— из процедур синтеза цифро-аналоговых преобра­зователей, синтеза алгоритма вычисления на управляющей ЭВМ компенсирующего сигнала, анализа функционирования цифрово­го следящего привода.

Режимы проектирования в САПР. По характеру и степени участия человека и использова­ния ЭВМ при выполнении некоторого мар­шрута различают несколько режимов проектирования.

Автоматический режим имеет место при выполнении маршрута проектирования по формальным алгоритмам на ЭВМ без вмешательства человека в ход решения.

Ручной (неавтоматизированный) режим характеризу­ется выполнением маршрута без помощи ЭВМ.

Автоматизированное проектирование является час­тично автоматизированным, если часть проектных про­цедур в маршруте выполняется человеком вручную, а часть — с использованием ЭВМ. Такой режим обычно отражает невысокую степень автоматизации проектиро­вания.

Диалоговый (интерактивный) режим является более совершенным режимом, при нем все процедуры в марш­руте выполняются с помощью ЭВМ, а участие человека

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

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

Во многих случаях пользователь САПР в режиме диалога только вводит и редактирует исходные данные для выполнения определенного маршрута проектирования, а непосредственное исполнение маршрута производится в автоматическом (пакетном) режиме работы ЭВМ.

Развитие САПР происходит, в частности, в направле­нии повышения степени автоматизации проектирования. Однако работа в режиме диалога в САПР остается необ­ходимой в связи с тем, что полностью процесс проектиро­вания сложных систем формализовать не удается, и что участие человека в ряде случаев позволяет ускорить при­нятие решения.

 КРАТКИЕ ВЫВОДЫ

Проектирование — процесс получения описаний, достаточных для изготовления нового технического объек­та в заданных условиях. Описания сложных технических объектов имеют иерархическую структуру и могут относиться к тем или иным сторонам [группам свойств) объекта. Поэтому выделяют ряд иерар­хических уровней и аспектов описаний.

Процесс проектирования делится на этапы. Этап объединяет выполнение проектных процедур по созданию описаний, относя­щихся к одному аспекту или иерархическому уровню.

При выполнении проектных процедур решаются задачи синтеза и анализа описаний. При решении задач синтеза определяются со­став элементов и способ их связи между собой, а при решении задач анализа оцениваются свойства синтезированной структуры.

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

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

Ресурсами являются элементы, необходимые для процесса. В отличие от входов, ресурсы не изменяются в процессе. Такими ресурсами процессный подход определяет оборудование, документацию, финансы, персонал, инфраструктуру, среду и пр.

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

У каждого процесса должны быть поставщики и потребители. Поставщики обеспечивают входные элементы процесса, а потребители заинтересованы в получении выходных элементов. У процесса могут быть как внешние, так и внутренние поставщики и потребители. Если у процесса нет поставщиков, то процесс не будет выполнен. Если у процесса нет потребителей, то процесс не востребован.

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

ПРЕИМУЩЕСТВА ПРОЦЕССНОГО ПОДХОДА

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

Основными преимуществами процессного подхода являются:

Координация действий различных подразделений в рамках процесса;

Ориентация на результат процесса;

Повышение результативности и эффективности работы организации;

Прозрачность действий по достижению результата;

Повышение предсказуемости результатов;

Выявление возможностей для целенаправленного улучшения процессов;

Устранение барьеров между функциональными подразделениями;

Сокращение лишних вертикальных взаимодействий;

Исключение невостребованных процессов;

Сокращение временных и материальных затрат.

СОВЕРШЕНСТВОВАНИЕ ДЕЯТЕЛЬНОСТИ НА ОСНОВЕ ПРОЦЕССНОГО ПОДХОДА

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

К таким направлениям относятся:

Всеобщий менеджмент качества (TQM). Это концепция, которая предусматривает непрерывное повышение качества продукции, процессов и системы управления организацией. В основу работы организации ставится удовлетворение потребителя;

Любой проект по реинжинирингу должен начинаться с подготовительного этапа - создания системы управления проектом, на котором должны быть определены: участники проекта по реинжинирингу, их роли и обязанности; план проведения реинжиниринга (см. рис. 4.1).

Участники проекта по реинжинирингу, их роли и обязанности.

На рис. 4.2 приведена типовая организационная структура для участников проекта по реинжинирингу. М Хаммер и Дж. Чампи для среднего проекта выделяют следующих участников реинжиниринга компании [3]:

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

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

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

3. Исполнительный директор (в [3] - "царь") - специалист компании, выполняющий функции оперативного руководителя всех работ по реинжинирингу в компании. Поскольку лидер не имеет возможности осуществлять повседневное оперативное управление проектом, он нуждается в помощнике, берущим на себя руководство штатом по реинжинирингу. Он подчиняется непосредственно лидеру проекта и выполняет две основные функции: во-первых, обеспечивает работу по каждому конкретному проекту; во-вторых, координирует работы по всем одновременно выполняемым проектам.

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

4. Владельцы процессов - менеджеры высшего звена, отвечающие за обновляемые процессы. Они назначаются лидером проекта.

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

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

· Группа моделирования бизнеса - специалисты, которые непосредственно занимаются созданием моделей существующего бизнеса, выработкой решений по реконструкции бизнеса, созданием моделей нового бизнеса, анализом и оценкой моделей и т.д. Они должны хорошо разбираться в деятельности компании, ее положении в соответствующей отрасли, внутренней организации компании, структуре ее продукции.

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

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

загрузка...

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

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

· Администратор проекта - специалист, отвечающий за выполнение текущих планов с учетом стоимости и сроков разработки. В больших проектах такой администратор просто необходим.

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

Планирование проведения реинжиниринга

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

· размер реконструируемой компании и масштаб реинжиниринга (отдел, компания в целом, совокупность компаний в рамках отрасли);

· сложность инфраструктуры бизнеса (степень диверсификации компании, территориальная разбросанность и др.);

· опыт разработчиков как в области реинжиниринга в целом, так и в использовании конкретных методологий;

· готовность копании к реинжинирингу (степень поддержки со стороны руководства и сотрудников компании.

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

· последовательность этапов реинжиниринга,

· содержание этапов, включая конкретные виды работ, используемые методики и перечень разрабатываемых документов,

· способы взаимодействия участников проекта по реинжинирингу.

Последовательность этапов. Состав этапов для любого проекта примерно одинаков и включает в себя кроме подготовительного этапа этапы визуализации, прямого, обратного инжиниринга и внедрения. Однако схема применения этапов, порядок их следования и организация работ могут существенно отличаться. Существует несколько типовых схем организации работ, разработанных для процессов создания информационных (автоматизированных) систем, однако эти схемы могут быть распространены и на проекты по реинжинирингу. Различают 3 основных схемы [1,12]:

1. Каскадная (водопадная) схема предполагает строгое линейное следование этапов анализа, проектирования, реализации, внедрения и эксплуатации системы по единому заранее разработанному плану. Такая схема, обладая определенными преимуществами (детерминированность, логичность, простота), имеет существенные недостатки, главный из которых заключается в том, что к моменту завершения работ система "устаревала" по причине изменения требований пользователей и внешних ограничений.

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

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

· создание на различных этапах разработки системы вместо законченных прототипов макетов, представленных хотя бы и на бумаге, и оперативно проверяемых и обсуждаемых со всеми заинтересованными сторонами (будущими пользователями, заказчиками и т.д.);

· на любом этапе по результатам обсуждений макетов при необходимости принимается решение о возврате на любой из предыдущих этапов с целью корректировки принятых решений;

· параллельное (хотя бы частично) выполнение этапов и отдельных работ в рамках каждого этапа.

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

На рис. 4.3 приведены связи между этапами, характерные для каждой из рассмотренных схем разработки.

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

· цели никогда не удается сформулировать окончательно ясно, поэтому в ходе выполнения конкретной работы происходит их постоянное уточнение;

· некоторые цели, запланированные в начале работы над проектом, оказываются нереалистичными и не могут быть достигнутыми;

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

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

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

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

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

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

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

Рассмотрим 3 вида обсуждений [3]:

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

На неформальных совещаниях членами команды обсуждаются созданные макеты и промежуточные документы. По итогам обсуждения вносятся необходимые коррективы и намечаются пути дальнейшей работы.

2. Инспекция. Это наиболее мощный из всех методов оценки и контроля. Представляет собой формальную методику оценки, результаты которой должны быть зафиксированы письменно. При проведении инспекции выделяют следующие конкретные роли ее участников:

· Арбитр - председатель, который обеспечивает создание творческой и продуктивной атмосферы и направляет деятельность участников на выявление ошибок;

· Секретарь - фиксирует каждую обнаруженную ошибку, ее приоритет и степень серьезности;

· Инспектор - несет ответственность за критический разбор;

· Автор или проектировщик - дает необходимые пояснения.

Итогом инспекционного обсуждения должно быть решение, принимается ли обсуждавшийся документ без изменений, принимается с внесенными корректировками или его принятие откладывается до очередной инспекции с тем, чтобы документ был доработан и исправлены все выявленные ошибки.

Инспекционное совещание должно длиться не более двух часов, и число участников не должно превышать 8 человек.

3. Прогон. Это неформальный способ оценки, при котором проектировщик "проводит" одного или нескольких членов команды, участвующих в проекте, через разработанный сегмент модели. Члены команды делают замечания по стилю методам, возможным ошибкам, нарушению стандартов и т.д. Все ошибки, обнаруженные во время прогона, должны быть зафиксированы проектировщиком для дальнейшей проработки. Однако никаких формальных записей и протоколов не требуется: цель прогона - дать проектировщику информацию, необходимую для коррекции его работы. Прогон представляет собой хорошее упражнение с широким обменом информацией.

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

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

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

Такая классификация соответствует логике самого системного исследования – от описания идеи (гипотезы) до ее реализации различными формализованными способами, включая разработку математических и имитационных моделей.

В учебнике «Основы теории систем и системного анализа» авторов В.Н. Волковой и А.А. Денисова вводится термин «методы формализованного представления систем» (МФПС), которые позволяет представить единую систему методов системного анализа.

Аналитические методы,которые позволяют описать ряд свойств многомерной и многосвязной системы отображаемой в виде одной единственной точки, совершающей движение в n-мерном пространстве. Это отображение осуществляется с помощью функции f(s) или посредством оператора (функционала) F(S). Также возможно отобразить точками две или более систем или их части и рассматривать взаимодействие этих точек. Каждая из этих точек совершает движение и имеет свое поведение в n-мерном пространстве. Это поведение точек в пространстве и их взаимодействие описывается аналитическими закономерностями, и может быть представлено в виде величин, функций, уравнений или системы уравнений. Аналитические методы являются основой классической математики (методы интегрального и дифференциального исчисления, поиска экстремума функции, вариационного исчисления и многие другие) и математического программирования (методы теории алгоритмом, теории игр и т.п.) Аналитические методы применяются лишь в том случае, когда свойства системы могут быть представлены в детерминированных параметрах или зависимостей между ними. Для сложных многокомпонентных, многокритериальных систем получение таких аналитических зависимостей не всегда возможно, поэтому требуется предварительное установление степени адекватности описания такой системы аналитическими методами. Поэтому, в данном случае необходимо создавать промежуточные, абстрактные модели, которые в определенной степени могут быть исследованы аналитическими методами или разрабатывать новые методы системного анализа.

Статистические методы позволяют отобразить систему с помощью случайных (стохастических) событий, процессов, которые описываются соответствующими вероятностными (статистическими) характеристиками и статистическими закономерностями. В данном случае система представляется в виде «размытой» точки (области) в n-мерном пространстве, в которую переводится система, с учетом ее свойств, посредством оператора   .

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

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

Логические методыявляются языком описания систем в понятиях алгебры логики, которая лежит в основе функционирования микроэлементов любого компьютера. Наибольшее распространение логические методы получили под названием Булевой алгебры, как бинарного представления о состоянии элементарных схем ЭВМ. Основными понятиями алгебры логики являются такие как: высказывания, предикат, логические операции (функции сочетания, логического сложения, вычитания, умножения, отрицания и т.п.). Логические методы позволяют описывать систему в виде более простых структур на основе законов математической логики. Каждое состояние элемента рассматривается в качестве 1 или 0.На базе таких методов развиваются новые теории формального описания систем в теориях логического анализа, теории автоматов. Все эти методы расширяют возможность применения системного анализа и синтеза в прикладной информатике. Эти методы используются для создания моделей сложных систем, адекватных законом математической логики построения устойчивых структур.

загрузка...

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

- прагматика – это оценка и сравнение различных языков программирования, программ и систем по критериям полезности, выгодности и эффективности их использования;

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

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

- синтаксис грамматические правила расстановки знаков в тексте.

Лингвистические и семиотические методы стали широко применяться в том, случае, когда для первого этапа исследования невозможно формализовать принятие решений в плохо формализуемых ситуациях и нельзя использовать аналитические и статистические методы. Эти методы являются основой развития языков программирования, моделирования, автоматизации проектирования систем разной сложности.

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

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

Измерение и анализ показателей процесса

Измерение и анализ показателей процесса являются важнейшими средствами, позволяющими находить пути улучшения процессов. Как уже говорилось выше, процесс могут характеризовать несколько групп показателей:

· показатели процесса;

· показатели продукта процесса;

· показатели удовлетворенности клиентов процесса.

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

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

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

На рисунке приводится простейшая классификация показателей процессов.

Классификация показателей процесса

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

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