Методические рекомендации по выполнению практических работ профессионального модуля
 Скачать 2.97 Mb.
|
|
Теоретическое обоснование Результатом моделирования бизнес-процессов является модель бизнес-процессов, ко- торая относится к одному из трех типов: модель AS-IS (как есть) - модель текущей организации бизнес-процессов предпри- ятия модель TO-BE (как будет) - модель идеальной организации бизнес-процессов модель SHOULD-BE(как должно бы быть) - идеализированная модель, не отра- жающая реальную организацию бизнес-процессов предприятия Цель моделирования. Модель не может быть построена без четко сформулирован- ной цели. Цель должна отвечать на следующие вопросы: Почему этот процесс должен быть смоделирован? Что должна показывать модель? Что может получить читатель? Точка зрения. Не смотря на то, что при построении модели учитываются мнения раз- личных людей, модель должна строиться с единой точки зрения. Точку зрения можно пред- ставить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. В течении моделирования важно оставаться на выбранной точке зрения. Декомпозиция — это разделение сложного объекта, системы, задачи на составные части, элементы. С методической точки зрения при моделировании полезно использовать мнение экс- пертов, имеющих разные взгляды на предметную область, однако каждая отдельно взятая модель должна разрабатываться исходя из единственной заранее определенной точки зрения. Часто другие точки зрения в краткой форме документируются в прикрепленных диаграммах FEO (см. ниже) исключительно для наглядности изложения. Точку зрения нужно подбирать достаточно аккуратно, основой для выбора должна служить поставленная цель моделирования. Наименованием точки зрения может являться название должности, подразделения (например, руководитель отдела или менеджер по про- дажам). Как и в случае с определением цели моделирования, четкое определение точки зре- ния необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры. Может оказаться необходимым построение моделей с разных точек зрения для детального отражения всех особенностей, выделенных в системе функциональных блоков. Одним из положительных результатов построения функциональных моделей оказыва- ется четкое определение границ моделирования системы в целом и ее основных компонен- тов. Хотя и предполагается, что в процессе работы над Моделью будет происходить 136 некоторое изменение границ моделирования, их вербальное (словесное) описание должно поддерживаться с самого начала для обеспечения координации работы участвующих в про- екте аналитиков. Как и при определении цели моделирования, отсутствие границ затрудняет оценку степени завершенности модели, поскольку границы моделирования имеют тенден- цию к расширению с увеличением размеров модели. Границы моделирования имеют два компонента: ширину охвата и глубину детали- зации. Ширина охвата обозначает внешние границы моделируемой системы. Глубина дета- лизации определяет степень подробности, с которой нужно проводить декомпозицию функциональных блоков. Чтобы облегчить правильное определение границ моделирования при разработке IDEFO-моделей, существенные усилия затрачиваются на разработку и рецензирование кон- текстной диаграммы IDEFO (диаграммы "самого верхнего" уровня). Иногда даже прибегают к построению дополнительной диаграммы для отображения уровня более высокого, чем кон- текстный для данной модели, что позволяет обозначить систему, внутри которой располага- ется объект для моделирования. Существенные затраты на разработку контекстной диаграммы вполне оправданы, поскольку она является своего рода "точкой отсчета" для ос- тальных диаграмм модели, и вносимые в нее изменения каскадом отражаются на все лежа- щие ниже уровни. Когда границы моделирования понятны, также становится ясным, какие объекты системы по тем или иным причинам не вошли в модель. Рекомендуется следующая последовательность действий при построении модели "с нуля": формулирование цели моделирования, выбор точки зрения, определение границ мо- делирования. Наименование контекстного блока — функционального блока самого высо- кого уровня — обобщает определение границ моделирования. Правила подбора имени для контекстного блока в целом не отличаются от общих пра- вил именования функциональных блоков, поэтому для них обычно подбирают обобщаю- щие названия типа "Управление отделом по работе с клиентами", "Обработка заказов" и т.п. Стрелки IDEF0-диаграмм обычно проще проектировать в следующем порядке: выход, вход, механизм исполнения, управление. Каждый функциональный блок обозначает отдельную функцию, и эта функция часто имеет четко описываемые результаты работы. Наличие неясно- стей при анализе выходов того или иного функционального блока — возможный сигнал необхо- димости проведения реинжиниринга рассматриваемого бизнес-процесса. Определение выходов. После идентификации возможных выходов полезно провести анализ модели на предмет предвидения всех возможных сценариев поведения процесса. Это означает, что если существует вероятность возникновения той или иной ситуации в ходе процесса, модель ее отражает. Многие начинающие аналитики забывают отразить негатив- ные результаты работы функциональных блоков. Например, блок "Провести экзамен по во- ждению" определенно произведет поток водителей, только что получивших права, но вполне правомерно ожидать и поток лиц, не сдавших экзамен. Негативные результаты часто исполь- зуются в качестве обратных связей, их анализ должен проводиться для каждого блока. Также важным является необходимость включения в модель "спорных" стрелок, решение о наличии которых в модели могут принимать рецензирующие модель эксперты. Определение входов. Входы можно рассматривать как особым образом преобразуе- мые функциональными блоками сырье или информация для получения выхода. В производ- ственных отраслях определить, как входное сырье преобразуется в готовую продукцию, обычно довольно просто. Однако при моделировании информационных потоков входной по- ток данных может представляться не потребляемым и не обрабатываемым вообще. Случаи, когда входящие и исходящие стрелки называются одинаково, крайне редки и в основном указывают на бесполезность данного блока для системы в целом или на некорректный выбор имени для исходящей стрелки. Решением может служить применение более подробного опи- сания для входящих и исходящих потоков данных. Например, вход может иметь название "Предварительный диагноз пациента", а выход — "Уточненный диагноз пациента". 137 Определение механизмов исполнения. После создания входов и выходов можно при- ступить к рассмотрению механизмов исполнения или ресурсов, относящихся к функцио- нальному блоку. В понятие механизма исполнения входят персонал, оборудование, информационные системы и т.п. Например, функциональный блок "Собрать деталь" может потребовать использования какого-либо оборудования, например, гаечного ключа. При приеме экзаменов на водительские права механизмом исполнения является инспектор ГИБДД. Как правило, определить механизмы исполнения для функциональных блоков до- вольно просто. Определение управления. Наконец, должно быть определено управление, контроли- рующее ход работы функционального блока. Все функциональные блоки в IDEF0 должны иметь хотя бы одно управление. В случаях когда неясно, относить ли стрелку ко входу или к управлению, следует ее рисовать как управление. Важно помнить, что управление можно рассматривать как особую форму входа функционального блока. Когда контекстная диаграмма представляется завершенной, попробуйте задать сле- дующие вопросы: Обобщает ли диаграмма моделируемый бизнес-процесс? Согласуется ли диаграмма с границами моделирования, точкой зрения и целью мо- делирования? Подходит ли выбранный уровень детализации стрелок для контекстного блока? Все функциональные блоки IDEF0 нумеруются. В номерах допускается использова- ние префиксов произвольной длины, но в подавляющем большинстве моделей используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет но- мер АО. Префикс повторяется для каждого блока модели. Номера используются для отраже- ния уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки Al, A2, A3 и т.д.; блок А1 — в А11, А12, А13 и т.д.; блок — А11 в А111, А112, А113 и т.д. Для каждого уровня декомпозиции в конце номера добавляется одна цифра. Модели могут проектироваться как с использованием подхода "в ширину", когда ка- ждая диаграмма максимально детализируется перед своей декомпозицией, так и с подходом "в глубину", когда сначала определяется иерархия блоков, а затем создаются соединяющие их стрелки. Естественно, возможно применение комбинации этих подходов, причем иерар- хия блоков может иногда немного меняться после того, как нарисованы стрелки. Это проис- ходит в случае, когда создание стрелок может изменить понимание внутренней архитектуры моделируемого объекта. Сформулированная цель моделирования содержит вопросы, на которые должна отве- чать модель. Когда становится возможным получение ответов на них с помощью модели, по- следняя считается удовлетворяющей поставленным требованиям и рассматривается как за- вершенная. При построении декомпозиции первого уровня нужно следить за тем, чтобы все блоки на диаграмме лежали внутри определенных ранее границ моделирования. Перед де- композированием блока нужно удостовериться, не приведет ли это к превышению установ- ленной ранее глубины детализации данной модели. Еще одно правило состоит в том, что IDEF0-моделирование должно продолжаться до тех пор, пока стрелки предшествования (вход и выход) преобладают на диаграммах. При необходимости дальнейшей детализации отдельных процессов может быть ис- пользована методология IDEF3. В дополнение к контекстным диаграммам и диаграммам декомпозиции при разработ- ке и представлении моделей могут применяться другие виды IDEF0-диаграмм. Дерево модели. Дерево модели — обзорная диаграмма, показывающая структуру всей модели. Обычно вершина дерева соответствует контекстному блоку, под вершиной выстраи- вается вся иерархия блоков модели. Однако не запрещается назначать вершиной произволь- ный блок, помещая под ним все его детские блоки. Из-за высокой итеративности функционального моделирования можно ожидать, что дерево модели будет неоднократно 138 изменяться существенным образом до тех пор, пока не будет получена его стабильная вер- сия. Обзор модели с использованием дерева помогает сконцентрироваться на функциональ- ной декомпозиции модели. Презентационные диаграммы. Презентационные диаграммы (For Exposition Only diagrams — FEO diagrams) часто включают в модели, чтобы проиллюстрировать другие точ- ки зрения или детали, выходящие за рамки традиционного синтаксиса IDEF0. Диаграммы FEO допускают нарушение любых правил построения диаграмм IDEF0 в целях выделения важных с точки зрения аналитика частей модели. Естественно, если диаграмма FEO включе- на в модель исключительно для отображения другой точки зрения на систему, она, скорее всего, внешне будет выглядеть как обыкновенная IDEF0-диаграмма, удовлетворяя всем ог- раничениям IDEF0. Один из способов использования FEO-диаграмм состоит в отделении функционально- го блока от его окружения посредством создания диаграммы с единственным блоком и всеми относящимися к нему стрелками наподобие контекстной диаграммы (рис. 4.12). Это может оказаться полезным в ситуациях, когда необходимо быстро получить информацию об интер- фейсе (стрелках) функционального блока, а соответствующая диаграмма декомпозиции со- держит слишком много объектов. Кроме того, встречаются следующие виды презентационных диаграмм: копия IDEF0-диаграммы, которая содержит все функциональные блоки и стрел- ки, относящиеся только к одному из функциональных блоков, — это позволяет отразить взаимодействие между этим блоком и другими объектами диаграммы; IDEF0-диаграммы, которая содержит все функциональные блоки и стрелки, непо- средственно относящиеся только ко входу и/или выходу родительского блока; различные точки зрения, как правило, на глубину одного уровня декомпозиции. Рабочее место BPwin выполнено в виде рабочего стола, состоящего из нескольких окон. На рабочем столе размещены: меню; стандартная панель инструментов; панель инструментов «ModelMart»; дерево модели; область для рисования; панель инструментов BPwin; статусная строка. Панель меню BPwin соответствует стандартам Windows и обеспечивает доступ ко всем функциям BPwin. Приведем некоторые из них: печать — чтобы открыть окно печати, на панели меню выберите «File», затем «Print»; масштаб — на панели меню выберите «View», затем измените масштаб изображения для активной диаграммы или для всех диаграмм в модели на тот, который вам нужен. Как и любая другая панель инструментов BPwin, стандартная панель может быть рас- положена в любой точке экрана или находиться в любом месте в области диаграммы. Вы можете также показывать или скрывать ее, используя функцию «View» на панели меню. Дерево модели BPwin — мощный инструмент, который используется для про- смотра структуры модели и изменения любых объектов диаграмм в открытой модели BPwin. Одновременно работая с несколькими моделями, можно рассматривать все диаграммы или только активные при свернутой и развернутой структуре иерархического дерева. Для любой используемой методологии перечень исследуемых моделей дает полное представление о всей модели. С использованием дерева можно также выполнять задачи моделирования. Вы можете показывать и скрывать дерево модели, используя кнопки «Model Explorer». Когда дерево модели активно, оно находится в раздвигающемся окне слева, а активная диаграмма — в правом. Дерево модели используется для: просмотра разных моделей, построенных с использованием различных методоло- гий моделирования; 139 переключения режимов просмотра диаграмм или действий; немедленного перехода к просмотру или работе с соответствующей диаграммой в рабочем пространстве BPwin посредством v щелчка мышью на названии диаграммы или действия; просмотра действий и объектов диаграммы согласно уровням декомпозиции; редактирования имени модели, диаграммы или действия посредством двойного щелчка мышью на соответствующем названии; просмотра соответствующей объекту FEO-диаграммы, Node Tree или родственной диаграммы посредством щелчка мышью на названии объекта диаграммы в иерархическом дереве. Область для рисования — это большая площадь справа от главного окна BPwin, в котором расположено дерево модели. Она состоит из трех областей: заголовок; область для рисования; название. Когда дерево моделей скрыто, рисунок занимает полную область окна. Вы можете создавать, редактировать и управлять диаграммами BPwin в области для рисования. По ва- шему желанию диаграмма может быть масштабирована при помощи инструментов настрой- ки масштаба. Панель инструментов BPwin содержит инструменты для рисования объектов в диа- грамме BPwin. Эти инструменты могут быть размещены в любой стороне экрана или нахо- диться где-то в области диаграммы. Вы можете показывать или скрывать панель инструментов, используя функцию «View» на панели меню. В BPwin существует три разных панели инструментов — по числу поддерживаемых программой методологий. Нужная панель инструментов подбирается программой автоматически при выборе одной из предлагаемых при первоначальном создании модели методологий. Контекстная диаграмма— это модель, представляющая систему как набор иерархи- ческих действий, в которой каждое действие преобразует некоторый объект или набор объ- ектов. Высшее действие иерархии называется действием контекста — это самый высокий уровень, который непосредственно описывает систему. Уровни ниже называются порожден- ными декомпозициями и представляют подпроцессы родительского действия. При создании модели сначала необходимо изобразить самый высокий уровень— действие контекста. Наименование действия описывает систему непосредственно и, как пра- вило, состоит из одного активного глагола в сочетании с обобщающим существительным, которое разъясняет цель деятельности с точки зрения самого общего взгляда на систему. Каждый блок может иметь различные типы связанных с ним стрелок. Стрелки обо- значают людей, место, вещи, понятия или события. Стрелки связывают границы диаграммы с блоками, а также действия (блоки) на диаграмме между собой. В диаграммах IDEF0 имеет- ся четыре основных типа стрелок. Вход блока представляет материал или информацию, которая должна быть использо- вана или преобразована блоком, чтобы произвести продукцию (выпуск). Стрелки входа все- гда направляются в левую сторону блока. Стрелки входа необязательны, так как не все действия могут преобразовать или изменять (заменять) что-либо. Каждый блок должен иметь по крайней мере одну стрелку контроля (управления). Управление всегда входит в вершину блока. Управление, как правило, представляется в виде правил, инструкций, политики компании, процедур или стандартов. Оно влияет на деятель- ность без фактического преобразования чего-либо. Управление может также использоваться для описания процедуры начала или окончания выполнения действия. Стрелки выхода (выпуска) — это материал или информация, произведенная блоком. Каждый блок должен иметь по крайней мере одну стрелку выхода (выпуска). Процессы, ко- торые не производят продукции (выпуска), лучше не моделировать вообще. Механизмы исполнения — это те ресурсы, которые обеспечивают выполнение дейст- вия. В качестве механизма исполнения могут быть рассмотрены персонал компании, маши- |