понедельник, 6 июля 2009 г.

Качество снижает затраты

 

Из статьи “Собираетесь обмануть расходы? Тогда мы идем к вам!”

Давным-давно, когда «я был мал и свободен под яблоневыми кронами» (Из стихотворения Д. Томаса «Папоротниковый холм». — Прим. пер.), считалось, что вы должны выбирать между затратами и качеством (или «дифференциацией», если пользоваться терминологией Майкла Портера). Как я уже говорил в главе 1, нельзя было иметь более высокое качество и одновременно более низкие затраты.

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

При этом было очевидно — японцам не приходилось увеличивать затраты, чтобы получить более высокое качество. Как раз наоборот. Чем больше они фокусировались на качестве, тем более эффективными и экономичными становились. Этот неожиданный эффект получил известность как «парадокс Toyota». Он возникает по нескольким причинам.

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

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

Внедрение подхода «нулевых дефектов» создает необходимые условия для борьбы с неэффективностью системы. Возьмите метод управления запасами и производством «точно вовремя», пионером которого была все та же Toyota. До появления этого метода производители старались накапливать значительные буферные запасы на разных этапах производственного процесса, чтобы подстраховаться на случай сбоя поставок. Японцы обнаружили, что буферные запасы на практике лишь усугубляют проблемы, которые призваны решать: из-за наличия такой «подушки безопасности» менеджеры расслабляются, становятся более терпимыми к задержкам, невыполнению поставок, неоптимальным графикам. И разумеется, хранение буферных запасов само по себе — большая затратная статья.

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

пятница, 26 июня 2009 г.

“Сверху” или “снизу”?

 

Хочу развенчать одну из крайностей в подходах к моделированию бизнес-процессов.

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

Правильными являются оба подхода одновременно. Т.е. структура приблизительно на два три уровня должна быть выстроена сверху. И только после того как структура согласована и принята высшим руководством, необходимо приступать к моделированию “снизу”. Объясню в чем суть такого компромиссного подхода на примере минусов и сложностей, подходов бескомпромиссных.

“Сверху”. Выбирая такой подход мы рискуем получить неадекватную модель по причине того, что структура и видение руководства, а именно это основная информация, на основании которой формируются укрупненные бизнес-процессы верхнего уровня, не всегда может на 100% соответствовать действительности. Вполне может сложится картина идеализированного представления о процессах, о разграничении сферы ответственности между владельцами бизнес-процессов и т.д. И пытаясь подогнать все под полученную структуру, т.е. создав структуру верхнего уровня глубиной 2 и 3 уровня,  и продолжая дальше декомпозировать, мы можем отсечь очень много ценной информации о реально существующей деятельности, взаимосвязях, а полученная картина процессов на нижних уровнях будет излишне разбита на мелкие подпроцессы и процедуры. Т.е. мы вместо сквозных процессов, которые главным образом и востребованы при процессном подходе, мы в итоге получим множество мелких операций, связанных между собой только структурно в нотации IDEF0.

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

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

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

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

  • Даже перейдя с нотаций описания логики и взаимодействия (EPC, Cross-Functional Flowchart) на уровень структурного моделирования IDEF0 лучше придерживаться группировки процессов в более крупные по тому, в какой последовательности они выполняются. Т.е. нотация IDEF0 хоть и не призвана отображать логику взаимодействия и хронологическую последовательность, тем не менее при таком подходе читаемость диаграмм повышается, а связи взаимодействия процессов между собой ресурсами и информацией наиболее упрощаются и минимизируются междиаграмные переходы стрелок.
  • Самым трудным может оказаться момент, когда необходимо будет сформировать слияние вершины айсберга с процессами нижнего уровня. На самом деле ничего сложно нет: просто в каждом случае рассогласования модели необходимо принять решение, корректировать структуру верхнего уровня или пересматривать группировку на нижнем уровне исходя из того, какой из подходов будет наименее трудоемким т.е., который повлечет наименьшую реструктуризацию сфер ответственности владельцев БП или перегруппировку процессов нижнего уровня для “подгонки” под процессы структуру верхнего уровня (именно перегруппировку т.к. реальные изменения бизнес-процессов на нижнем уровне инициированы не могут быть, т.к. если где в полученной информации и могут быть ошибки, так это ошибки при интерпретации сведений из анкет или ошибки в видении руководства на структуру процессов верхнего уровня, но никак не ошибки в самой деятельности компании)

To-be или As-is?

 

Большинство сталкиваются с этим вопросом при моделировании бизнес-процессов и не знают ответа. Основная проблема заключается в следующем. Большинство случаев, когда необходимо моделировать деятельность, происходит в рамках проектов по внедрению информационных систем. Моделирование бизнес-процессов ради других целей (организация управления процессами, регламентация и т.д.) отпочковалось от целей автоматизации позже, а подходы в моделировании стали скорее не полезными методами, а стереотипами моделирования. Столпы методологий внедрения так и продавливают варианты, в которых сперва моделируется деятельность как есть, без прикрас, а только затем проводится анализ и оптимизация БП (в некоторых методологиях оптимизация, т.е. To-be моделирование производится уже после внедрения ИС).

Это ещё вызвано тем, что основная цель проекта внедрения ИС  - это внедрение ИС! Т.е. у To-be моделирования есть четкие цели: подгонка бизнеса под референтные бизнес процессы ИС, а первоначальное As-is моделирование при таком подходе необходимо лишь как исследование бизнеса и подготовка плацдарма для перехода на To-be модель. При этом очевидно, что описание существующих процессов происходит семимильными шагами.

Справедливы ли те же подходы при моделировании деятельности в рамках проектов внедрения процессного подхода в управлении БП, внедрении СМК, внедрении регламентации деятельности и т.д.?

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

Оба варианта на практике оказываются крайностями. В то время как на самом деле оптимальным является разумный компромиссный подход. Я называю его “Optimized as-is+”. Т.е. на этапе моделирования ни в коем случае нельзя уходить от описания бизнеса как-есть, если вы только не организуете бизнес-процесс с нуля, но и не всегда целесообразно описывать все в точности как есть: особо вопиющие случаи неправильной работы, дублирования функций и т.д. Плюс необходимо обязательно сохранять все идеи в тех случаях, когда все таки процесс описан как есть, но требуются слишком глобальные изменения. Т.е. на этапе планирования проекта должны быть выработаны критерии и процедуры касающиеся оптимизации выявленных недостатков (немедленной или в будущем), а именно:

  • Должна быть определена процедура внесения немедленных корректировок и превентивных мер при выявлении вопиющих случаев неправильного выполнения бизнес-процесса (анализ, согласование, корректировка, существующей на тот момент, управляющей документации, необходимые приказы и т.д.) и отражение в модели уже нового оптимизированного процесса.
  • Сформирована база знаний по выявленным недостаткам, которые требуют тщательного анализа на этапе последующего To-be моделирования (описание процесса таким образом, чтобы все возникшие идеи на этапе моделирования не были потеряны и доступны потом).
  • Выработаны критерии, по которым бизнес-аналитик сможет принимать решения, запускать немедленную процедуру оптимизации или откладывать её на потом. Здесь нужно учитывать временные ограничения проекта, т.к. иногда может оказаться что оптимизировать будет быстрее чем описать как есть, или наоборот. Четкие критерии должны помочь избежать затягивания проекта из-за чрезмерно большого кол-ва оптимизаций на этапе первоначального моделирования (гонкой за лучшим, которое как известно враг хорошего)

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

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

четверг, 25 июня 2009 г.

Используем механизм ролей эффективно

 

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

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

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

image

Мы видим что структура отображает административное подчинение, директор – администратор – сотрудники филиала. Именно это подчинение должно отображаться в должностной инструкции  - все правильно. Но как же быть с функциональным подчинением? Т.е. очевидно что Логистик 1, 2, 3 подчиняется по вопросам логистики Директору по логистике, аналогично бухгалтер 1 2 3  подчиняется Финансовому директору и т.д. Вот тут и приходят на помощь роли. Функциональную структуру можно сформировать используя роли:

image

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

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

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

Таким образом мы убиваем сразу трех зайцев:

  1. Отображаем функциональное подчинение сотрудников
  2. Используем одну роль для описания функции аналогичных должностей по в каждом филиале
  3. Экономим усилия в будущем при изменениях в бизнес-процессах и организационной структуре.

понедельник, 1 июня 2009 г.

Моделирование бизнес-процессов

 

Введение

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

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

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

Основу многих современных методологий моделирования бизнес-процессов составила методология SADT. В настоящее время наиболее широко используемая методология описания бизнес-процессов - стандарт США IDEF.

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

1 Сущность и значение моделирования бизнес-процессов

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

Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:

1) моделирование бизнес-процессов - это описание бизнес-процессов предприятия позволяющее руководителю знать, как работают рядовые сотрудники, а рядовым сотрудникам - как работают их коллеги и на какой конечный результат направлена вся их деятельность [3];

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

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

4) моделирование бизнес-процессов - это метод, позволяющий дать оценку текущей деятельности предприятия по отношению к требованиям, предъявляемым к его функционированию, управлению, эффективности, конечным результатам деятельности и степени удовлетворенности клиента [3];

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

6) моделирование бизнес-процессов - это всегда верный способ выявления текущих проблем на предприятии и предвидения будущих.

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

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

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

Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.

Рисунок 1 - Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:

ь изменение организационной структуры;

ь

оптимизацию функций подразделений и сотрудников;

ь

перераспределение прав и обязанностей руководителей;

ь

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

ь

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

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

1)

существующая организационная структура;

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

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

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

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

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

Детальная модель бизнес-процесса должна включать:

1) набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

2) диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;

3) диаграммы взаимодействия, отражающие схемы документооборота.

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

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

2 Методика проведения моделирования бизнес-процессов

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

- теоретическая база;

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

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

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

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

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

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

3 История развития методологий моделирования бизнес-процессов

Основу многих современных методологий моделирования бизнес-процессов составила методология SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования) и алгоритмические языки, применяемые для разработки программного обеспечения.

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

Рисунок 2 - История развития методологий моделирования бизнес-процессов

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

ь моделирования бизнес-процессов (Business Process Modeling);

ь описания потоков работ (Work Flow Modeling);

ь описания потоков данных (Data Flow Modeling).

Методологии моделирования бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов - стандарт США IDEF0. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с совершенствованием поддерживающих ее инструментов - программных продуктов для моделирования бизнес-процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.). Методология IDEF0 предоставляет аналитику широкие возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа - по информации, управлению, движению материальных ресурсов [2].

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

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

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

IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных;

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

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

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

IDEF5 - методология исследования сложных систем [2].

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

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

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

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

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования - ERM, UML, OMT и др.

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

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - "функция", "событие", "структурное подразделение", "документ" и т.п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Основная бизнес-модель ARIS - eEPC (extended Event Driven Process Chain - расширенная модель цепочки процессов, управляемых событиями). По существу, она расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Применение большого числа различных объектов, связанных различными типами связей, может значительно увеличить размер модели и сделать ее плохо читаемой [1].

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

Сводная информация об основных существующих сегодня методологиях представлена на рисунке [2].

Рисунок 4 - Методологии моделирования бизнес-процессов

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

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

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

- внешние сущности (материальный объект или физическое лицо, являющиеся источником или приёмником информации, например, заказчики, персонал, поставщики, клиенты, склад);

- системы и подсистемы (например, подсистема по работе с физическими лицами);

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

- накопители данных (абстрактные устройства для хранения информации);

- потоки данных.

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

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

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

Заключение

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

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

Основу многих современных методологий моделирования бизнес-процессов составила методология SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования) и алгоритмические языки, применяемые для разработки программного обеспечения. С помощью методологии семейства IDEF можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему.

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

пятница, 29 мая 2009 г.

Как, используя BPWin, познакомиться с девушкой

 

Рассмотрены две различные модели одного и того же процесса – экскурсии молодых людей по достопримечательностям города Уфы. Модели построены на основе использования стандартов IDEF0 и DFD в сочетании с принципом процессного подхода из серии стандартов ISO9000.

         В качестве инструментального средства разработки использован  программный продукт BPWin , входящий в пакет All Fusion Process Modeler (Version 4.1 Service Pack 1)  фирмы Computer Associates International, Inc. (CA).

 

В соответствии с планом техучебы сотрудников было предусмотрено проведение практических занятий по освоению программного продукта BPWin , входящего в пакет All Fusion Process Modeler (Version 4.1 Service Pack 1)  фирмы Computer Associates International, Inc. (CA). С этой целью было проведено три занятия:

1. CASE-средства: общий обзор и сравнительные характеристики  (см. Приложение 1)

2. Универсальный язык моделирования UML (см. Приложение 2)

3. Диаграммы структурно-системного анализа (см. Приложение 3)

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

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

1. Постановка задачи

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

Для выполнения поставленной задачи используем метод структурного анализа SADT в сочетании с принципом процессного подхода. Такой подход позволяет представить деятельность искателя приключений в виде совокупности процессов, каждый из которых описан в рамках стандартов моделирования IDEF0 и/или DFD.

2. Построение модели
         В соответствии с требованиями стандарта IDEF0 необходимо сначала определить цель моделирования, выбрать точку зрения и область применения модели.
         Для определения цели моделирования составим список вопросов, на которые модель должна давать ответ.
         Где взять саму девушку?
         Как ее убедить в неизбежности мероприятия?
         Куда ее отвести?
         Что с ней делать после мероприятия?
         Перечень вопросов может быть продолжен. Поскольку общая канва уже прочерчена, дадим краткую формулировку цели в виде одного предложения: цель состоит в том, чтобы хорошо провести время с девушкой на экскурсии.  
         Точка зрения очевидна: выбираем точку зрения самого искателя приключений.
         Область применения – потенциальные искатели приключений, которые хотели бы хорошо провести время с девушкой на экскурсии, но пока еще не знают, как этого добиться. А вот зачем это им надо, для чего они готовы тратить свое драгоценное время, деньги и прочие нервы на организацию и проведение всего этого мероприятия, остается за скобками нашей модели.
ВНИМАНИЕ: модель НЕ ПРЕДНАЗНАЧЕНА для представительниц лучшей половины рода людского.. Зачем им суровая правда об аисте и капусте? Пусть живут в неведении спокойно и счастливо..
         Контекстная диаграмма модели представлена на рис. 2.1.

image

         ICOM: Как видно из рис. 2.1, входы, управление, выходы и механизмы модели следующие:
Входы (inputs):
            Девушки г. Уфы и окрестностей
            Карта Уфы и окрестностей
Управление (controls):
            Что люди скажут?
            Резервы свободного времени
            Материальные возможности
Выходы (outputs):
            Успешно проведенное мероприятие
            Благодарная девушка
Механизмы (mechanisms):
            Искатель приключений
            Транспорт
В начало    Дальше

3. Этапы большого пути

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

Допустим, девушка обнаружена, местонахождение ее установлено, что дальше? “Это же элементарно, Ватсон!” Нужно выбрать куда ее вести и объяснить ей, что деваться ей уже все равно некуда, хотя бы потому, что при всем богатстве выбора остальные – еще хуже.

Как говаривал незабвенный Дейл Карнеги, “Единственный способ заставить меня что-либо сделать – это убедить меня в том, что я сам этого хочу”. Так и тут: необходимо разъяснить девушке, что она сама хочет на экскурсию. А для этого время и место встречи должно удовлетворять определенным требованиям, кроме того, искатель приключений должен провести определенную работу над собой, чтобы представить себя в наиболее выгодном свете и тогда у него появятся реальные шансы на успех при переходе к практической организации мероприятия. Наконец, немаловажно также и красиво закончить мероприятие, то есть поблагодарить девушку и проводить ее домой.

В итоге получаем следующие пять основных этапов большого пути:
1. Выбрать девушку
2. Выбрать место и время встречи
3. Убедить девушку в неизбежности краха империализма
4. Организовать мероприятие
5. Провести заключительные операции

Указанные выше 5 этапов большого пути, в свою очередь, могут быть подразделены на отдельные операции, или шажочки, ведущие неугомонного искателя приключений по тернистому пути к заветной цели.. Движущая сила этого процесса вряд ли может вызвать сомнения даже у самых заядлых скептиков. Нравится это кому-то или нет, но искатели приключений были, есть и будут рыскать по поверхности планеты Земля по крайней мере до тех пор, пока на ней еще будут присутствовать хотя бы одна представительница привилегированного племени, которой и доступ в заведения с буквой «Ж» на входе открыт в любое время дня и ночи, и отсутствуют особые ограничения на выбор интерфейса и пользователя, и в которую на стадии проектирования заложен глупый интерес к тем, кто их ищет, пуст и с обратным знаком (по направлению)… Чтобы долго не рассусоливать, обратимся к рис. 2.2, на котором выписаны как сами этапы, так и оставляющие их шажочки.

 image

      Как видно из рис. 2.2, каждый этап операции по установлению местонахождения, локализации и лишения способности к самостоятельному передвижению интересующего искателя приключений субъекта так же, в свою очередь, может быть подразделен на отдельные технологические операции. Например, где взять девушку? Ясно дело: в большой семье не щелкай клювом, и во время перемещения своего бренного тела от уютного кухонного стола к менее уютному рабочему столу и обратно проводи постоянный мониторинг всех встреченных по пути субъектов на предмет наличия соответствия выдуманным самим же искателем приключений чертам Идеала, который может водиться разве что в его почти здоровом воображении, но никак не на поверхности планеты Земля.. Что ж, в этом случае  поиск проводится из условия минимума отличий реального субъекта за нумером таким-то от вышеуказанного Идеала по некоторой наперед заданной норме.. Аналогичным образом могут быть детально описаны и остальные этапы большого пути, чему и посвящен следующий параграф нашего повествования.

      

4. Описание этапов большого пути

 

4.1. Выбор субъекта


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

image 

Рис. 3.1. Описание процесса выбора девушки (стандарт DFD)

         Желтым цветом на рис. 3.1 помечена внешняя сущность «Конкуренты». Очевидно, что классовая сущность персоналий, которые входят в это непривилегированное сообщество двуногих, мало чем отличается от сущности самого искателя приключений. В двух словах она может быть охарактеризована девизом «Вкусно поесть и….» туда.. На поиск приключений на собственные хвост и прочие части тела.. Однако случаи здоровой (а иногда и не очень) конкуренции являются отличительной чертой не только рыночного, но и самого что ни на есть социалистического общества, поскольку в любом наборе двуногих приматов, которым всегда открыта дверь в заведения с вывеской «М» на пороге (это не метро), завсегда можно выбрать как минимум двух претендентов на одно и то же, тем более если цели их при этом совпадают как по субъекту, их воплощающему, так и по перечню мероприятий, планируемых к осуществлению с этими самыми субъектами. 
         Процесс перехода субъекта из состояния «Знакомая девушка» в состояние «Понравившаяся девушка» в деталях описан на диаграмме (рис. 3.1) и в дальнейших пояснениях, по-видимому, уже не нуждается.

4.2. Выбор места и времени

          На рис. 3.2 дано описание процесса выбора места совершения прест.., то есть, проведения экскурсии. На дурацкие вопросы типа «А где взять карту Уфы и окрестностей» модель ответа не дает, потому как тем, кто задает такие детские вопросы, еще рано не только девушек на экскурсии водить, но и читать подобного рода наставления и справочники. Им бы еще молоко через соску из бутылочки и колыбельную на ночь.. 

image

Рис. 3.2. Описание процесса выбора места и  времени экскурсии

4.3 Как убедить девушку?


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

image 

Рис. 3.3. Описание процесса убеждения девушки

          На рис. 3.3 представлено детальное описание процесса убеждения понравившейся девушки (очевидно же, что убеждать в чем либо непонравившуюся девушку может только душевнобольной или представитель какого-нибудь меньшинства). На входе (слева) – понравившаяся девушка. Многие молодые искатели приключений с упорством, достойным лучшего применения, совершают одну и ту же ошибку: начинают процесс с самовосхваления.. Что с них взять? – Молодые.. Глупые.. Несутся на призрачный мираж выдуманного Идеала как мотыльки на огонь ничего не видя и не слыша.. Прыгают с высокого берега в глубокий омут своих неясных ощущений как безработные в Нью-Йорке с Бруклинского моста и бьются потом как муха об стекло в попытках словесного излияния своих не до конца осознанных чувств и стремлений..
         Больно интересно той же девушку слушать, как вы себя нахваливаете.. Ей это надо? – Вы сначала ей скажите, какая у нее кожа бархатистая, походка легкая, голос нежный, глаза лучистые, как ей идет платье сегодняшнее, какая у нее замечательная прическа и т.д. и т.п. И цветы.. И взгляд внимательный. И ладонь в ладони.. На эту тему песни петь можно долго. Единственное жесткое условие: не врать.. Потому как в этом вопросе: шаг вправо, шаг влево – побег, стреляют без предупреждения. Да у каждой девушки завсегда можно найти что-то такое, что можно показать, высветить, всесторонне рассмотреть и обсудить, не обращая внимания на ее попытки что-то там остановить и/или перевести разговор на другую тему. Уверяю вас: ни одна нормальная девушка равнодушно такие слова слушать все равно не сможет! Какая бы она там ни была.. Интерес к этому слушанию вложен в нее изначально, еще на стадии проектирования этой самой совершенной в мире конструкции, потому-то не слушать она просто не сможет, а если будет слушать, то все дальнейшее будет уже делом техники. Ваша же задача- вызвать интерес девушки к вам.. И вот на этой стадии уже можно заняться и саморекламой.. Незаметной.. Мягкой.. Ненавязчивой.. Задача в данном случае не в том, чтобы доказать, что именно вы – самый-самый-самый (это будет нужно сделать потом, попозже), а в том, что с вами сходить на экскурсию – можно.. Вы же не алкаш какой-нибудь.. И не наркоман.. И не бомж.. И вообще, очень правильный, культурный, интеллигентный, воспитанный, внимательный, заботливый, спокойный, надежный и т.д. и т.п. Но говорить об этом низзя! Пусть сама эти выводы делает.. А вы ей тут же – рассказ о достопримечательностях Уфы, - вот тут уже раскрывайтесь и отрывайтесь на всю катушку! И какой у нас город замечательный (плевать на фенол и толуол), и какая речка у нас, и какие памятники (кинотеатры, мосты, театры, парки и далее по расписанию), и как хорошо, что девушка живет именно в этом городе и вообще, вообще, вообще.  В процессе рассказа о городе выжидаете момент, когда девушка немного теряет бдительность.. (например, показалась ее маршрутка). Вот тут-то и пришло ваше время – назначаете дату, место и время. Все ее отговорки типа голова болит, времени нет выбрасываются в отсев (см. рис. 3.3). Если вы правильно соблюдете порядок выполнения отдельных операций, то никаких шансов у девушки уже просто не останется.   Только имейте совесть – не назначайте девушке свидание в полночь на кладбище.. Она ведь может и прийти.. Да знаю я, что нету у вас совести (сам такой), но у нас же цель такая: успешно проведенная экскурсия!

4.4. Организация мероприятия


         Ну, это уже вообще элементарно. Просто дело техники. Покупаете цветы или безделушку какую-нибудь (в зависимости от степени переполнения ваших карманов и бумажников) и… ждете под часами. Работа у вас такой. Не забудьте хорошо побриться, спрысните себя какой-нибудь вонючей жидкостью или там дезодорантом (запах для девушки тоже очень важен!), не поленитесь сбегать в парикмахерскую (искусство требует жертв), погладьте брюки, смените носки и т.д. и т.п. Выучите пару стишков, несколько песен, прочитайте последние новости, заучите наизусть имена каких-нибудь модных писателей и прочее, приготовьте пару-тройку детских анекдотов.. Девушки России – лучшие в мире! Если начнете ныть, что у вас денег мало (а у кого их много), то вспомните Жванецкого: "На трамвае прокатил, мороженым угостил – твоя!"

image 

Рис. 3.4. Описание процесса «Организация мероприятия»

4.5. Заключительные операции

          Если в процессе проведения мероприятия у вас появились какие-то неопределенные виды и туманные надежды на продолжение непонятно чего неизвестно куда и даже в том случае, если ничего такого не появилось, элементарные правила этикета требуют красивого завершения всего мероприятия. Что это означает? – См. рис. 3.5. Вы же провели время с девушкой, которая вам понравилась.. Она потратила свое личное драгоценное время, чтобы выслушать вас.. Сделать свои выводы. На предмет вашей перспективности/бесперспективности. Она же вам ничего такого все равно не скажет. Даже если вы – вообще по нулям. В смысле – бесперспективный.. Большинство нормальных девушек таких сажают на поводок. Чтобы, значит, прирученными были. Под рукой то есть.. Так.. На всякий пожарный случай. В хозяйстве пригодится. В парикмахерскую там отвезти, на вокзал проводить, по хозяйству помочь, - таким же только свистни – рады будут на задних лапках к ней бежать.. Как там у Владимира Леви? – Самое неинтересное для женщины существо – мужчина прирученный, предсказуемый, управляемый и т.д. и т.п.

image 

Рис. 3.5. Заключительные операции

6. Другая точка зрения


         Если вдруг изложенные выше материалы попадут в область досягаемости тех, для кого они не предназначены, дальнейшая судьба того, кто написал всю эту бредятину, становится весьма расплывчатой и неопределенной. Конечно, он может успеть прокричать на последок что-то типа «Не виноватая я, она сам пришла».. Однако сути дела это не изменит: результат будет предрешен, и суровые представительницы Верховного суда в строгих платьях (три пальца выше колена) вынесут свой вердикт, и судебные приставы-исполнительницы в коротких юбочках недрогнувшей рукою приведут приговор в исполнение..
         Что ж.. Чему быть – того не миновать.. Все мы по краю ходим. Все мы в этом мире – пилигримы.. И срок нашей очередной командировки на поверхность планеты Земля рано или поздно, но обязательно подойдет к своему заслуженному окончанию.. Или продолжению? Независимо от выбранного ответа, постараемся успеть пропеть напоследок еще одну песню, лебединую ль, соловьиную или просто кобе…, то есть IDEFиную..  

6.1. Смена модели

         В тексте стандарта IDEF0 (по крайней мере, в его англоязычном оригинале) говорится о том, что смена точки зрения (не говоря уже о цели моделирования) влечет за собой не просто кардинальную перестройку, а смену модели. То есть мы говорим уже о другой модели, вообще говоря, другого объекта. В учебных целях будет полезно рассмотреть конкретный пример смены точки зрения. Рассмотрим тот же самый процесс с кочки зрения девушки.
         Цель остается та же самая, но с точки зрения девушки вопросы будут формулироваться немного по-другому.
Где найти подходящего спутника?
Как убедить его в неизбежности мероприятия?
Как обеспечить личную безопасность?
Куда сходить?
Что с ним делать после мероприятия?
И т.д. и т.п.
         Цель: хорошо провести время на экскурсии вместе со спутником.
         Как читатели уже, видимо, догадались, автор модели и текста относится по общепринятой классификации к той части рода людского, которым на роду написано входить в помещения с буквой «М» на входе (не путать с Метро!), а вход в помещения с буквой «Ж» запрещен, и которым от рождения наложены определенные социальные ограничения на внешний облик, боевую раскраску и выбор формы одежды, зато нет особых ограничений на выбор форм социальной активности в поиске своего Идеала, в том числе, примитивным методом перебора. В этой связи процесс построения модели от лица «Ж» представляет определенные технические сложности и носит в связи с вышеуказанным печальным обстоятельством несколько умозрительный характер. Тем не менее.. Попытка – не пытка.. В такого рода ситуациях обычно сильно помогает моделирование с использованием метода аналогий. Многие из тех, кто обучался в технических вузах, хорошо знакомы с электромеханическими аналогиями, кто-то, возможно, вспомнит мембранную аналогию Прандтля, ниже же будет использована рыбалочная аналогия. Обоснование очень простое: не все кончали вузы, не все помнят это дело, зато уж рыбачить любят все или почти все. 
         Итак, где взять спутника и как его соблаз.. то есть убедить? Ну, вопрос где взять – не проблема. Вон их сколько бегает по улицам Уфы нашей, сколько их на работе крутится, да в той же сети тоже рыскают в поисках приключений на свои хвосты и прочие части тела. В общем, тут все ясно. Проблема основная не в этом. Проблема в том, чтобы карась клюнул. А для этого нужно провести серьезную подготовительную работу: подготовить снасти, насадку, выбрать наиболее удачные водоем и место на нем, а также время и технику лова. В Приложении 4 описаны некоторые детали (разведданные из зарубежных источников).

6.2. Основные процедуры


         Постараемся сейчас разбить процесс достижения поставленной цели на основные этапы. 
1. Подготовка к рыбалке.
2. Проведение рыбалки.
3. Отбор отловленных экземпляров
4. Проведение мероприятия
5. Принятие решения о дальнейшей судьбе спутника
         После некоторых размышлений можно прийти к выводу о том ,что проведение рыбалки и отбор выловленных экземпляров представляют собой две стороны одной и той же медали, стало быть, имеет смысл сократить число основных технологических операций до 4.
1. Подготовительные мероприятия 
2. Выбор спутника .
3. Проведение мероприятия
4. Оценка перспективности экземпляра
         Очевидно, что основное внимание должно быть уделено в первую очередь первым двум этапам. Именно на этой стадии закладывается успех всего мероприятия. Поскольку основной целью подопытного экземпляра является достижение желаемого результата без особых последствий для своей свободы по принципу «поматросил и бросил», основным контраргументом должно стать: прогулял? – Спасибо тебе за это… Спокойной ночи..  

6.3. Описание модели


         Контекстная диаграмма модели представлена на рис. 6.1.

image

Рис. 6.1. Контекстная диаграмма

         Если сравнить рис. 6.1 и 2.1, отличия будут налицо. Позволим себе привести дальнейшее описание модели без особых комментариев. Кому надо – и так поймет, а кто не поймет – так тому это и не надо.
         На рис. 6.2 показаны основные этапы на пути к поставленной цели:

image 

Рис. 6.2. Основные этапы

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

image

Рис. 6.3. Дерево модели

image

Рис. 6.4. Описание процесса подготовки

image

Рис. 6.5. Описание процесса выбора спутника

image

Рис. 6.6. Описание процесса проведения мероприятия

image

Рис. 6.7. Описание процесса оценки претендента

7. Заключение


         Были рассмотрены две различные модели одного и того же процесса – экскурсионной прогулки девушки с молодым человеком по памятным местам славного города Уфы. Первая модель составлена с точки зрения молодого человека, а вторая – с точки зрения девушки. Легко видеть, что получены разные модели одного и того же процесса, хотя цели в обоих случаях были сформулированы почти одинаково – устроить прогулку. Это и неудивительно: было бы странно, если бы эти модели не отличались друг от друга. Модели имеют и различную область применения: если первая явным образом не предназначена для молодых девушек, то вторую не рекомендуется читать молодым и горячим искателям приключений. Зачем им это знать? Не лучше ли жить и действовать по принципу: война план покажет?… По крайней мере, в молодости, когда все еще впереди, - и глупости, и ошибки, и шишки на лбу и сердечные раны.. И жизнь твоя еще не поделена на две неравные половины: до и после рождения детей, и алименты ты пока еще не платишь, и живешь у родителей, не задумываясь о всяких дурацких проблемах типа крыши над головой и/или способах мирного сосуществования двух поколений, и девушки кругом тебе улыбаются, и даже небо сегодня синее-синее.. 
         Продолжу в понедельник, если начальство к стенке не припрет..

Автор Еникеев Ф.  

Оригинал статьи: http://sancase.narod.ru/Articles/OnOna.htm

Ресурс для начинающих бизнес-инженеров

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